Bug#959024: Problems with uscan'ing on github from tracker.debian.org

[Sergey B Kirpichev]

Package: tracker.debian.org
Severity: important

Right now in https://tracker.debian.org/pkg/auto-07p I see:
-->8--
Problems while searching for a new upstream version

uscan had problems while searching for a new upstream version:

In watchfile debian/watch, reading webpage
  https://github.com/auto-07p/auto-07p/releases failed: 429 too many
  requests
-->8--

Set severity important to reflect the checker status (high).

Bug#958277: simple-cdd: Resulting Install CD asks for questions answered in the profiles/NAME.x files

[Vagrant Cascadian]

On 2020-04-28, Buck wrote:
> This is not clear.  It sounds like a riddle.  Please provide examples of 
> usage of each.

What is not clear? What is a riddle? Examples of usage of each of what?

I will admit, I am feeling the same way about these bug reports from
this side of the computer screen. :P


>>> It would be helpful if you could provide your proposed profile in
>>> more detail. 
>
> I will, now that I know you want this.  But first in this message and
> your next reply, I want to eliminate usage errors as the problem.
> Then we can move into the details of the profile.

Yes, it could have saved a *lot* of back and forth to provide those up
front.

It is much easier to explain specific details that demonstrate specific
issues and concepts than speak about this sort of thing in general...


>> If you want to override parts of the "default" profile, you also need
>> ~/my-simple-cdd/profiles/default.* as well. The "default" profile is
>> always included, and for questions asked very early in debian-installer,
>> the only way to preseed some questions using simple-cdd.
>
> Wait wait whoah whoah.  The docs I've been reading for weeks don't
> sound like this at all.  I'm going to explain what I've been lead to
> believe.  You will hopefully tell me *specifically* how I am wrong,
> and suggest correct usage instead.

What docs are you referring to?

From the README:

  Default Profile

  the profile named "default" is special, because it always gets installed.

  modify the profile/default.* files with care, as simple-cdd relies upon the
  default profile working in certain ways ...


> My objective is to build a QEMU image of an installer that requires
> zero (ZERO) user interaction, and can actually be run headless,
> because it knows the answers ahead of time.  Then I want this VM to
> automatically run a script after Debian is install, and this script
> pulls from a private Git repo, and runs another script from that repo.
> That's the objective.

It's certainly possible, as long as all the packages you install support
debconf preseeding correctly.

The "test" profile attempts to automate everything in this way, and
might be a good example of the kinds of things you may need for a fully
automated install.

It's actually used as a profile to test the other profiles with minimal
interaction, and is meant to simply be added to the profiles to automate
testing a profile:

  simple-cdd --profiles x-basic,ltsp,router,test --auto-profiles test,router

Should include all four profiles (plus the default profile) on the
installer image, and then automatically select the test and router
profiles without interaction.

  simple-cdd --profiles x-basic,ltsp,router,test

Should generate an image with the same profiles as above, but prompt for
which you want to use at installation time (obviously not your desired
use-case, but I include it for the clarification of the difference
between --profiles and --auto-profiles).


> I've been lead to believe that to accomplish this, I need a
> custom.preseed file that answers all of the important questions.  And
> I need a custom.postinst that is a BASH script.

Not necessarily bash, most likely /bin/sh, possibly whatever #! you put
in your script. Though it's been a long time since I've looked, it might
specifically require #!/bin/sh...

The .postinst scripts are really just for quick hacks that can't be
handled with preseeding.


> And these must be the only files read by build-simple-cdd, and they go
> in profiles/ under the directory I run build-simple-cdd from (which is
> ~/my-simple-cdd).
...
> I've been lead to believe that if I put custom.preseed and
> custom.postinst into a profiles/ directory under ~/my-simple-cdd, and
> I run `build-simple-cdd --profiles custom` from within
> ~/my-simple-cdd, then the custom profile will be read.  The
> implication from the docs is that *only* the custom profile will be
> read if I am using `--profiles custom`.

I don't understand where you get this impression from.


> But when I run with `--profiles custom`, I get an image, which I run
> in QEMU and I see a normal default Debian installer that asks me if I
> want graphical vs text, etc. and

The default profile attempts to answer many debconf questions, but may
need updates to reflect new questions in debian-installer or installed
packages. It hasn't been tested by me since the release of buster...


> then asks me to choose a language and I know I (think I) put that in
> my custom.preseed file.

Language selection is addressed in the README in the "Language and
Country Selection" heading. It's one of those special configurations.

There's also some debian-installer documentation the briefly touches on
what questions can be answered with which methods of preseeding:

  https://www.debian.org/releases/stable/amd64/apbs01.en.html

There are a lot of other things documented in the adjacent
chapters. It's pretty much what simple-cdd is designed to facilitate, as
a thin layer on top of d

Bug#959023: cgmanager: does not work in cgroup2 / unified hierarchy

[Ryutaroh Matsumoto]

Package: cgmanager
Version: 0.41-2+b1
Severity: normal
Tags: wontfix
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2

Dear Maintainer,

When cgmanager was implemented, the cgroup2 / unified hierarchy did not exist.
So, cgmanager does not work in the cgroup2 / unified hierarchy, as

root@bullseye-qemu:/usr/share/cgmanager/tests# cgm ping
Failed opening dbus connection: org.freedesktop.DBus.Error.FileNotFound: Failed 
to connect to socket /sys/fs/cgroup/cgmanager/sock: No such file or directory
root@bullseye-qemu:/usr/share/cgmanager/tests# systemctl status cgmanager
● cgmanager.service - Cgroup management daemon
 Loaded: loaded (/lib/systemd/system/cgmanager.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Tue 2020-04-28 15:25:48 JST; 1min 
56s ago
Process: 1591 ExecStart=/sbin/cgmanager -m name=systemd (code=killed, 
signal=ABRT)
   Main PID: 1591 (code=killed, signal=ABRT)
 IP: 0B in, 0B out
CPU: 9ms

Apr 28 15:25:48 bullseye-qemu systemd[1]: cgmanager.service: Scheduled restart 
job, restart counter is at 9.
Apr 28 15:25:48 bullseye-qemu systemd[1]: Stopped Cgroup management daemon.
Apr 28 15:25:48 bullseye-qemu systemd[1]: cgmanager.service: Start request 
repeated too quickly.
Apr 28 15:25:48 bullseye-qemu systemd[1]: cgmanager.service: Failed with result 
'signal'.
Apr 28 15:25:48 bullseye-qemu systemd[1]: Failed to start Cgroup management 
daemon.

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.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 cgmanager depends on:
ii  libc6  2.30-4
ii  libcgmanager0  0.41-2+b1
ii  libdbus-1-31.12.16-2
ii  libnih-dbus1   1.0.3-10+b5
ii  libnih11.0.3-10+b5

cgmanager recommends no packages.

cgmanager suggests no packages.

-- no debconf information

Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy

[Ryutaroh Matsumoto]

Package: cgroup-tools
Version: 0.41-10
Severity: normal
Tags: wontfix
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2

Dear Maintainer,

It does not work in the cgroup2 / unified hierarchy. It gives

# lssubsys
# lscgroup
cgroups can't be listed: Cgroup is not mounted

Best regards, Ryutaroh Matsumoto


-- Package-specific info:

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.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 cgroup-tools depends on:
ii  libc6   2.30-4
ii  libcgroup1  0.41-10

cgroup-tools recommends no packages.

cgroup-tools suggests no packages.

-- no debconf information

Bug#959021: cgroupfs-mount: does not work in cgroup2 / unified hierarchy

[Ryutaroh Matsumoto]

Package: cgroupfs-mount
Version: 1.4
Severity: normal
Tags: wontfix
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2


Dear Maintainer,

When Debian uses the cgroup2 / unified hierarchy, cgroupfs-mount gives

# /usr/bin/cgroupfs-mount 
mount: /sys/fs/cgroup/cpuset: cgroup already mounted or mount point busy.
mount: /sys/fs/cgroup/cpu: cgroup already mounted or mount point busy.
mount: /sys/fs/cgroup/blkio: cgroup already mounted on /sys/fs/cgroup/cpuacct.
mount: /sys/fs/cgroup/memory: cgroup already mounted on /sys/fs/cgroup/cpuacct.
mount: /sys/fs/cgroup/pids: cgroup already mounted on /sys/fs/cgroup/cpuacct.
# /usr/bin/cgroupfs-umount 
rmdir: failed to remove 'init.scope': Device or resource busy
rmdir: failed to remove 'system.slice': Device or resource busy
rmdir: failed to remove 'user.slice': Device or resource busy

Nobody may expect it to work in the cgroup2 / unified hierarchy...
This package is recommended by docker.io.

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.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 cgroupfs-mount depends on:
ii  lsb-base  11.1.0

cgroupfs-mount recommends no packages.

cgroupfs-mount suggests no packages.

-- no debconf information

Bug#958929: git: Regression due to CVE-2020-11008 fix

[Jonathan Nieder]

severity 958929 important
tags 958929 + upstream
forwarded 958929 https://lore.kernel.org/git/20200428052510.ga201...@google.com/
quit

Stefan Tauner wrote:

> the vulnerability in CVE-2020-11008 is related to the handling
> of credential helpers in git. In Buster this has been fixed in
> 1:2.20.1-2+deb10u3. This broke my existing configuration where
> repositories have credential.helper=store set. This is
> documented in /usr/share/man/man1/git-credential-store.1.gz
> and other files from git, git-doc etc.
> I am unsure how to proceed... is this helper now unsupported?
> Is this a simple regression that should be fixed?

The latter --- it's a simple regression.  Let's take this upstream.

Thanks,
Jonathan

Bug#958455: From a minimum installation of Sid, metapackage enlightenment installs neither X nor a login manager. Debian Sid, 15 april 2020

[Ross Vandegrift]

On Thu, Apr 23, 2020 at 07:06:29AM +, Daniel Tourde wrote:
> Now I am not really sure I really grasp what you mean with 'Suggests'. Would
> it be a message on the console saying "Well, if you need a login manager
> please install now package 'x-display-manager'? That's an option

Well, not quite.  By default apt will just tell you that a package you're
installing has suggested another.  For example it might look like this:

  $ sudo apt install enlightenment
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following additional packages will be installed:
... enlightenment ... (lots of stuff)
  Suggested packages:
... x-display-manager ... (potentially lots of stuff)
  The following NEW packages will be installed:
... enlightenment ... (lots of other stuff)
  0 upgraded, 278 newly installed, 0 to remove and 0 not upgraded.
  Need to get 158 MB of archives.
  After this operation, 623 MB of additional disk space will be used.

You would need to notice that x-display-manager is in the Suggested list, and
then install it yourself.  So I don't think this will really help.

Alternatively, you can run `apt install --install-suggests` - but you need to
know that you want the suggestions first.

> The other option is to have a 'enlightenment-desktop' metapackage which
> install enlightenment and a simple login-manager (even though it is not
> EFL-based).

Without a natural choice (ie, EFL-based or something), I don't want to add a
metapackage just for this.  A standalone window manager will usually need
additional pieces anyhow - I don't think I can effectively curate that list for
all users.

Ross

Bug#752884: quarry: textures for board are in fact solid colours

[Ian Zimmerman]

These files are correct in the source tree on github:

https://github.com/elmindreda/quarry

I don't know if the same is true for the original source from which
the github project was imported.

Ian

Bug#959020: upgrade-reports: Soundcard not detected after upgrading to kernel 5.5.0-2-amd64 in testing

[Dennis]

Package: upgrade-reports
Severity: normal

Dear Maintainer,

since updating to kernel 5.5.0-2-amd64 #1 SMP Debian 5.5.17-1 (2020-04-15) 
x86_64 GNU/Linux my audio card is not
detected anymore. With kernel 5.4 the audio card was working and playing sound.

This is my card:
#sudo lspci -vv | grep -i audio
00:1f.3 Multimedia audio controller: Intel Corporation Smart Sound Technology 
Audio Controller (rev 30)
Subsystem: Hewlett-Packard Company Smart Sound Technology Audio 
Controller
Kernel driver in use: sof-audio-pci

Driver does not load:
#sudo dmesg | grep -i audio
[   15.202408] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[   15.202521] sof-audio-pci :00:1f.3: Digital mics found on Skylake+ 
platform, using SOF driver
[   15.202530] sof-audio-pci :00:1f.3: enabling device ( -> 0002)
[   15.202684] sof-audio-pci :00:1f.3: warning: No matching ASoC machine 
driver found
[   15.203611] sof-audio-pci :00:1f.3: DSP detected with PCI 
class/subclass/prog-if 0x040100
[   15.203799] sof-audio-pci :00:1f.3: use msi interrupt mode
[   15.204308] sof-audio-pci :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   15.208666] sof-audio-pci :00:1f.3: hda codecs found, mask 5
[   15.208668] sof-audio-pci :00:1f.3: using HDA machine driver 
skl_hda_dsp_generic now
[   15.224546] sof-audio-pci :00:1f.3: firmware: failed to load 
intel/sof/sof-icl.ri (-2)
[   15.224594] sof-audio-pci :00:1f.3: Direct firmware load for 
intel/sof/sof-icl.ri failed with error -2
[   15.224596] sof-audio-pci :00:1f.3: error: request firmware 
intel/sof/sof-icl.ri failed err: -2
[   15.224641] sof-audio-pci :00:1f.3: error: failed to load DSP firmware -2
[   15.225529] sof-audio-pci :00:1f.3: error: sof_probe_work failed err: -2

Any help is appreciated, please let me know if you need further details.
Best -Dennis

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

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

Bug#958948: (no subject)

[Buck]

Maybe.  I usually remember to delete tmp/ but maybe I forgot.

This is confirmed working now.

> You're not receiving the replies? You should be able to reply to
> bugnum...@bugs.debian.org.

That doesn't work under this setup but I did find a way to reply using 
reportbug, thank you.

Bug#958277: (no subject)

[Buck]

This is not clear.  It sounds like a riddle.  Please provide examples of usage 
of each.

>> It would be helpful if you could provide your proposed profile in
>> more detail. 

I will, now that I know you want this.  But first in this message and your next 
reply, I want to eliminate usage errors as the problem.  Then we can move into 
the details of the profile.

> If you want to override parts of the "default" profile, you also need
> ~/my-simple-cdd/profiles/default.* as well. The "default" profile is
> always included, and for questions asked very early in debian-installer,
> the only way to preseed some questions using simple-cdd.

Wait wait whoah whoah.  The docs I've been reading for weeks don't sound like 
this at all.  I'm going to explain what I've been lead to believe.  You will 
hopefully tell me *specifically* how I am wrong, and suggest correct usage 
instead.

My objective is to build a QEMU image of an installer that requires zero (ZERO) 
user interaction, and can actually be run headless, because it knows the 
answers ahead of time.  Then I want this VM to automatically run a script after 
Debian is install, and this script pulls from a private Git repo, and runs 
another script from that repo.  That's the objective.

I've been lead to believe that to accomplish this, I need a custom.preseed file 
that answers all of the important questions.  And I need a custom.postinst that 
is a BASH script.  And these must be the only files read by build-simple-cdd, 
and they go in profiles/ under the directory I run build-simple-cdd from (which 
is ~/my-simple-cdd).

I've been lead to believe that if I put custom.preseed and custom.postinst into 
a profiles/ directory under ~/my-simple-cdd, and I run `build-simple-cdd 
--profiles custom` from within ~/my-simple-cdd, then the custom profile will be 
read.  The implication from the docs is that *only* the custom profile will be 
read if I am using `--profiles custom`.

But when I run with `--profiles custom`, I get an image, which I run in QEMU 
and I see a  normal default Debian installer that asks me if I want graphical 
vs text, etc. and then asks me to choose a language and I know I (think I) put 
that in my custom.preseed file.

>  That said, not including or aggressively overriding contents in the default 
> profile is
> possible to break how simple-cdd works, so be selective in what you
> override.

That's not helpful!  Please point me to the docs that explain the precise 
interplay between default and custom profiles, including a specific list of 
what I must not override!

> In general, I've tried to make the default profile not too
> intrusive, so it shouldn't need to be overridden in most cases...

Thank you, but the docs suggested to me that it must be completely overridden, 
100%, as in default vs custom is either/or.  So I'll need details of what is 
"most cases" vs other cases, etc.

>> If you want to override the built-in profiles, you need to create
>> replacement files (e.g. profiles/default.preseed,
>> profiles/default.*), though I would generally recommend providing
>> additional profiles rather than overriding the default profiles.

Okay but again, please point to docs that give a detailed explanation of how 
custom and default profiles interact.

> The custom.preseed file may not be loaded till later in the process; it
> depends on which questions you're thinking are answered by it. There is
> a question during the install that asks which simple-cdd profiles to
> load; any pquestions asked before that obviously can't be preseeded.

