Bug#970259: Weather API update

[Pavel R.]

Hello, I've fixed the plugin by bumping weather API version to 2.0

Patch is attached

--- xfce4-weather-plugin-0.8.10.orig/panel-plugin/weather.c
+++ xfce4-weather-plugin-0.8.10/panel-plugin/weather.c
@@ -619,17 +619,14 @@ update_handler(plugin_data *data)
 end_tm = *localtime(_t);
 
 /* build url */
-url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/1.1/?;
+url = g_strdup_printf("https://api.met.no/weatherapi/sunrise/2.0/?;
   "lat=%s;lon=%s;"
-  "from=%04d-%02d-%02d;"
-  "to=%04d-%02d-%02d",
+  "date=%04d-%02d-%02d;"
+  "offset=00:00",
   data->lat, data->lon,
   now_tm.tm_year + 1900,
-  now_tm.tm_mon + 1,
-  now_tm.tm_mday,
-  end_tm.tm_year + 1900,
-  end_tm.tm_mon + 1,
-  end_tm.tm_mday);
+  now_tm.tm_mon + 1, 
+  now_tm.tm_mday);
 
 /* start receive thread */
 g_message(_("getting %s"), url);
@@ -647,8 +644,8 @@ update_handler(plugin_data *data)
 /* build url */
 url =
 g_strdup_printf("https://api.met.no/weatherapi;
-"/locationforecastlts/1.3/?lat=%s;lon=%s;msl=%d",
-data->lat, data->lon, data->msl);
+"/locationforecast/2.0/classic?lat=%s;lon=%s",
+data->lat, data->lon);
 
 /* start receive thread */
 g_message(_("getting %s"), url);

Bug#963522: WebKitWebProcess: random crash (SIGSEGV)

[Paul Wise]

Control: close -1

On Tue, 2020-09-15 at 23:35 +0200, Alberto Garcia wrote:

> Have you been able to reproduce this problem again? If you have you
> could try to see if it also happens with 2.30.0.

I haven't had any further crashes in WebKitWebProcess and I don't have
any method to reproduce the original crash.

> If it happened only once I'm tempted to close this bug until you hit
> this problem again.

That seems reasonable, I'll reopen if the same thing happens again.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#939264: Fwd: [cyrusimap/cyrus-imapd] Mailboxes with children are reported as "(\HasNoChildren)" if mailbox with similar name (#3182)

[Xavier]

Response from GitHub:

 Message transféré 
Subject :   Re: [cyrusimap/cyrus-imapd] Mailboxes with children are
reported as "(\HasNoChildren)" if mailbox with similar name (#3182)
Date :  Tue, 15 Sep 2020 18:35:43 -0700
>From : elliefm 
Reply To :  cyrusimap/cyrus-imapd

To :cyrusimap/cyrus-imapd 



The problem is that the internal mailbox separator is ASCII '.', which
sorts /after/ valid mailbox characters like '-' and space. It's fixed by
enabling the following setting in imapd.conf:

|improved_mboxlist_sort: 0 If enabled, a special comparator will be
used which will correctly sort mailbox names that contain characters
such as ' ' and '-'. Note that this option SHOULD NOT be changed on
a live system. The mail‐ boxes database should be dumped
(ctl_mboxlist) before the option is changed, removed, and then
undumped after changing the option. When not using flat files for
the subscriptions databases the same has to be done (cyr_dbtool) for
each subscription database See improved_mboxlist_sort.html. |

Ideally this setting would default to enabled, or indeed, be the only
behaviour (with no option at all). But it has ramifications for existing
deployments, so we can't just change it. I assume that it's not simply
enabled in the imapd.conf that the Debian package ships for much the
same reason.

The "improved_mboxlist_sort.html" referenced in the man page seems to be
https://www.cyrusimap.org/imap/developer/thoughts/improved_mboxlist_sort.html

The problem they're seeing (as well as other similar issues between
similarly-named folders that differ by a character that sorts before
ASCII '.') are unfixable in stable releases without enabling this option.

I don't understand all the ramifications of an admin changing the
improved_mboxlist_sort option. It might be as "simple" as the
documentation suggests (dumping and undumping mailboxes and subscription
databases) or it might be more complicated these days. I'd suggest they
join the info-cyrus list
 and see if
anyone has been through this process recently and has guidance to offer.

Bug#970421: apparmor limit blocks temperature reading

[Matt Corallo]

Package: chrony
Version: 3.4-4

Current apparmor profile for chrony lists
@{sys}/class/hwmon/hwmon[0-9]*/temp[0-9]*_input r,

which is great (and even how I have mine configured -
tempcomp /sys/class/hwmon/hwmon0/temp1_input 1 0 0 0 0) but it doesn't actually 
work. It results in lots of log lines like

Sep 15 23:06:37 gw.as397444.net audit[24397]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/chronyd" 
name="/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input" pid=24397 comm="chronyd" requested_mask="r" 
denied_mask="r" fsuid=112 ouid=0

Sep 15 23:06:37 gw.as397444.net chronyd[24397]: Could not read temperature from 
/sys/class/hwmon/hwmon0/temp1_input
Sep 15 23:06:37 gw.as397444.net kernel: audit: type=1400 audit(1600225597.313:127): apparmor="DENIED" operation="open" 
profile="/usr/sbin/chronyd" name="/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input" pid=24397 
comm="chronyd" requested_mask="r" denied_mask="r" fsuid=112 ouid=0


Looks like somehow apparmor is resolving the file to a different path, 
checking, and then failing it.

An extra line like the following fixes it:
@{sys}/devices/virtual/thermal/thermal_zone[0-9]*/hwmon[0-9]*/temp[0-9]*_input 
r,

Matt

Bug#969835: iwatch: autopkgtest should be marked superficial

[Eriberto Mota]

Please, can you explain why this bug is marked as serious?

Regards,

Eriberto

Bug#970420: python: Unmet dependencies when installing python package

[Koutheir Attouchi]

Package: python
Version: 2.7.17-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: kouth...@gmail.com

Dear Maintainer,

What led up to the situation?

```
$ sudo apt-get install python
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python : PreDepends: python-minimal (= 2.7.17-2) but it is not going to be
installed
  Depends: libpython-stdlib (= 2.7.17-2) but it is not going to be
installed
  Depends: python2 (= 2.7.17-2) but 2.7.18-2 is to be installed
E: Unable to correct problems, you have held broken packages.
```

In order to keep other python packages, I marked the `python2` and `python3`
packages as manually installed.



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

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

Versions of packages python depends on:
pn  libpython-stdlib  
pn  python-minimal
ii  python2   2.7.18-2
ii  python2.7 2.7.18-1

python recommends no packages.

Versions of packages python suggests:
pn  python-doc  
ii  python-tk   2.7.18-1

Bug#970419: lilyterm: No longer starts (likely related to VTE changes)

[James Tocknell]

Package: lilyterm
Version: 0.9.9.4+git20150208.f600c0-5
Severity: grave
Justification: renders package unusable

It appears that lilyterm is unable to start, running lilyterm gives the
following errors:

** Message: 11:20:26.198: Can NOT connect to a existing lilyterm socket!

(lilyterm:4801): Gtk-WARNING **: 11:20:26.267: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): Gtk-WARNING **: 11:20:26.267: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): Gtk-WARNING **: 11:20:26.267: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): Gtk-WARNING **: 11:20:26.267: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): VTE-CRITICAL **: 11:20:26.268: gboolean 
vte_terminal_spawn_sync(VteTerminal*, VtePtyFlags, const char*, char**, char**, 
GSpawnFlags, GSpawnChildSetupFunc, gpointer, GPid*, GCancellable*, GError**): 
assertion 'envv == nullptr ||_vte_pty_check_envv(envv)' failed

(lilyterm:4801): Gtk-WARNING **: 11:20:26.268: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): Gtk-WARNING **: 11:20:26.268: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): Gtk-WARNING **: 11:20:26.268: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): Gtk-WARNING **: 11:20:26.268: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4801): VTE-CRITICAL **: 11:20:26.268: void 
vte_terminal_match_set_cursor_type(VteTerminal*, int, GdkCursorType): assertion 
'tag >= 0' failed

(lilyterm:4801): VTE-CRITICAL **: 11:20:26.268: void 
vte_terminal_match_set_cursor_type(VteTerminal*, int, GdkCursorType): assertion 
'tag >= 0' failed

(lilyterm:4801): VTE-CRITICAL **: 11:20:26.269: void 
vte_terminal_match_set_cursor_type(VteTerminal*, int, GdkCursorType): assertion 
'tag >= 0' failed

(lilyterm:4801): VTE-CRITICAL **: 11:20:26.269: void 
vte_terminal_match_set_cursor_type(VteTerminal*, int, GdkCursorType): assertion 
'tag >= 0' failed

and running lilyterm with -s gives:

(lilyterm:4807): Gtk-WARNING **: 11:20:57.451: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): Gtk-WARNING **: 11:20:57.451: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): Gtk-WARNING **: 11:20:57.452: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): Gtk-WARNING **: 11:20:57.452: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): VTE-CRITICAL **: 11:20:57.453: gboolean 
vte_terminal_spawn_sync(VteTerminal*, VtePtyFlags, const char*, char**, char**, 
GSpawnFlags, GSpawnChildSetupFunc, gpointer, GPid*, GCancellable*, GError**): 
assertion 'envv == nullptr ||_vte_pty_check_envv(envv)' failed

(lilyterm:4807): Gtk-WARNING **: 11:20:57.453: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): Gtk-WARNING **: 11:20:57.453: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): Gtk-WARNING **: 11:20:57.454: Theme parsing error: 
:2:32: The style property GtkWidget:focus-line-width is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): Gtk-WARNING **: 11:20:57.454: Theme parsing error: 
:3:29: The style property GtkWidget:focus-padding is deprecated and 
shouldn't be used anymore. It will be removed in a future version

(lilyterm:4807): VTE-CRITICAL **: 11:20:57.454: void 
vte_terminal_match_set_cursor_type(VteTerminal*, int, GdkCursorType): assertion 
'tag >= 0' failed

(lilyterm:4807): VTE-CRITICAL **: 

Bug#969608: [Debian-med-packaging] Bug#969608: makeblastdb 2.10.x on 32-bit architectures

[Aaron M. Ucko]

Étienne Mollier  writes:

> Wow, thanks for the comprehensive background information.  In

No problem.

> case someone else (me in a not so near future for instance)
> stumbles upon this again, I keep note that reducing the size of
> BLASTDB_LMDB_MAP_SIZE a bit might help:

One final clarification: This variable is an override, not a cap, so any
unconditional settings thereof should be low enough to work on 32-bit
systems.

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

Bug#970418: RFS: 2vcard/0.6-4 [QA] [RC] -- convert an addressbook to VCARD file format

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "2vcard":

 * Package name: 2vcard
   Version : 0.6-4
   Upstream Author : Jan Schaumann 
 * URL : https://www.netmeister.org/apps/2vcard/
 * License : BSD-3-Clause
 * Vcs : https://salsa.debian.org/debian/2vcard
   Section : utils

It builds those binary packages:

  2vcard - convert an addressbook to VCARD file format

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

  https://mentors.debian.net/package/2vcard/

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

  dget -x https://mentors.debian.net/debian/pool/main/2/2vcard/2vcard_0.6-4.dsc