Okay and I see why you need my exact files and I will send them.  But first 
please tell me this: is my objective of a 100% non-interactive QEMU image of a 
Debian installer possible with simple-cdd or will there always be some 
requirement for user interaction?

> Where do you expect $default_desktop to be defined?

That was essentially the question I was asking you in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958276 but I think it does 
not matter because that error was caused by me removing the default profiles.  
I did not expect to ever see $default_desktop and I do not want my installer to 
require a desktop, and it does not require any GUI or UI because it must 
require no user interaction.

> Are you running from ~ or running from ~/my-simple-cdd ?

>From ~/my-simple-cdd when I got this bug.

> you can just specify one of the profiles in
> /usr/share/simple-cdd/profiles, preferably in a directory that does not
> contain any "profiles" directory:

That was the opposite of what I am trying to test.  I am asking you to please 
recommend a default set of profile files I can download, put into 
~/my-simple-cdd/profiles, and run with `build-simple-cdd --profiles thatone` so 
that I can test if the problem is my specific profiles files, or the process of 
loading a custom profile.  Once I understand correct usage, and I test running 
with a custom profile set (in ~/my-simple-cdd/profiles) *then

Bug#959019: lintian: True or false positive for uses-dpkg-database-directly? Checking for a running dpkg by testing for locks on /var/lib/dpkg/lock

[Axel Beckert]

Package: lintian
Version: 2.68.0

Hi,

lintian on aptitude-robot emits (beyond others) these two tags of which
I'm not sure if they're true or false positives:

W: aptitude-robot: uses-dpkg-database-directly etc/init.d/aptitude-robot
W: aptitude-robot: uses-dpkg-database-directly usr/sbin/aptitude-robot-session

Actually it is wrong that these scripts access dpkg's _database_. They
only access respectively check for other accesses of /var/lib/dpkg/lock:

[…]/aptitude-robot → git grep /var/lib/dpkg
aptitude-robot-session:if fuser -s /var/lib/dpkg/lock ; then
debian/init.d:if fuser -s /var/lib/dpkg/lock ; then
[…]/aptitude-robot →

So my question (mostly to Guillem, X-Debbugs-CC'ed): Does this file
really belong to the "internal interface", "the entire dpkg database,
its layout and files"?

If yes, how do I check with dpkg's tools if dpkg's database is currently
locked or more generally in use? (And maybe a hint in the lintian tag
description would be nice. :-)

If no, lintian should continue check for "/var/lib/dpkg" in code, but
ignore all occurrences of "/var/lib/dpkg/lock" before emitting the tag.

Depending on the answer, please either close this "bug report" or adjust
the severity accordingly. TIA!

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils 2.34-6
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.45-1
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.112-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-10
ii  t1utils  1.41-4
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.34-6
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#958982: Fwd: Slow disk resize during boot on VMs with Debian 10 Buster images

[Theodore Y. Ts'o]

On Mon, Apr 27, 2020 at 09:01:56AM -0700, Igor Dvorzhak wrote:
> Package: e2fsprogs
> 
> resize2fs takes extra 90 seconds to resize 2TB boot disk during boot on
> Debian 10 than on Debian 9.
> 
> Note that time to create/provision VM instance (gcloud compute instances
> create ...) is the same (around 10 seconds) for both Debian 9 and Debian
> 10, but time to successful SSH is different (see while loop in my test
> command) - this is when VM is actually booted, not when gcloud instances
> create ... returns.

How the root file system is resized on Debian 9 and Debian 10 are very
different, and the difference seems to stem from Google's initramfs scripts.

In Debian 9, the root file system is resized after it is mounted.  We
can see this in the kernel messages.  In Debian 10, the root file
system is resized in the initramfs, and the root file system isn't
even mounted until 168 seconds after the systme is booted.

There are two scripts in Debian 10's initramfs on GCE, and they are
both marked "Copyright 2018 Google Inc.", and they
scripts/expand-lib.sh, and local-premount/expand_rootfs.  These
scripts are not in stock Debian's /usr/share/initramfs-tools
directory, so they are a Google special.

What the bash function resize_filesystem in scripts/expand-lib.sh does
is that it runs e2fsck on the root partition, and then does an
off-line resize.  It is the off-line resize which is appearing to take
a long time.

Looking at the off-line resize, it does do a bit more I/O.  In
particuar, it's going to do 16k or so extra 4k random writes which
aren't done with an on-line resize.  That shouldn't translate to PD
taking 90 seconds to do those writes, though!

That being said, the differences do appear to be in how Google to do
the file system resizing before the file system is mounted.  I'm not
sure why someone decided it would be a good idea to do an off-line
resize in Debian 10, but that appears to be a Google decision, not a
Debian decision.

> I also tested this with the newer 1.45.5-2 e2fsprogs version on Debian 10
> (updated from buster-backports repo) and Ubuntu 20.04 LTS. But only Debian
> 10 VM still have this regression, Ubuntu 20.04 LTS doesn't have it, so it
> seems that this is a Debian 10-specific issue.
> 
> Are there any configuration options that allow to restore Debian 9 behavior
> in Debian 10 for resize2fs during VM boot time?

No, it looks like it would require making some changes to the GCE's
init scripts in the Debian 10 image.   I suspect it means needing to dig around 
at:

https://github.com/GoogleCloudPlatform/compute-image-packages

Cheers,

- Ted

Bug#959018: Domain name queried during installation is not used

[martin f krafft]

Package: debian-installer
Version: 20190702+deb10u3
Severity: normal
Tags: d-i

During installation, I have to provide netcfg/domain. However, when the
installation has finished and the system is booted, that domain name 
is not actually put in place anywhere. If I run

  # grep -r 'example\.org' /etc /var

then the only reference I find is in /var/log/installer. At the very 
least, I'd expect the domain name to end up in /etc/hosts to ensure 
that `hostname --fqdn` works post-install. Whether to put it into 
/etc/hostname is another question…

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

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


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


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

Bug#955807: transition: netcdf

[Sebastiaan Couwenberg]

On 4/27/20 5:57 AM, Sebastiaan Couwenberg wrote:
> On 4/25/20 9:09 PM, Sebastian Ramacher wrote:
>> On 2020-04-25 17:23:03, Sebastiaan Couwenberg wrote:
>>> vtk7 (7.1.1+dfsg2-3) was just uploaded and it FTBFS as reported in #958817.
>>>
>>> Since it's a key package the RC bug won't trigger autoremoval of it and
>>> its rdeps like lammps.
>>>
>>> If #958817 is not fixed soon, rebuilds in testing-proposed-updates like
>>> for hdf5 may be required to enable migration of netcdf and the affected
>>> packages.
>>
>> I don't think this will be necessary. libnetcdf15 and libnetcdf18 are
>> co-installable so netcdf should be smooth-updatable.
> 
> netcdf and most rdeps have migrated to testing. eccodes & vtk7 should
> migrated tomorrow. gdal on armel & mips* still need to migrate as well.

eccodes & vtk7 have migrated. gdal on armel & mips* is still TODO.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#958991: RFS: setzer/0.2.4-1 [ITP] -- simple yet full-featured LaTeX editor

[Boyuan Yang]

Hi,

Quick comment: at least files under data/resources/gtksourceview/language-
specs has different license information than what currently written in
debian/copyright. Please review copyright information again.

-- 
Best,
Boyuan Yang

在 2020-04-27星期一的 18:13 +，Stephan Lachnit写道：
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "setzer"
> 
>Package name: setzer
>Version : 0.2.4-1
>Upstream Author : cvfosa 
>URL : https://www.cvfosa.org/setzer/
>License : GPL-3.0+
>Vcs : https://salsa.debian.org/debian/setzer
>Section : tex
> 
> It builds those binary packages:
> 
>   setzer - simple yet full-featured LaTeX editor
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/setzer
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/setzer/setzer_0.2.4-1.dsc
> 
> Changes since the last upload:
> 
>* Initial release. (Closes: #954847)
> 
> 
> Setzer is an amazing LaTeX Editor with Gnome looks written in Python. It
> features a dark mode, many shortcuts for common symbols used in Latex, a
> document creation wizard and more.
> The only real build dependency is Meson, the runtime dependencies are also
> pretty light: Python GLib bindings and python3-xdg.
> I already had some contact with the developer to wire up support for Meson,
> and he responds very quickly to issues and PRs.
> 
> I don't mind maintaining it in a team, if someone is interested in that.
> 
> Cheers,
> Stephan
> 


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

Bug#959017: ITP: libtest-json-schema-acceptance-perl -- Acceptance testing for JSON-Schema based validators like JSON::Schema

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : libtest-json-schema-acceptance-perl
  Version : 0.990+ds
  Upstream Author : Ben Hutton 
* URL : https://metacpan.org/release/Test-JSON-Schema-Acceptance
* License : Expat
  Programming Lang: Perl
  Description : Acceptance testing for JSON-Schema based validators
like JSON::Schema
 This module allows the JSON Schema Test Suite tests to be used in Perl to
 test a module that implements json-schema. These are the same tests
that many
 modules (libraries, plugins, packages, etc.) use to confirm support of
 json-schema. Using this module to confirm support gives assurance of
 interoperability with other modules that run the same tests in different
 languages.

Remark: This package is to be maintained with Debian Perl Group at
  
https://salsa.debian.org/perl-team/modules/packages/libtest-json-schema-acceptance-perl

Bug#959016: lists.debian.org: New mailing list request: debian-bazel

[Olek Wojnar]

Package: lists.debian.org
Severity: wishlist

Dear listmasters,

Please consider creating a new list for the packaging of the Bazel build
system in Debian. This project has attracted recent attention due to the
Bazel dependency for tensorflow and tensorflow's extensive use in the
scientific and medical communities. Debian's continued inability to package
tensorflow was a high-priority issue during the recent biohackathon where
we identified impediments to effective COVID-19 research. 

We currently have a half-dozen people interested in working on the build
system and, once it becomes available, people wanting to build tensorflow
and other packages that build with Bazel will need an easy way to contact
the maintainers. The maintainers will also need a convenient way to
coordinate with each other.

Please let me know if you have any questions about my request, I'll be happy
to discuss further!

List name: debian-bazel
Rationale: Please see above
Short Description: Debian Bazel Build System Maintainers
Long Description: Discussions related to Debian packaging of Bazel, a build
 system developed and used by Google, as well as building of Bazel packages in
 Debian. Please share bug reports, porting issues, questions, or patches here.
Category: Developers (devel)
Subscription Policy: Open
Post Policy: Open
Web Archive: Yes

Bug#959015: Add symbolic link for modules in debian/build_modules to node_modules

[Pirate Praveen]

Package: pkg-js-tools
Version: 0.9.32
Severity: wishlist

Similar to components, I think pkg-js-tools should add symbolic link 
for debian/build_modules too.

Bug#955469: initramfs-tools-core: Enable zstandard support

[Ben Hutchings]

On Wed, 01 Apr 2020 09:05:22 +0200 Norbert Lange  wrote:
> Package: initramfs-tools-core
> Version: 0.136
> Severity: wishlist
> Tags: patch
> 
> Hello,
> 
> there are Kernelpatches for zstandard initramfs support
> available for several years, and will hopefully accepted
> upstream soon.

If the kernel doesn't yet support it, I'm not sure what the point of
supporting it in initramfs-tools is.

> Please enable support for this compression.
> 
> The patch should be simple enough, I chosen to try zstd
> as first decompressor because it supports a whole
> range of formats on debian.

> diff -burN initramfs-tools.org/conf/initramfs.conf 
> initramfs-tools/conf/initramfs.conf
> --- initramfs-tools.org/conf/initramfs.conf   2019-02-06 00:55:47.0 
> +0100
> +++ initramfs-tools/conf/initramfs.conf   2020-03-31 18:38:48.558687968 
> +0200
> @@ -38,7 +38,7 @@
>  KEYMAP=n
> 
>  #
> -# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | xz ]
> +# COMPRESS: [ gzip | bzip2 | lz4 | lzma | lzop | zstd | xz ]

Aside from gzip (the default), this list is sorted alphabetically.  So
zstd belongs at the end.

>  #
> 
>  COMPRESS=gzip
> diff -burN initramfs-tools.org/mkinitramfs initramfs-tools/mkinitramfs
> --- initramfs-tools.org/mkinitramfs   2020-01-18 19:36:00.0 +0100
> +++ initramfs-tools/mkinitramfs   2020-03-31 18:31:31.046107765 +0200
> @@ -185,6 +185,7 @@
>   fi
>   ;;
>  lz4) compress="lz4 -9 -l" ;;
> +zstd)compress="zstd -19" ;;
>  xz)  compress="xz --check=crc32"
>   # If we're not doing a reproducible build, enable multithreading
>   test -z "${SOURCE_DATE_EPOCH}" && compress="$compress --threads=0"
> diff -burN initramfs-tools.org/unmkinitramfs initramfs-tools/unmkinitramfs
> --- initramfs-tools.org/unmkinitramfs 2019-07-31 16:25:58.0 +0200
> +++ initramfs-tools/unmkinitramfs 2020-03-31 18:36:36.821308275 +0200
> @@ -29,7 +29,9 @@
>   dir="$2"
>   shift 2
> 
> - if gzip -t "$archive" >/dev/null 2>&1 ; then
> + if zstd -q -c -t "$archive" >/dev/null 2>&1 ; then
> + zstd -q -c -d "$archive"
> + elif gzip -t "$archive" >/dev/null 2>&1 ; then
>   gzip -c -d "$archive"
>   elif xzcat -t "$archive" >/dev/null 2>&1 ; then
>   xzcat "$archive"

gzip should be checked first as it's most likely to be the actual
compression used.  Aside from that, I don't think the order matters
here.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.




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

Bug#929685: sudo apt install default-jre/jdk

[Seth]

Package: default-jdk
Version: openjdk-11-jre
Followup-For: Bug #929685

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
 - I was installing default-jre/jdk on my 32-bit ARM machine and it refused 
to install
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 - sudo apt install default-jre
   * What was the outcome of this action?
 Setting up ca-certificates-java (20190405) ...
 head: cannot open '/etc/ssl/certs/java/cacerts' for reading: No such file 
or directory
 Adding debian:ISRG_Root_X1.pem
 Adding debian:EC-ACC.pem
 Adding debian:Staat_der_Nederlanden_EV_Root_CA.pem
 Adding debian:thawte_Primary_Root_CA.pem
 Adding debian:GeoTrust_Universal_CA_2.pem
 Adding debian:GeoTrust_Primary_Certification_Authority_-_G3.pem
 Adding debian:thawte_Primary_Root_CA_-_G2.pem
 Adding debian:Sonera_Class_2_Root_CA.pem
 Adding debian:IdenTrust_Commercial_Root_CA_1.pem
 Adding debian:SSL.com_Root_Certification_Authority_RSA.pem
 Adding debian:ePKI_Root_Certification_Authority.pem
 Adding 
debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem
 #
 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  SIGILL (0x4) at pc=0xb40da688, pid=2392, tid=2398
 #
 # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 
11.0.7+10-post-Debian-3deb10u1)
 # Java VM: OpenJDK Server VM (11.0.7+10-post-Debian-3deb10u1, mixed mode, 
serial gc, linux-)
 # Problematic frame:
 # J 46% c2 
sun.security.provider.X509Factory.readOneBlock(Ljava/io/InputStream;)[B 
java.base@11.0.7 (447 bytes) @ 0xb40da688 [0xb40da440+0x0248]
 #
 # No core dump will be written. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again
 #
 # An error report file with more information is saved as:
 # //hs_err_pid2392.log
 Could not load hsdis-arm.so; library not loadable; PrintAssembly is 
disabled
 #
 # If you would like to submit a bug report, please visit:
 #   https://bugs.debian.org/openjdk-11
 #
 /var/lib/dpkg/info/ca-certificates-java.postinst: line 88:  2390 Done  
  find /etc/ssl/certs -name \*.pem
 2391   | while read filename; do
 alias=$(basename $filename .pem | tr A-Z a-z | tr -cs a-z0-9 _); 
alias=${alias%*_}; if [ -n "$FIXOLD" ]; then
 echo "-${alias}"; echo "-${alias}_pem";
 fi; echo "+${filename}";
 done
 2392 Aborted | java -Xmx64m -jar $JAR -storepass 
"$storepass"
 dpkg: error processing package ca-certificates-java (--configure):
 installed ca-certificates-java package post-installation script subprocess 
returned error exit status 134
 Processing triggers for fontconfig (2.13.1-2) ...
 Processing triggers for mime-support (3.62) ...
 Processing triggers for hicolor-icon-theme (0.17-2) ...
 Processing triggers for libc-bin (2.28-10) ...
 Processing triggers for man-db (2.8.5-2) ...
 Processing triggers for ca-certificates (20190110) ...
 Updating certificates in /etc/ssl/certs...
 0 added, 0 removed; done.
 Running hooks in /etc/ca-certificates/update.d...

 done.
 done.
 Errors were encountered while processing:
 ca-certificates-java
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 * What outcome did you expect instead?

 *** End of the template - remove these template lines ***


 -- System Information:
 Debian Release: 10.3
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable')
 Architecture: armhf (armv7l)

 Kernel: Linux 4.19.94-ti-r42 (SMP w/1 CPU core; PREEMPT)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)

 Versions of packages default-jdk depends on:
 pn  default-jdk-headless  
 pn  default-jre   
 pn  openjdk-11-jdk

 default-jdk recommends no packages.

 default-jdk suggests no packages.