Changes since the last upload:

 2vcard (0.6-4) unstable; urgency=medium
 .
   * QA upload.
   * debian/control: bumped 'debhelper-compat' in Build-Depends field to 13.
   * debian/copyright:
   - Added myself in packaging block.
   - Added Upstream-Contact field.
   * debian/tests/control: test marked as superficial. (Closes: #969795)

If someone is willing to sponsor this package, could also, please, grant me 
rights
on salsa repository so that I can commit the updates?

Cheers,

-- 
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E



signature.asc
Description: OpenPGP digital signature

Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS

[Finn Thain]

On Wed, 16 Sep 2020, Thorsten Glaser wrote:

> Finn Thain dixit:
> 
> >I think it would be helpful to everyone if nocheck could be avoided 
> >where possible. I wonder where is that possible.
> 
> I'd prefer if it could be added only for problematic packages, or done 
> in porter uploads, but on the buildds not for all packages.
> 

If the problem was build time, one solution could be to enable 'make 
check' at random (for slow packages) with some predetermined probability 
needed to reach the desired average buildd throughput.

> >Which architectures are using nocheck?
> 
> According to the list in, I think, GCC, which I copied, that is on m68k 
> and sh4. (The package I copied from ignores nocheck on these 
> architectures as well, as protection from greater issues.)
> 

I wonder whether sh4 and m68k have the same reason for using nocheck.

> >Would it help if test failures could be triaged, such that an "ENOMEM" 
> >result could be treated as "undecided", since that is what it is?
> 
> I highly doubt that. Test failures abort the build, and you can't just 
> carry on afterwards.
> 

It's normal for the build to carry on after a "skipped" test. And nocheck 
just means skip all tests, right?

Treating "ENOMEM" like "skipped" for certain tests is probably more 
correct in many instances than treating it like "failed".

The implementation of that logic would probably have to be made acceptable 
to upstream developers however.

> Plus I think these aren't even the problems; problematic is when the 
> testsuite hangs the buildd. (But even so, builds are killed after some 
> time of inactivity, normally.)
> 

I can see that being a problem at 66 MHz but is it still a problem for 
qemu-user or qemu-system?

Bug#946900: latest neomutt no longer uses account-hook for initial login [regression]

[Marvin Renich]

* Antonio Radici  [200624 08:00]:
> Control: tag -1 +moreinfo
> 
> Can you provide an example configuration that allow us to reproduce this bug
> against the version that is currently on sid?

The only things necessary are "set spoolfile=...", "mailboxes ...", and
an account-hook that sets imap_user and imap_pass for the account used
in the common imap spoolfile/mailbox.

This simple file demonstrates the bug for me in a relatively clean
buster VM with neomutt from unstable:

set realname="Your Name"
set from="y...@example.com"
set use_from
set spoolfile="imap://mail.example.com/inbox"
set folder="imap://mail.example.com"
mailboxes imap://mail.example.com/inbox
account-hook imap://mail.example.com/ 'set imap_user=you imap_pass=secret'

(Obviously, use a real imap server and account.)

If you comment out the mailboxes line, you are not prompted.  In my
real setup, mailboxes contains a list of folders, and I have "set
sidebar_visible=yes".

...Marvin

Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS

[Thorsten Glaser]

Finn Thain dixit:

>I think it would be helpful to everyone if nocheck could be avoided where
>possible. I wonder where is that possible.

I’d prefer if it could be added only for problematic packages, or
done in porter uploads, but on the buildds not for all packages.

>Which architectures are using nocheck?

According to the list in, I think, GCC, which I copied, that is on
m68k and sh4. (The package I copied from ignores nocheck on these
architectures as well, as protection from greater issues.)

>Why is it needed for qemu-user on m68k?

It is not needed to build mksh under qemu-user on m68k.

(In fact, mksh’s build process uses the testsuite to determine
whether the klibc-built, musl-built, and/or dietlibc-built
binary of mksh-static works well enough to promote it to /bin/
and uses the same library to compile the lksh binary as well;
if nocheck is given or all three other libraries fail, glibc
(the system libc) is used but it’s… much less suitable, for
static linking especially; this works, e.g. on kfreebsd/hurd,
but glibc is… a moloch.)

>Would it help if test failures could be triaged, such that an "ENOMEM"
>result could be treated as "undecided", since that is what it is?

I highly doubt that. Test failures abort the build, and you
can’t just carry on afterwards.

Plus I think these aren’t even the problems; problematic is
when the testsuite hangs the buildd. (But even so, builds are
killed after some time of inactivity, normally.)

I’d prefer the reason to add nocheck for m68k and sh4 qemu buildds
to be revisited. (Also, do any ARAnyM and bare-metal buildds use
this as well?) Unless needed for qemu-specific reasons, it was a
great tool while helping to get the port back into shape, and I
occasionally need it on porter uploads where the broken functionality
is less important than having the library available as build depen‐
dency, but that is rare and always manual.

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#970417: bind-host: missing 'host' binary

[Eldon Koyle]

Package: bind-host
Version: 1:9.13.3-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The `bind-host` package in experimental is missing both the executable
and the manpage.

esk@esk-xps:~$ dpkg -L bind-host
/.
/usr
/usr/bin
/usr/share
/usr/share/doc
/usr/share/doc/bind-host
/usr/share/doc/bind-host/changelog.Debian.amd64.gz
/usr/share/doc/bind-host/changelog.Debian.gz
/usr/share/doc/bind-host/changelog.gz
/usr/share/doc/bind-host/copyright
/usr/share/man
/usr/share/man/man1
esk@esk-xps:~$

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bind-host depends on:
ii  bind-libs  1:9.13.3-1+b1
ii  libc6  2.31-1
ii  libidn2-0  2.3.0-1
ii  libssl1.1  1.1.1g-1

bind-host recommends no packages.

bind-host suggests no packages.

-- debconf-show failed

-- 
Eldon Koyle

Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS

[Finn Thain]

On Tue, 15 Sep 2020, John Paul Adrian Glaubitz wrote:

> > 
> >> On m68k and sh4, the buildds are currently configured to pass 
> >> "nocheck"
> > 
> > Precisely for this reason, some packages in the archive ignore that on 
> > these architectures.
> > 
> > Without the testsuite we cannot reliably build due to bugs in the 
> > toolchain, and it doesn’t run for long anyway.
> 
> I understand the reasoning but it's nevertheless incorrect.
> 
> If you want to see a testsuite being run, you can ask the buildd 
> maintainers or test the package yourself. But you shouldn't arbitrarily 
> override policy-defined mechanisms so that a package behaves 
> unexpectedly.
> 

Arguably, downstream should try to avoid arbitrarily overriding upstream 
policy. But instead of arbitrating the arbiters, perhaps we can discuss 
the root cause.

> "nocheck" will remain activated as long as we're using qemu-user over 
> qemu-system which will be the case until the kernel on the affected 
> architectures can use more RAM on emulated systems.
> 

I think it would be helpful to everyone if nocheck could be avoided where 
possible. I wonder where is that possible.

Which architectures are using nocheck?

Why is it needed for qemu-user on m68k?

Would it help if test failures could be triaged, such that an "ENOMEM" 
result could be treated as "undecided", since that is what it is?

Bug#970416: ITP: pbmm2 -- minimap2 SMRT wrapper for PacBio data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: pbmm2 -- minimap2 SMRT wrapper for PacBio data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: pbmm2
  Version : 1.3.0
  Upstream Author : , Pacific Biosciences of California, Inc.
* URL : https://github.com/PacificBiosciences/pbmm2
* License : custom
  Programming Lang: C
  Description : minimap2 SMRT wrapper for PacBio data
 pbmm2 is a SMRT C++ wrapper for minimap2's C API. Its purpose is to
 support native PacBio in- and output, provide sets of recommended
 parameters, generate sorted output on-the-fly, and postprocess
 alignments. Sorted output can be used directly for polishing using
 GenomicConsensus, if BAM has been used as input to pbmm2. Benchmarks
 show that pbmm2 outperforms BLASR in sequence identity, number of
 mapped bases, and especially runtime. pbmm2 is the official replacement
 for BLASR

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

Bug#967909: Update to recent fork of editline?

[Bastian Germann]

Am 15.09.20 um 22:22 schrieb Joel Rivera:
> Bastian,
> 
> correct me if I'm wrong, but you're suggesting to remove [1] in favor of [2]?

That is right.

> I've been trying to update editline to the fork that seems to have been 
> evolved from the original debian sources at [3]. My interest in particular is 
> due to that is a dependency of the Nix package manager [4],  currently the 
> debian package of Nix is trying to work around the situation by adding 
> support to readline (but is not complete and it seems that the upstream 
> project is considering to stop/revert the integration with it). 
> 
> You can get the additional context from the emails that I sent to 
> debian-mentors like a month ago [5],  and the other one to debian-devel [6], 
> the maintainer (Sam Hocevar) seems to be on vacation or simply is not 
> responsive. I'm starting to consider to salvage the package, but that idea 
> conflicts with the current proposal of this bug report.

If you salvage this package, just close this bug.

> Currently a debian source package of the updated editline is part of the 
> upsteam repo [7]  (based on the original one in debian sources), so is mostly 
> a matter to be integrated in debian. 
> 
> Do you have any opinions this situation? I do not know more about libedit and 
> compatibility with the newer editline, I'm only trying to integrate the 
> dependency that the upstream project (Nix) seems to favor the most. 

Most libedit/editline implementations floating around, including the two
mentioned ones stem from the original version from Rich Salz.

Therefore, nix might be able to compile with libedit instead. The main
difference from [3] is that it needs ncurses. Additionally, the include
paths differ. libedit seems to try to be a bit more of a readline
drop-in replacement..

The current situation in Debian is the following: We have at least four
readline-like implementations in the archive:

readline (v8)
readline5 which is kept around for license reasons
editline
libedit

I think it would be good to reduce the number of those libraries and
apart from the effort to remove editline, I also handed in patches to
the readline5 users to build with libedit.

The main reason to get rid of editline and readline5 is their orphaned
status. But if you want to maintain the package properly after
salvaging, please go ahead.

> Thanks,
> --
> Joel Rivera
> 
> [1]: https://tracker.debian.org/pkg/editline
> [2]: https://tracker.debian.org/pkg/libedit
> [3]: https://github.com/troglobit/editline
> [4]: https://tracker.debian.org/pkg/nix
> [5]: https://lists.debian.org/debian-mentors/2020/08/msg00096.html
> [6]: https://lists.debian.org/debian-devel/2020/08/msg00187.html
> [7]: https://github.com/troglobit/editline/tree/master/debian
> 

Bug#952538: libwolfssl-dev: user_settings.h missing

[Felix Lechner]

Hi Otto,

On Wed, Feb 26, 2020 at 2:48 PM Otto Kekäläinen  wrote:
>
> fatal error: openssl/evp.h: No such file or directory

Did you follow the instructions [1]  exactly? They are not very clear
but upstream gave me this advice verbally:

1. '#include ' in each file that uses wolfSSL as the
first header.
2. Prefix all  header locations with 

I usually bracket the changes with USE_WOLFSSL or similar. The manual
is not very clear, but these instructions work for me every time. We
can address missing functions or symbols conflicts with upstream.
Often, the names are just different. (wolfSSL support for EVP is not
great; they offer cryptographic primitives in wolfcrypt instead.)

Upstream is eager to see the major databases ported and is giving the
highest level of technical support to my efforts with PostgreSQL.
Perhaps I can help with porting MariaDB at the same time (if needed)
although the upstream bug you mentioned is still open. [2]

Kind regards
Felix Lechner

[1] https://www.wolfssl.com/docs/wolfssl-manual/ch13/
[2] https://jira.mariadb.org/browse/MDEV-21835

Bug#886419: systray-mdstat: complains at startup, despite everything appears to be fine

[Axel Beckert]

Control: tag -1 + unreproducible

Hi Francesco,

sorry for the very late reply.

Francesco Poli (wintermute) wrote:
> As soon as I start it, it complains on stdout (and Gtk complains on
> stderr):
> 
>   $ systray-mdstat 
>   no notify because setup failed: 
>   Gtk-Message: GtkDialog mapped without a transient parent. This is 
> discouraged.
> 
> In the meanwhile, a dialog window appears, informing me that all my md
> devices are OK.

A dialog window? It should be a notification, no real window.

> But then, why the complaint on stdout?

I don't know and can't remember that I ever saw that myself (and at
least currently can't reproduce it).

> I haven't found any trace of needed setup in the documentation.

There is none. Should work out of the box and does for me. :-/

> Moreover, I would love to see Gtk stop complaining.
> Is there anything that can be done to fix the issue reported by Gtk,
> if it is an issue at all?

I must admit, I have no idea. I'm not really experienced in writing
GUI applications and fought a lot especially with GTK.

GTK being an always moving target is also one of the reasons why I
didn't work on this project for quite a while. Took me ages to get
this working with GTK3 instead of GTK2. And everything seemed to get
just more complicated.

Since for the upcoming 1.2.0 bascially the whole GUI backend stuff
changed, I wouldn't be surprised if this issue will be gone with
1.2.0. But since I can't reproduce this, I can't test it.

In case you're curious, you could build the soon-to-be 1.2.0-1 package
from a git checkout of https://github.com/xtaran/systray-mdstat and if
that fixes it, I'll close the bug report with the upload. Otherwise,
I'd wait for your feedback after uploading 1.2.0-1 and then
retroactively close this bug report if it's fixed.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#942915: ca-certificates: Python2 removal in sid/bullseye

[peter green]

severity 942915 serious
thanks

The "python" binary package is no longer available in testing or unstable (in 
unstable it's present as a cruft package
but uninstallable, in testing it's completely gone)

Bug#951388: [akonadi-backend-postgresql] apparmor profile unsuitable

[Sandro Knauß]

Forwarded: https://invent.kde.org/pim/akonadi/-/merge_requests/32

Hey,

I have pushed the needed changes to upstream. The AppArmor profile is living 
there.

hefee

--
On Samstag, 15. Februar 2020 21:08:15 CEST Bastien Roucariès wrote:
> Package: akonadi-backend-postgresql
> Version: 4:19.08.3-1
> Severity: grave
> Justification: renders package unusable
> Tags: patch
> 
> Dear Maintainer,
> 
> Please find the following update for apparmor
> 
> Please apply
> 
> Bastien



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

Bug#970415: aseba build-depends unsatisfiable in testing and unstable.

[peter green]

Source: aseba
Version: 1.6.0-5
Severity: serious
Tags: bullseye, sid

aseba build-depends on the "python" binary package which is no longer built by the 
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is 
uninstallable due to strictly versioned depdencies.
In testing it is gone completely. Either way your build-dependencies are 
unsatisfiable.

If you *really* need to stick with python2, you can build-depend on python2 
instead and fix any python invocations to
invoke that instead of the unversioned python. Ideally though you should be 
moving to python 3.

Bug#968501: btrfs-heatmap: Please depend on python3:any or drop python3 dependency

[Hans van Kranenburg]

Hi!

On 8/16/20 3:36 PM, Elrond wrote:
> Package: btrfs-heatmap
> Version: 8-1
> Severity: wishlist
> User: multiarch-de...@lists.alioth.debian.org
> Usertags: multiarch
> 
> Hi,
> 
> btrfs-heatmap currently depends on just python3.
> As btrfs-heatmap is Architecture=all, it probably
> should depend on python3:any.
> Alternatively, the python3 dependency could be dropped, as
> the dependency on python3-btrfs will already pull in
> an appropriate python3.

Yes, you're right.

btrfs-heatmap has a hard dependency on pyton3-btrfs, so I'll drop the
python3 dependency for btrfs-heatmap in the next upload.

Thanks,
Hans

Bug#970414: seer FTCBFS: cross compiler does not honour LIBRARY_PATH

[Helmut Grohne]

Source: seer
Version: 1.1.4-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

seer fails to cross build from source, because the cross compiler does
not find -lhdf5. It seems that it does not honour the LIBRARY_PATH
environment variable. Passing the library path via LDFLAGS makes cross
building seer work. Please consider applying the attached patch.

Helmut
diff --minimal -Nru seer-1.1.4/debian/changelog seer-1.1.4/debian/changelog
--- seer-1.1.4/debian/changelog 2020-06-02 00:05:16.0 +0200
+++ seer-1.1.4/debian/changelog 2020-09-15 06:05:45.0 +0200
@@ -1,3 +1,10 @@
+seer (1.1.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass hdf5 libdir via LDFLAGS. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 15 Sep 2020 06:05:45 +0200
+
 seer (1.1.4-3) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru seer-1.1.4/debian/rules seer-1.1.4/debian/rules
--- seer-1.1.4/debian/rules 2020-06-02 00:05:16.0 +0200
+++ seer-1.1.4/debian/rules 2020-09-15 06:05:45.0 +0200
@@ -5,12 +5,14 @@
 include /usr/share/dpkg/default.mk
 include /usr/share/dpkg/architecture.mk
 export CPATH := /usr/include/hdf5/serial
-export LIBRARY_PATH := /usr/lib/$(DEB_TARGET_MULTIARCH)/hdf5/serial
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 CMAKE_EXTRA_FLAGS += -DARMA_USE_HDF5=1
 
+override_dh_auto_build:
+   dh_auto_build -- LDFLAGS+=-L/usr/lib/$(DEB_HOST_MULTIARCH)/hdf5/serial
+
 override_dh_auto_install:
dh_auto_install -- PREFIX=$(CURDIR)/debian/$(DEB_SOURCE)/usr
for pl in scripts/*.pl ; do \

Bug#963522: WebKitWebProcess: random crash (SIGSEGV)

[Alberto Garcia]

On Tue, Jun 23, 2020 at 02:49:52PM +0200, Alberto Garcia wrote:

> > I got a random crash (SIGSEGV) in WebKitWebProcess. I've included
> > the gdb backtrace and some possibly related syslog messages
> > below. I don't know how to reproduce the crash. I'm not entirely
> > sure but I think it was from liferea. It could also have been from
> > evolution or gnome-ring.
> 
> Thanks, I forwarded the backtrace to the team, although it didn't
> ring any bell yet. The WebKitWebSource component got a significant
> rewrite in the 2.29 branch so it might be that it doesn't happen
> in trunk anymore, but also that it won't be possible to reproduce
> there.

WebKitGTK 2.30.0 has been released (it's in Debian experimental at the
moment).

Have you been able to reproduce this problem again? If you have you
could try to see if it also happens with 2.30.0.

If it happened only once I'm tempted to close this bug until you hit
this problem again.

Berto

Bug#921012: [Pkg-utopia-maintainers] Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Matthew Vernon]

Dear Michael,

On 15/09/2020 20:37, Michael Biebl wrote:

The removal of the SysV init script was not a mistake that needs to be
corrected.


You appreciate that both the restoration of the init script and use of 
the logind virtual package are both essential for network-manager to be 
installable on non-systemd systems?


AFAIAA there isn't any other way of enabling that; nor are there any 
problems that this enabling work will have for systemd systems.


Am I incorrect in either regard?

Regards,

Matthew

Bug#969663: polyphone is marked for autoremoval from testing

[Thorsten Glaser]

Felix Lechner dixit:

>Uploaded, although I am still looking for it on the buildds:

First it must be ACCEPTED, then the dak run for incoming must
run, then B-Ds are checked, then it gets into Needs-Build status,
and only then the buildds pick it up.

It’s there now: https://buildd.debian.org/status/package.php?p=wolfssl
(ports will pick it up in a bit)

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#969663: polyphone is marked for autoremoval from testing

[Thorsten Glaser]

Dixi quod…

>It’s there now: https://buildd.debian.org/status/package.php?p=wolfssl

… and already FTBFSing on s390x:

/usr/bin/ld: src/.libs/libwolfssl.so: undefined reference to `ByteReverseWords'

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#968504: RFS: aqemu/0.9.2-2.4 [NMU] [RC] -- Qt5 front-end for QEMU and KVM

[Alexis Murzeau]

Le 15/09/2020 à 18:31, Tobias Frost a écrit :
> I wouldn't consider use case not using official debian packages too much…
> Instead, lets look what policy says on Depends (omitting non relevant 
> paragraphs)
> 
>   The Depends field should be used if the depended-on package is required for
> the depending package to provide a significant amount of functionality.
> 
> (I can't judge because I don't know aqemu, but my feeling is Recommends would
> be too weak)

Ok I think Depends is the right thing too, indeed.

>>
>> Thanks for your review :)
> 
> To avoid a dead-lock, you say when you're ready? (by removing the moreinfo 
> tag)
> 

Yes, in fact I was refering to your first mail :) (so not asking for a new 
review (yet)).

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



signature.asc
Description: OpenPGP digital signature

Bug#969663: polyphone is marked for autoremoval from testing

[Felix Lechner]

Hi Thorsten,

Uploaded, although I am still looking for it on the buildds:

> wolfssl_4.5.0+dfsg-1_source.changes uploaded successfully to localhost
> along with the files:
>   wolfssl_4.5.0+dfsg-1.dsc
>   wolfssl_4.5.0+dfsg.orig.tar.xz
>   wolfssl_4.5.0+dfsg-1.debian.tar.xz
>   wolfssl_4.5.0+dfsg-1_source.buildinfo
>
> Greetings,
>
> Your Debian queue daemon (running on host usper.debian.org)

Kind regards
Felix Lechner

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Timo Aaltonen]

On 15.9.2020 19.50, Svante Signell wrote:
> On Mon, 2020-09-14 at 20:52 +0300, Timo Aaltonen wrote:
>> On 14.9.2020 18.44, Svante Signell wrote:
>>> found 909436 2.4.102-1
>>> thanks
>>>
>>> Hello again,
>>>
>>> libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still
>>> missing support for Hurd in drm.h and xf86drm.h. Attached is a
>>> patch, hurd-port.diff, to fix this. The rest of that patch address
>>> PATH_MAX issuesin xf86dri.c as PATH_MAX is not defined for
>>> GNU/Hurd.
>>>
>>> Note: hurd-port.diff depends on that xf86drm.c.diff in #970304 is
>>> applied before!
>>
>> these would need to go upstream..
> 
> Both patches (somewhat modified) submitted upstream to the old issues:
> https://gitlab.freedesktop.org/mesa/drm/-/issues/23
> https://gitlab.freedesktop.org/mesa/drm/-/issues/24

thanks, but I'm afraid they don't get noticed unless they're sent as
merge-requests..


-- 
t

Bug#970400: grcompiler: diff for NMU version 5.2-2.1

[Bobby de Vos]

Tobias and Bastian,

I don't think the package needs to be delayed any further. However, I am
curious to see how well it builds and passes the tests, since one commit
[1] has not been added to this package

[1]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961444#24

I talked to the author of the recent commits, and it is not clear if the
missing commit is crucial.

Bobby

On 2020-09-15 10:49 a.m., Tobias Frost wrote:
> Package: grcompiler
> Version: 5.2-2
> Severity: normal
> Tags: patch  pending
> 
> 
> Dear maintainer,
> 
> Bastian Germann  has prepared an NMU [1] for 
> grcompiler
> (versioned as 5.2-2.1) and uploaded it to DELAYED/5. Please feel free to tell
> me if I should delay it longer.
> 
> Regards.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969910
> 

-- 
Bobby de Vos
/bobby_de...@sil.org/



signature.asc
Description: OpenPGP digital signature

Bug#970344: ncbi-blast+: tblastn segfaults intermittently with multiple threads

[Étienne Mollier]

Hi Aaron,

Aaron M. Ucko, on 2020-09-15 16:01:33 -0400:
> I captured this crash, but getting to the root cause turned out to be
> difficult.  The good news is that the latest upstream 2.10.1 release
> should include a pair of commits with promising messages:
> 
>   Fix tblastn mt issue (seqdb changes), JIRA:SB-2784 [1]
>   Fix tblastn mt issue (engine changes),JIRA:SB-2784 [2]
> 
> It also contains at least one x86ism I'll need to conditionalize
> appropriately, but that should be straightforward enough.
> 
> As such, I plan to put further investigation on hold in hopes that the
> upgrade will suffice, and to take care of the latter when I get a chance.

Sounds good to me, we may work the issue around by single
threading execution of tblastn in the meantime, and use this bug
as reference when we hit this problem again.

Thanks for your investigations,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#969665: closed by Jelmer Vernooij (Fixed in newer silver-platter)

[Paul Gevers]

Control: reassign -1 src:silver-platter 0.3.0+git20200611.b4292bf-1
Control: fixed -1 0.3.0+git20200906.d2bd137-1

Hi Jelmer,

On 15-09-2020 13:18, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:breezy-debian, src:silver-platter package:
> 
> #969665: breezy-debian breaks silver-platter autopkgtest: cannot import name 
> 'MissingUpstreamTarball'
> 
> It has been closed by Jelmer Vernooij .

The BTS was a bit confused because the fixed version of breezy-debian
was older than the found version of breezy-debian.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#970413: RM: pbgenomicconsensus -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: ti...@debian.org

Please remove pbgenomicconsensus. It's dead upstream and depends on Python 2.
Removal has been acked by one of the maintainers (CCed).

Cheers,
Moritz

Bug#937255: pbgenomicconsensus: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Tue, Sep 15, 2020 at 10:56:22AM +0200, Andreas Tille wrote:
> Hi Moritz,
> 
> On Mon, Aug 31, 2020 at 08:59:37PM +0200, Moritz Mühlenhoff wrote:
> > On Fri, Aug 30, 2019 at 07:30:23AM +, Matthias Klose wrote:
> > > Package: src:pbgenomicconsensus
> > > Version: 2.3.2-5
> > > Severity: normal
> > > Tags: sid bullseye
> > > User: debian-pyt...@lists.debian.org
> > > Usertags: py2removal
> > > 
> > > Python2 becomes end-of-live upstream, and Debian aims to remove
> > > Python2 from the distribution, as discussed in
> > > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > 
> > Upstream development seems to have stalled, let's remove?
> 
> Yes, lets remove.  Nobody explicitly answered my call for comments.

Ack, I've just filed an RM bug.
 
Cheers,
Moritz

Bug#964399: Should ganglia be removed?

[Moritz Mühlenhoff]

On Mon, Sep 14, 2020 at 12:17:00AM +0200, Marcos Fouces wrote:
> Hi Moritz!
> 
> Yes, i uploaded it to salsa.d.o and i am waiting for Frontdesk aproval
> to become DD (that should happens in a few days) in order to upload it
> myself instead of asking for sponsorship.
> 
> Its new home is here: https://salsa.debian.org/debian/ganglia.

Ack! And congrats for becoming a DD in advance :-)

Cheers,
Moritz

Bug#970412: src:rust-rand-chacha: fails to migrate to testing for too long: unsatified Build-Depends on s390x

[Paul Gevers]

Source: rust-rand-chacha
Version: 0.2.1-1
Severity: serious
Control: close -1 0.2.2-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 961335

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:rust-rand-chacha in its current version in unstable has been trying
to migrate for 134 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=rust-rand-chacha




signature.asc
Description: OpenPGP digital signature

Bug#970264: slrn cannot connect when using SSL encrypted connections

[Moritz Mühlenhoff]

On Mon, Sep 14, 2020 at 09:02:39AM +0200, Moritz Muehlenhoff wrote:
> On Sun, Sep 13, 2020 at 03:54:04PM -0700, Brian Murray wrote:
> > Package: slrn
> > Version: 1.0.3+dfsg-4
> > Severity: important
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu groovy
> > 
> > Dear Maintainer,
> > 
> > It is not possible to connect to a secure news server. The following
> > command fails:
> > 
> > NNTPSERVER=snews://secure-us.news.easynews.com:8000 slrn --create
> > ...
> > Connecting to host secure-us.news.easynews.com ...
> > Failed to initialize server
> > Run-Time Error
> > Reason:
> > slrn fatal error:
> > Failed to initialize server.
> > 
> > The servers for easynews listen on mutliple ports
> > (https://help.easynews.com/kb/article/11-nntp-server-addresses/) but it
> > is not possible to connect to any of the SSL setups. However, using
> > NNTP=news.easynews.com:8000 works without error.
> 
> Can you try a local build with OpenSSL instead of GNUTLS? (by removing
> the --with-gnutls in debian/rules)
> 
> As soon as OpenSSL 3.0 is released and uploaded to unstable (which has a
> GPL-compatible license) I'm planning to switch slrn to OpenSSL.

Summarising further investigation (which happens off bug): Switching to OpenSSL
fixes this, which is planned once OpenSSL 3.0 hits unstable.

Cheers,
Moritz

Bug#967909: Update to recent fork of editline?

[Joel Rivera]

Bastian,

correct me if I'm wrong, but you're suggesting to remove [1] in favor of [2]?

I've been trying to update editline to the fork that seems to have been evolved 
from the original debian sources at [3]. My interest in particular is due to 
that is a dependency of the Nix package manager [4],  currently the debian 
package of Nix is trying to work around the situation by adding support to 
readline (but is not complete and it seems that the upstream project is 
considering to stop/revert the integration with it). 

You can get the additional context from the emails that I sent to 
debian-mentors like a month ago [5],  and the other one to debian-devel [6], 
the maintainer (Sam Hocevar) seems to be on vacation or simply is not 
responsive. I'm starting to consider to salvage the package, but that idea 
conflicts with the current proposal of this bug report.

Currently a debian source package of the updated editline is part of the 
upsteam repo [7]  (based on the original one in debian sources), so is mostly a 
matter to be integrated in debian. 

Do you have any opinions this situation? I do not know more about libedit and 
compatibility with the newer editline, I'm only trying to integrate the 
dependency that the upstream project (Nix) seems to favor the most. 

Thanks,
--
Joel Rivera

[1]: https://tracker.debian.org/pkg/editline
[2]: https://tracker.debian.org/pkg/libedit
[3]: https://github.com/troglobit/editline
[4]: https://tracker.debian.org/pkg/nix
[5]: https://lists.debian.org/debian-mentors/2020/08/msg00096.html
[6]: https://lists.debian.org/debian-devel/2020/08/msg00187.html
[7]: https://github.com/troglobit/editline/tree/master/debian

Bug#970410: src:html5lib: fails to migrate to testing for too long: autopkgtest regressions

[Paul Gevers]

Source: html5lib
Version: 1.0.1-3
Severity: serious
Control: close -1 1.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 968630

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:html5lib 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=html5lib




signature.asc
Description: OpenPGP digital signature

Bug#970411: src:python-uvicorn: fails to migrate to testing for too long: depends on non-migrating package

[Paul Gevers]

Source: python-uvicorn
Version: 0.11.3-1
Severity: serious
Control: close -1 0.11.5-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:python-uvicorn in its current version in unstable has been trying to
migrate for 61 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=python-uvicorn




signature.asc
Description: OpenPGP digital signature

Bug#936913: librelp: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

tags 936913 fixed-upstream
thx

On Fri, Aug 30, 2019 at 07:24:14AM +, Matthias Klose wrote:
> Package: src:librelp
> Version: 1.4.0-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

This has been fixed in 
https://github.com/rsyslog/librelp/commit/b8c715e88d22dabc1d2bbd078f2f29e0705e234c
(post 1.7.0 but applies cleanly on top of 1.7.0). The actual Python script 
should already work fine
with Py 2 and 3 in 1.6.0 already.

Cheers,
Moritz

Bug#970409: src:google-http-client-java: fails to migrate to testing for too long: depends on non-migrating package

[Paul Gevers]

Source: google-http-client-java
Version: 1.27.0-3
Severity: serious
Control: close -1 1.31.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

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:google-http-client-java in its current version in unstable has been
trying to migrate for 61 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=google-http-client-java




signature.asc
Description: OpenPGP digital signature

Bug#970408: facter: FTBFS: cc1plus: all warnings being treated as errors

[Sebastian Ramacher]

Source: facter
Version: 3.11.0-4.3
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

facter currently fails to build:
| cd /<>/obj-x86_64-linux-gnu/lib && /usr/bin/c++ 
-DBOOST_ALL_DYN_LINK -DBOOST_LOG_WITHOUT_WCHAR_T -DBOOST_SYSTEM_NO_DEPRECATED 
-DLEATHERMAN_I18N -DLEATHERMAN_LOGGING_NAMESPACE=\"puppetlabs.facter\" 
-DLEATHERMAN_USE_LOCALES 
-DPROJECT_DIR=\"/<>/obj-x86_64-linux-gnu\" 
-DPROJECT_NAME=\"FACTER\" -DUSE_BLKID -DUSE_CPPHOCON -DUSE_CURL -DUSE_OPENSSL 
-DUSE_YAMLCPP -Dlibfacter_EXPORTS -I/<>/lib/inc 
-I/<>/../vendor/nowide/include -Wextra -std=c++11 -Wall 
-Wno-unused-parameter -Wno-unused-local-typedefs -Wno-unknown-pragmas 
-Wno-missing-field-initializers -Werror -Wno-maybe-uninitialized -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -o 
CMakeFiles/libfactersrc.dir/src/util/bsd/scoped_ifaddrs.cc.o -c 
/<>/lib/src/util/bsd/scoped_ifaddrs.cc
| In file included from /usr/include/string.h:495,
|  from /usr/include/c++/10/cstring:42,
|  from /usr/include/boost/regex/v4/regex_workaround.hpp:24,
|  from /usr/include/boost/regex/v4/regex.hpp:32,
|  from /usr/include/boost/regex.hpp:31,
|  from /<>/lib/inc/facter/facts/resolver.hpp:12,
|  from 
/<>/lib/inc/internal/facts/linux/../bsd/../posix/../resolvers/networking_resolver.hpp:7,
|  from 
/<>/lib/inc/internal/facts/linux/../bsd/../posix/networking_resolver.hpp:7,
|  from 
/<>/lib/inc/internal/facts/linux/../bsd/networking_resolver.hpp:7,
|  from 
/<>/lib/inc/internal/facts/linux/networking_resolver.hpp:7,
|  from 
/<>/lib/src/facts/linux/networking_resolver.cc:1:
| In function ‘char* strncpy(char*, const char*, size_t)’,
| inlined from ‘virtual boost::optional 
facter::facts::linux::networking_resolver::get_link_mtu(const string&, void*) 
const’ at /<>/lib/src/facts/linux/networking_resolver.cc:82:16:
| /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:34: error: ‘char* 
__builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 16 
equals destination size [-Werror=stringop-truncation]
|   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
(__dest));
|   |  
^~
| cc1plus: all warnings being treated as errors

See
https://buildd.debian.org/status/fetch.php?pkg=facter=amd64=3.11.0-4.3%2Bb1=1599808837=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#964139: [Pkg-utopia-maintainers] Bug#964139: Bug#964139: Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Martin Steigerwald]

Michael Biebl - 15.09.20, 21:37:18 CEST:
> The removal of the SysV init script was not a mistake that needs to be
> corrected.

Why did you remove it?

The changelog does not mention a reason as I pointed out already.

Thanks,
-- 
Martin

Bug#970344: ncbi-blast+: tblastn segfaults intermittently with multiple threads

[Aaron M. Ucko]

u...@debian.org (Aaron M. Ucko) writes:

> FTR, the BTS accepted this attachment, thanks!  As proposed on -med, I
> will try to reproduce the bug under rr, though doing so isn't quite as
> straightforward as I'd hoped because rr emulates a single CPU; to
> compensate, I must temporarily patch out BLAST+'s logic to limit the
> thread count accordingly.

I captured this crash, but getting to the root cause turned out to be
difficult.  The good news is that the latest upstream 2.10.1 release
should include a pair of commits with promising messages:

  Fix tblastn mt issue (seqdb changes), JIRA:SB-2784 [1]
  Fix tblastn mt issue (engine changes),JIRA:SB-2784 [2]

It also contains at least one x86ism I'll need to conditionalize
appropriately, but that should be straightforward enough.

As such, I plan to put further investigation on hold in hopes that the
upgrade will suffice, and to take care of the latter when I get a chance.

[1] https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=89479
[2] https://www.ncbi.nlm.nih.gov/viewvc/v1?view=revision=89480

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

Bug#970405: avw.lv2 build-depends unsatisfiable in testing and unstable.

[Sebastian Ramacher]

Control: severity 942964 serious
Control: forcemerge 942964 -1

On 2020-09-15 20:20:24 +0100, peter green wrote:
> Source: avw.lv2
> Version: 0.1.6~dfsg0-1
> Severity: serious
> Tags: bullseye, sid
> 
> avw.lv2 build-depends on the "python" binary package which is no longer built 
> by the "python-defaults" source package.
> In unstable it is present as a cruft package but said cruft package is 
> uninstallable due to strictly versioned depdencies.
> In testing it is gone completely. Either way your build-dependencies are 
> unsatisfiable.

This is already tracked in #942964. Instead of fixing this issue, it
should be replaced with ams.lv2 (see #942856)

Cheers

> 
> If you *really* need to stick with python2, you can build-depend on python2 
> instead and fix any python invocations to
> invoke that instead of the unversioned python. Ideally though you should be 
> moving to python 3.
> 
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#970407: please package new version 0.10.0

[Martin]

Source: libstrophe
Version: 0.9.3-2
Severity: wishlist

Version 0.10.0 has been released.
Supports c-ares (asynchronous DNS requests) with --enable-cares, btw.

Bug#969608: [Debian-med-packaging] Bug#969608: makeblastdb 2.10.x on 32-bit architectures

[Étienne Mollier]

Hi Aaron,

Aaron M. Ucko, on 2020-09-14 17:36:14 -0400:
> 
> Thanks for clarifying.  AFAICT, this environment imposes a tighter limit
> than native arm64 hardware, and versions 2.10.0-1 and 2.10.0-3 both hit
> it.  Rough bisection via the BLASTDB_LMDB_MAP_SIZE environment variable
> gives an empirical limit of 20,073,607,168 bytes (4,900,783 4K pages).
> This number isn't particularly round, so it presumably reflects what
> remains of some cumulative limit.  As such, the default should probably
> be at most 20,000,000,000 bytes (4,882,812½ pages ;-) to build in more
> of a margin.  That's 1/15 upstream's default, but with any luck should
> be plenty in practice, so I'm open to making that adjustment.  Also,
> this reduced limit would still be well more than we (can) allow on
> 32-bit architectures, which is in turn much more than upstream's trunk
> allows on Windows:
> 
> https://www.ncbi.nlm.nih.gov/IEB/ToolBox/CPP_DOC/lxr/source/include/objtools/blast/seqdb_writer/writedb_lmdb.hpp#L51

Wow, thanks for the comprehensive background information.  In
case someone else (me in a not so near future for instance)
stumbles upon this again, I keep note that reducing the size of
BLASTDB_LMDB_MAP_SIZE a bit might help:

(sid-arm64-sbuild)$ makeblastdb -in NC_005816.faa -dbtype prot 
-hash_index -max_file_sz 20MB -parse_seqids -taxid 10


Building a new DB, current time: 09/15/2020 19:37:37
New DB name:   /tmp/NC_005816.faa
New DB title:  NC_005816.faa
Sequence type: Protein
Deleted existing Protein BLAST database named /tmp/NC_005816.faa
Keep MBits: T
Maximum file size: 2000B

No volumes were created.

Error: mdb_env_open: Cannot allocate memory

(sid-arm64-sbuild)$ BLASTDB_LMDB_MAP_SIZE=100 makeblastdb -in 
NC_005816.faa -dbtype prot -hash_index -max_file_sz 20MB -parse_seqids -taxid 10


Building a new DB, current time: 09/15/2020 19:37:34
New DB name:   /tmp/NC_005816.faa
New DB title:  NC_005816.faa
Sequence type: Protein
Deleted existing Protein BLAST database named /tmp/NC_005816.faa
Keep MBits: T
Maximum file size: 2000B
Adding sequences from FASTA; added 10 sequences in 0.166301 seconds.

Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#948336: selinux-policy-default: systemd-journal cannot access processes with 'signull' (RedHat Bug 1676923).

[Mario Koppensteiner]

Hello,

Today I installed a Debian Box with selinux enabled. I found that I'm 
affected by this bug. Is there any activity to solve this bug?


The referenced Redhat Bug 1676923 is closed.


Links:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1676923


sincerely yours

Mario Koppensteiner

Bug#970387: cargo 0.43.1-3~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970387 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cargo
Version: 0.43.1-3~deb10u1

Explanation: new upstream release

Bug#964139: [Pkg-utopia-maintainers] Bug#964139: Bug#964139: Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Michael Biebl]

The removal of the SysV init script was not a mistake that needs to be
corrected.



signature.asc
Description: OpenPGP digital signature

Bug#970406: flowcanvas build-depends unsatisfiable in testing and unstable.

[peter green]

Source: flowcanvas
Version: 0.7.1+dfsg0-0.5
Severity: serious
Tags: bullseye, sid

flowcanvas build-depends on the "python" binary package which is no longer built by the 
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is 
uninstallable due to strictly versioned depdencies.
In testing it is gone completely. Either way your build-dependencies are 
unsatisfiable.

If you *really* need to stick with python2, you can build-depend on python2 
instead and fix any python invocations to
invoke that instead of the unversioned python. Ideally though you should be 
moving to python 3.

Bug#970402: transition: log4cxx

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

Hi Tobias,

On 15/09/2020 19:52, Tobias Frost wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello release team!
> 
> I'm preparing the transition of log4cxx. It's already showing up
> on https://release.debian.org/transitions/html/auto-log4cxx.html, so
> ben seems to be hapy…
> 
> Building r-deps was successful:
> ros-rosconsole ✔
> solarpowerlog  ✔
> zookeeper ✔
> 
> Everything looks ready ;-)
> 
> Waiting for the green light from you ;-)

Go ahead.

Cheers,
Emilio

Bug#942960: catch: Python2 removal in sid/bullseye

[peter green]

severity 942960 serious
thanks

The "python" binary package has now been removed from testing, hence this bug 
is now serious.

If there is still no maintainer response I may well NMU this later.

Bug#921012: [Pkg-utopia-maintainers] Bug#964139: Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Matthew Vernon]

Dear Michael,

On 15/09/2020 19:53, Michael Biebl wrote:

Am 15.09.20 um 20:45 schrieb Matthew Vernon:

Hi,
On 15/09/2020 19:26, Michael Biebl wrote:

Am 15.09.20 um 19:44 schrieb Matthew Vernon:

Hi,

These two related init compatibility issues haven't seen any activity
recently, so I've uploaded an NMU (delayed/14) to fix them in line with
the patches already posted; in the case of the init script I simply
reverted your commit removing it.



I don't agree with this NMU. Please cancel it.


Could you please explain what the problem with it is?


This package is not unmaintained. So an NMU is not warranted. Especially
since those changes were made deliberately.


To clarify: your objection is that you do not want bugs 964139 and 
921012 (restoring the sysv init script and using the logind virtual 
package dependency) fixing at all?


Regards,

Matthew

Bug#970405: avw.lv2 build-depends unsatisfiable in testing and unstable.

[peter green]

Source: avw.lv2
Version: 0.1.6~dfsg0-1
Severity: serious
Tags: bullseye, sid

avw.lv2 build-depends on the "python" binary package which is no longer built by the 
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is 
uninstallable due to strictly versioned depdencies.
In testing it is gone completely. Either way your build-dependencies are 
unsatisfiable.

If you *really* need to stick with python2, you can build-depend on python2 
instead and fix any python invocations to
invoke that instead of the unversioned python. Ideally though you should be 
moving to python 3.

Bug#970404: shovill: Please provide autopkgtest

[Nilesh Patra]

Package: shovill
Severity: wishlist
X-Debbugs-Cc: npatra...@gmail.com

Dear Maintainer,

Please provide autopkgtest for this package. This also doesn't work
properly at the moment
and needs minor patching for the same.


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Thank you for using reportbug

Bug#970279: O: nutsqlite -- Dietary nutrition analysis software

[Andreas Tille]

Hi Iain,

On Tue, Sep 15, 2020 at 07:37:14PM +0100, Iain Learmonth wrote:
> Ok, someone added me to the team so I've pushed the changes straight to
> the team git on salsa.

Thanks.  I've now simply uploaded after replacing your ID by mine.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Kyle Edwards]

On 9/15/20 11:00 AM, Drew Parsons wrote:
Mind you, reading your README reminds me I probably want dh 
--buildsystem=cmake anyway, rather than dh --with cmake.


dh doesn't document its --buildsystem option properly. The dh man page 
documents --with but not --buildsystem (which gets mentioned only in 
an example). But that's not dh-cmake's fault!


You'll need both `--buildsystem=cmake` and one of `dh-sequence-cmake` 
(modern, preferable) or `--with cmake` (old, deprecated). 
`--buildsystem=cmake` is provided by Debhelper proper, and existed long 
before dh-cmake, while `--with cmake` and `dh-sequence-cmake` are 
provided by dh-cmake. They have different purposes. 
`--buildsystem=cmake` controls the configuration step, while 
`dh-sequence-cmake` controls the installation step.


Kyle

Bug#964139: [Pkg-utopia-maintainers] Bug#964139: Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Michael Biebl]

Am 15.09.20 um 20:45 schrieb Matthew Vernon:
> Hi,
> On 15/09/2020 19:26, Michael Biebl wrote:
>> Am 15.09.20 um 19:44 schrieb Matthew Vernon:
>>> Hi,
>>>
>>> These two related init compatibility issues haven't seen any activity
>>> recently, so I've uploaded an NMU (delayed/14) to fix them in line with
>>> the patches already posted; in the case of the init script I simply
>>> reverted your commit removing it.
>>>
>>
>> I don't agree with this NMU. Please cancel it.
> 
> Could you please explain what the problem with it is?

This package is not unmaintained. So an NMU is not warranted. Especially
since those changes were made deliberately.



signature.asc
Description: OpenPGP digital signature

Bug#883245: More info

[Carsten Schoenert]

Hello Jesus,

Am 15.09.20 um 19:50 schrieb Jesus Eguiluz:

Hi, I have more info.

The same problem, I can't open links from thunderbird.

I used to be workaround it by put the
/etc/apparmor.d/usr.bin.thunderbird in complain mode. But this not work
anymore.

Now I have to disable de /etc/apparmor.d/usr.bin.thunderbird profile
with sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird


sep 15 14:36:55 gsus-v110-14ast audit[9930]: AVC apparmor="DENIED"
operation="file_mmap" profile="thunderbird//sanitized_helper"
name="/opt/waterfox/waterfox" pid=9930 comm="waterfox"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
sep 15 14:36:55 gsus-v110-14ast kernel: audit: type=1400
audit(1600191415.454:368): apparmor="DENIED" operation="file_mmap"
profile="thunderbird//sanitized_helper" name="/opt/waterfox/waterfox"
pid=9930 comm="waterfox" requested_mask="m" denied_mask="m" fsuid=1000
ouid=0


you try to run /opt/waterfox/waterfox which isn't allowed by the shipped 
apparmor profile.


Please open a issue on

  https://gitlab.com/apparmor/apparmor-profiles/-/issues

and ask the apparmor profile maintainer how to get your issue solved.

Please note also the file /usr/share/doc/thunderbird/README.apparmor 
which has some small additional information about Thunderbird and Apparmor.


---
Regards
Carsten Schoenert

Bug#753752: Bootloader hooks patch for dracut

[наб]

Hi!

I'm attaching a patch that implements this, stolen from i-t:
  
https://sources.debian.org/src/initramfs-tools/0.139/update-initramfs/?hl=L158#L158

Best,
наб
From 4b5bcda703b4655c7eea52a092a21fdd61da1204 Mon Sep 17 00:00:00 2001
From: наб 
Date: Tue, 15 Sep 2020 20:32:08 +0200
Subject: [PATCH] Invoke bootloader hooks from /etc/initramfs/post-update.d
 after making image
---
 dracut.sh | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/dracut.sh b/dracut.sh
index 1c8cce82..6c134bad 100755
--- a/dracut.sh
+++ b/dracut.sh
@@ -2141,4 +2141,10 @@ if test -d $dracutsysrootdir/run/systemd/system; then
 fi
 fi
 
+# Invoke policy-conformant bootloader hooks
+if [ -d /etc/initramfs/post-update.d/ ]; then
+   run-parts --arg="${kernel}" --arg="${outfile}" \
+   /etc/initramfs/post-update.d/
+fi
+
 exit 0
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#970279: O: nutsqlite -- Dietary nutrition analysis software

[Iain Learmonth]

Hi,

> On 14/09/2020 12:25, Andreas Tille wrote:
>> Would you mind pushing your latest changes to the package to Git?
>> I'd volunteer to add my ID as Uploader (if nobody else wants to for
>> sure!)

Ok, someone added me to the team so I've pushed the changes straight to
the team git on salsa.

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Kyle Edwards]

On 9/15/20 10:41 AM, Drew Parsons wrote:

Maybe it's a packaging and documentation bug?

There is no README file provided by the dh-cmake package, and no man 
page for /usr/bin/dh_cmake_install 


OK, yeah, this is definitely a documentation bug. The README is here:

https://gitlab.kitware.com/debian/dh-cmake/-/blob/master/README.md

I'll look at adding the README to the package, though I'd definitely 
like to get man pages written at some point.


Kyle

Bug#921012: [Pkg-utopia-maintainers] Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Matthew Vernon]

Hi,
On 15/09/2020 19:26, Michael Biebl wrote:

Am 15.09.20 um 19:44 schrieb Matthew Vernon:

Hi,

These two related init compatibility issues haven't seen any activity
recently, so I've uploaded an NMU (delayed/14) to fix them in line with
the patches already posted; in the case of the init script I simply
reverted your commit removing it.



I don't agree with this NMU. Please cancel it.


Could you please explain what the problem with it is?

Regards,

Matthew

Bug#963827: closed by Gianfranco Costamagna (Re: [virtualbox] guests limited to 800x600)

[Lyndon Brown]

Re-opening. This is most certainly *not* fixed.

I have a Debian Sid installation (with a Gnome environment) in a VBox
VM, fully up-to-date, and the problem still exists with this.

When the problem surfaced, I had to restore from backup and place a
hold on kernel and virtualbox-guest-* package updates to keep the VM
usable (but insecure), while maintaining a duplicate copy that I
install the updates on to test if each new version fixes it, wasting a
chunk of my disk space. This has not been at all ideal. AS I said, I've
just double checked things, and the problem is definitely still there.

Frustratingly, when I looked at the VBox bug tracker some weeks ago,
others were in the same position; VBox guys were just asking if those
users were using wayland, and stating that the resizing simply does not
work for wayland, contradicting the simple fact that it clearly was
working fine up until the point release that broke it as people tried
to point out. There was also some suggestion of an environment variable
being involved, and possibly not used correctly by some distros, if I
recall correctly. I have not been holding my breath for a quick fix.

Interestingly I have just discovered something useful - I tried
selecting 'gnome on xorg' at the login screen, and was pleased to find
that the login environment under that at least works fine. I guess this
must have been one of the later fixes and I did not previously think to
recheck. So the problem only affects the default (wayland) environment.
This eases some of the impact upon myself - I guess I can manage with
an X11 environment for the time being.

Fundamentally though, the problem is only partially fixed, it's still
broken for wayland, which *was* working previously, despite the
illogical claims of VBox guys. And thus since the problem partially
still exists, the bug should remain open - the small login screen is
mostly just cosmetic in nature, but not being able to have a usable
wayland session is problematic.


On Tue, 2020-09-15 at 08:09 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:virtualbox package:
> 
> #963827: [virtualbox] guests limited to 800x600
> 
> It has been closed by Gianfranco Costamagna  >.
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Gianfranco
> Costamagna  by
> replying to this email.
> 
> 

Bug#964139: [Pkg-utopia-maintainers] Bug#964139: NMU (delayed/14) to fix two init compatibility issues

[Michael Biebl]

Am 15.09.20 um 19:44 schrieb Matthew Vernon:
> Hi,
> 
> These two related init compatibility issues haven't seen any activity
> recently, so I've uploaded an NMU (delayed/14) to fix them in line with
> the patches already posted; in the case of the init script I simply
> reverted your commit removing it.
> 

I don't agree with this NMU. Please cancel it.



signature.asc
Description: OpenPGP digital signature

Bug#964125: calibre: Please switch from sip4 to sip5

[Dmitry Shachnev]

Hi, small update about Calibre vs. SIP situation:

On Fri, Jul 03, 2020 at 07:21:53PM +0300, Dmitry Shachnev wrote:
> However, indeed it looks like the -b option was removed [2], and sip5 can no
> longer generate .sbf files. Calibre's build system (namely get_sip_data()
> function) uses those files, so that is a problem :-(

https://github.com/kovidgoyal/calibre/commit/a4df5cc67ba6ee82 was committed
yesterday, and with that commit Calibre no longer uses the -b option.

So simply exporting SIP_BIN=sip5 may be enough to make it build with sip5.

For various reasons I have delayed the switch of PyQt5 to sip5, so still no
need to upload that change right now.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#970303: pending

[Iain Learmonth]

tags 970303 + pending
kthxbye

Hi,

I've commited a fix for this in the team git repository.

https://salsa.debian.org/debian-hamradio-team/chirp/-/commit/82f2fbaf6bd8f722283775d70e498dfd0690ae74

Thanks,
Iain.



signature.asc
Description: OpenPGP digital signature

Bug#970403: RM: linpsk -- ROM; dead upstream; alternatives in debian

[Iain R. Learmonth]

Package: ftp.debian.org
Severity: normal
User: i...@debian.org
Usertags: refactor2020
X-Debbugs-Cc: debian-h...@lists.debian.org

Hi,

Please remove linpsk from unstable. The upstream is gone since 2013 and
we have alternatives in Debian already, e.g. fldigi.

Thanks,
Iain.

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Kyle Edwards]

Hi Drew,

Thanks for trying dh-cmake.

On 9/15/20 9:54 AM, Drew Parsons wrote:

dh-cmake has been configured to fail if debian/dh-cmake.compat does
not exist.
You can also require `dh-cmake-compat (=1)` in your `Build-Depends` as a 
modern alternative. (You can even take out `dh-cmake`, since 
`dh-cmake-compat` implicitly depends on this.) I don't think the README 
even mentions the `dh-cmake.compat` file anymore.

I think it would work better if dh_cmake assumed version 1, unless
a different version is provided in debian/dh-cmake.compat.
I think requiring `dh-cmake-compat (=1)` is sufficiently lightweight, 
but if lots of people complain I may end up doing this.

i.e. dh --with cmake should just work (as dh_make version 1), without
having to provide an explicit debian/dh-cmake.compat


Please note that the `--with` argument is also outdated, the modern 
approach is to require `dh-sequence-cmake` in your `Build-Depends`.


Please let me know what you think.

Kyle

Bug#921012: NMU (delayed/14) to fix two init compatibility issues

[Matthew Vernon]

Hi,

These two related init compatibility issues haven't seen any activity 
recently, so I've uploaded an NMU (delayed/14) to fix them in line with 
the patches already posted; in the case of the init script I simply 
reverted your commit removing it.


I attach my commits here, and I'll also be sending you an MR on salsa.

HTH,

Matthew
>From f6cb26bcc9b54d75f6e343019714cd905afe1cc1 Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Sun, 13 Sep 2020 12:42:23 +0100
Subject: [PATCH 1/3] Revert "Remove SysV init script" (closes: #964139)

This reverts commit 588ae1fa93a571b7da8f969052e5fd957e65e8c8.

This is to restore the SysV init script, which is useful for init
compatibility.
---
 ...ork-manager-config-connectivity-debian.postinst |  2 +-
 debian/network-manager.init| 92 ++
 debian/network-manager.links   |  1 +
 debian/network-manager.maintscript |  1 -
 debian/network-manager.postinst|  3 -
 5 files changed, 94 insertions(+), 5 deletions(-)
 create mode 100644 debian/network-manager.init
 create mode 100644 debian/network-manager.links

diff --git a/debian/network-manager-config-connectivity-debian.postinst b/debian/network-manager-config-connectivity-debian.postinst
index 576f8898..eb087aa4 100644
--- a/debian/network-manager-config-connectivity-debian.postinst
+++ b/debian/network-manager-config-connectivity-debian.postinst
@@ -3,7 +3,7 @@
 set -e
 
 if [ "$1" = configure ]; then
-nmcli general reload 2>/dev/null || true
+invoke-rc.d network-manager force-reload || true
 fi
 
 #DEBHELPER#
diff --git a/debian/network-manager.init b/debian/network-manager.init
new file mode 100644
index ..ac9c584c
--- /dev/null
+++ b/debian/network-manager.init
@@ -0,0 +1,92 @@
+#! /bin/sh
+### BEGIN INIT INFO
+# Provides:  network-manager
+# Required-Start:$remote_fs dbus udev
+# Required-Stop: $remote_fs dbus udev
+# Should-Start:	 $syslog
+# Should-Stop:   $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop:  0 1 6
+# Short-Description: network connection manager
+# Description:   Daemon for automatically switching network 
+#		 connections to the best available connection.
+### END INIT INFO
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+DESC="network connection manager"
+NAME="NetworkManager"
+
+DAEMON=/usr/sbin/$NAME
+
+PIDFILE=/run/$NAME/$NAME.pid
+
+SCRIPTNAME=/etc/init.d/network-manager
+
+# Gracefully exit if the package has been removed.
+test -x $DAEMON || exit 0
+
+. /lib/lsb/init-functions
+
+test -f /etc/default/NetworkManager && . /etc/default/NetworkManager
+
+#
+#	Function that starts the daemon/service.
+#
+d_start() {
+	start-stop-daemon --start --quiet --pidfile $PIDFILE \
+		--exec $DAEMON -- $DAEMON_OPTS
+}
+
+#
+#	Function that stops the daemon/service.
+#
+d_stop() {
+	start-stop-daemon --stop --retry 5 --quiet --pidfile $PIDFILE \
+		--exec $DAEMON
+}
+
+d_reload() {
+	start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE \
+		--exec $DAEMON
+}
+
+case "$1" in
+  start)
+	log_daemon_msg "Starting $DESC" "$NAME"
+	d_start
+	case "$?" in
+		0) log_end_msg 0 ;;
+		1) log_progress_msg "already started"
+		   log_end_msg 0 ;;
+		*) log_end_msg 1 ;;
+	esac
+	;;
+  stop)
+	log_daemon_msg "Stopping $DESC" "$NAME"
+	d_stop
+	case "$?" in
+		0) log_end_msg 0 ;;
+		1) log_progress_msg "already stopped"
+		   log_end_msg 0 ;;
+		*) log_end_msg 1 ;;
+	esac
+	;;
+  reload|force-reload)
+	log_daemon_msg "Reloading $DESC" "$NAME"
+	d_reload
+	log_end_msg $?
+	;;
+  restart)
+	$0 stop
+	$0 start
+	;;
+  status)
+	status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
+	;;
+  *)
+	echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload|status}" >&2
+	exit 1
+	;;
+esac
+
+exit 0
diff --git a/debian/network-manager.links b/debian/network-manager.links
new file mode 100644
index ..d32ad80e
--- /dev/null
+++ b/debian/network-manager.links
@@ -0,0 +1 @@
+lib/systemd/system/NetworkManager.service lib/systemd/system/network-manager.service
diff --git a/debian/network-manager.maintscript b/debian/network-manager.maintscript
index bb7498aa..673456df 100644
--- a/debian/network-manager.maintscript
+++ b/debian/network-manager.maintscript
@@ -1,4 +1,3 @@
 mv_conffile /etc/NetworkManager/dispatcher.d/01ifupdown /etc/NetworkManager/dispatcher.d/01-ifupdown 1.8.0-5~
 rm_conffile /etc/dbus-1/system.d/nm-dispatcher.conf 1.14.4-4~
 rm_conffile /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf 1.14.4-4~
-rm_conffile /etc/init.d/network-manager 1.25.91-1~
diff --git a/debian/network-manager.postinst b/debian/network-manager.postinst
index 2996afcc..f62edf2a 100644
--- a/debian/network-manager.postinst
+++ b/debian/network-manager.postinst
@@ -53,9 +53,6 @@ case "$1" in
 chmod 0600 /var/lib/NetworkManager/secret_key
 fi
 fi
-if dpkg --compare-versions "$2" lt-nl 

Bug#883245: More info

[Jesus Eguiluz]

Hi, I have more info.

The same problem, I can't open links from thunderbird.

I used to be workaround it by put the
/etc/apparmor.d/usr.bin.thunderbird in complain mode. But this not work
anymore.

Now I have to disable de /etc/apparmor.d/usr.bin.thunderbird profile
with sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird


sep 15 14:36:55 gsus-v110-14ast audit[9930]: AVC apparmor="DENIED"
operation="file_mmap" profile="thunderbird//sanitized_helper"
name="/opt/waterfox/waterfox" pid=9930 comm="waterfox"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
sep 15 14:36:55 gsus-v110-14ast kernel: audit: type=1400
audit(1600191415.454:368): apparmor="DENIED" operation="file_mmap"
profile="thunderbird//sanitized_helper" name="/opt/waterfox/waterfox"
pid=9930 comm="waterfox" requested_mask="m" denied_mask="m" fsuid=1000
ouid=0
sep 15 14:36:55 gsus-v110-14ast audit[9932]: AVC apparmor="DENIED"
operation="file_mmap" profile="thunderbird//sanitized_helper"
name="/opt/waterfox/waterfox" pid=9932 comm="waterfox"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
sep 15 14:36:55 gsus-v110-14ast kernel: audit: type=1400
audit(1600191415.556:369): apparmor="DENIED" operation="file_mmap"
profile="thunderbird//sanitized_helper" name="/opt/waterfox/waterfox"
pid=9932 comm="waterfox" requested_mask="m" denied_mask="m" fsuid=1000
ouid=0
sep 15 14:36:55 gsus-v110-14ast audit[9934]: AVC apparmor="DENIED"
operation="file_mmap" profile="thunderbird//sanitized_helper"
name="/opt/waterfox/waterfox" pid=9934 comm="waterfox"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
sep 15 14:36:55 gsus-v110-14ast kernel: audit: type=1400
audit(1600191415.684:370): apparmor="DENIED" operation="file_mmap"
profile="thunderbird//sanitized_helper" name="/opt/waterfox/waterfox"
pid=9934 comm="waterfox" requested_mask="m" denied_mask="m" fsuid=1000
ouid=0
sep 15 14:36:55 gsus-v110-14ast audit[9937]: AVC apparmor="DENIED"
operation="file_mmap" profile="thunderbird//sanitized_helper"
name="/opt/waterfox/waterfox" pid=9937 comm="waterfox"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
sep 15 14:36:55 gsus-v110-14ast kernel: audit: type=1400
audit(1600191415.846:371): apparmor="DENIED" operation="file_mmap"
profile="thunderbird//sanitized_helper" name="/opt/waterfox/waterfox"
pid=9937 comm="waterfox" requested_mask="m" denied_mask="m" fsuid=1000
ouid=0
sep 15 14:36:56 gsus-v110-14ast audit[9939]: AVC apparmor="DENIED"
operation="file_mmap" profile="thunderbird//sanitized_helper"
name="/opt/waterfox/waterfox" pid=9939 comm="waterfox"
requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
sep 15 14:36:56 gsus-v110-14ast kernel: audit: type=1400
audit(1600191416.234:372): apparmor="DENIED" operation="file_mmap"
profile="thunderbird//sanitized_helper" name="/opt/waterfox/waterfox"
pid=9939 comm="waterfox" requested_mask="m" denied_mask="m" fsuid=1000
ouid=0

Sl2


Jesus Eguiluz
Ingeniero Electrónico.
Investigación y Desarrollo
Andes Electrónica Ltda.
+56 2 2347-8780
www.andeselec.com

Bug#970402: transition: log4cxx

[Tobias Frost]

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

Hello release team!

I'm preparing the transition of log4cxx. It's already showing up
on https://release.debian.org/transitions/html/auto-log4cxx.html, so
ben seems to be hapy…

Building r-deps was successful:
ros-rosconsole ✔
solarpowerlog  ✔
zookeeper ✔

Everything looks ready ;-)

Waiting for the green light from you ;-)

Cheers,
-- 
tobi

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Niels Thykier]

On Tue, 15 Sep 2020 23:00:44 +0800 Drew Parsons  wrote:
> [...]
> 
> dh doesn't document its --buildsystem option properly. The dh man page 
> documents --with but not --buildsystem (which gets mentioned only in an 
> example). But that's not dh-cmake's fault!
> 
> 

Pedantic interjection to explain the status quo... ;)

--buildsystem is *NOT* a dh option. :)

The --buildsystem option is an option for the dh_auto_* helpers and dh
merely passes it on to (all) helpers. I hope that clarifies why dh would
not document it (because it does not really care about it except for
optimization purposes).

Thanks,
~Niels

Bug#970401: linux-image-5.8.0-1-amd64: Cursor still blinks (not usually visibly) even after it is turned off

[Asher Gordon]

Package: src:linux
Version: 5.8.7-1
Severity: normal
X-Debbugs-Cc: Asher Gordon 

Dear Maintainer,

When the cursor is turned off in the console, using

$ printf '\e[?17;0;0c'

the cursor still blinks, although not visibly. This may not seem like a
serious bug, or even a bug at all, but it becomes noticeable and
annoying when watching a video with mplayer using the fbdev2 output. For
example,

$ printf '\e[?17;0;0c'; mplayer -quiet -vo fbdev2 -vf 
scale= ; tput reset

The cursor is visible as a flickering black rectangle, making it very
annoying to watch videos like this.

Note that this bug is not present in linux-image-5.7.0-3-amd64, and when
I boot onto that kernel, I cannot reproduce the bug. When watching
videos as I have described, while booted onto the old kernel, the cursor
is not visible at all (although, it is of course if you omit the initial
'printf').

And before you ask "why don't you just use Totem or VLC or something?"
it's because I prefer to work in the console. :-)

Thanks,
Asher

-- Package-specific info:
** Version:
Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 
(2020-09-05)

** Command line:
BOOT_IMAGE=/vmlinuz root=/dev/sda1 rw quiet splash

** Tainted: I (2048)
 * workaround for bug in platform firmware applied

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Libiquity
product_name: Taurinus X200
product_version: 1.0
chassis_vendor: Libiquity
chassis_version: 
bios_vendor: coreboot
bios_version: CBET4000 4.0
board_vendor: Libiquity
board_name: Taurinus X200
board_version: 1.0

** Loaded modules:
rfcomm
fuse
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
ctr
ccm
bnep
ath9k
ath9k_common
btusb
btrtl
btbcm
btintel
ath9k_hw
bluetooth
ath
mac80211
jitterentropy_rng
drbg
coretemp
kvm_intel
cfg80211
aes_generic
kvm
snd_hda_codec_conexant
crypto_simd
uvcvideo
cryptd
snd_hda_codec_generic
glue_helper
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
snd_hda_intel
snd_intel_dspcfg
videobuf2_common
irqbypass
ansi_cprng
snd_hda_codec
videodev
pcspkr
snd_hda_core
serio_raw
mc
iTCO_wdt
intel_pmc_bxt
iTCO_vendor_support
snd_hwdep
sg
watchdog
ecdh_generic
ecc
libaes
snd_pcm
libarc4
nvram
snd_timer
ledtrig_audio
ac
snd
soundcore
rfkill
binfmt_misc
evdev
acpi_cpufreq
ecryptfs
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
xor
zstd_decompress
zstd_compress
raid6_pq
libcrc32c
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
i915
ahci
libahci
libata
i2c_algo_bit
drm_kms_helper
cec
psmouse
drm
e1000e
uhci_hcd
ehci_pci
scsi_mod
ehci_hcd
i2c_i801
usbcore
i2c_smbus
lpc_ich
usb_common
ptp
pps_core
battery
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub [8086:2a40] (rev 07)
Subsystem: Lenovo ThinkPad T400 [17aa:20e0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics 
Controller [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller [8086:2a43] (rev 07)
Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics 
Controller [17aa:20e4]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network 
Connection [8086:10f5] (rev 03)
Subsystem: Lenovo ThinkPad T400 [17aa:20ee]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T400 [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: uhci_hcd
Kernel modules: 

Bug#970384: ITP: image-factory -- Image factory for the IONOS customers images

[Sandro Tosi]

> * Package name: image-factory
>   Version : 1.0.0
>   Upstream Author : Benjamin Drung 
> * URL : https://github.com/ionos-enterprise/image-factory
> * License : ISC
>   Programming Lang: Python
>   Description : Image factory for the IONOS customers images

isnt `image-factory` a way too generic name for something that seems
IONOS specific? or does the short description not need to mention
IONOS if it's actually a tool to "build golden Linux images" (But
actually use that in the short descr)?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#969910: RFS: grcompiler/5.2-2.1 [NMU] [RC] -- Compiler of smart (graphite) fonts

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #969910
Control: close -1

Hi Bastian,

the NMU looks good. I uploaded it to DELAYED/5 and send a nmudiff to the 
package.
(I'm closing the bug, if something happens to the NMU we can reopen it.)

Thanks for your contribution to Debian!

-- 
tobi 

Bug#970400: grcompiler: diff for NMU version 5.2-2.1

[Tobias Frost]

Package: grcompiler
Version: 5.2-2
Severity: normal
Tags: patch  pending


Dear maintainer,

Bastian Germann  has prepared an NMU [1] for 
grcompiler
(versioned as 5.2-2.1) and uploaded it to DELAYED/5. Please feel free to tell
me if I should delay it longer.

Regards.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969910

-- 
tobi
diff -Nru grcompiler-5.2/debian/changelog grcompiler-5.2/debian/changelog
--- grcompiler-5.2/debian/changelog	2020-08-16 11:41:30.0 +0200
+++ grcompiler-5.2/debian/changelog	2020-09-08 17:44:40.0 +0200
@@ -1,3 +1,12 @@
+grcompiler (5.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patches for big endian (Closes: #961445)
+  * Add upstream patch for font names (Closes: #961438)
+  * d/copyright: Add missing Upstream-Contact
+
+ -- Bastian Germann   Tue, 08 Sep 2020 17:44:40 +0200
+
 grcompiler (5.2-2) unstable; urgency=medium
 
   * Team upload 
diff -Nru grcompiler-5.2/debian/copyright grcompiler-5.2/debian/copyright
--- grcompiler-5.2/debian/copyright	2020-08-16 11:41:30.0 +0200
+++ grcompiler-5.2/debian/copyright	2020-09-08 17:44:22.0 +0200
@@ -1,5 +1,6 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: GrCompiler
+Upstream-Contact: silgraphite-de...@lists.sourceforge.net
 Source: https://github.com/silnrsi/grcompiler
 License: LGPL-2.1+ or CPL-0.5+
 
diff -Nru grcompiler-5.2/debian/patches/0001-Build-with-system-s-LZ4.patch grcompiler-5.2/debian/patches/0001-Build-with-system-s-LZ4.patch
--- grcompiler-5.2/debian/patches/0001-Build-with-system-s-LZ4.patch	2020-08-16 11:41:30.0 +0200
+++ grcompiler-5.2/debian/patches/0001-Build-with-system-s-LZ4.patch	1970-01-01 01:00:00.0 +0100
@@ -1,59 +0,0 @@
-From: Bastian Germann 
-Date: Thu, 21 May 2020 11:32:59 +0200
-Description: Build with system's LZ4

-diff --git a/compiler/CMakeLists.txt b/compiler/CMakeLists.txt
-index dcc7f2d..deb50c7 100644
 a/compiler/CMakeLists.txt
-+++ b/compiler/CMakeLists.txt
-@@ -22,9 +22,8 @@ message(STATUS "ICU Libraries: " ${ICU_VERSION})
- 
- add_subdirectory(Generic)
- add_subdirectory(Grammar)
--add_subdirectory(LZ4)
- 
--include_directories(Generic Grammar LZ4 ${ICU_INCLUDE_DIR})
-+include_directories(Generic Grammar ${ICU_INCLUDE_DIR})
- 
- add_library(TtfUtil OBJECT TtfUtil.cpp)
- 
-diff --git a/compiler/Makefile.am b/compiler/Makefile.am
-index 2cf0fea..3bd2242 100644
 a/compiler/Makefile.am
-+++ b/compiler/Makefile.am
-@@ -1,7 +1,7 @@
--AM_CPPFLAGS = -I@srcdir@/Generic -I@srcdir@/Grammar -I@srcdir@/LZ4
-+AM_CPPFLAGS = -I@srcdir@/Generic -I@srcdir@/Grammar
- 
--SUBDIRS = Generic Grammar LZ4
--LIBS = @LIBS@ @LIBICONV@ -LGeneric -LGrammar -LLZ4 -lgeneric -lparser -llz4
-+SUBDIRS = Generic Grammar
-+LIBS = @LIBS@ @LIBICONV@ -LGeneric -LGrammar -lgeneric -lparser -llz4
- EXTRA_DIST = resource.h GrCompiler.rc GrpParser.g GrpParser_readme.txt GrpParserTokenTypes.txt stddef.gdh
- 
- bin_PROGRAMS = grcompiler
-diff --git a/compiler/OutputToFont.cpp b/compiler/OutputToFont.cpp
-index 677a04a..a462fed 100644
 a/compiler/OutputToFont.cpp
-+++ b/compiler/OutputToFont.cpp
-@@ -16,7 +16,7 @@ Description:
- 	Include files
- ***/
- #include "main.h"
--#include "LZ4/lz4hc.h"
-+#include 
- 
- #include 
- #include 
-diff --git a/configure.ac b/configure.ac
-index f9439c3..22cf145 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -139,7 +139,6 @@ AC_CONFIG_FILES(Makefile \
- 	compiler/Makefile \
- 	compiler/Generic/Makefile \
- 	compiler/Grammar/Makefile \
--	compiler/LZ4/Makefile \
- test/Makefile)
- 
- AC_CONFIG_SUBDIRS([test/GrcRegressionTest])
diff -Nru grcompiler-5.2/debian/patches/0001-Reimplement-BuildFontNames-using-std-lib.patch grcompiler-5.2/debian/patches/0001-Reimplement-BuildFontNames-using-std-lib.patch
--- grcompiler-5.2/debian/patches/0001-Reimplement-BuildFontNames-using-std-lib.patch	1970-01-01 01:00:00.0 +0100
+++ grcompiler-5.2/debian/patches/0001-Reimplement-BuildFontNames-using-std-lib.patch	2020-09-08 17:40:48.0 +0200
@@ -0,0 +1,312 @@
+Origin: https://github.com/silnrsi/grcompiler/commit/a9e6dec71cbc11c5d637fa342e51867330001862
+From: Tim Eves 
+Date: Mon, 17 Aug 2020 16:20:01 +0700
+Subject: Fix #32 Reimplement BuildFontNames using std lib
+
+Since C++11 utf version of std::string are available, reimplement
+GrcMnager::BuildFontNames() using these instead of lots of memcpy calls
+and buffer allocations to perform the require string manipulations. This
+also makes the logic of the function more apparent.
+---
+diff --git a/compiler/GrcManager.h b/compiler/GrcManager.h
+index df40f5f..2e86e03 100644
+--- a/compiler/GrcManager.h
 b/compiler/GrcManager.h
+@@ -32,12 +32,9 @@ struct PlatEncChange
+ 	uint16 encodingID;
+ 	uint16 engLangID;
+ 	bool fChangeName;
+-	utf16 * pchwFullName;
+-	utf16 * pchwUniqueName;
+-	utf16 * 

Bug#970398: xfwm4: Since 4.14.5-1 I get a garbled desktop

[Elimar Riesebieter]

Package: xfwm4
Version: 4.14.5-1
Severity: important
Tags: patch


Dear Maintainer,

since 4.14.5-1 I get a garbled desktop. Bisecting upstreams source
brought me to commit 168cf03 "Fix errorTrap leak in Free_win_data".
BTW installing xfwm4-4.14.2-1 gets back a normal desktop.

Attached patch reverts tis commit and 4.15.5 is running fine now.


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

Kernel: Linux 5.8.9-pippin-lxtec-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfwm4 depends on:
ii  libc6 2.31-3
ii  libcairo2 1.16.0-4
ii  libepoxy0 1.5.4-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libglib2.0-0  2.66.0-1
ii  libgtk-3-03.24.23-1
ii  libpango-1.0-01.46.1-1
ii  libpangocairo-1.0-0   1.46.1-1
ii  libstartup-notification0  0.12-6
ii  libwnck-3-0   3.36.0-1
ii  libx11-6  2:1.6.10-3
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfce4ui-2-04.14.1-1+b1
ii  libxfce4util7 4.14.0-1
ii  libxfconf-0-3 4.14.3-1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxinerama1  2:1.1.4-2
ii  libxpresent1  1.0.0-2+b10
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxres1  2:1.2.0-4

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.48.8+dfsg-1

Versions of packages xfwm4 suggests:
pn  xfce4  

-- no debconf information
>From 55183d7ffd3e2d18b7bfaaaecc4617b4932d030b Mon Sep 17 00:00:00 2001
From: Elimar Riesebieter 
Date: Tue, 15 Sep 2020 17:06:30 +0200
Subject: [PATCH] Revert Fix errorTrap leak in free_win_data

---
 src/compositor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor.c b/src/compositor.c
index 93932081d..0bc569595 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -857,7 +857,7 @@ free_win_data (CWindow *cw, gboolean delete)
 cw->saved_picture = cw->picture;
 cw->picture = None;
 }
-myDisplayErrorTrapPopIgnored (display_info);
+myDisplayErrorTrapPush (display_info);
 }
 
 static Picture
-- 
2.28.0

Bug#970399: firefox-esr-l10n-fi recommends non existing package xul-ext-mozvoikko

[Witold Baryluk]

Package: firefox-esr-l10n-fi
Version: 78.2.0esr-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

firefox-esr-l10n-fi Recommends xul-ext-mozvoikko

but that packages doesn't exist, it was removed from unstable in 2018.
The last time it was shipped in stable, is jessie in 2012.


Please remove this recommends from the package. It probably even should
be recommends, but suggest in the first place, but that is not important.


Thanks!



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

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

Versions of packages firefox-esr-l10n-fi depends on:
ii  firefox-esr  78.2.0esr-1

Versions of packages firefox-esr-l10n-fi recommends:
pn  xul-ext-mozvoikko  

firefox-esr-l10n-fi suggests no packages.

-- no debconf information

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Svante Signell]

On Mon, 2020-09-14 at 20:52 +0300, Timo Aaltonen wrote:
> On 14.9.2020 18.44, Svante Signell wrote:
> > found 909436 2.4.102-1
> > thanks
> > 
> > Hello again,
> > 
> > libdrm still FTBFS on GNU/Hurd now due to bug #970304 and still
> > missing support for Hurd in drm.h and xf86drm.h. Attached is a
> > patch, hurd-port.diff, to fix this. The rest of that patch address
> > PATH_MAX issuesin xf86dri.c as PATH_MAX is not defined for
> > GNU/Hurd.
> > 
> > Note: hurd-port.diff depends on that xf86drm.c.diff in #970304 is
> > applied before!
> 
> these would need to go upstream..

Both patches (somewhat modified) submitted upstream to the old issues:
https://gitlab.freedesktop.org/mesa/drm/-/issues/23
https://gitlab.freedesktop.org/mesa/drm/-/issues/24

Thanks!

Bug#954189: Upload approval for acmetool 0.2 in buster-backports

[Ralph Giles]

As an update on this, I've gotten acmetool 0.2 to build on buster. The
following packages need backporting:

- golang-github-gofrs-uuid
- golang-golang-x-xerrors
- golang-github-google-go-cmp
- golang-gopkg-square-go-jose.v2
- golang-gopkg-hlandau-acmeapi.v2
- acmetool

The 5 golang-* packages are source-only libraries, which shouldn't
affect users of buster. They're just necessary to build the newer
version entirely from packaged software.

Of these packages, two require minor changes:

- acmetool packaging fails because dwz can't find any debug tables to
remove in the binary built by buster's golang 1.11. I suggest just
skipping this step.

- golang-gopkg-square-go-jose.v2 depends on dephelper-compat 13, but
buster has 12. Downgrading the requirement seems to work fine.

On IRC I got push-back from the go-team about reviewing changes, so I'm
unsure how to proceed. Can someone from the letsencrypt team please
comment on the proposed changes, either here, or on the salsa
repositories?

I've been recording the current state of my backport effort, including
patches, at https://gitlab.xiph.org/rillian/acmetool-backport if anyone
wants to reproduce.

Thanks,
Ralph


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

Bug#968504: RFS: aqemu/0.9.2-2.4 [NMU] [RC] -- Qt5 front-end for QEMU and KVM

[Tobias Frost]

On Sun, Sep 13, 2020 at 04:33:01PM +0200, Alexis Murzeau wrote:
> Hi,
> 
> Thanks for your review :)
> 
> Le 26/08/2020 à 12:39, Tobias Frost a écrit :
> > Control: tags -1 moreinfo
> > 
> > Hi Alexis,
> > 
> > this is an incomplete review, 'cause I ran out of time, lunch break was not 
> > long
> > enough :-(
> > 
> > - This should be not an NMU but an QA-Upload so you need to Set the 
> > maintainer
> > to the QA group, as explained here: 
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning-a-package
> > 
> > [...]
 
> Ok, I've put sources with imported debsnap history in 
> https://salsa.debian.org/debian/aqemu.


 
> > 
> > -  "(For: #957003)"
> > Please close the bug in the changelog; it can always be reopened if it fails
> > again…)
> 
> Ok
> 
> > 
> > -  I'm not sure about dropping the Depends on qemu entirely. Does aqemu work
> > without qemu installed? If not, you probably need to follow the 
> > recommendation
> > in #966261
> > and add a Depend on qemu-system-XXX | qemu-system-XXX | … (listing all 
> > archs).
> > 
> 
> I'm wondering if I should put these as a Recommends instead.
> I'm thinking about cases where someone would want to use a different qemu not 
> packaged,
> like a custom one or a manually compiled one.
> 
> But I'm not sure I should handle these cases, what do you think ?