Bug#959014: RFS: filezilla/3.39.0-2+deb10u1 [NMU, RC] -- Full-featured graphical FTP/FTPS/SFTP client

[Phil Wyett]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "filezilla".

 * Package name: filezilla
   Version : 3.39.0-2+deb10u1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla - Full-featured graphical FTP/FTPS/SFTP client
  filezilla-common - Architecture independent files for filezilla

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.39.0-2+deb10u1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * Added: 02_untrusted_search_path.patch - CVE-2019-5429. (Closes:
#928282)

===

Note: Package requires sponsor for stable updates upload.

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

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#959013: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME

[Phil Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnome-maps"

 * Package name: gnome-maps
   Version : 3.30.3.1-0+deb10u1
   Upstream Author : maps-l...@gnome.org
 * URL : https://wiki.gnome.org/Apps/Maps
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/gnome-team/gnome-maps
   Section : gnome

It builds those binary packages:

  gnome-maps - map application for GNOME

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

  https://mentors.debian.net/package/gnome-maps

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnome-maps/gnome-maps_3.30.3.1-0+deb10u1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * New upstream release
 - Make the shape layer renderer use the tile size specified in the
dynamic
   service file, fixing an issue with misaligned shape layer
(GeoJSON, GPX,
   KML) rendering with the new 512 pixel tile
 - Update Icelandic translation

===

Note: Package requires sponsor for stable updates upload.

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

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#955709: initramfs-tools: All LVM members of a Btrfs raid1 rootfs are not activated prior to btrfs device scan.

[Ben Hutchings]

On Sat, 04 Apr 2020 01:40:18 +0200 Samuel Progin  
wrote:
[...]
>* What led up to the situation?
> 1. A single Btrfs rootfs on the top of lvm is converted to a raid 1 array by 
> adding a device (logical volume in this case) and running a Btrfs balance 
> convert start.
> 2. # update-initramfs -u
> 3. # reboot
> 4. the reboot fails as the btrfs rootfs cannot be mounted, complaining that a 
> device is missing, and dropping to an initramfs shell. The second device is 
> missing as it is not yet active in lvm.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I created a script in /etc/initramfs-tools/scripts/local-top that activates 
> all LV with "lvm vgchange -ay" and chrooted and rebuilded with 
> update-initramfs -u
> 
>* What was the outcome of this action?
> The logical volumes are activated, and the btrfs rootfs volume is mounted 
> properly. The systems boots up.

I can see why this is going wrong, and I'm not sure quite how to fix
it.  We've historically tried to make the initramfs portable across
device changes, so that rather than recording device IDs we rely on the
kernel command line and /etc/fstab to tell us which devices are
needed[*].  But they only name one device for each filesystem.

I can think of several options:

1. initramfs-tools provides a way for btrfs (and similar filesystems)
   to tell it about any extra devices they need, and records those in
   the initramfs (by LVM path or UUID).  They are activated at boot in
   the same way as other devices.  Moving the / or /usr filesystem to a
   new LV or changing its UUID can require an initramfs rebuild.
   Hopefully this won't be too surprising.

2. initramfs-tools or lvm2 provides a way to name additional required
   devices or volume groups, on the kernel command line.  This could
   be done in addition to option 1, as a rescue mechanism.

3. lvm2 adds a configuration option to control which volume groups are
   activated at boot.  The default could be all volume groups, or the
   current behaviour.

I would welcome comments on these from other maintainers.

Ben.

[*] The hibernation/resume device is an exception to this, but
hibernation images won't work across a device change anyway.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.




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

Bug#959012: ITP: golang-github-moby-sys -- Library to parse mount info and mount filesystems

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: golang-github-moby-sys
  Version : 0.0~git20200320.6154f11-1
  Upstream Author : Kir Kolyshkin 
* URL : https://github.com/moby/sys
* License : Apache-2.0
  Programming Lang: Go
  Description : Library to parse mount info and mount filesystems

 It provides following Go libraries:
 .
  * github.com/moby/sys/mount
  * github.com/moby/sys/mountinfo

 Package is prepared at
 https://salsa.debian.org/go-team/packages/golang-github-moby-sys

Bug#959011: RFS: rumur/2020.04.26-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: rumur
   Version : 2020.04.26-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.04.26-1.dsc

Changes since the last upload:

   * New upstream release.

Regards,
Matthew

Bug#885195: [Pkg-electronics-devel] Bug#885195: geda-gaf: please migrate to guile-2.2

[Bdale Garbee]

Rob Browning  writes:

> Please try to migrate soon, and at this point, to guile-3.0 if possible.
> Otherwise we might need to consider removing the package from Debian.

As far as I'm concerned, you can feel free to remove geda-gaf from Debian.

I'm personally quite happily living on the fork that I've packaged of
lepton-eda.  Lepton-eda is very actively maintained and improved, and
while there's a recent new release of geda-gaf, I'm not likely to spend
any more time working on the geda-gaf packaging.

> Sometimes it's sufficient to just update the build dependency from say
> guile-2.0-dev to guile-3.0-dev and adjust some of the related versions
> in configure.ac (or configure.in).

This is absolutely not true for geda-gaf, the recent release still
demands guile-2.0.  If someone actually wants to fix geda-gaf to work
with guile-2.2 or later, my suggestion would be to look at how
lepton-eda fixed the scheme code in question.

Bdale


signature.asc
Description: PGP signature

Bug#453266: Il tuo ordine 6817681 e stato completato

[indirizzo]

Gentile cliente,

Il tuo ordine di acquisto stato comunicato all'esercente che provvederа ad 
evaderlo in base alle condizioni di vendita definite.
La conferma definitiva dell'acquisto la riceverai direttamente dall'esercente, 
che potrа confermarla o annullarla.

Dati del negozio
Codice Esercente: WEB_0045898265
Per scaricare i file da lei acquistati in formato digitale,
deve loggarsi a questo file : fattura.xls
Dati del pagamento
Data e ora:  4/28/2020   5:29:25 AM
Divisa: EUR
Importo: 34,00

Codice XPay attribuito all'ordine di pagamento: C885ORI293923562
Codice autorizzativo assegnato dal circuito di pagamento: 239834

Dati dell'acquirente
Circuito della carta: VISA
Indirizzo email dell'acquirente: 453...@bugs.debian.org


fattura_7.xls
Description: MS-Excel spreadsheet

Bug#959010: zytrax: no synthesizer plugins available, cannot produce a new track

[Daniel Kahn Gillmor]

Package: zytrax
Version: 0+git20190810-2
Severity: important

I installed zytrax and tried to follow http://zytrax.org/tutorial/ -- it
says:

 > press the Insert FX label at the bottom, on the rack section. This
 > will open a menu where you can select the scanned plugins.
 > 
 > The effect added should now appear on the rack. Make sure to select a
 > synth, or else no sound generation will happen.


But none of the effects appear to be "synth" effects, and it's unclear
how to get such a thing to become available.  I tried installing
zam-plugins, which put a bunch of .so files in /usr/lib/vst/, but they
weren't recognized by zytrax.

Perhaps some Recommends: lines need to be added to the package?  or if
zytrax knows how to use VST plugins, then maybe it needs to learn to
look in /usr/lib/vst/ ?

At the very least some documentation is probably necessary to make the
tool be usable.

The tutorial seems to encourage using Synister, which does not appear to
be in debian, but maybe could be if someone wants to ITP it (i can't do
it myself, alas): https://github.com/the-synister/the-source/

Thanks for maintaining zytrax in debian!

   --dkg

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

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

Versions of packages zytrax depends on:
ii  libasound2   1.2.2-2.1
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libc62.30-4
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libgcc-s1 [libgcc1]  10-20200418-1
ii  libgcc1  1:10-20200418-1
ii  libglib2.0-0 2.64.2-1
ii  libglibmm-2.4-1v52.64.2-1
ii  libgtk-3-0   3.24.18-1
ii  libgtkmm-3.0-1v5 3.24.2-1
ii  libpangomm-1.4-1v5   2.42.1-1
ii  libpulse013.0-5
ii  libsigc++-2.0-0v52.10.2-1
ii  libstdc++6   10-20200418-1
ii  libx11-6 2:1.6.9-2

zytrax recommends no packages.

zytrax suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#953084: initramfs-tools: Hangs while trying to generate the initrd

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 04 Mar 2020 09:48:08 +0100 Nicolas Patrois  
wrote:
> Package: initramfs-tools
> Version: 0.136
> Severity: important
> 
> Dear Maintainer,
> 
> Since today’s upgrade, update-initramfs hangs while it tries to build 
> 5.4.0-2’s
> initrd.
> I can’t even kill the aptitude or dpkg process with CTRL-C, I must kill it 
> with
> killall.

Please run this (as root) and send the output:

mkinitramfs -v -o initrd.img

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.




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

Bug#959009: rlwrap: fails to build reproducibly when varying the cpu count

[Mike Miller]

Source: rlwrap
Version: 0.43-1
Severity: wishlist

The configure stage gives different results when running on a system
with one CPU or with multiple CPUs. The reason is a configure feature
test that runs a program in the background and then checks to see that
its state has changed. In a single CPU build environment, it's likely
that the background process is not scheduled, and the check fails.

The feature test could be patched to give hardcoded known answers for
Debian archs, or the test could be completely rewritten to be robust to
changes in the number of CPUs or task scheduling.

No patch at the moment to do either, open to suggestions or patches.

-- 
mike

Bug#959008: tmuxinator: nags user about new tmux versions

[brian m. carlson]

Package: tmuxinator
Version: 1.1.4-3
Severity: normal

tmuxinator nags the user when the version of tmux is unknown to it.
This is a deliberate upstream decision, but it annoys users and is not
in their interest.  The sole option to disable this requires an explicit
version for a specific subcommand which means one cannot just use a
shell alias to avoid the warning.

If it is really the case that tmuxinator is not functional with newer
tmux versions, or it can't be suitably guaranteed by the Debian package,
please add a suitable Depends requirement on the versions it supports,
such that tmux cannot be upgraded to an unsupported version that causes
tmuxinator to nag the user.

Otherwise, if it is the case that this is a needless warning, please
patch it out.  Debian already does this for a variety of other software,
including OpenSSL, that has excessively strict version warnings.

Note that upgrading tmuxinator here is not sufficient to solve the
problem (unless that version removes the warning), since it will reoccur
with the next upgrade.  The defect being described here is that the user
is able to be nagged at all when Debian dependencies are satisfied, not
that tmuxinator is out of date.

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

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

Versions of packages tmuxinator depends on:
ii  ruby 1:2.7+1
ii  ruby-erubis  2.7.0-3
ii  ruby-thor0.20.3-2
ii  ruby-xdg 2.2.3-1
ii  tmux 3.1-1

tmuxinator recommends no packages.

tmuxinator suggests no packages.

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#959007: liblognorm: Please provide new upstream release (2.0.6)

[Boyuan Yang]

Source: liblognorm
Version: 2.0.5-1.1
Severity: normal

Dear Debian liblognorm maintainer,

The liglognorm upstream has been providing new upstream release 2.0.6 since
2018. Is there any possibility to have this version packaged and provided in
Debian?

-- 
Thanks,
Boyuan Yang


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

Bug#959006: [live-manual] translation/contributing documentation inadequacies

[jnqnfe]

Package: live-manual
Version: 2:20151217.1

In moving (in live-manual MR #27) the contributing notes out of the
manual itself to files under `doc/` in the repo, I see problems with
the translation/contributing documentation that could do with
addressing. Preferably after MR #27 has merged.

I'd submit an MR myself, and may do later, but now's not the best
moment to do any such rewriting for me (more important stuff to
address) and I'd have to research the translation tool usage details.

Including:

 - The set of files referenced for starting a new translation seem to
be outdated and in need of replacement with reference to all *.pot
files.
 - The instructions should be reclarified to instruct making a copy of
the *.pot files as *.po files within manual/po/XX/ where XX is a
suitable language reference, and then translate those files.
 - The *.pot files can commonly be out of date, making it a good idea
for translators to start by regenerating them to ensure they are
working from up-to-date strings. There are no instructions about this.
It may be also be helpful to give a hint as to whether or not a commit
updating the *.pot files is welcome.
 - Similarly there could be stray *.pot files (or stray translation
*.po files) left over from removed English files, so a good idea to
hint that they compare to the set of English *.po files to ensure they
do not unintentionally waste time.
 - The `doc/contributing.md` content should perhaps note to readers
that they should checkout `doc/authoring` for SiSU markup hints (until
such time that we possibly move to a more common markup if we do).
 - The new `doc/contributing.md` file (which is focussed on
contributing to the manual) should be adjusted to properly suit the
different users who might read it - those wanting to update the English
text vs. those interested in translating.

Bug#954893: aptitude: messages from AppStream garble the ncurses interface

[Gabriele Stilli]

Il 24/03/20 22:55, Gabriele Stilli ha scritto:

> Package: aptitude
> Version: 0.8.12-3
> 
> Hello,
> 
> I use aptitude with the ncurses interface. Every time I do an update
> (press "u" in the program), the following message from AppStream pops up
> at the end:
> 
> "The AppStream system cache was updated, but some components were
> ignored. Refer to the verbose log for more information."
> 
> As a result, the interface gets garbled all around. I attach a
> screenshot illustrating the end result.

Hello again,

just for information, apparently I can't reproduce the bug anymore. This
might mean that something has changed in my AppStream cache
configuration or perhaps some other reason I can't spot right now. The
aptitude version hasn't changed (and hopefully neither has its
configuration). Just thought it useful to mention this.

Regards,
Gabriele Stilli

Bug#885195: geda-gaf: please migrate to guile-2.2

[Rob Browning]

Please try to migrate soon, and at this point, to guile-3.0 if possible.
Otherwise we might need to consider removing the package from Debian.

Sometimes it's sufficient to just update the build dependency from say
guile-2.0-dev to guile-3.0-dev and adjust some of the related versions
in configure.ac (or configure.in).

I may investigate further myself if I have time, but please don't rely
on that.

Thanks
-- 
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#959005: debian-policy: recommends an old version of libjs-sphinxdoc, once again

[Gabriele Stilli]

Package: debian-policy
Version: 4.5.0.1

Hi,

once again (#910561, #921889, #932359), the latest libjs-sphinxdoc
(2.4.3-2) breaks d-p's Recommends.

Thank you, once more!

Regards,
Gabriele Stilli

Bug#956780: solaar: Depends on deprecated libappindicator

[Kentaro Hayashi]

FYI:

It seems that AyatanaIndicator support was already merged into master.
https://github.com/pwr-Solaar/Solaar/pull/728

And It will be shipped as 1.0.2-rc2 (not yet).
https://github.com/pwr-Solaar/Solaar/compare/1.0.2-rc1...master#diff-02f0b547c2779d25cff89672135f20e3R1

Bug#958858: golang-github-docker-docker-dev: Please install library k8s.io/klog in golang-github-docker-docker-dev

[Reinhard Tartler]

Understood, I'll do that then.

Thanks

On April 25, 2020 6:19:49 PM EDT, Dmitry Smirnov  wrote:
>Control: tags -1 wontfix
>
>On Sunday, 26 April 2020 7:56:17 AM AEST Reinhard Tartler wrote:
>> I'm trying to update the packge golang-github-openshift-imagebuilder
>and
>> the package build fails with this failure:
>
>I think "golang-github-openshift-imagebuilder" should use its own
>vendored 
>"k8s.io/klog".
>
>
>> I saw that the library is available in the source package
>src:docker.io,
>> and should be easy to get installed into
>golang-github-docker-docker-dev.
>
>It is not up to Docker to provide 3rd party libraries.
>
>
>> Please let me know if you have any concerns with this approach.
>
>Docker is one of the worst in regards to versioning and vendoring.
>I don't trust Docker the slightest to provide "k8s.io/klog".
>
>My other concern is about additional maintenance burden to otherwise
>very 
>difficult package.
>
>Also "imagebuilder" might FTBFS when built against whatever is vendored
>by 
>Docker.

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

Bug#885188: freehdl: please migrate to guile-2.2

[Rob Browning]

Please try to update this soon, or we'll need to consider removing
freehdl from Debian, and if possible please attempt to move to guile-3.0
instead of guile-2.2 now, if possible.

Thanks
-- 
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#885212: libmatheval: please migrate to guile-2.2

[Rob Browning]

I think we probaly either need to address this soon, or consider
removing libmatheval from Debian.

Sometimes it's sufficient to just update the build dependency from say
guile-2.0-dev to guile-3.0-dev and adjust some of the related versions
in configure.ac (or configure.in), but in this case it looks like more
might be required.

When I make those adjutments to 3.0 with the current package I see some
SCM related type errors which I suspect are problems with the
types/prototypes in the library, i.e. int is (and was) not
(transparently) interchangable with SCM.

I may investigate further myself if I have time, but please don't rely
on that.

Thanks
-- 
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#959004: exim4-daemon-heavy: exiscan is missing EICAR signature in message body but finds it in attachment

[brunoc68]

Package: exim4-daemon-heavy
Version: 4.92-8+deb10u3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Installation of exim4-daemon-heavy with av_scanner = clamd

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

1. include EICAR virus signature in .txt or .zip attachment
2. include EICAR virus signature in message body

   * What was the outcome of this action?

1. mail refused at ACL time
2. mail accepted : message found as clean in clamd log

   * What outcome did you expect instead?

1. outcome ok
2. mail refused at ACL time




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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
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 exim4-daemon-heavy depends on:
ii  debconf [debconf-2.0]  1.5.61
pn  exim4-base 
ii  libc6  2.24-11+deb9u3
ii  libdb5.3   5.3.28-12+deb9u1
ii  libgnutls-dane03.5.8-5+deb9u3
ii  libgnutls303.5.8-5+deb9u3
ii  libldap-2.4-2  2.4.44+dfsg-5+deb9u3
ii  libmariadbclient18 10.1.37-0+deb9u1
ii  libpam0g   1.1.8-3.6
ii  libpcre3   2:8.39-3
ii  libperl5.245.24.1-3+deb9u5
ii  libpq5 9.6.17-0+deb9u1
ii  libsasl2-2 2.1.27~101-g0780600+dfsg-3+deb9u1
ii  libsqlite3-0   3.16.2-5+deb9u1

exim4-daemon-heavy recommends no packages.

exim4-daemon-heavy suggests no packages.

Bug#959003: firefox-esr: tab crash + segfault in dmesg for a specific page once rendered (WOFF-related?)

[Thorsten Glaser]

Package: firefox-esr
Version: 68.7.0esr-1
Severity: normal

Running iceweasel, even with…

MOZILLA_DISABLE_PLUGINS=1 firefox-esr 
https://nonchalantxfish.tumblr.com/post/185970643996

… shortly renders the page, then shows a “tab has crashed” dialogue box.

dmesg knows:

Apr 28 00:32:30 tglase-nb vmunix: [1047389.883679] Web Content[13080]: segfault 
at 0 ip 561a1dc0d90d sp 7ffe70f09370 error 6 in 
firefox-esr[561a1dc0d000+28000]
Apr 28 00:32:30 tglase-nb vmunix: [1047389.883691] Code: 8d 15 2f 7c 02 00 48 
89 10 c7 04 25 00 00 00 00 dc 0c 00 00 e8 f0 01 00 00 48 8d 05 fd 10 03 00 48 
8d 1d be 7c 02 00 48 89 18  04 25 00 00 00 00 60 08 00 00 e8 cf 01 00 00 48 
8d 05 dc 10 03


I ran the same (including MOZILLA_DISABLE_PLUGINS=1) under gdb;
typescript attached. Note that *during* the session only a SIGPIPE
was caught by gdb, but since I have corekeeper installed, I got a
core dump to analyse, which is included as well.

I reported the precisely same crash (while still running under gdb) as:
https://crash-stats.mozilla.org/report/index/f3688f84-6592-47f0-807b-5dcea0200427


I also have a Firefox 45 locally installed from the official
Mozilla i386 binaries, which seems to crash on the same tumblr,
albeit not on the same page, as well. This seems to be WOFF-related.


-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Classic Theme Restorer
Location: ${PROFILE_EXTENSIONS}/classicthemeresto...@arist2noia4dev.xpi
Status: app-disabled

Name: Clear Search 2
Location: ${PROFILE_EXTENSIONS}/clearsear...@extension-id.invalid.xpi
Status: app-disabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Monitor
Location: /usr/lib/firefox-esr/browser/features/fxmoni...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: HTTPS Everywhere
Location: /usr/share/webext/https-everywhere
Package: webext-https-everywhere
Status: user-disabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Offline QR Code Generator
Location: ${PROFILE_EXTENSIONS}/offline-qr-c...@rugk.github.io.xpi
Status: enabled

Name: Old Image Style
Location: ${PROFILE_EXTENSIONS}/{dfac41f2-b87d-4759-8825-a8bfd4cce744}.xpi
Status: enabled

Name: SoundFixer
Location: ${PROFILE_EXTENSIONS}/soundfi...@unrelenting.technology.xpi
Status: enabled

Name: Twitter
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Twitter View Original Images
Location: ${PROFILE_EXTENSIONS}/{0e05c778-ab7d-45a5-98d0-ed365ac4653b}.xpi
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox-esr 68.7.0esr-1  amd64Mozilla Firefox web 
browser - Extended Support Release (ESR)
ii  webext-https-everywhere 2020.3.16-1  all  Extension to force the 
use of HTTPS on many sites

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-4
ii  libasound21.2.2-2.1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-4
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig1   

Bug#959002: broadcom-sta-dkms: Wl driver 6.30.223.271 (r587334) failed with code 21

[Gert van de Kraats]

Package: broadcom-sta-dkms
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Because I recently had trouble with Wifi after an upgrade of package
firmware-b43-installer,
I purged this package and tried to install package broadcom-sta-dkms,
according to the recently updated instruction at 
https://wiki.debian.org/wl .

Installation uses the package from bullseye/testing not from some backport.

Loading of the wl-module  fails according to the next log:
Apr 26 12:34:04 debian kernel: [   20.895977] cfg80211: Loading compiled-in
X.509 certificates for regulatory database
Apr 26 12:34:04 debian kernel: [   20.897629] cfg80211: Loaded X.509 cert
'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
Apr 26 12:34:04 debian kernel: [   20.905587] cfg80211: Loaded X.509 cert
'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
Apr 26 12:34:04 debian kernel: [   20.907222] cfg80211: Loaded X.509 cert
'sforshee: 00b28ddf47aef9cea7'
Apr 26 12:34:04 debian kernel: [   21.247936] platform regulatory.0: 
firmware:

direct-loading firmware regulatory.db
Apr 26 12:34:04 debian kernel: [   21.347325] platform regulatory.0: 
firmware:

direct-loading firmware regulatory.db.p7s
Apr 26 12:34:04 debian kernel: [   22.420136] wl: loading out-of-tree module
taints kernel.
Apr 26 12:34:04 debian kernel: [   22.420148] wl: module license
'MIXED/Proprietary' taints kernel.
Apr 26 12:34:04 debian kernel: [   22.420149] Disabling lock debugging 
due to

kernel taint
Apr 26 12:34:04 debian kernel: [   22.431299] wl: module verification 
failed:

signature and/or required key missing - tainting kernel
Apr 26 12:34:04 debian kernel: [   22.492802] malloc in abgphy done
Apr 26 12:34:04 debian kernel: [   22.495075] malloc in abgphy done
Apr 26 12:34:04 debian kernel: [   22.495484] wl driver 6.30.223.271 
(r587334)

failed with code 21
Apr 26 12:34:04 debian kernel: [   22.495488] ERROR @wl_cfg80211_detach :
Apr 26 12:34:04 debian kernel: [   22.495489] NULL ndev->ieee80211ptr, 
unable

to deref wl

Card:
0c:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4311
802.11a/b/g [14e4:4312] (rev 01)
    Subsystem: Dell Wireless 1490 Dual Band WLAN Mini-Card [1028:0007]
    Flags: bus master, fast devsel, latency 0, IRQ 17
    Memory at dfdfc000 (32-bit, non-prefetchable) [size=16K]
    Capabilities: [40] Power Management version 2
    Capabilities: [58] MSI: Enable- Count=1/1 Maskable- 64bit-
    Capabilities: [d0] Express Legacy Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [13c] Virtual Channel
    Kernel driver in use: b43-pci-bridge




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 5.5.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

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

Versions of packages broadcom-sta-dkms depends on:
ii  dkms  2.8.1-5

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-13.1

broadcom-sta-dkms suggests no packages.

Bug#958104: system-config-printer-udev: ABRT: free(): invalid pointer

[Bernhard Übelacker]

Dear Maintainer,
looking at the backtrace from message 13 and at the changes
done by upstream, following commit sounds related:

https://github.com/OpenPrinting/system-config-printer/commit/b9289dfe105bdb502f183f0afe7a115ecae5f2af#diff-d3f2f90b6e176486d4b8dfe3222577f7

Kind regards,
Bernhard

Bug#959001: RFS: vzdump/1.2.6-6 [QA] -- OpenVZ backup scripts

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: vzdump
   Version : 1.2.6-6
   Upstream Author : Proxmox Server Solutions GmbH
 * URL : 
http://www.proxmox.com/cms_proxmox/en/virtualization/openvz/vzdump/
 * License : GPL-2.0+
 * Vcs : None
   Section : admin

It builds those binary packages:

  vzdump - OpenVZ backup scripts

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vzdump/vzdump_1.2.6-6.dsc

Changes since the last upload:

   * QA upload.
   * Mark source format as 3.0
 - Import old diff in quilt format.
   * Update Standards-Version to 4.5.0
 - Mark priority as optional.
   * Use delhelper-compat.
 - Update to compat level 12.
   * Remove whitespace from rules and changelog.

Note:
Looks like this got removed from testing because of #925803, which has
been fixed with ploop update. There are still few lintian warning and
only little changes has been done so that a source only upload can be
done.


-- 
Regards
Sudip

Bug#958408: etherape: crashes with "critical: read_all() failed on control socket"

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce the issue on i386 and tried to collect
some more information.

It crashes with the backtrace below.

The crash seems to be caused by using the wrong data type
in the calls to variadic functions goo_canvas_ellipse_new
and goo_canvas_polyline_new.

The modifications below made it work at i386 too.
(Just changing integer to floating point values).
Tested it just shortly.

Kind regards,
Bernhard




(gdb) bt
#0  __strchr_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:60
#1  0xb73243ce in g_param_spec_pool_lookup (pool=0x136e260, param_name=0x1 
, owner_type=26014064, 
walk_ancestors=1) at ../../../gobject/gparam.c:1071
#2  0xb731fbce in g_object_set_valist (object=, 
first_property_name=, var_args=0xbfb6a0b4 "") at 
../../../gobject/gobject.c:2289
#3  0xb7f6e4be in goo_canvas_ellipse_new (parent=0x1685848, center_x=0, 
center_y=0, radius_x=0, radius_y=0) at goocanvasellipse.c:214
#4  0x0044feea in check_new_node (canvas=0x1650380, node=0x14b1600) at 
diagram.c:935
#5  diagram_update_nodes (canvas=0x1650380) at diagram.c:541
#6  update_diagram (canvas=0x1650380) at diagram.c:735
#7  0x00450828 in update_diagram_callback (data=0x0) at diagram.c:1910
#8  0xb7076a51 in g_timeout_dispatch (source=0x14793c0, callback=0x450810 
, user_data=0x0) at ../../../glib/gmain.c:4667
#9  0xb7075e65 in g_main_dispatch (context=0x13b1fd0) at 
../../../glib/gmain.c:3182
#10 g_main_context_dispatch (context=0x13b1fd0) at ../../../glib/gmain.c:3847
#11 0xb7076269 in g_main_context_iterate (context=0x13b1fd0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:3920
#12 0xb7076609 in g_main_loop_run (loop=0x1478ea0) at ../../../glib/gmain.c:4116
#13 0xb799139e in gtk_main () at ../../../../gtk/gtkmain.c:1323
#14 0x0044049e in main (argc=, argv=) at 
main.c:316