I wouldn't consider use case not using official debian packages too much…
Instead, lets look what policy says on Depends (omitting non relevant 
paragraphs)

  The Depends field should be used if the depended-on package is required for
the depending package to provide a significant amount of functionality.

(I can't judge because I don't know aqemu, but my feeling is Recommends would
be too weak)

 
> 
> > 
> > There were other bugs on the packages too. Did you try to triage them?
> > (It would be nice to at least report them to upstream, but that's not a show
> > stopper for the sponsoring)
> 
> I'm not using aqemu myself, but some of them or probably upstream, and maybe 
> fixed
> since they were reported, but newer versions (0.9.6+) are qualified as not yet
> stable by upstream.
> I will see if they were already reported or still relevant
> (some of them were created in 2012).

Cool, thanks for your help here

> > 
> > Many thanks for contributing to Debian!
> > 
> 
> Thanks for your review :)

To avoid a dead-lock, you say when you're ready? (by removing the moreinfo tag)

-- 
tobi

Bug#969663: polyphone is marked for autoremoval from testing

[Thorsten Glaser]

Felix Lechner dixit:

>> Is there anything I can help to ensure it’s not autoremoved?
>
>I just saw it this morning and plan to upload 4.5.0 later today. From
>what I understand, closing #969663 should postpone the autoremoval
>process?

Thanks!

The autoremoval will go on until a version with #969663 fixed
enters testing, but that is why such a long advance notice is
given (five weeks or so).

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#970397: hw-probe: recommends transitional package vulkan-utils

[Jonas Smedegaard]

Package: hw-probe
Version: 1.5-1
Severity: normal

hw-probe recommends transitional package vulkan-utils.

Please instead recommend real package vulkan-tools.

Bug#969663: polyphone is marked for autoremoval from testing

[Felix Lechner]

Hi Thorsten,

> Is there anything I can help to ensure it’s not autoremoved?

I just saw it this morning and plan to upload 4.5.0 later today. From
what I understand, closing #969663 should postpone the autoremoval
process?

Kind regards
Felix

Bug#257457: gnucash: Double click on placeholder account should open tree, not open account

[[Stephan Magg]]

Hello,

As of version 3.10 or earlier, the subtree can be opened or closed with a
double click on a placeholder account.

Best regards,
Stephan Magg

Bug#970396: Please include kde shortcut configuration

[Shengjing Zhu]

Package: flameshot
Version: 0.8.0~git20200907-1
Severity: wishlist

As upstream provides the kde shortcuts, I think it could be included the
package. Maybe /usr/share/khotkeys/ is the right place to put.

Bug#969663: polyphone is marked for autoremoval from testing