--- etherape-0.9.18.orig/src/diagram.c
+++ etherape-0.9.18/src/diagram.c
@@ -939,7 +939,7 @@ static gint check_new_node(node_t * node
 0.0,
 "fill-color", "white",
 "stroke-color", "black",
-"line-width", 0,
+"line-width", 0.0,
  "visibility", GOO_CANVAS_ITEM_INVISIBLE,
  NULL);
   addref_canvas_obj(G_OBJECT(new_canvas_node->node_item));
@@ -1480,16 +1480,16 @@ static gint check_new_link(link_id_t * l
   /* set the lines position using groups positions */
   new_canvas_link->src_item =
 goo_canvas_polyline_new(rootgroup, TRUE, 2,
-0,0,
-1,1,
+0.0,0.0,
+1.0,1.0,
 "fill-color", "tan",
 NULL);
   g_object_ref(G_OBJECT (new_canvas_link->src_item));
 
   new_canvas_link->dst_item =
 goo_canvas_polyline_new(rootgroup, TRUE, 2,
-0,0,
-1,1,
+0.0,0.0,
+1.0,1.0,
 "fill-color", "tan",
 NULL);
   g_object_ref(G_OBJECT (new_canvas_link->dst_item));







PS.: Could not install etherape on a multiarch amd64/i386 system because
 it tells it depends on non-existing etherape-data:i386.

Buster i386 qemu VM 2020-04-27

apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm mc fakeroot quilt 
strace valgrind gdb etherape etherape-dbgsym libgtk-3-0-dbgsym 
libglib2.0-0-dbgsym libgoocanvas-2.0-9-dbgsym
apt build-dep etherape




export DISPLAY=:0
export XAUTHORITY=/home/benutzer/.Xauthority
/usr/bin/etherape -n -i ens4


# /usr/bin/etherape -n -i ens4
EtherApe-INFO: 22:31:04.097: Protokoll sctp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.097: Protokoll ddp nicht unterstützt
EtherApe-INFO: 22:31:04.483: Ergebnis von get_interface: »«
EtherApe-INFO: 22:31:04.484: Verfügbare Schnittstellen für die Erfassung: 
usbmon1 nfqueue nflog lo any ens4
EtherApe-INFO: 22:31:04.550: Verweistyp ist Ethernet
EtherApe-INFO: 22:31:04.551: Diagramm gestartet
EtherApe-INFO: 22:31:04.793: Neuer Knoten: IP: 10.0.2.15. Anzahl der Knoten 1
EtherApe-INFO: 22:31:04.794: Neuer Knoten: IP: 10.0.2.2. Anzahl der Knoten 2
unexpected EOF in read_all()
critical: read_all() failed on control socket
Speicherzugriffsfehler (Speicherabzug geschrieben)



dmesg:
[  344.474571] etherape[918]: segfault at 0 ip b6da9726 sp bfb69ed8 error 4 in 
libc-2.28.so[b6d2a000+14

Bug#949762: [Python-modules-team] Bug#949762: Please update hypothesis package to >= 5.1

[Emmanuel Arias]

Hi Ole,

I am working on the python-hypothesis.

One of the test fail on autopkgtest, so I am workint on it.

I push to salsa [0] my last change if you want to take a look.

[0] https://salsa.debian.org/python-team/modules/python-hypothesis

Thanks!
Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El sáb., 25 de abr. de 2020 a la(s) 06:18, Ole Streicher
(ole.streic...@gmx.de) escribió:
>
> Hi Emanuel,
>
> On Sat, 25 Jan 2020 08:59:00 -0300 Emmanuel Arias wrote:
> > Hypothesis from >= 5.0.0 version drop Python 2 support. So, I think we
> > should wait on Debian until
> > python-hypothesis remove the Python2 support.
>
> Since there is no more a Python2 package for hyptothesis, could I ask to
> upgrade to 5.1 now? This starts to block upgrading the whole astropy
> chain now.
>
> Thanks
>
> Ole
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#959000: rakudo: fails to configure: missing dependency on libipc-system-simple-perl

[Dagfinn Ilmari Mannsåker]

Package: rakudo
Version: 2020.02.1-1
Severity: serious

Dear Maintainer,

/usr/share/perl6/rakudo-helper.pl uses autodie and system(), which
requires IPC::System::Simple, causing the following error when
installing or upgrading the package:

Setting up rakudo (2020.02.1-1) ...
IPC::System::Simple required for Fatalised/autodying system() at 
/usr/share/perl6/rakudo-helper.pl line 20.
main::BEGIN() called at /usr/share/perl6/rakudo-helper.pl line 20
eval {...} called at /usr/share/perl6/rakudo-helper.pl line 20
BEGIN failed--compilation aborted at /usr/share/perl6/rakudo-helper.pl line 20.
dpkg: error processing package rakudo (--configure):
installed rakudo package post-installation script subprocess returned error 
exit status 2

Manually installing libipc-system-simple-perl allows the upgrade to proceed.

- ilmari
-- 
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least.   - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article.  - Calle Dybedahl

Bug#754129: Reworked for v0.5.5

[Stephan Lachnit]

Lutris 0.5.5 got sponsored and is in NEW since 3 weeks: 
https://ftp-master.debian.org/new/lutris_0.5.5-1.html

I also packed 0.5.6 since then, which is on Mentors: 
https://mentors.debian.net/package/lutris

One of the reason why it's so long in NEW is probably the license situation. 
Some of the icons use the "Flaticon" license, for which it isn't exactly clear 
weather it's DFSG compliant (probably not). More on this GitHub issue: 
https://github.com/lutris/lutris/issues/2553

Cheers,
Stephan

Bug#956216: buster-pu: package systemd/241-7~deb10u3

[Adam D. Barratt]

On Mon, 2020-04-27 at 19:17 +0200, Michael Biebl wrote:
> Am 25.04.20 um 21:41 schrieb Adam D. Barratt:
> > On Wed, 2020-04-08 at 16:11 +0200, Michael Biebl wrote:
> > I'd be OK with that, but this will need a KiBi-ack, so CCing and
> > tagging accordingly.
> 
> After talking to KiBi on IRC, we decided to include the fix for
> #958397
> as well. I kept the changes minimal and only included 60-rules in
> udev-udeb and the initramfs.
> 
For the record, I'm OK with that from the SRM side.

Regards,

Adam

Bug#947464: buster-pu: gnome-maps/3.30.3.1-1+deb10u1

[Adam D. Barratt]

On Mon, 2020-04-27 at 07:44 +0100, Phil Wyett wrote:
> On Sat, 2020-04-25 at 20:35 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
[...]
> I am neither DM or DD, so this upload will need to be done by someone
> carrying the appropriate access and signing ability. Files related to
> update are at link below.
> 
> http://development.kathenas.org/debian/versions/buster_updates/gnome_maps/
> 

You might get lucky and find that someone spots the mail on -release
and sponsors the upload, but do you have a usual sponsor(s)? It might
be worth seeing if anyone from the GNOME team is interested in
sponsoring the upload, or raising an RFS.

Regards,

Adam

Bug#958999: igraph: the library and PC metadata report wrong version

[Jerome Benoit]

Source: igraph
Version: 0.8.1+ds-3
Severity: normal
Tags: patch

Dear Maintainer,

it appears that the version tuple encoded in the library
and in the pkg-config metadata is wrong. This can be a
development issue. The provided patch alters the upstream
script that generates on the fly the version tuple.
This patch generates a version tuple based on the verion
of the debian package.
Cheers,
Jerome

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- a/tools/getversion.sh
+++ b/tools/getversion.sh
@@ -1,13 +1,4 @@
 #! /bin/bash
-
-thistag=$(git describe --exact-match --tags HEAD 2>/dev/null || true)
-
-if [ -z "${thistag}" ]; then
-# taghash=$(git rev-list --tags --max-count=1)
-# tag=$(git describe --tags "$taghash")
-next_version=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && cat NEXT_VERSION )
-current=$(git rev-parse --short HEAD)
-echo "${next_version}-pre+${current}"
-else
-echo "${thistag}"
-fi
+version_upstream=$(dpkg-parsechangelog -S Version | sed -e 's/+[^+]*$//')
+echo "${version_upstream}"
+exit 0
--- a/tools/getversion.sh
+++ b/tools/getversion.sh
@@ -1,13 +1,4 @@
 #! /bin/bash
-
-thistag=$(git describe --exact-match --tags HEAD 2>/dev/null || true)
-
-if [ -z "${thistag}" ]; then
-# taghash=$(git rev-list --tags --max-count=1)
-# tag=$(git describe --tags "$taghash")
-next_version=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && cat NEXT_VERSION )
-current=$(git rev-parse --short HEAD)
-echo "${next_version}-pre+${current}"
-else
-echo "${thistag}"
-fi
+version_upstream=$(dpkg-parsechangelog -S Version | sed -e 's/+[^+]*$//')
+echo "${version_upstream}"
+exit 0