[Thorsten Glaser]

Debian testing autoremoval watch dixit:

>polyphone 2.2.0.20200612+dfsg1-1 is marked for autoremoval from testing on 
>2020-10-20
>
>It (build-)depends on packages with these RC bugs:
>969663: wolfssl: CVE-2020-12457 CVE-2020-15309 CVE-2020-24585 CVE-2020-24613
> https://bugs.debian.org/969663

Is there anything I can help to ensure it’s not autoremoved?

Thanks,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr

Bug#970352: unprivileged podman dies with gibberish

[Reinhard Tartler]

Control: tag -1 moreinfo

Hi Harald,


On Tue, Sep 15, 2020 at 1:51 AM Harald Dunkel  wrote:

> Package: podman
> Version: 2.0.6+dfsg1-1
>
> Unprivileged podman dies with some gibberish instead of a readable
> error message:
>
> % podman run -it debian /bin/bash
> Trying to pull quay.io/debian...
>error parsing HTTP 404 response body: invalid character '<' looking for
> beginning of value: " Final//EN\">\n404 Not Found\nNot Found\nThe
> requested URL was not found on the server. If you entered the URL manually
> please check
> your spelling and try again.\n"
> Trying to pull docker.io/library/debian...
> Getting image source signatures
> Copying blob 57df1a1f1ad8 done
> Copying config f6dcff9b59 done
> Writing manifest to image destination
> Storing signatures
> ERRO[0010] Error while applying layer: ApplyLayer exit status 1 stdout:
> stderr: there might not be enough IDs available in the namespace (requested
> 0:42 for /etc/gshadow): lchown /etc/gshadow: invalid argument
>ApplyLayer exit status 1 stdout:  stderr: there might not be enough IDs
> available in the namespace (requested 0:42 for /etc/gshadow): lchown
> /etc/gshadow: invalid argument
>

I think this is the relevant error message. May I ask a couple of questions:


   1. Did this work with an earlier verison of podman, i.e., is this a
   regression? What version worked for you before?
   2. Does the problem go away after a reboot?
   3. Does the command 'unshare -nr id' work for you?
   4. Did you read the file /usr/share/doc/podman/README.Debian, in
   particular the parts "User Namespaces" and "Troubleshooting rootless mode"?


Best,
-rt

-- 
regards,
Reinhard

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Drew Parsons]

On 2020-09-15 22:13, Kyle Edwards wrote:

Hi Drew,

Thanks for trying dh-cmake.

On 9/15/20 9:54 AM, Drew Parsons wrote:

dh-cmake has been configured to fail if debian/dh-cmake.compat does
not exist.

You can also require `dh-cmake-compat (=1)` in your `Build-Depends` as
a modern alternative. (You can even take out `dh-cmake`, since
`dh-cmake-compat` implicitly depends on this.) I don't think the
README even mentions the `dh-cmake.compat` file anymore.

I think it would work better if dh_cmake assumed version 1, unless
a different version is provided in debian/dh-cmake.compat.

I think requiring `dh-cmake-compat (=1)` is sufficiently lightweight,
but if lots of people complain I may end up doing this.

i.e. dh --with cmake should just work (as dh_make version 1), without
having to provide an explicit debian/dh-cmake.compat