Bug#958998: CVE-2020-12135 in embedded bson

[Moritz Muehlenhoff]

Source: duo-unix
Severity: normal
Tags: security

duo-unix seems to embed a copy of bson, which is affected by
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12135

Nothing inside duo-unix seems to call bson_ensure_space(), but
it probably still makes sense for upstream to update the embedded
copy to the latest version.

Cheers,
Moritz

Bug#958997: RFP: pgsql-postal -- PostgreSQL Postal Address Normalizer

[Alex Gould]

Package: wnpp
Severity: wishlist

Package name: pgsql-postal
Version: 
Upstream Author: Paul Ramsey 
URL: https://github.com/pramsey/pgsql-postal
License: MIT
Programming Lang: C, SQL
Description: PostgreSQL Postal Address Normalizer

This is a PostgreSQL extension that uses Libpostal 
(https://github.com/openvenues/libpostal) to parse and normalize street 
addresses.

Bug#800878: inkscape: non-free file "gallardo.svgz"

[Mattia Rizzolo]

On Sun, Oct 04, 2015 at 07:00:06PM +0200, Jonas Smedegaard wrote:
> >> According to its metadata, image 
> >> "/usr/share/inkscape/examples/gallardo.svgz" 
> >> appears to be non-free:
> > It's funny because according to that wikipedia page the image under a
> > double license GFDL-1.2 / CC-BY-SA-3.0.
> 
> Indeed, that's interesting.
> 
> We could try locate and get in touch with the copyright holder of the 
> SVG, and ask kindly if he agrees to relicense, also making him aware 
> that arguably¹ he has no choice.
> 
> According to metadata of the file, his name is Michael Grosberg and he 
> used Windows² at the time.  A Michael Grosberg have been active on the 
> Inkscape developers' list, so maybe his email is in some commit message 
> or his list posts hare unscrambled somewhere...
> 
> Anyone who wants to try contact Michael?

Today it felt the right time to bring up this bug with upstream (I
talked with Mc over #inkscape-devel).  They found an address for
Michael, but it needs to be mentioned that there haven't been a trace of
that address for 15 years, even if the mail didn't bounce.


Regarding animated-clock.svg, the copyright holder of that is an active
Inkscape contributor, so we just pinged him over IRC.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#958996: ITP: python-pauvre -- QC and genome browser plotting Oxford Nanopore and PacBio long reads

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-pauvre -- QC and genome browser plotting Oxford Nanopore 
and PacBio long reads
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-pauvre
  Version : 0.1924
  Upstream Author : Darrin T. Schultz
* URL : https://github.com/conchoecia/pauvre
* License : GPL-3+
  Programming Lang: Python
  Description : QC and genome browser plotting Oxford Nanopore and PacBio 
long reads
 Pauvre is a plotting package designed for nanopore and PacBio long reads.
 .
 This package currently hosts four scripts for plotting and/or printing stats.
 .
  pauvre marginplot
 Takes a fastq file as input and outputs a marginal histogram with a
 heatmap.
  pauvre stats
 Takes a fastq file as input and prints out a table of stats, including
 how many basepairs/reads there are for a length/mean quality cutoff.
 This is also automagically called when using pauvre marginplot
  pauvre redwood
 Method of representing circular genomes. A redwood plot contains long
 reads as "rings" on the inside, a gene annotation "cambrium/phloem",
 and a RNAseq "bark". The input is .bam files for the long reads and
 RNAseq data, and a .gff file for the annotation.
  pauvre synteny
 Makes a synteny plot of circular genomes. Finds the most parsimonius
 rotation to display the synteny of all the input genomes with the
 fewest crossings-over. Input is one .gff file per circular genome
 and one directory of gene alignments.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-pauvre

Bug#950988: Response on your feedback

[Leon Marz]

Hi Jordan and Thomas,

thank you for your kind advise. I updated the package with all the 
proposed requests.


> Do you plan to try to maintain the package going forward? (Watch for

> new upstream releases, work on bugs, etc?)

Yes, I want to further maintain this package.


Do you have plans to manage the package files in git, perhaps on
salsa.debian.net? I'm not sure if it is allowed to start using salsa
for a project before it makes it into debian. The salsa FAQ is vague
on this point:


> https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa


But I think it is often allowed. I know of at least 2 cases where a
repo was created for a package before it got included into Debian. I
expect some basic review of the package is probably good first, and
perhaps this email can serve for that.

If not salsa.debian.net, you could still host it in a github repo and
include the links to it in the control file. (And, that could move to
salsa later too.)


I do want to manage the package on salsa.debian.org. It would be nice, 
if you could create a repository and give me upload rights to it. My 
username is lmarz.


- Leon

Bug#958994: buster-pu: package tzdata/2020a-0+deb10u1

[Aurelien Jarno]

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

Dear stable release team,

The world is improving and for once we don't need to go through
stable-updates to distribute the new version in tzdata. The changes
in version 2020a-0+deb10u1 are the following:
 - Morocco springs forward on 2020-05-31, not 2020-05-24.
 - Canada's Yukon advanced to -07 year-round on 2020-03-08.

Despite the Yukon change happening on 2020-03-08 for the time zone
change, the impact on the actual time will happen on 2020-11-01.

I have already uploaded this new version to stable-new.

Regards,
Aurelien

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#754129: Reworked for v0.5.5

[Diane Trout]

On Mon, 30 Mar 2020 11:05:07 + Stephan Lachnit <
stephanlach...@protonmail.com> wrote:
> Just reworked it for v0.5.5, still need a sponsor (#945588).
> 
> Stephan
> 
> 

Hi,

I am a Debian Developer and was wondering what the status of this
sponsorship request is, do you have a copy on mentors? Is it just in
git?

Diane Trout


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

Bug#958995: stretch-pu: package tzdata/2020a-0+deb9u1

[Aurelien Jarno]

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

Dear oldstable release team,

The world is improving and for once we don't need to go through
oldstable-updates to distribute the new version in tzdata. The changes
in version 2020a-0+deb9u1 are the following:
 - Morocco springs forward on 2020-05-31, not 2020-05-24.
 - Canada's Yukon advanced to -07 year-round on 2020-03-08.

Despite the Yukon change happening on 2020-03-08 for the time zone
change, the impact on the actual time will happen on 2020-11-01.

I have just uploaded this new version to oldstable-new.

Regards,
Aurelien

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

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#956351: transition: opencascade

[Tobias Frost]

On Mon, 27 Apr 2020 21:42:53 +0200 Tobias Frost  wrote:

> The following packages of Dependency level 2 could already be binNMUed:
> gmsh_4.5.6+ds1
> kicad_5.1.5+dfsg1-2

Sorry for the noise, I just realized that that has happened already. 
Read: You are awesome!)

netgen is now in DELAYED/5.

-- 
tobi

Bug#956359: netgen: diff for NMU version 6.2.1804+dfsg1-3.1

[Tobias Frost]

Control: tags 956359 + pending


Dear maintainer,

I've prepared an NMU for netgen (versioned as 6.2.1804+dfsg1-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
tobi
diff -Nru netgen-6.2.1804+dfsg1/debian/changelog netgen-6.2.1804+dfsg1/debian/changelog
--- netgen-6.2.1804+dfsg1/debian/changelog	2019-03-01 19:44:35.0 +0100
+++ netgen-6.2.1804+dfsg1/debian/changelog	2020-04-27 22:01:24.0 +0200
@@ -1,3 +1,10 @@
+netgen (6.2.1804+dfsg1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch to fix FTBFS against opencascade 7.4. (Closes: #956359)
+
+ -- Tobias Frost   Mon, 27 Apr 2020 22:01:24 +0200
+
 netgen (6.2.1804+dfsg1-3) unstable; urgency=medium
 
   * [425e45e] Use new OpenCASCADE path
diff -Nru netgen-6.2.1804+dfsg1/debian/patches/opencascade7.4.patch netgen-6.2.1804+dfsg1/debian/patches/opencascade7.4.patch
--- netgen-6.2.1804+dfsg1/debian/patches/opencascade7.4.patch	1970-01-01 01:00:00.0 +0100
+++ netgen-6.2.1804+dfsg1/debian/patches/opencascade7.4.patch	2020-04-27 22:01:02.0 +0200
@@ -0,0 +1,17 @@
+Description: Fix FTBFS with opencascade 7.4
+Origin: https://github.com/NGSolve/netgen/commit/18070c9f03072cadffe7baed4ba4045dd9ea680e#diff-3ee1c88f2a71a62145e31da1ef21ea3f
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956359
+Forwarded: not-needed
+Last-Update: 2020-04-10
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libsrc/occ/occgeom.hpp
 b/libsrc/occ/occgeom.hpp
+@@ -73,7 +73,6 @@
+ #include "ShapeUpgrade_ShellSewing.hxx"
+ #include "ShapeFix_Shape.hxx"
+ #include "ShapeFix_Wireframe.hxx"
+-#include "BRepMesh.hxx"
+ #include "BRepMesh_IncrementalMesh.hxx"
+ #include "BRepBndLib.hxx"
+ #include "Bnd_Box.hxx"
diff -Nru netgen-6.2.1804+dfsg1/debian/patches/series netgen-6.2.1804+dfsg1/debian/patches/series
--- netgen-6.2.1804+dfsg1/debian/patches/series	2018-12-29 04:42:35.0 +0100
+++ netgen-6.2.1804+dfsg1/debian/patches/series	2020-04-11 09:09:35.0 +0200
@@ -1,2 +1,3 @@
 disable-windows.patch
 add-sse-guard.patch
+opencascade7.4.patch


signature.asc
Description: PGP signature

Bug#939170: linux: does not suspend completely, locks up

[Frank Loeffler]

On Sat, Mar 14, 2020 at 02:23:05PM +0100, Daniel M. wrote:

On Sun, 26 Jan 2020 18:03:23 +0100 Felix Rublack  wrote:

Hi everyone,

I have the same issue on a ThinkPad T460s (suspend works only half way,
reboot and poweroff stop just short before actual shutdown).

I bisected the problem to the TPM driver. Blacklisting the module in
modprobe.d fixed the problem for me.

Sample configuration: /etc/modprobe.d/blacklist-tpm.conf

# Prevent TPM from loading. It breaks suspend and power cycle.
blacklist tpm
blacklist tpm_crb
blacklist tpm_tis
blacklist tpm_tis_core

Greetings
Felix Rublack


Hi, thanks a lot! I can confirm that this works also on my Thinkpad
E460. Since you can probably provide more details, could you forward
this to kernel.org?


Hi,

just to add one tiny bit of confirmation: this helped also in my case 
(big thanks!):


I am on Buster with a Lenovo Thinkpad T460, with kernels 4.19.0.8 and 
5.4.0.0.bpo.4 installed. Suspend works fine with 4.19.0.8. The same 
system fails consistently when booted with 5.4, in the same way reported 
earlier: the system starts to suspend, but stops somewhere close to the 
finish line: display is black (don't remember if backlight was off, but 
I think it was), power-led is blinking, but the led-indicators like mute 
stay on. I cannot say something about the fan, as it is usually not 
running for me anyway. Nothing brings the laptop back at this stage 
other than pressing the power-button for like 10 seconds (complete 
restart): no shorter press of the power button, no lid action. Both 
should, and with the 4.19 kernel, do.


With above blacklisting, suspend now also works for kernel version 5.4.

Big thanks again - and it would be interesting to follow this at the 
kernel.org-level (to know when to remove the blacklist again).


Frank Löffler



signature.asc
Description: PGP signature

Bug#956351: transition: opencascade

[Tobias Frost]

On Sat, Apr 25, 2020 at 02:29:53PM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed

> Go ahead.

Thanks!

opencascade is now in unstable and all archs have successuflly built.

The following packages of Dependency level 2 could already be binNMUed:
gmsh_4.5.6+ds1
kicad_5.1.5+dfsg1-2

For netgen (the remaining package in Depenency level 2) I will prepare a NMU 
soon.

Cheers,
--
tobi

Bug#958574: toil: autopkgtest regression in a superficial test

[Paul Gevers]

Control: reopen -1
Control: retitle -1 autopkgtest must be marked superficial

On 23-04-2020 22:16, Paul Gevers wrote:
> with my release team member
> hat on, I request you to mark you smoke-test as superficial as it's
> hardly testing the package.

I don't see this has happened.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#958925: grub-efi: Does not sign EFI entries.

[Santiago José López Borrazás]

El 27/4/20 a las 17:36, Steve McIntyre escribió:

Hi again.I was thinking about formatting the /boot/efi directory, because I
think it's a directory problem, in case 2 appears.

Well I see one in / boot/efi/Boot, with another one that is in
/boot/efi/EFI/debian, because there is another one from debian, that is in
/boot/efi/debian.

I do not know, if it is because I have 2 directories equal to others, but
with these different files that I see, which is the bootx64.efi file, which
seems to be 2 sizes.

The same is the failure in which it arises. Because these 2 problems can go
there.

I am sure I would have to fix it quickly later, with the Debian flash drive
that I have to do everything in "Rescue Mode".

I can do it, because if it doesn't work, it is then, the problem of the
packages, for sure.

--
Saludos de Santiago José López Borrazás.
Enviando desde Mozilla Thunderbird.

Bug#958988: key packages script does not take account of virtual packages.

[Andreas Beckmann]

On 27/04/2020 19.55, peter green wrote:
> 1. What should the policy be on handling virtual packages? it seems to
> me that virtual packages with only a single provider should be treated
> much the same as real packages but what about those with multiple
> providers? ignore them? pick one according to priority and popcon?
> include them all? (it seems like the latter could lead to unnessacery
> growth of the key packages list).

You should not need to worry about multiple providers, as such virtual
packages should not occur as the default alternative. (And if they show
up, e.g. because the default alternative does not exist/is not
installable, file a bug.)

Policy 7.5:

[...]
To specify which of a set of real packages should be the default to
satisfy a particular dependency on a virtual package, list the real
package as an alternative before the virtual one.
[...]

E.g. Depends: default-mta | mail-transport-agent


Andreas

PS: There are currently 14 providers of mail-transport-agent in sid ;-)

Bug#958989: dgit-user(7): building instructions don't work

[Nikolaus Rath]

Hi Ian,

Thanks for the quick response!

On Apr 27 2020, Ian Jackson  wrote:
> Nikolaus Rath writes ("Bug#958989: dgit-user(7): building instructions don't 
> work"):
>> I'm trying to follow dgit-user(7) to build a modified version of a package.
>> I did:
>
> Hi.  This is a thing you should be able to do.
>
>> $ dgit clone valgrind
>> $ cd valgrind
>> $ git apply ../my_special_patch.diff
>> $ git commit -m "Way better than vanilla!"
>> $ gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit
>> $ git clean -xdf
>> $ sbuild -c buster-amd64 -A --no-clean-source --dpkg-source-opts='-Zgzip -z1 
>> --format=1.0 -sn'
>> 
>> But this eventually fails with:
> ...
>>  dpkg-source -b .
>> dpkg-source: error: can't build with source format '3.0 (quilt)': no 
>> upstream tarball
>> found at ../valgrind_3.15.0.orig.tar.{bz2,gz,lzma,xz}
>> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 25
>
> How sad.
>
> There are two things wrong here.
>
> One is that sbuild seems to be ignoring the --dpkg-source-opts, or
> maybe the rune was always wrong.  I think I will have to investigate.
> I *thought* we had a test for this rune but maybe not one involving
> sbuild.
>
> ... yes, we do.  tests/tests/sbuild-gitish.  Obviously the test isn't
> working right.
>
> The other oddity, is that this complaint about
> valgrind_3.15.0.orig.tar.* implies that there isn't a
> valgrind_3.15.0.orig.tar.bz2 but when I tried dgit clone valgrind it
> left me one in my "..".

Yes, I have one too:

$ ls -d ../valgrind*
../valgrind/
../valgrind_3.15.0.orig.tar.bz2
../valgrind_3.15.0-1.debian.tar.xz
../valgrind_3.15.0-1.dsc
../valgrind_3.15.0-1.tar.gz
../valgrind_3.15.0-1_amd64.build@
../valgrind_3.15.0-1_amd64-2020-04-27T18:01:38Z.build
../valgrind_3.15.0-1_amd64-2020-04-27T18:05:35Z.build
../valgrind_3.15.0-2~1.gbpd4e99a.dsc
../valgrind_3.15.0-2~1.gbpd4e99a.tar.gz
../valgrind_3.15.0-2~1.gbpd4e99a_amd64.build@
../valgrind_3.15.0-2~1.gbpd4e99a_amd64-2020-04-27T18:06:33Z.build

> I conjecture that you have a non-default
> build-products dir for dgit but your sbuild doesn't have that
> configured ?  This ought not to matter with the --format=1.0 -sn rune.
> I don't think this is in your way but it would be nice to confirm that
> there isn't another bug here.

I don't remember setting something like this, but I may have
forgotten. Where would I look for that?

I do not have a ~/.dgit*, nor is dgit mentioned in ~/.gitconfig.

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#956121: Blank screen on 2nd display using wayland

[Simon McVittie]

On Mon, 27 Apr 2020 at 19:48:14 +0200, Pierre Cheynier wrote:
> * upgrading my system except gnome-shell/mutter etc.
> I tried to bump gir1.2-gnomedesktop-3.0, but this breaks gnome either
> in 3.36.1-2 or 3.36.1-3
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956896).
> May I suggest to add a "Breaks: gnome-shell (<< 3.36)" instead of
> "Breaks: gnome-shell (<< 3.34)"? Or maybe I'm missing something?

What's meant to have happened is that gir1.2-gnomedesktop-3.0 Depends on
libgnome-desktop-3-19, which Depends on a matching gnome-desktop3-data,
which prevents installation of libgnome-desktop-3-18, which avoids the
crash. The goal is that you can have either libgnome-desktop-3-19 or
libgnome-desktop-3-18, but never both at the same time.

This is not completely fixed in testing until
libgnome-desktop-3-18_3.36.1-2 and gir1.2-gnomedesktop-3.0_3.36.1-2
disappear from testing, which should have happened 5 days ago but has been
held up by some changes to other packages. If I'm reading the migration
logs correctly, this is being delayed by the rebuilt version of evince
having picked up a dependency on a newer libsecret, and might be solved
in 2 days when libsecret is old enough to migrate.

Increasing the version in the Breaks wouldn't really help you here,
because gir1.2-gnomedesktop-3.0_3.36.1-2 didn't have it, and there's
nothing we can do that will retroactively change version 3.36.1-2:
we have to wait for the state of the archive to be suitable for
version 3.36.1-2 to disappear.

> * repackaging mutter 3.36.1+git20200419-1 with my revert of 59e9b073
> from upstream (context in the gnome thread
> https://gitlab.gnome.org/GNOME/mutter/-/issues/1193#note_776408)
> Unfortunately it requires libgnome-desktop-3-dev which depends on
> gir1.2-gnomedesktop-3.0, same version, so I'm back to the first issue.
> I can upgrade, compile, downgrade though.

The best route would be to rebuild mutter against packages from
unstable (in particular, with libgnome-desktop-3-dev_3.36.1-3 and
libgnome-desktop-3-19 installed), with a revert of the commit(s) that
you suspect are causing this.

If you're able to build mutter in sbuild or pbuilder, in a container, or
in a virtual machine, then the easiest way will be to do that, using an
up-to-date unstable environment in the chroot/container/VM.

Or you could upgrade to the unstable version of libgnome-desktop-3-19
(which will require upgrading gnome-shell and mutter to their latest
versions from unstable, or at least a recent-ish version), and apply
whatever workarounds make your system halfway usable for long enough
to compile mutter with the problematic commit reverted. If this issue
is Wayland-specific, maybe you could edit /etc/gdm3/daemon.conf and
force X11 by uncommenting "WaylandEnable=false"; or you could
temporarily disable gdm and use text mode to compile mutter.

smcv

Bug#958989: dgit-user(7): building instructions don't work

[Ian Jackson]

Nikolaus Rath writes ("Bug#958989: dgit-user(7): building instructions don't 
work"):
> I'm trying to follow dgit-user(7) to build a modified version of a package.
> I did:

Hi.  This is a thing you should be able to do.

> $ dgit clone valgrind
> $ cd valgrind
> $ git apply ../my_special_patch.diff
> $ git commit -m "Way better than vanilla!"
> $ gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit
> $ git clean -xdf
> $ sbuild -c buster-amd64 -A --no-clean-source --dpkg-source-opts='-Zgzip -z1 
> --format=1.0 -sn'
> 
> But this eventually fails with:
...
>  dpkg-source -b .
> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream 
> tarball found at ../valgrind_3.15.0.orig.tar.{bz2,gz,lzma,xz}
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 25

How sad.

There are two things wrong here.

One is that sbuild seems to be ignoring the --dpkg-source-opts, or
maybe the rune was always wrong.  I think I will have to investigate.
I *thought* we had a test for this rune but maybe not one involving
sbuild.

... yes, we do.  tests/tests/sbuild-gitish.  Obviously the test isn't
working right.

The other oddity, is that this complaint about
valgrind_3.15.0.orig.tar.* implies that there isn't a
valgrind_3.15.0.orig.tar.bz2 but when I tried dgit clone valgrind it
left me one in my "..".  I conjecture that you have a non-default
build-products dir for dgit but your sbuild doesn't have that
configured ?  This ought not to matter with the --format=1.0 -sn rune.
I don't think this is in your way but it would be nice to confirm that
there isn't another bug here.


Regards,
Ian.

Bug#958991: RFS: setzer/0.2.4-1 [ITP] -- simple yet full-featured LaTeX editor

[Stephan Lachnit]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

   Package name: setzer
   Version : 0.2.4-1
   Upstream Author : cvfosa 
   URL : https://www.cvfosa.org/setzer/
   License : GPL-3.0+
   Vcs : https://salsa.debian.org/debian/setzer
   Section : tex

It builds those binary packages:

  setzer - simple yet full-featured LaTeX editor

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/setzer/setzer_0.2.4-1.dsc

Changes since the last upload:

   * Initial release. (Closes: #954847)


Setzer is an amazing LaTeX Editor with Gnome looks written in Python. It 
features a dark mode, many shortcuts for common symbols used in Latex, a 
document creation wizard and more.
The only real build dependency is Meson, the runtime dependencies are also 
pretty light: Python GLib bindings and python3-xdg.
I already had some contact with the developer to wire up support for Meson, and 
he responds very quickly to issues and PRs.

I don't mind maintaining it in a team, if someone is interested in that.

Cheers,
Stephan

Bug#958990: src:node-hoek: fails to migrate to testing for too long

[Paul Gevers]

Source: node-hoek
Version: 8.5.0+~4.2.1+~3.3.1-1
Severity: serious
Control: close -1 9.0.3+~5.0.0+~4.0.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 952143

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:node-hoek in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=node-hoek




signature.asc
Description: OpenPGP digital signature

Bug#958943: [3dprinter-general] Bug#958943: cura: Cura 4.5.0-1 crashes on start

[Gregor Riepl]

>   File "/usr/lib/python3/dist-packages/UM/Trust.py", line 9, in 
> from cryptography.hazmat.backends import default_backend
> ModuleNotFoundError: No module named 'cryptography'

Missing dependency in python3-uranium, should be easy to fix.

diff --git a/debian/control b/debian/control
index c1299f578..970cb74b2 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@ Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends},
  python3-pyqt5 (>= 5.10), python3-pyqt5.qtopengl (>= 5.10),
  python3-pyqt5.qtquick (>= 5.10), python3-pyqt5.qtsvg (>= 5.10),
  qml-module-qtqml-models2, qml-module-qtquick-dialogs,
- python3-arcus (>= 3.3.0)
+ python3-arcus (>= 3.3.0), python3-cryptography
 Recommends: python3-stl
 Provides:
  ${python3:Provides}

Bug#958989: dgit-user(7): building instructions don't work

[Nikolaus Rath]

Package: dgit
Version: 9.10
Severity: normal

Dear Maintainer,

I'm trying to follow dgit-user(7) to build a modified version of a package.
I did:

$ dgit clone valgrind
$ cd valgrind
$ git apply ../my_special_patch.diff
$ git commit -m "Way better than vanilla!"
$ gbp dch -S --since=dgit/dgit/sid --ignore-branch --commit
$ git clean -xdf
$ sbuild -c buster-amd64 -A --no-clean-source --dpkg-source-opts='-Zgzip -z1 
--format=1.0 -sn'

But this eventually fails with:


dpkg-buildpackage
-

Command: dpkg-buildpackage -us -uc -rfakeroot
dpkg-buildpackage: info: source package valgrind
dpkg-buildpackage: info: source version 1:3.15.0-2~1.gbpd4e99a
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Nikolaus Rath 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --with=autoreconf
   dh_clean
 dpkg-source -b .
dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream 
tarball found at ../valgrind_3.15.0.orig.tar.{bz2,gz,lzma,xz}
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 25




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

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

Versions of packages dgit depends on:
ii  apt1.8.2
ii  ca-certificates20190110
ii  coreutils  8.30-3
ii  curl   7.64.0-4+deb10u1
ii  devscripts 2.20.2~bpo10+1
ii  dpkg-dev   1.19.7
ii  dput   1.0.3
ii  git [git-core] 1:2.20.1-2+deb10u3
ii  git-buildpackage   0.9.14
ii  libdpkg-perl   1.19.7
ii  libjson-perl   4.02000-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  liblocale-gettext-perl 1.07-3+b4
ii  libtext-csv-perl   1.99-1
ii  libtext-glob-perl  0.10-1
ii  libtext-iconv-perl 1.7-5+b7
ii  libwww-curl-perl   4.17-5
ii  perl [libdigest-sha-perl]  5.28.1-6

Versions of packages dgit recommends:
ii  distro-info-data 0.41+deb10u1
ii  liburi-perl  1.76-1
ii  openssh-client [ssh-client]  1:7.9p1-10+deb10u2

Versions of packages dgit suggests:
ii  sbuild  0.78.1-2

-- no debconf information

Bug#958987: dh: fails to handle wrapped Architecture field

[Thorsten Glaser]

Eh, forgot the actual error:

[…]
 debian/rules clean
dh clean
 debian/rules binary-arch
dh binary-arch
 dpkg-genbuildinfo --build=any
dpkg-genbuildinfo: error: binary build with no binary artifacts found; 
.buildinfo is meaningless
dpkg-buildpackage: error: dpkg-genbuildinfo --build=any subprocess returned 
exit status 255


I’ve found out a bit since then:

$ dh -v build
dh: warning: No packages to build. Possible architecture mismatch: x32, want: 
alpha amd64 arm64 armel armhf hurd-i386 i386 ia64


So, dh indeed fails to parse debian/control correctly *and* fails to
abort on the parse failure.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#958988: key packages script does not take account of virtual packages.

[peter green]

package: qa.debian.org
user: qa.debian@packages.debian.org
usertags: udd
x-debbugs-cc: debian-rele...@lists.debian.org

The debian rust team makes heavy use of virtual packages to reduce the number 
of real packages in the archive (and in some cases the number of trips through 
new) while retaining flexibility to split if necessary (either for multiple 
versions of a crate or where featuresets that previously had the same 
dependencies diverge).

Unfortunately the key packages script does not take virtual packages into 
account. The result of this is that a large number of rust packages that ought 
to be on the key packages list (as a result of firefox depending on cbindgen 
which build-depends on a bunch of rust packages) are not on there.

This raises a couple of questions.

1. What should the policy be on handling virtual packages? it seems to me that 
virtual packages with only a single provider should be treated much the same as 
real packages but what about those with multiple providers? ignore them? pick 
one according to priority and popcon? include them all? (it seems like the 
latter could lead to unnessacery growth of the key packages list).
2. how to actually implement that? it looks to me like it would involve 
extending add_pkg_sources in 
https://salsa.debian.org/qa/udd/-/blob/master/scripts/update-key-packages.pl 
but I'm not a perl guy or a udd guy.

Bug#958987: dh: fails to handle wrapped Architecture field

[Thorsten Glaser]

Package: debhelper
Version: 13

I don’t know if this is really a bug in debhelper, but:

$ cat debian/control
[…]
Architecture: alpha amd64 arm64 armel armhf hurd-i386 i386 ia64
 kfreebsd-amd64 kfreebsd-i386 mips64el mipsel ppc64el riscv64 sh4 x32
[…]

The .dsc file contains…

Architecture: alpha amd64 arm64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips64el mipsel ppc64el riscv64 sh4 x32

… and similar in the Package-List.

There’s not really an overview anywhere which fields in the rfc822-like
format Debian likes to use can be wrapped, but if this field could not
be wrapped, both dpkg-source (used to create the .dsc) and debhelper
would refuse to parse the debian/control file due to it, so I’m guessing
it _is_ a bug in debhelper, either to not allow wrapping this field, or
not complaining about it, and in the latter case, also a bug elsewhere…

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.8.0-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl13
ii  libdpkg-perl 1.19.7
ii  man-db   2.9.1-1
ii  perl 5.30.0-10
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#956121: Blank screen on 2nd display using wayland

[Pierre Cheynier]

Hi Simon, list,

This evening, I gave a try to:

* upgrading my system except gnome-shell/mutter etc.
I tried to bump gir1.2-gnomedesktop-3.0, but this breaks gnome either
in 3.36.1-2 or 3.36.1-3
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956896).
May I suggest to add a "Breaks: gnome-shell (<< 3.36)" instead of
"Breaks: gnome-shell (<< 3.34)"? Or maybe I'm missing something?

* repackaging mutter 3.36.1+git20200419-1 with my revert of 59e9b073
from upstream (context in the gnome thread
https://gitlab.gnome.org/GNOME/mutter/-/issues/1193#note_776408)
Unfortunately it requires libgnome-desktop-3-dev which depends on
gir1.2-gnomedesktop-3.0, same version, so I'm back to the first issue.
I can upgrade, compile, downgrade though.

Any path I could follow to not experience too much troubles while
still being able to test an upgrade with this revert?

pch

Bug#902204: Processed: Re: Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Vincent Lefevre]

Hi,

On 2020-04-27 17:07:39 +0300, Sergey B Kirpichev wrote:
> On Wed, Apr 22, 2020 at 08:48:49PM +0200, mart...@tildeslash.com wrote:
> > Hello,
> > 
> > the problem is fixed: 
> > https://bitbucket.org/tildeslash/monit/commits/f3bea23a52db
> 
> I'm glad to hear.  Please try post to the bug thread next time.
> 
> Will be 5.27.0 soon (May?) or I should rather port this fix,
> which seems to be trivial.

I confirm that removing the 3 lines in monit 1:5.26.0-5 fixes the bug.

Thanks.

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

Bug#958986: celery: FTBFS with Sphinx 2.0.0

[Mattia Rizzolo]

Source: celery
Version: 4.4.2-1
Severity: serious
Control: block -1 by 958983
Control: 958983 !
Owner: !

SSIA.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#958985: sphinx: please add Breaks: python3-sphinx-celery (<< 2.0.0-1)

[Mattia Rizzolo]

Package: python3-sphinx
Version: 2.4.3-2
Severity: important

sphinx-celery doesn't autopkgtest or somesuch so this wasn't really
caught, nor debugged untile today.

I'm updating the package now for #958983 - so please add this Breaks on
your next upload of sphinx.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#956216: buster-pu: package systemd/241-7~deb10u3

[Michael Biebl]

Am 25.04.20 um 21:41 schrieb Adam D. Barratt:
> On Wed, 2020-04-08 at 16:11 +0200, Michael Biebl wrote:
> I'd be OK with that, but this will need a KiBi-ack, so CCing and
> tagging accordingly.

After talking to KiBi on IRC, we decided to include the fix for #958397
as well. I kept the changes minimal and only included 60-rules in
udev-udeb and the initramfs.

We might consider a different, opt-out approach for udev-rules in the
future as suggested by Steve [1] and Marco [2]. But that's probably too
invasive for a stable upload.

Updated debdiff is attached. The changes to the previous debdiff can be
found at
https://salsa.debian.org/systemd-team/systemd/-/commit/4b7f1d2b1763574cfc9ef43e728045518d440c1a


Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958397#12
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958397#22
diff --git a/debian/changelog b/debian/changelog
index 1d263f7..14ef57f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+systemd (241-7~deb10u4) buster; urgency=medium
+
+  * polkit: when authorizing via PolicyKit re-resolve callback/userdata
+instead of caching it.
+This fixes a heap use-after-free vulnerability in systemd, when
+asynchronous PolicyKit queries are performed while handling DBus messages.
+CVE-2020-1712 (Closes: #950732)
+  * Install 60-block.rules in udev-udeb and initramfs-tools.
+The block device rules were split out from 60-persistent-storage.rules
+into its own rules file in v220. Those rules ensure that change events
+are emitted and the udev db is updated after metadata changes.
+Thanks to Pascal Hambourg (Closes: #958397)
+
+ -- Michael Biebl   Mon, 27 Apr 2020 19:02:57 +0200
+
 systemd (241-7~deb10u3) buster; urgency=medium
 
   * core: set fs.file-max sysctl to LONG_MAX rather than ULONG_MAX.
diff --git a/debian/extra/initramfs-tools/hooks/udev 
b/debian/extra/initramfs-tools/hooks/udev
index 6305d09..bbbd351 100755
--- a/debian/extra/initramfs-tools/hooks/udev
+++ b/debian/extra/initramfs-tools/hooks/udev
@@ -28,7 +28,8 @@ if [ -d /etc/systemd/network ]; then
 fi
 
 mkdir -p "$DESTDIR/lib/udev/rules.d/"
-for rules in 50-firmware.rules 50-udev-default.rules 
60-persistent-storage.rules \
+for rules in 50-firmware.rules 50-udev-default.rules \
+60-block.rules 60-persistent-storage.rules \
 61-persistent-storage-android.rules 71-seat.rules 
73-special-net-names.rules \
 73-usb-net-by-mac.rules 75-net-description.rules \
 80-net-setup-link.rules 80-drivers.rules; do
diff --git a/debian/patches/Fix-typo-in-function-name.patch 
b/debian/patches/Fix-typo-in-function-name.patch
new file mode 100644
index 000..4f3c521
--- /dev/null
+++ b/debian/patches/Fix-typo-in-function-name.patch
@@ -0,0 +1,77 @@
+From: =?utf-8?q?Zbigniew_J=C4=99drzejewski-Szmek?= 
+Date: Tue, 4 Feb 2020 18:39:04 +0100
+Subject: Fix typo in function name
+
+(cherry picked from commit bc130b6858327b382b07b3985cf48e2aa9016b2d)
+(cherry picked from commit b4eb8848240c3540180e4768216a0b884a5ed783)
+(cherry picked from commit f14fa558ae9e139c94ee3af4a1ef1df313b2ff66)
+(cherry picked from commit dd8aa0871d9cafa60a916d4ec01dd82d64edf7ed)
+---
+ TODO| 2 +-
+ src/libsystemd/sd-bus/bus-message.h | 2 +-
+ src/libsystemd/sd-bus/sd-bus.c  | 8 
+ src/shared/bus-polkit.c | 2 +-
+ 4 files changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/TODO b/TODO
+index 462db57..327fead 100644
+--- a/TODO
 b/TODO
+@@ -138,7 +138,7 @@ Features:
+ 
+ * the a-posteriori stopping of units bound to units that disappeared logic
+   should be reworked: there should be a queue of units, and we should only
+-  enqeue stop jobs from a defer event that processes queue instead of
++  enqueue stop jobs from a defer event that processes queue instead of
+   right-away when we find a unit that is bound to one that doesn't exist
+   anymore. (similar to how the stop-unneeded queue has been reworked the same
+   way)
+diff --git a/src/libsystemd/sd-bus/bus-message.h 
b/src/libsystemd/sd-bus/bus-message.h
+index 7fd3f11..849d638 100644
+--- a/src/libsystemd/sd-bus/bus-message.h
 b/src/libsystemd/sd-bus/bus-message.h
+@@ -211,4 +211,4 @@ int bus_message_remarshal(sd_bus *bus, sd_bus_message **m);
+ 
+ void bus_message_set_sender_driver(sd_bus *bus, sd_bus_message *m);
+ void bus_message_set_sender_local(sd_bus *bus, sd_bus_message *m);
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m);
++int sd_bus_enqueue_for_read(sd_bus *bus, sd_bus_message *m);
+diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
+index 94380af..c20adcf 100644
+--- a/src/libsystemd/sd-bus/sd-bus.c
 b/src/libsystemd/sd-bus/sd-bus.c
+@@ -4145,7 +4145,7 @@ _public_ int sd_bus_get_close_on_exit(sd_bus *bus) {
+ return bus->close_on_exit;
+ }
+ 
+-int sd_bus_enqeue_for_read(sd_bus *bus, sd_bus_message *m) {
++int sd_bus_enqueue_for_read(sd_bus *bus, sd

Bug#926725: eric: No source code documentation provider

[Dave Hill]

There is a thread in the Eric issue tracker on solving this:

https://www.mail-archive.com/eric@riverbankcomputing.com/msg04281.html

Basically, the instruction is to install either of the rope or jedi 
plugins - in the plugins list, rope is called "Refactoring, Rope" and 
jedi is called "Completions, Jedi". You may need to to do Plugins, 
Plugins Repository, Update first. (In 19.x it's the Plugins menu item; 
in 20.x it's Extras, Plugins...)


Once you've installed the plugin, you need to select it as the Code Info 
Provider at the top of the Code Documentation Viewer on the far right.


This worked for me on Eric 19.01 and 20.3 - hope it helps,
David

On Tue, 09 Apr 2019 17:20:16 +0100 Kevin Steen  
wrote:


> Package: eric
> Version: 19.02.1+ds1-1
> Severity: normal
>
> On a new installation (Debian Buster), the Code Documentation Viewer 
window

> shows an error message: "No source code documentation provider has been
> registered"
>
> Looking through the settings, it seems all the paths to Python 
documentation

> are correct (and the paths contain html files.)
>
> I tried installing QT Assistant (package qt5-assistant) and 
re-starting Eric.

>
> I tried using the Plugin Repository to download and install the 
"Documentation

> Set, Python 3.5.2" but that also made no difference.
>
> Please can you advise how to enable the Code Documentation Viewer?
>
> Many thanks
> -Kevin
>
>
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: i386 (i686)
>
> Kernel: Linux 4.19.0-4-686-pae (SMP w/1 CPU core)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages eric depends on:
> ii libjs-jquery 3.3.1~dfsg-1
> ii libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2
> ii libjs-jquery-isonscreen 1.2.0-1
> ii libjs-jquery-tablesorter 1:2.31.1+dfsg1-1
> ii libjs-jquery-ui 1.12.1+dfsg-5
> ii python3 3.7.2-1
> ii python3-chardet 3.0.4-3
> ii python3-distutils 3.7.3~rc1-1
> ii python3-pygments 2.3.1+dfsg-1
> ii python3-pyqt5 5.11.3+dfsg-1+b3
> ii python3-pyqt5.qsci 2.10.4+dfsg-2
> ii python3-pyqt5.qtsql 5.11.3+dfsg-1+b3
> ii python3-pyqt5.qtsvg 5.11.3+dfsg-1+b3
> ii python3-pyqt5.qtwebkit 5.11.3+dfsg-1+b3
>
> Versions of packages eric recommends:
> ii eric-api-files 19.02.1+ds1-1
> pn python3-pyqt5.qtwebengine 
> ii python3-rope 0.10.5-3
>
> Versions of packages eric suggests:
> pn pyqt5-dev-tools 
> pn pyqt5-doc 
> ii python [python-profiler] 2.7.16-1

Bug#958984: ITP: python-drf-spectacular -- OpenAPI 3 schema generation for Django REST framework

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-drf-spectacular
  Version : 0.9.1
  Upstream Author : T. Franzel 
* URL : https://github.com/tfranzel/drf-spectacular/
* License : BSD-3-clause
  Programming Lang: Python
  Description : OpenAPI 3 schema generation for Django REST framework

 Sane and flexible OpenAPI 3 schema generation for Django REST framework. The
 code is a heavily modified fork of the DRF OpenAPI generator, which is/was
 lacking all of the below listed features:
 .
  * Serializers modelled as components (arbitrary nesting and recursion
supported)
  * Authentication support (DRF natives included, easily extendable)
  * Custom serializer class support
  * Tags extraction
  * Description extraction from docstrings
  * Sane fallbacks where no Serializer is available
  * Sane operation_id naming (based on path)
  * Easy to use hooks for extending the AutoSchema class
  * Optional schema serving with SpectacularAPIView

I do intend to maintain this package as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl6nDMIRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrBmwf9GRTefWYJTlCDu3egVIy0rvZnEbI93PlR
5DzFDMH24X58+uHNnfoCaHNQhlqfbbq0uxRIWexlTRxob+F/LWSMwrOmq5PAw9Tv
Vdv1HifKZunStdLztl/jBo3GJcPQGQJvpch0dMmC4eF61nRnFHNpJqlZ2azgitFc
pp/mVzCzkV8WzDGfS8Gepohm8tCgDpokWif1bFSwSN7Sjoxjj4lOX7XdxGkGKYTl
D0JljefmkdLCpARpc2x5OXTavpXLUhcLOU7W5/V8xhHVBbkoQJpmccZnzMHiFG2+
Z0lGBO8ScnNe95hNs6eVzo2QhsL7napufa1jQX+Z3ijCNrwycx5wAg==
=ig3Y
-END PGP SIGNATURE-

Bug#958948: simple-cdd on stretch fails with reprepro errors

[Vagrant Cascadian]

On 2020-04-27, Buck wrote:
> Running simple-cdd in default mode on fresh stretch installation fails as 
> follows:
>
> $ build-simple-cdd
> 2020-04-27 00:29:23 ERROR reprepro: updating package lists exited with code 
> 255
> 2020-04-27 00:29:23 ERROR Last 5 lines of standard error:
> 2020-04-27 00:29:23 ERROR reprepro: updating package lists: of the databases 
> belonging to those removed parts.
> 2020-04-27 00:29:23 ERROR reprepro: updating package lists: (Another reason 
> to get this error is using conf/ and db/ directories
> 2020-04-27 00:29:23 ERROR reprepro: updating package lists:  belonging to 
> different reprepro repositories).

This looks like you've run simple-cdd from a directory where tmp/mirror
already exists as a reprepro repository, but with a different
configuration (e.g. a run where bullseye was specified, and in the new
installation, you're attempting stretch?). Indeed, simple-cdd should
handle this scenario better.

The workaround is to wipe out the above mentioned conf and db
directories in the reprepro repository.


> 2020-04-27 00:29:23 ERROR reprepro: updating package lists: To ignore use 
> --ignore=undefinedtarget.
> 2020-04-27 00:29:23 ERROR reprepro: updating package lists: There have been 
> errors!
> 2020-04-27 00:29:23 ERROR reprepro failed with exit code: 255
>
> (Please note it does not seem possible to reply to replies to these Debian 
> bugs threads so replies may not be possible.)

You're not receiving the replies? You should be able to reply to
bugnum...@bugs.debian.org.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#958983: sphinx-celery: incompatible with sphinx 2+

[Mattia Rizzolo]

Source: sphinx-celery
Version: 1.3.1-2
Severity: serious

This theme is not compatible with sphinx 2.

There seems to be a new upstream available in
https://github.com/celery/sphinx_celery that at least has relevant
commits.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#958277: simple-cdd: Resulting Install CD asks for questions answered in the profiles/NAME.x files

[Vagrant Cascadian]

On 2020-04-27, Buck wrote:
> Yes sorry.  The command:
>
> `~/my-simple-cdd$ build-simple-cdd`
>
>> You may also want to use "--auto-profiles NAME" additionally
>
> Why?  The documentation is not clear how --auto-profiles vs --profiles works.

"profiles" defines which profiles are included in simple-cdd,
"auto-profiles" selects which profiles to use at run-time without asking
the user.


>> It would be helpful if you could provide your proposed profile in
>> more detail. 
>
>> Ideally, the exact commands you ran and the exact state of
>> the directory you're running them from.
>
> The command is above.  The state is that ~/my-simple-cdd/ has a
> profiles/ directory.  profiles/ directory contains custom.description,
> custom.packages, custom.postinst, custom.udebs, custom.preseed.  Do
> you want the details from each of these?

Yes, please include the contents of these files, otherwise it's
essentially impossible for me to understand what you're doing or what's
going wrong.

If you want to override parts of the "default" profile, you also need
~/my-simple-cdd/profiles/default.* as well. The "default" profile is
always included, and for questions asked very early in debian-installer,
the only way to preseed some questions using simple-cdd. That said, not
including or aggressively overriding contents in the default profile is
possible to break how simple-cdd works, so be selective in what you
override. In general, I've tried to make the default profile not too
intrusive, so it shouldn't need to be overridden in most cases...


>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>
> I have been changing Debian versions, thinking the problem is bugs in
> simple-cdd, tasksel, or reprepro.  Different erros come up with
> different versions.  All are being reported.
>
>> If you want to override the built-in profiles, you need to create
>> replacement files (e.g. profiles/default.preseed,
>> profiles/default.*), though I would generally recommend providing
>> additional profiles rather than overriding the default profiles.
>
> I did the latter of these, added profiles/custom.X files.  However
> when I do this, I get this current error where the CD is created and
> it looks like a normal Debian installer that asks quesitons that I
> believe are answered in the custom.preseed file.

The custom.preseed file may not be loaded till later in the process; it
depends on which questions you're thinking are answered by it. There is
a question during the install that asks which simple-cdd profiles to
load; any pquestions asked before that obviously can't be preseeded.


> I also tried using a default-custom (as in, a template for X.preseed
> that I found online) and this also build a default Debian install CD.
>
>>* What was the outcome of this action?
>>
>>  New error: $default_desktop not defined
>
> The error for this bug is not an error message, it is a working Debian
> installer CD that behaves different from I expect, becaues it behaves
> like a default Debian installer.
>
> But what is reporting error
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958276
> ($default_desktop) is the output of build-simple-cdd.

Where do you expect $default_desktop to be defined? Again, including
the actual files you're trying to use would make it a *lot* easier for
me to see what you're doing, or even reproduce whatever issue you're
having if it is indeed a bug.


>> It will read the profiles from profiles in your working directory,
>
> This does not happen, but I am happy that you say this is what should
> happen.  That tells me that there is a bug that is preventing my
> ~/my-simple-cdd/profiles/custom.X files being read.  It is also
> possible I have a bad config but I don't think so because I tried a
> default custom config.

Are you running from ~ or running from ~/my-simple-cdd ?


> Can you suggest a config I should use to test, that will create a
> Debian installer that is different from default to verify that this
> preseed is being read?

you can just specify one of the profiles in
/usr/share/simple-cdd/profiles, preferably in a directory that does not
contain any "profiles" directory:

  simple-cdd --profiles router,x-basic

That should create an installer image that prompts weather or not to
load the router and x-basic profiles during the install, and then loads
the profiles you've asked for, or if you select none of them, a minimal
install just using the default profile.

If that's not working, then there's definitely a bug in simple-cdd.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#958934: bind9: named fails to start after upgrade to 9.16.2

[Andreas Hasenack]

Also check if you don't have systemd overrides in place, that could be
preventing named from writing to certain directories:

systemctl cat bind9.service

On Mon, Apr 27, 2020 at 1:04 PM Simon Deziel  wrote:
>
> On 2020-04-27 11:33 a.m., Scott Bailey wrote:
> > buzz:~# journalctl -k -b0 | grep -F apparmor
> > buzz:~#
> >
> > So whatever's going on, it doesn't look like AppArmor has anything to do 
> > with it.
>
> To completely rule out Apparmor, please share the following:
>
> aa-enabled
> sudo aa-status | grep -E '^[0-9]+|named'
>
> Thanks,
> Simon
>

Bug#952544: driver 340.108 kernel crash at boot

[Andreas Beckmann]

Control: tag -1 - moreinfo
Control: close -1

On 27/04/2020 13.22, Frédéric Lamorce wrote:
> Thanks for your answer. I understand. I googled a little bit and found it
> may be a GCC problem, so I upgrade from GCC 6.4 to 7.3, re-installed the
> driver, and it works now.

The out-of-tree (e.g. nvidia) kernel modules need to be compiled with
the same version as the kernel was built. This usually works
out-of-the-box for the Debian kernel headers (they depend on and call
the correct compiler version), but I have no idea about others.

I'll close this bug report now.


Andreas

Bug#958934: bind9: named fails to start after upgrade to 9.16.2

[Scott Bailey]

Here you go -- I have no idea what I am looking at...

buzz:~# aa-enabled
Yes
buzz:~# aa-status | grep -E '^[0-9]+|named'
43 profiles are loaded.
40 profiles are in enforce mode.
   /usr/sbin/named
   named
3 profiles are in complain mode.
79 processes have profiles defined.
77 processes are in enforce mode.
   /usr/sbin/named (209351)
2 processes are in complain mode.
0 processes are unconfined but have a profile defined.
buzz:~#

You didn't ask, but I can sense the inevitable follow-on questions:

buzz:~# dpkg -S /etc/apparmor.d/usr.sbin.named
bind9: /etc/apparmor.d/usr.sbin.named
buzz:~# dpkg -V bind9
??5?? c /etc/bind/named.conf.local
??5?? c /etc/bind/named.conf.options
buzz:~#

Of course, this is the stable package, but I'll add this to my list of things 
to look at when I retry 9.16.2 (perhaps tonight)...

Thanks,

Scott

-Original Message-
From: Simon Deziel  
Sent: Monday, April 27, 2020 11:43 AM
To: Scott Bailey ; 958...@bugs.debian.org
Subject: Re: Bug#958934: bind9: named fails to start after upgrade to 9.16.2

On 2020-04-27 11:33 a.m., Scott Bailey wrote:
> buzz:~# journalctl -k -b0 | grep -F apparmor
> buzz:~#
> 
> So whatever's going on, it doesn't look like AppArmor has anything to do with 
> it.

To completely rule out Apparmor, please share the following:

aa-enabled
sudo aa-status | grep -E '^[0-9]+|named'

Thanks,
Simon

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Sergey B Kirpichev]

tags 902204 +fixed-upstream
forwarded 902204 
https://bitbucket.org/tildeslash/monit/issues/840/regression-failed-link-check-generates
thanks

Bug#958384: [Pkg-utopia-maintainers] Bug#958384: network-manager: Crash after connecting to OpenVPN

[Mirko]

Thank you for your fast reply. I finally managed to raise the issue to
upstream.

On Tuesday, 21.04.20 at 12:21, Michael Biebl wrote:
> That said, there might be a real issue here, so I would ask you to raise
> this at
>  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues
> so the upstream developers can have a look.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/425

Cheers,
Mirko

Bug#958925: grub-efi: Does not sign EFI entries.

[Santiago José López Borrazás]

El 27/4/20 a las 17:36, Steve McIntyre escribió:
> Can you run the following for me please?
> $ COLUMNS=100 dpkg -l '*grub*'
>
> We did have a problem with the signed versions of grub binaries taking
> a few days to come through the archive, in combination with too-tight
> dependencies (bug #958722). That *might* have caused you to uninstall
> the grub-efi-amd64-signed by accident.
>
> Things should now be fixed, I believe - let's see how your system is
> set up.

I, what I have are these packages:

ii  grub-common  
2.04-7  amd64    GRand Unified Bootloader
(common files)
ii  grub-efi 
2.04-7  amd64    GRand Unified Bootloader,
version 2 (dummy package)
ii  grub-efi-amd64   
2.04-7  amd64    GRand Unified Bootloader,
version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin   
2.04-7  amd64    GRand Unified Bootloader,
version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed
1+2.04+7    amd64    GRand Unified Bootloader,
version 2 (amd64 UEFI signed by Debian)
ii  grub-efi-amd64-signed-template   
2.04-7  amd64    GRand Unified Bootloader,
version 2 (EFI-AMD64 signing template)
ii  grub2-common 
2.04-7  amd64    GRand Unified Bootloader
(common files for version 2)

With "grub-install / dev / sda" I had no problems, nor with "update-grub".

Which doesn't tell me anything.

Which does not give me errors. It's weird, because it doesn't tell me anything.

Possibly what you are saying, which is due to the problem of the
grub-efi-amd64-signed package, that I have installed.

I don't see another one, because without "Secure Boot" I fit perfectly, with
"Secure Boot" not.

-- 
Saludos de Santiago José López Borrazás.
Enviando desde Mozilla Thunderbird.

Bug#958934: bind9: named fails to start after upgrade to 9.16.2

[Simon Deziel]

On 2020-04-27 11:33 a.m., Scott Bailey wrote:
> buzz:~# journalctl -k -b0 | grep -F apparmor
> buzz:~#
> 
> So whatever's going on, it doesn't look like AppArmor has anything to do with 
> it.

To completely rule out Apparmor, please share the following:

aa-enabled
sudo aa-status | grep -E '^[0-9]+|named'

Thanks,
Simon

Bug#958925: grub-efi: Does not sign EFI entries.

[Steve McIntyre]

On Mon, Apr 27, 2020 at 05:25:10PM +0200, Santiago José López Borrazás wrote:
>El 27/4/20 a las 17:07, Steve McIntyre escribió:
>> I'm sorry, I don't understand what you're saying here. Can you please
>> explain a little more? What exactly are you trying to do? What exactly
>> is happening that you don't expect?
>Nothing, installing the new Grub 2.0.4-7 packages, which are already in the
>unstable branch.
>
>It is that, it is rare, that when I tried to install everything, the boot in
>safe mode does not recognize me in UEFI mode. I had to remove the "Secure
>boot" to enter Linux, because in another Win partition it does work.
>
>I did nothing, just install the packages that had to be for the boot to work
>in EFI.
>
>Therefore, it does not allow me to enter "secure boot", if I remove it, I
>enter perfectly.
>
>This, in 2.0.4-6, does not happen to me, or that I have not had any problem,
>and yes in this new version. And it's weird.

Can you run the following for me please?

$ COLUMNS=100 dpkg -l '*grub*'

We did have a problem with the signed versions of grub binaries taking
a few days to come through the archive, in combination with too-tight
dependencies (bug #958722). That *might* have caused you to uninstall
the grub-efi-amd64-signed by accident.

Things should now be fixed, I believe - let's see how your system is
set up.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#958934: bind9: named fails to start after upgrade to 9.16.2

[Scott Bailey]

Thanks, Simon!

buzz:~# journalctl -k -b0 | grep -F apparmor
buzz:~#

So whatever's going on, it doesn't look like AppArmor has anything to do with 
it.

Cheers,

Scott

-Original Message-
From: Simon Deziel  
Sent: Monday, April 27, 2020 10:10 AM
To: Scott Bailey ; 958...@bugs.debian.org
Subject: Re: Bug#958934: bind9: named fails to start after upgrade to 9.16.2

On 2020-04-27 9:34 a.m., Scott Bailey wrote:
> Does anybody have any additional suggestions on what to look at the next time 
> I start a troubleshooting session?

Apparmor denials show up in kernel logs, so dmesg/journalctl -k are good
places to look.

  sudo journalctl -k -b0 | grep -F 'apparmor="DENIED"'

HTH,
Simon

Bug#958981: ITP: xreader -- A generic document reader

[Hugo Ziviani]

Package: wnpp
Severity: wishlist

Starting working on the packing for xreader.
Available on: (https://github.com/linuxmint/xreader)

hugoziviani

Bug#958925: grub-efi: Does not sign EFI entries.

[Santiago José López Borrazás]

El 27/4/20 a las 17:07, Steve McIntyre escribió:
> I'm sorry, I don't understand what you're saying here. Can you please
> explain a little more? What exactly are you trying to do? What exactly
> is happening that you don't expect?
Nothing, installing the new Grub 2.0.4-7 packages, which are already in the
unstable branch.

It is that, it is rare, that when I tried to install everything, the boot in
safe mode does not recognize me in UEFI mode. I had to remove the "Secure
boot" to enter Linux, because in another Win partition it does work.

I did nothing, just install the packages that had to be for the boot to work
in EFI.

Therefore, it does not allow me to enter "secure boot", if I remove it, I
enter perfectly.

This, in 2.0.4-6, does not happen to me, or that I have not had any problem,
and yes in this new version. And it's weird.

--
Saludos de Santiago José López Borrazás.
Enviando desde Mozilla Thunderbird.

Bug#958980: apt install chromium needs removing 141 other packages

[Pierre]

Package: chromium

Severity: grave
Justification: causes non-serious data loss
Tags: a11y d-i

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***


   * What led up to the situation?
   I need to install chromium for visio meeting web application

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 sudo install chromium

   * What was the outcome of this action?
pierre@Hermes:~$ sudo apt install chromium
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus 
nécessaires :
  accountwizard ant-contrib apg apt-config-icons-large baloo-kf5 
bluez-obexd brasero-common breeze breeze-cursor-theme
  breeze-icon-theme cdparanoia cdrdao cheese-common coinor-libcbc3 
coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5
  coinor-libcoinutils3v5 coinor-libosi1v5 cups-browsed cups-daemon 
cups-ipp-utils cups-pk-helper cups-ppdc
  cups-server-common digikam-data dleyna-server dnsmasq-base 
dvd+rw-tools evince-common faad ffmpegthumbs
  firebird3.0-common firebird3.0-common-doc firebird3.0-server-core 
firebird3.0-utils fonts-hack fonts-opensymbol
  foomatic-db-compressed-ppds foomatic-db-engine foomatic-filters 
frameworkintegration gdal-data gir1.2-clutter-1.0
  gir1.2-clutter-gst-3.0 gir1.2-cogl-1.0 gir1.2-coglpango-1.0 
gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0
  gir1.2-gtkclutter-1.0 gir1.2-gtksource-3.0 
gir1.2-javascriptcoregtk-4.0 gir1.2-json-1.0 gir1.2-notify-0.7
  gir1.2-packagekitglib-1.0 gir1.2-secret-1 gir1.2-soup-2.4 
gir1.2-webkit2-4.0 gkbd-capplet gnome-control-center-data
  gnome-online-accounts gnome-settings-daemon gnome-user-docs growisofs 
gstreamer1.0-clutter-3.0 hp-ppd iceweasel kamera
  kde-config-gtk-style kde-config-sddm kde-style-breeze 
kde-style-breeze-qt4 kde-style-oxygen-qt5 kde-style-qtcurve-qt4
  kde-style-qtcurve-qt5 kdepim-themeeditors kgamma5 khotkeys 
khotkeys-data kimageformat-plugins kio-extras
  kio-extras-data kio-ldap kipi-plugins-common kmenuedit kscreen 
ksysguard ksysguardd kwin-style-breeze kwrited
  libabw-0.1-1 libadplug-2.2.1-0v5 libaec0 libaopalliance-java 
libapache-poi-java libappstreamqt2 libargs4j-java
  libarmadillo9 libarpack2 libasm-java libass5 libastro1 libaudiofile1 
libavresample2 libbase-java libbinio1v5
  libboost-atomic1.67.0 libboost-date-time1.67.0 
libboost-filesystem1.67.0 libboost-iostreams1.67.0
  libboost-locale1.67.0 libboost-thread1.67.0 libbsh-java libburn4 
libcdi-api-java libcdio-cdda1 libcdio-paranoia1
  libcdio13 libcdr-0.1-1 libcglib-java libcharls2 
libclucene-contribs1v5 libclucene-core1v5 libclutter-gst-3.0-0
  libcodemodel-java libcolorcorrect5 libcolord-gtk1 libcommons-cli-java 
libcommons-codec-java
  libcommons-collections3-java libcommons-collections4-java 
libcommons-compress-java libcommons-math3-java libcue2
  libcurvesapi-java libdap25 libdapserver7v5 libdirac-decoder0 
libdirac-encoder0 libdirectfb-1.2-9
  libdleyna-connector-dbus-1.0-1 libdleyna-core-1.0-3 
libdmapsharing-3.0-2 libdtd-parser-java libe-book-0.1-1
  libehcache-java libenca0 libeot0 libepsilon1 libepub0 
libepubgen-0.1-1 libetonyek-0.1-1 libexttextcat-2.0-0
  libfastinfoset-java libfbclient2 libflute-java libfontembed1 
libfonts-java libformula-java libfreehand-0.1-1
  libfreexl1 libfyba0 libgdata-common libgdcm2.8 libgeoclue-2-0 
libgeocode-glib0 libgeos-3.7.1 libgeos-c1v5 libgeotiff2
  libgeronimo-annotation-1.3-spec-java 
libgeronimo-interceptor-3.0-spec-java libgif4 libgjs0g libgnome-bluetooth13
  libgoa-1.0-0b libgoa-1.0-common libgoa-backend-1.0-1 libgom-1.0-0 
libgps23 libgsf-1-114 libgsf-1-common libgsl23
  libgslcblas0 libgspell-1-1 libgspell-1-common libgssdp-1.0-3 
libgstreamer-plugins-bad1.0-0 libgtkmm-2.4-1v5
  libgtksourceview-3.0-1 libgtksourceview-3.0-common libgtkspell0 
libgtop-2.0-11 libguava-java libguice-java
  libgupnp-1.0-4 libgupnp-av-1.0-2 libgupnp-dlna-2.0-3 
libgupnp-igd-1.0-4 libgutenprint-common libgutenprint9
  libgweather-3-15 libgweather-common libgxps2 libhdf4-0-alt 
libhdf5-103 libhpmud0 libhsqldb1.8.0-java
  libhttpclient-java libhttpcore-java libib-util libibus-1.0-5 
libicu4j-java libintellij-annotations-java libiptcdata0
  libiso9660-11 libisofs6 libistack-commons-java libitext-java 
libjaxb-java libjcommon-java
  libjetbrains-annotations-java libjs-sphinxdoc libjsr305-java libjte1 
libkeybinder0 libkf5akonadicalendar-data
  libkf5akonadicalendar5abi1 libkf5alarmcalendar-data 
libkf5alarmcalendar5abi1 libkf5calendarsupport-data
  libkf5calendarsupport5abi1 libkf5calendarutils5 libkf5eventviews-data 
libkf5eventviews5abi1 libkf5incidenceeditor-data
  libkf5incidenceeditor5abi1 libkf5jsapi5 libkf5jsembed-data 
libkf5jsembed5 libkf5kaddressbookimportexport5
  libkf5kexiv2-15.0.0 libkf5kmanagesieve5 libkf5konq6 libkf5ksieve-data 
libkf5ksieve5 libkf5ksieveui5
  libkf5mailcommon-data libkf5mailcommon5abi2 libkf5mail