Please note that the `--with` argument is also outdated, the modern
approach is to require `dh-sequence-cmake` in your `Build-Depends`.

Please let me know what you think.



Maybe it's a packaging and documentation bug?

There is no README file provided by the dh-cmake package, and no man 
page for /usr/bin/dh_cmake_install


I got debian/dh-cmake.compat from reverse engineering 
/usr/lib/python3/dist-packages/dhcmake/common.py against the error 
message "CompatError("No compat level specified")" associated with 
self._compat


My bug report is equivalent to saying self._compat should always be set 
to 1, unless otherwise specified.


If the package provides the README file, then I can read it to see what 
it says about setting dh-cmake-compat (=1)

Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS

[John Paul Adrian Glaubitz]

On 9/15/20 4:42 PM, Thorsten Glaser wrote:
> Control: severity -1 wishlist
> Control: tags -1 wontfix
> 
> John Paul Adrian Glaubitz dixit:
> 
>> On m68k and sh4, the buildds are currently configured to pass "nocheck"
> 
> Precisely for this reason, some packages in the archive ignore that
> on these architectures.
> 
> Without the testsuite we cannot reliably build due to bugs in the
> toolchain, and it doesn’t run for long anyway.

I understand the reasoning but it's nevertheless incorrect.

If you want to see a testsuite being run, you can ask the buildd maintainers
or test the package yourself. But you shouldn't arbitrarily override 
policy-defined
mechanisms so that a package behaves unexpectedly.

"nocheck" will remain activated as long as we're using qemu-user over 
qemu-system
which will be the case until the kernel on the affected architectures can use 
more
RAM on emulated systems.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#970340: [Debian-med-packaging] Bug#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

[Andreas Tille]

Dear Sascha,

On Tue, Sep 15, 2020 at 04:32:02PM +0200, Sascha Steinbiss wrote:
> 
> I can confirm that that was the issue. I have pushed a fix to git and
> will make an upload later if there are no objections.

No objections for fixing a bug at all. ;-)

Thanks a lot

   Andreas.

-- 
http://fam-tille.de

Bug#970392: dh-cmake: dh_cmake should not require dh-cmake.compat

[Drew Parsons]

On 2020-09-15 22:46, Kyle Edwards wrote:

On 9/15/20 10:41 AM, Drew Parsons wrote:

Maybe it's a packaging and documentation bug?

There is no README file provided by the dh-cmake package, and no man 
page for /usr/bin/dh_cmake_install


OK, yeah, this is definitely a documentation bug. The README is here:

https://gitlab.kitware.com/debian/dh-cmake/-/blob/master/README.md

I'll look at adding the README to the package, though I'd definitely
like to get man pages written at some point.




Mind you, reading your README reminds me I probably want dh 
--buildsystem=cmake anyway, rather than dh --with cmake.


dh doesn't document its --buildsystem option properly. The dh man page 
documents --with but not --buildsystem (which gets mentioned only in an 
example). But that's not dh-cmake's fault!

Bug#970391: /bin/systemctl: Changes in [Install] not valued by "systemctl enable" if service already enabled.

[Michael Biebl]

Please post full test example files and complete sequence of commands.



signature.asc
Description: OpenPGP digital signature

Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs

[Michael Musenbrock]

Source: firmware-nonfree
Severity: important

Dear maintainer,

first of all thanks for maintaining and packaging the linux-firmware files 
repository as debian packages.

We currently need to manually obtain the 
linux-firmware.git:amd/amd_sev_fam17h_model3xh.sbin [1] file on
our AMD EPYC servers. The firmware files containing the AMD SEV firmware 
closing security vulnerabilities [2]
and fixes bugs and adds improvements to the AMD SEV implementation.

I'm most likely unqualified for legal questions but the LICENSE.amd-sev [3] 
reads quite similar to the already
added amdgpu license [4]. So I hope this is not the reason, why those files 
were not added in the past.

The severity was choosen because it fixes a security vulnerability, please 
change accordingly if you think
it is wrong.

Thanks in advance. Best regards,
michael

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amd-sev
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amdgpu

Bug#970353: mksh: Ignores "nocheck" in DEB_BUILD_OPTIONS

[Thorsten Glaser]

Control: severity -1 wishlist
Control: tags -1 wontfix

John Paul Adrian Glaubitz dixit:

>On m68k and sh4, the buildds are currently configured to pass "nocheck"

Precisely for this reason, some packages in the archive ignore that
on these architectures.

Without the testsuite we cannot reliably build due to bugs in the
toolchain, and it doesn’t run for long anyway.

Release architectures aren’t affected.

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

Bug#970238: ITP: survivor -- Tool set for simulating/evaluating SVs

[Tomas Pospisek]

On 13.09.20 13:40, Nilesh Patra wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nilesh Patra mailto:npatra...@gmail.com>>
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> 
> * Package name    : survivor
>   Version         : 1.0.6-1
>   Upstream Author : Fritz Sedlazeck
> * URL             : https://github.com/fritzsedlazeck/SURVIVOR
> * License         : Expat
>   Programming Lang: C++
>   Description     :  Tool set for simulating/evaluating SVs
>  SURVIVOR is a tool set for simulating/evaluating
>  SVs, merging and comparing SVs within and among
>  samples, and includes various methods to reformat
>  or summarize SVs.
> 
> I shall maintain this package.

Could you please clarify in the description what an SV is supposed to
be? I'd suggest:

SURVIVOR is a tool set for simulating/evaluating
SVs (Solenoid Valves)[https://en.wikipedia.org/wiki/Solenoid_valve],
merging and ...