date:20201028

Hi Thorsten,

On Wed, Oct 28, 2020 at 8:47 PM Thorsten Glaser  wrote:
>
> So lintian maybe behaves different from that testcase?

Probably not. The test case was reduced from Lintian. (And yes, we
ship a snowman!)

Kind regards
Felix Lechner

Bug#973334: lintian: URL in systemd-service-file-uses-deprecated-syslog-facility incorrect

2020-10-28 Thread Vagrant Cascadian

Package: lintian
Version: 2.99.0
Severity: normal

The URL referenced in systemd-service-file-uses-deprecated-syslog-facility:

  Refer to https://github.com/systemd/systemd/blob/master/NEWS#L101 for
  details.

This references a changing file by line number, and it tends to get new
changes at the top, so the link is very likely to point to the wrong
line on any project that is still making updates.

It should probably point to a specific revision and/or tag, such as:

  
https://github.com/systemd/systemd/blob/6706384a89ae0c462e7172588c80667190c4d9e2/NEWS#L724


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#972878: lintian: Wide character in say at Lintian::Output line 156

2020-10-28 Thread Thorsten Glaser

Felix Lechner dixit:

>Feel free to try it. The test case is attached.

tglase@tglase-nb:~ $ perl /tmp/x
Wide character in say at /tmp/x line 13.
UTF-8: ✓ (☃)

So lintian maybe behaves different from that testcase?

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

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

Hi Paul,

On Wed, Oct 28, 2020 at 7:39 PM Paul Wise  wrote:
>
> Since most folks would only be interested in the lintian results for
> the latest version in unstable, it would be nice if the middle click
> could be eliminated using a symlink or redirect. An "all versions" link
> could be added for folks who are interested in that.

We just found a hosting provider for our new dynamic web site. It will
be an experiment for the time being, but is expected to bring this
feature, as well as many others, based on queries in a Postgres
database that is already installed there.

Kind regards
Felix Lechner

Bug#972878: lintian: Wide character in say at Lintian::Output line 156

Hi Thorsten,

On Wed, Oct 28, 2020 at 7:47 PM Thorsten Glaser  wrote:
>
> So it will just go away if we wait long enough.

Maybe. I did not see it in a chroot with unstable, but the Perl folks
who helped did not use Debian, and still confirmed the behavior.
Perhaps someone patched our Perl; the bugs remain open upstream.

Feel free to try it. The test case is attached.

Kind regards
Felix Lechner

wide-character-error
Description: Binary data

Bug#972878: lintian: Wide character in say at Lintian::Output line 156

2020-10-28 Thread Thorsten Glaser

Felix Lechner dixit:

>The issues have been open since 2007 and 2011. We do not currently
>have a plan for mitigation.

AIUI this only affects buster anyway and not sid?

So it will just go away if we wait long enough.

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

2020-10-28 Thread Paul Wise

Package: lintian
Severity: wishlist

When clicking through to lintian.d.o from tracker.d.o and other places,
there is an extra click from the source package page to the source
package version page containing the actual lintian results.

https://tracker.debian.org/pkg/iotop ->
https://lintian.debian.org/sources/iotop.html ->
https://lintian.debian.org/sources/iotop/0.6-24-g733f3f8-1.1.html

Since most folks would only be interested in the lintian results for
the latest version in unstable, it would be nice if the middle click
could be eliminated using a symlink or redirect. An "all versions" link
could be added for folks who are interested in that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

2020-10-28 Thread Antonio Terceiro

On Wed, Oct 28, 2020 at 07:02:06PM -0300, Lucas Kanashiro wrote:
> Thanks to David Rodriguez (our dear bundler upstream maintainer :) I was
> able to workaround the bug locally and understand a bit better what is going
> on.
> 
> The source of this problem is this commit:
> 
> https://github.com/rubygems/rubygems/commit/226ec115fe503bcc93bffdf5cd3e8a668890b4d8
> 
> Quoting David:
> 
> "Anyways, the actual check making bundler believe the ffi gem is missing
> extensions is `File.exist?(gem_build_complete_path)`. I believe the idea of
> this check is that bundler/rubygems are not able to know which artifacts an
> extension will generate, so what rubygems does is generating this dummy file
> at a well known path after a successful extension compilation, so that it
> can later check the existence of this path when it needs to know whether a
> gem is missing extensions."
> 
> There are 2 workarounds to fix this issue:
> 
> 1) Create this dummy file.
> 
> $ mkdir -p 
> /usr/share/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/ffi-1.12.2/
> 
> $ touch 
> /usr/share/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/ffi-1.12.2/gem.build_complete
> 
> 
> After that 'bundle --local' will find the ffi gem.
> 
> 2) Remove the extension from gemspec.
> 
> $ sed -i.bak -e 3d
> /usr/share/rubygems-integration/2.7.0/specifications/ffi-1.12.2.gemspec
> 
> After removing the header line containing "# stub: ext/ffi_c/extconf.rb",
> 'bundler --local' also works fine and find the ffi gem.
> 
> I think the second approach is what we want, and the proper fix would be to
> not include extensions in our gemspecs. We could try to achieve that via
> gem2deb. Any thoughts?

I think we should diverge less, not more, from upstream. So I would go
for 1).

We already use the Rubygems classes that do builds, but it seems that
this new feature was added around the method we use. I think we should
change gem2deb to include that file, ideally reusing more of the code
from rubygems.

The relevant code is lib/rubygems/ext/builder.rb in rubygems, and
lib/gem2deb/extension_builder.rb in gem2deb.


signature.asc
Description: PGP signature

Bug#972878: lintian: Wide character in say at Lintian::Output line 156

Control: retitle -1 lintian: Drop global UTF-8 PerlIO encoding layer

Hi,

> Wide character in say at
> /lcl/lechner/lintian/git/bin/../lib/Lintian/Output.pm line 156.

This is a bug in Perl:

https://rt.cpan.org/Public/Bug/Display.html?id=69011

in combination with

https://github.com/perl/perl5/issues/8997
https://github.com/perl/perl5/issues/8998

The issues have been open since 2007 and 2011. We do not currently
have a plan for mitigation.

One way would be to drop the global PerlIO encoding layer for UTF-8
and instead use Unicode::UTF8::encode_utf8 explicitly, everywhere.
That would generate a fair amount of work, though.

Kind regards
Felix Lechner

Bug#968607: [pkg-apparmor] Bug#968607: pidgin-openpgp: AppArmor profil prevents execution of XEP-0027.pl

2020-10-28 Thread Seth Arnold

On Sat, Oct 24, 2020 at 06:27:08PM +0200, intrigeri wrote:
> Given pidgin-openpgp was removed from testing and sid,
> IMO it's not worth adding support for it in the AppArmor profile,
> so let's instead ensure the obsolete pidgin-openpgp package
> gets removed if apparmor-profiles-extra is installed:
> 
> https://salsa.debian.org/apparmor-team/apparmor-profiles-extra/-/commit/eedb248ece01e65ce5572f5cc0b1a59c1bfc8f06

Hello intrigeri, I'm not comfortable with this approach.

apparmor-profiles-extra is just text files.

I don't know what merits or demerits pidgin-openpgp actually has, but if
an administrator installed it and hasn't purged it themselves when it was
removed from the repos, they may actually use it.

There's no compelling technical reason why both packages can't exist at
once on one system. A site admin could easily add necessary lines to
/etc/apparmor.d/local/usr.bin.pidgin to fix this without incurring
the wrath of dpkg's configuration file handling.

I'd rather this bug be closed wontfix with "since pidgin-openpgp was
removed from Debian we don't see a pressing need to fix the profiles" and
take no other action.

Thanks

signature.asc
Description: PGP signature

Bug#973327: [Pkg-fonts-devel] Bug#973327: fonts-noto-unhinted: Text in italic after upgrading the package

Quoting Nelson A. de Oliveira (2020-10-29 02:09:08)
> On Wed, Oct 28, 2020 at 9:43 PM Jonas Smedegaard  wrote:
> > To clarify, I don't doubt that your experience is real.  Reason I
> > suggested to restart between tests is that (as I understand it) caches
> > can play tricks like this: "please draw font object 217" might point to
> > a different object if the font gets replaced - with the resulting
> > experience that "new font renders differently" when in fact it is "new
> > font renders differently if some data tables from old font is still in
> > cache".
> 
> I just redid the tests to make sure:
> 
> Rebooted with the newest version installed, opened Chromium and got italic.
> Downgraded, rebooted, Chromium again, no issues.
> Upgraded, rebooted, Chromium and italic again.
> 
> Not every page is displayed in italic.
> 
> If there is anything else that I could testo/do to help just let me know.

No need for further testing - I agree the package is broken, and a new 
has been released.

Thanks,

 - Jonas

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

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

signature.asc
Description: signature

Bug#973327: [Pkg-fonts-devel] Bug#973327: fonts-noto-unhinted: Text in italic after upgrading the package

2020-10-28 Thread Nelson A. de Oliveira

On Wed, Oct 28, 2020 at 9:43 PM Jonas Smedegaard  wrote:
> To clarify, I don't doubt that your experience is real.  Reason I
> suggested to restart between tests is that (as I understand it) caches
> can play tricks like this: "please draw font object 217" might point to
> a different object if the font gets replaced - with the resulting
> experience that "new font renders differently" when in fact it is "new
> font renders differently if some data tables from old font is still in
> cache".

I just redid the tests to make sure:

Rebooted with the newest version installed, opened Chromium and got italic.
Downgraded, rebooted, Chromium again, no issues.
Upgraded, rebooted, Chromium and italic again.

Not every page is displayed in italic.

If there is anything else that I could testo/do to help just let me know.

Thanks!

Best regards,
Nelson

Bug#973327: [Pkg-fonts-devel] Bug#973327: fonts-noto-unhinted: Text in italic after upgrading the package

Quoting Nelson A. de Oliveira (2020-10-29 01:14:36)
> Hi!
> 
> On Wed, Oct 28, 2020 at 8:52 PM Jonas Smedegaard  wrote:
> > Please try (if you didn't already) to completely restart your system, to
> > ensure that cached data causing this issue.
> 
> I did this and the problem still persists.
> I can also reproduce it anytime.
> 
> See the 2 attached screenshots when opening
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes=fonts-noto
> 
> after-downgrade.png is what I have with the older version and
> after-upgrade.png is what is happening with the new version.
> I did the test with Chromium and Chrome since I don't use them (to
> avoid anything that I might have changed in Firefox); in the 3
> browsers I have the same behavior.
> 
> It's reproducible even without needing to close the browser; if I
> upgrade/downgrade, I just need to open a new tab to see the difference
> between the two versions.

Thanks for the added details.

To clarify, I don't doubt that your experience is real.  Reason I 
suggested to restart between tests is that (as I understand it) caches 
can play tricks like this: "please draw font object 217" might point to 
a different object if the font gets replaced - with the resulting 
experience that "new font renders differently" when in fact it is "new 
font renders differently if some data tables from old font is still in 
cache".

...but concretely there seems to be a real issue with these fonts: The 
fonts shipped in fonts-noto-unhinted has identical font names as other 
Noto fonts which won't fare well.

Thanks again for reporting,

 - Jonas

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

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

signature.asc
Description: signature

Bug#973332: linux-image-5.8.0-0.bpo.2-amd64: ath10k_pci module has errors and locks up the wifi card every so often

2020-10-28 Thread Robert LeBlanc

Package: src:linux
Version: 5.8.10-1~bpo10+1
Severity: normal

Dear Maintainer,

Every so often the machine will lose networking and things like VPN
don't respond that the connection has gone away and pings don't respond
or error. I was able to rmmod the ath10k_pci module and modprobe it and
the networking came back. I did not see this problem with 5.7 so I
suspect it is new to 5.8.

-- Package-specific info:
** Version:
Linux version 5.8.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc-8 
(Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 
5.8.10-1~bpo10+1 (2020-09-26)

** Command line:
BOOT_IMAGE=/vmlinuz-5.8.0-0.bpo.2-amd64 root=/dev/mapper/system-root ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[195688.937988] pcieport :06:04.0: BAR 14: no space for [mem size 
0x0020]
[195688.937989] pcieport :06:04.0: BAR 14: failed to assign [mem size 
0x0020]
[195688.937990] pcieport :06:01.0: BAR 13: no space for [io  size 0x1000]
[195688.937990] pcieport :06:01.0: BAR 13: failed to assign [io  size 
0x1000]
[195688.937991] pcieport :06:02.0: BAR 13: no space for [io  size 0x1000]
[195688.937992] pcieport :06:02.0: BAR 13: failed to assign [io  size 
0x1000]
[195688.937993] pcieport :06:04.0: BAR 13: no space for [io  size 0x1000]
[195688.937993] pcieport :06:04.0: BAR 13: failed to assign [io  size 
0x1000]
[195688.937995] pcieport :06:04.0: BAR 14: no space for [mem size 
0x0020]
[195688.937996] pcieport :06:04.0: BAR 14: failed to assign [mem size 
0x0020]
[195688.937996] pcieport :06:04.0: BAR 13: no space for [io  size 0x1000]
[195688.937997] pcieport :06:04.0: BAR 13: failed to assign [io  size 
0x1000]
[195688.937999] pcieport :06:02.0: BAR 15: no space for [mem size 
0x0020 64bit pref]
[195688.938000] pcieport :06:02.0: BAR 15: failed to assign [mem size 
0x0020 64bit pref]
[195688.938001] pcieport :06:02.0: BAR 13: no space for [io  size 0x1000]
[195688.938001] pcieport :06:02.0: BAR 13: failed to assign [io  size 
0x1000]
[195688.938002] pcieport :06:01.0: BAR 14: no space for [mem size 
0x0020]
[195688.938003] pcieport :06:01.0: BAR 14: failed to assign [mem size 
0x0020]
[195688.938005] pcieport :06:01.0: BAR 15: no space for [mem size 
0x0020 64bit pref]
[195688.938006] pcieport :06:01.0: BAR 15: failed to assign [mem size 
0x0020 64bit pref]
[195688.938006] pcieport :06:01.0: BAR 13: no space for [io  size 0x1000]
[195688.938007] pcieport :06:01.0: BAR 13: failed to assign [io  size 
0x1000]
[195688.962444] usb 1-3.3: USB disconnect, device number 9
[195688.962461] usb 1-3.3.1: USB disconnect, device number 11
[195689.035001] usb 1-3.5: USB disconnect, device number 10
[195693.675018] pcieport :06:00.0: can't change power state from D3cold to 
D0 (config space inaccessible)
[195693.675542] pci_bus :07: busn_res: [bus 07] is released
[195693.675699] pci :06:00.0: Removing from iommu group 13
[195693.675861] pci_bus :08: busn_res: [bus 08-3a] is released
[195693.675995] pci :06:01.0: Removing from iommu group 14
[195693.676103] pci_bus :3b: busn_res: [bus 3b] is released
[195693.676373] pci :06:02.0: Removing from iommu group 15
[195693.677976] pci_bus :3c: busn_res: [bus 3c-6f] is released
[195693.678158] pci :06:04.0: Removing from iommu group 16
[195693.678273] pci_bus :06: busn_res: [bus 06-6f] is released
[195693.680701] pci :05:00.0: Removing from iommu group 12
[195746.441383] usb 1-2: new full-speed USB device number 13 using xhci_hcd
[195746.591926] usb 1-2: New USB device found, idVendor=290b, idProduct=1700, 
bcdDevice= 2.00
[195746.591932] usb 1-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[195746.591935] usb 1-2: Product: BeatsX
[195746.591938] usb 1-2: Manufacturer: Beats Electronics
[195746.591940] usb 1-2: SerialNumber: FL6Z2JKBH18V
[195746.594904] hid-generic 0003:290B:1700.0006: hiddev0,hidraw0: USB HID v1.11 
Device [Beats Electronics BeatsX] on usb-:00:14.0-2/input0
[197976.248380] usb 1-1: new full-speed USB device number 14 using xhci_hcd
[197976.398909] usb 1-1: New USB device found, idVendor=056a, idProduct=0374, 
bcdDevice= 1.11
[197976.398911] usb 1-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[197976.398913] usb 1-1: Product: Intuos S
[197976.398914] usb 1-1: Manufacturer: Wacom Co.,Ltd.
[197976.398914] usb 1-1: SerialNumber: 0GE00R2004080
[197976.401993] hid-generic 0003:056A:0374.0007: hiddev1,hidraw1: USB HID v1.10 
Device [Wacom Co.,Ltd. Intuos S] on usb-:00:14.0-1/input0
[197976.473447] input: Wacom Intuos S Pen as 
/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/0003:056A:0374.0007/input/input29
[197976.473818] input: Wacom Intuos S Pad as 
/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/0003:056A:0374.0007/input/input31
[197976.474240] wacom 0003:056A:0374.0007: hidraw1: USB HID v1.10 Device [Wacom

Bug#972832: dialog: can't change menu border lines

2020-10-28 Thread Thomas Dickey

On Sun, Oct 25, 2020 at 10:44:46PM +0100, Ennio-Sr wrote:
> In reply to:
> > 
> > From: Thomas Dickey 
> > To: 972...@bugs.debian.org
> > Cc: 972832-submit...@bugs.debian.org
> > Subject: Re: Bug#972832: dialog: can't change menu border lines
> > Date: Sun, 25 Oct 2020 16:27:13 -0400
> > 
> > [Message part 1
> > 
> > (text/plain, inline)]
> > 
> > On Sat, Oct 24, 2020 at 06:17:39PM +0200, Ennio-Sr wrote:
> > > Package: dialog
> > > Version: 1.3-20160828-2
> > > Severity: minor
> > >
> > > Hi all!
> > >
> > > As I like to work on virtual console with black background, when I try to
> > > use dialog with my personalized colors (and a .dialogrc file) the 'upper
> > > left inner box'  and 'lower right external box' lines appear as black
> > > lines on white background, whereas the remaining lines come out on a black
> > > background as the whole dialog background.
> > > Deleting the .dialogrc file the corner lines are still in differnet
> > > colors, but on the same 'grey' background.
> > 
> > I'd start by seeing if this option helps:
> > 
> >--no-shadow
> >   Suppress  shadows that would be drawn to the right and bottom 
> > of
> >   each dialog box.
> > 
> > -- 
> > Thomas E. Dickey
> > https://invisible-island.netftp://ftp.invisible-island.net
> 
> Thanks for your reply! 
> Unluckily the --no-shadow option doesn't solve the problem as my
> foreground is black.
> But, if I delete the .dialogrc file the whole screen foreground is
> blue. In this case I can see that the --no-shadow eliminates the right
> end corner (black) shadow but not the problem described above.
> 
> Afaic understand, in the dialog structure the border lines are written
> as 'black on white fg' which does not go well on my black background.
> Perhaps I should modify some of the dialog sources files but I don't
> know how and which one to adjust...
> 
> Regards,
>   Ennio
> 
> PS: If necessary I could send a copy of the script I'm testing with an
> abridged .dialogrc. But where to send it? As an attachement or within a
> massage (with '<< EOF - EOF')?

attachments are good, because they can be saved without loss of detail.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#966087: New info

2020-10-28 Thread Emmanuel Oliveros




Hi, I have the same exact problem in Debian 10.6 Buster i386 with
LibreOffice from backports. I did some tests and was able to find the
possible source of the problem


1. I completely uninstall libreoffice (sudo apt purge libreoffice 
libreoffice-writer

libreoffice-common; sudo apt --purge autoremove).

2. I installed only libreoffice-writer from backports (sudo apt -t 
buster-backports

install libreoffice-writer), but had the same error.

3. Completely uninstall libreoffice-writer from backports and installed 
the version from

Debian buster instead (sudo apt purge libreoffice-writer; sudo apt
--purge autoremove; sudo apt install libreoffice-writer), this time I
did not have the error

4. Upgrade to backports version of libreoffice-writer over the current 
version from buster

(sudo apt -t buster-backports install libreoffice-writer), this time
I did not have the error!!

5. Uninstall packages that apt marked as not needed after the upgrade 
(sudo apt --purge

autoremove) and the error came back, the uninstalled packages were:
libmhash2* libmwaw-0.3-3* libnumbertext-1.0-0* libnumbertext-data*
liborcus-0.14-0* libraptor2-0* librasqal3* librdf0* libxmlsec1*
libxmlsec1-nss* libyajl2*

6. I manually installed the packages again and the error no longer 
occurs (sudo apt install

libmhash2 libmwaw-0.3-3 libnumbertext-1.0-0 libnumbertext-data
liborcus-0.14-0 libraptor2-0 librasqal3 librdf0 libxmlsec1
libxmlsec1-nss libyajl2).

So the source of the problem is the lack of one or more of the above 
packages, I don't

know which ones exactly. I hope this information helps to solve the
problem, sorry for my english but i don't speak it so i used a
translator.

libreoffice-writer backports version: 1:7.0.2-2~bpo10+1, buster version: 
1:6.1.5-3+deb10u6

Bug#973327: [Pkg-fonts-devel] Bug#973327: fonts-noto-unhinted: Text in italic after upgrading the package

Hi Nelson,

Quoting Nelson A. de Oliveira (2020-10-28 22:15:09)
> After upgrading fonts-noto-unhinted from 20200323-1 to 20201027-2 to, 
> some pages are now displayed all in italic in Firefox, Chromium and 
> Chrome.
> 
> Downgrading to 20200323-1 fixes this issue.
> 
> Is there anything that I can do to help in debugging this, please?

Thanks for reporting this issue.

Please try (if you didn't already) to completely restart your system, to 
ensure that cached data causing this issue.

Also, please provide concrete examples to allow others to verify.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#973331: omegat: please upgrade to use at least lucene 5.2.1

2020-10-28 Thread Markus Koschany

Package: omegat
Version: 3.6.0.10+dfsg-3
Severity: normal

Hi,

I intend to remove solr from Debian before we freeze for Debian 11.
It would be ideal if we could also remove liblucene3-java and
liblucene3-contrib-java which are both built by src:lucene-solr too.
Omegat is the only reverse-dependency.

lucene3 is quite old, so an update to at least 5.2.1 seems to be
preferable. This is the same version omegat 5.3.0 appears to be depend
on, the latest upstream release.

However they seem to use a modified version

https://sourceforge.net/p/omegat/bugs/813/

As long as omegat is the only r-dep it wouldn't be too bad.

I'm filing this bug report only as severity normal because we can just
keep the binary packages for lucene3 for the foreseeable future but it
would be nice to have a newer version of lucene and omegat anyway.
Note there is also lucene4 package in Debian but I don't think it is
suitable for omegat.

Markus

Bug#973322: Acknowledgement (thunderbird: caldav calendar missing some events and shows "!" with Assert failed: unexpected endBatch in error console)

2020-10-28 Thread Ryan Nowakowski

On Wed, Oct 28, 2020 at 02:46:52PM -0500, Ryan Nowakowski wrote:
> With the previous version of thunderbird(68.12.0), I did not see this
> issue.

I have the older version (68.12.0) still running on a different Debian
10 machine(along with lightning 68.12.0 since it used to be  a separate
package).  I don't have this issue on that machine with the same calendar.

Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.

2020-10-28 Thread Sebastian Andrzej Siewior

On 2020-10-27 07:22:22 [+], Michael Borgelt wrote:
> I have tried different permissions for the file and the directory without
> success. The obove permissions are after a clean reinstall off clamav
> package.

The problem appears to be the apparmor or freshclam's profile for it. So
disabling apparmor should make freshclam work again.
Probably adding
| capability dac_override,

to the profile will help, too. I will test it later today…

Sebastian

Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

2020-10-28 Thread Lucas Kanashiro

Thanks to David Rodriguez (our dear bundler upstream maintainer :) I was
able to workaround the bug locally and understand a bit better what is
going on.

The source of this problem is this commit:

https://github.com/rubygems/rubygems/commit/226ec115fe503bcc93bffdf5cd3e8a668890b4d8

Quoting David:

"Anyways, the actual check making bundler believe the ffi gem is missing
extensions is `File.exist?(gem_build_complete_path)`. I believe the idea
of this check is that bundler/rubygems are not able to know which
artifacts an extension will generate, so what rubygems does is
generating this dummy file at a well known path after a successful
extension compilation, so that it can later check the existence of this
path when it needs to know whether a gem is missing extensions."

There are 2 workarounds to fix this issue:

1) Create this dummy file.

$ mkdir -p
/usr/share/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/ffi-1.12.2/

$ touch
/usr/share/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/ffi-1.12.2/gem.build_complete

After that 'bundle --local' will find the ffi gem.

2) Remove the extension from gemspec.

$ sed -i.bak -e 3d
/usr/share/rubygems-integration/2.7.0/specifications/ffi-1.12.2.gemspec

After removing the header line containing "# stub:
ext/ffi_c/extconf.rb", 'bundler --local' also works fine and find the
ffi gem.

I think the second approach is what we want, and the proper fix would be
to not include extensions in our gemspecs. We could try to achieve that
via gem2deb. Any thoughts?

--
Lucas Kanashiro

Bug#845980: Poor Little Orphan Package

2020-10-28 Thread Barak A. Pearlmutter

Given the time span, I think Kyle Spiers' generous offer has probably
lapsed. (If not let me know and you can have it!) So in the interests
of efficiency, I'll just adopt it. Did a quick packaging of the latest
upstream, pushed to salsa, and will upload w/ self as maintainer in a
moment.

If someone else wants it, please feel free to co-maintain, or do 0-NMU
uploads without even asking, or whatever.

--Barak Pearlmutter.

Bug#973330: recoll: B-D on python3-all-dev but only builds for current python

2020-10-28 Thread Steve Langasek

Package: recoll
Version: 1.27.3-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi Kartik,

The recoll package has a build-dependency on python3-all-dev, but its
debian/rules only builds for the current python.  This causes issues for
tracking transitions, since packages build-depending on python3-all-dev are
expected to build for all supported python3 versions.

The package should either build-depend only on python3-dev, or it should
build for all supported python3 versions.  Attached is a patch that
implements the latter.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru recoll-1.27.3/debian/rules recoll-1.27.3/debian/rules
--- recoll-1.27.3/debian/rules  2020-06-30 05:25:09.0 -0700
+++ recoll-1.27.3/debian/rules  2020-10-28 14:17:52.0 -0700
@@ -25,15 +25,19 @@
 
 override_dh_auto_install:
dh_auto_install
-   cd python/recoll; libdir=/usr/lib/$${DEB_BUILD_MULTIARCH} python3 \
+   cd python/recoll; for python in $$(py3versions -s); do \
+   libdir=/usr/lib/$${DEB_BUILD_MULTIARCH} $$python \
./setup.py install \
--install-layout=deb \
--prefix=/usr \
-   --root=$(CURDIR)/debian/tmp/
-   cd python/pychm; python3 ./setup.py install \
+   --root=$(CURDIR)/debian/tmp/; \
+   done
+   cd python/pychm; for python in $$(py3versions -s); do \
+   $$python ./setup.py install \
--install-layout=deb \
--prefix=/usr \
-   --root=$(CURDIR)/debian/tmp/
+   --root=$(CURDIR)/debian/tmp/; \
+   done
# Remove python2 filter
rm -f $(CURDIR)/debian/tmp/usr/share/recoll/filters/hotrecoll.py
# Cleanup

Bug#973329: Use system libimgui-dev

2020-10-28 Thread Yangfl

Source: dart
Severity: wishlist

Hi,

As libimgui-dev is now available, please consider using system library.

Also, it may be desirable to remove libdart6-external-imgui since
providing duplicate packages may cause confusion.

Bug#964845: Any Update

2020-10-28 Thread Ben Hutchings

Control: tag -1 moreinfo

On Wed, 2020-10-28 at 12:29 -0700, Wanli Li wrote:
> Hi, just wanted to know whether there's any update on this feature request?

Why would this be needed in a cloud deployment?  Hypervisors should be
able to suspend and resume guests without specific support in the guest
kernel.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?




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

Bug#973328: fonts-noto-unhinted: Enhances declared on obsolete package

2020-10-28 Thread Nelson A. de Oliveira

Package: fonts-noto-unhinted
Version: 20201027-2
Severity: minor

Hi!

fonts-noto-unhinted is declaring an Enhances on fonts-noto-hinted, but
fonts-noto-hinted description says:

=
Description-en: obsolete metapackage to pull in a subset of Noto fonts
 This is an obsolete metapackage
 to install a subset of Noto fonts.
 .
 NB! This package is obsolete.
 Please use appropriate other fonts-noto-* packages instead.
=

The Enhances should probably be updated to the proper package (fonts-noto-core
and/or fonts-noto-ui-core)

Thank you!

Best regards,
Nelson

-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  fontconfig 2.13.1-4.2amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.10.2+dfsg-4 amd64FreeType 2 font engine, 
shared library files
ii  libxft2:amd64  2.3.2-2   amd64FreeType-based font drawing 
library for X

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#973327: fonts-noto-unhinted: Text in italic after upgrading the package

2020-10-28 Thread Nelson A. de Oliveira

Package: fonts-noto-unhinted
Version: 20201027-2
Severity: important

Hi!

After upgrading fonts-noto-unhinted from 20200323-1 to 20201027-2 to,
some pages are now displayed all in italic in Firefox, Chromium and
Chrome.

Downgrading to 20200323-1 fixes this issue.

Is there anything that I can do to help in debugging this, please?

Thank you!

Best regards,
Nelson

-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  fontconfig 2.13.1-4.2amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.10.2+dfsg-4 amd64FreeType 2 font engine, 
shared library files
ii  libxft2:amd64  2.3.2-2   amd64FreeType-based font drawing 
library for X

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#973042: thunderbird: Thunderbird doesn't recognize GPG key if the address is not the primary identity on the key

2020-10-28 Thread Mark Caglienzi

On Tue, 27 Oct 2020 17:55:53 +0100 Carsten Schoenert 
 wrote:

Hello Mark,

Hello Carsten,
thank you for the quick reply!

Am 27.10.20 um 15:15 schrieb Mark Caglienzi:
...
> How can I make Thunderbird use my GPG key in both cases as it was before (when
> using enigmail)?

this is mainly a question Mozilla or the user community around
Thunderbird might able to answer.

It's also quite possible that the GPG integration in Thunderbird is
still lacking some needed functionality.

[...]

I recommend your report your problem to the Bugzilla issue tracker from
Mozilla and link back the created issue so we can follow it.

I registered on bugzilla.mozilla.org (I did not have an account there) 
and submitted the bug report, as you suggested.

The bug report is here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1673993

Thank you again!

PS: Do I have to do something else? If so, please tell me and I'll try to.

[...]

--
Regards
Carsten

Regards,
Mark

OpenPGP_0xE293A2EBCD542422.asc
Description: application/pgp-keys

OpenPGP_signature
Description: OpenPGP digital signature

Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.syst

2020-10-28 Thread Bernd Rinn


Hi Andreas,

I can confirm that this bug is in commons-io 2.8.0 while commons-io 2.6 
workes fine.


The bug is in PathUtils.deleteFile(), line 360 and 361:
"""
final boolean exists = Files.exists(file, 
LinkOption.NOFOLLOW_LINKS);

final long size = exists ? Files.size(file) : 0;
"""
It determines "exists" based on not following the symlink by using 
LinkOption.NOFOLLOW_LINKS, but then in the next line uses 
Files.size(file) to determine the size which *does* follow the symlink. 
Kaboom. This will prevent PathUtils.deleteFile() to delete any dangling 
symlink (which it has to in my test case).


I have attached a patch for commons-io 2.8.0 which fixes this bug.

Cheers,
Bernd

On 10/28/20 8:29 PM, Andreas Tille wrote:

Control: forwarded -1 Bernd Rinn 

Hi,

I'd recommend reading the bug report log from here to get some hints
about recommended changes in the code:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973070#17

For the moment I've excluded the affected tests.

Kind regards

   Andreas.



- Forwarded message from Markus Koschany  -

Date: Wed, 28 Oct 2020 19:34:35 +0100
From: Markus Koschany 
To: Debian Java List 
Cc: 973...@bugs.debian.org
Subject: Bug#973070: Bug#973070: Help needed: Bug#973070: libsis-base-java: 
FTBFS: Could not delete the directory
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 
exceptions: [java.io.IOException: Unable to delete file:

targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink]
X-Debian-PR-Message: followup 973070
X-Debian-PR-Package: src:libsis-base-java
X-Debian-PR-Keywords: bullseye ftbfs help sid
X-Debian-PR-Source: libsis-base-java



Am 28.10.20 um 16:01 schrieb olivier sallou:
[...]

*dumb* patch would be to simply remove those tests from code...


Either this or you can keep the override for dh_auto_test-arch empty.

The test creates a broken symlink but then FileUtils.deleteDirectory
fails to delete the file, obviously because it is not a directory but
I'm not sure how it really handles symlinks within directories. See also
[1]. Probably upstream should switch to the java.nio.file API (they
still use java.io.File), test for the existence of symlinks and then try
File.delete instead of FileUtils.deleteDirectory first. Not tested, just
a guess.

Markus


[1] https://issues.apache.org/jira/browse/IO-576





___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


- End forwarded message -
--- org/apache/commons/io/file/PathUtils.java.orig	2020-01-22 15:10:16.0 +0100
+++ org/apache/commons/io/file/PathUtils.java	2020-10-28 21:32:24.874024999 +0100
@@ -358,7 +358,8 @@
 }
 final PathCounters pathCounts = Counters.longPathCounters();
 final boolean exists = Files.exists(file, LinkOption.NOFOLLOW_LINKS);
-final long size = exists ? Files.size(file) : 0;
+final boolean existsFollowLink = Files.exists(file);
+final long size = existsFollowLink ? Files.size(file) : 0;
 if (overrideReadOnly(options) && exists) {
 setReadOnly(file, false, LinkOption.NOFOLLOW_LINKS);
 }


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#973325: apt starts installing packages before it has ordered them

2020-10-28 Thread Johannes 'josch' Schauer

Package: apt
Version: 2.1.11
Severity: important

Hi,

as agreed on IRC here my bugreport. I noticed this when running
mmdebstrap in chrootless mode:

$ ./mmdebstrap --mode=chrootless --variant=custom 
--include=bsdutils,coreutils,debianutils,diffutils,dpkg,findutils,grep,gzip,hostname,init-system-helpers,ncurses-base,ncurses-bin,perl-base,sed,tar
 unstable /dev/null
[...]
Reading package lists...
Building dependency tree...
Suggested packages:
  debconf-doc debconf-utils whiptail | dialog libterm-readline-gnu-perl
  libgtk3-perl libnet-ldap-perl perl debconf-kde-helper diffutils-doc wdiff
  apt debsig-verify mlocate | locate less glibc-doc libc-l10n locales
  rng-tools krb5-doc krb5-user sensible-utils bzip2 ncompress xz-utils
  tar-scripts tar-doc
Recommended packages:
  bsdextrautils apt-utils debconf-i18n libidn2-0 libgpg-error-l10n
  krb5-locales
The following NEW packages will be installed:
  bsdutils coreutils debconf debianutils diffutils dpkg findutils 
gcc-10-base
  grep gzip hostname init-system-helpers libacl1 libattr1 libbz2-1.0 libc6
  libcom-err2 libcrypt1 libgcc-s1 libgcrypt20 libgmp10 libgpg-error0
  libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0
  liblz4-1 liblzma5 libnsl2 libnss-nis libnss-nisplus libpcre2-8-0 libpcre3
  libselinux1 libssl1.1 libsystemd0 libtinfo6 libtirpc-common libtirpc3
  libzstd1 ncurses-base ncurses-bin perl-base sed tar zlib1g
0 upgraded, 47 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/19.2 MB of archives.
After this operation, 74.5 MB of additional disk space will be used.
Selecting previously unselected package gcc-10-base:amd64.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../gcc-10-base_10.2.0-15_amd64.deb ...
Unpacking gcc-10-base:amd64 (10.2.0-15) ...
Setting up gcc-10-base:amd64 (10.2.0-15) ...
Selecting previously unselected package libcrypt1:amd64.
(Reading database ... 9 files and directories currently installed.)
Preparing to unpack .../libcrypt1_1%3a4.4.17-1_amd64.deb ...
Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
Selecting previously unselected package libc6:amd64.
Preparing to unpack .../libc6_2.31-4_amd64.deb ...
Unpacking libc6:amd64 (2.31-4) ...
Selecting previously unselected package libgcc-s1:amd64.
Preparing to unpack .../libgcc-s1_10.2.0-15_amd64.deb ...
Unpacking libgcc-s1:amd64 (10.2.0-15) ...
Selecting previously unselected package libnss-nis:amd64.
Preparing to unpack .../libnss-nis_3.1-4_amd64.deb ...
Unpacking libnss-nis:amd64 (3.1-4) ...
Selecting previously unselected package libnsl2:amd64.
Preparing to unpack .../libnsl2_1.3.0-2_amd64.deb ...
Unpacking libnsl2:amd64 (1.3.0-2) ...
Selecting previously unselected package libtirpc3:amd64.
Preparing to unpack .../libtirpc3_1.2.6-3_amd64.deb ...
Unpacking libtirpc3:amd64 (1.2.6-3) ...
Selecting previously unselected package libgssapi-krb5-2:amd64.
Preparing to unpack .../libgssapi-krb5-2_1.17-10_amd64.deb ...
Unpacking libgssapi-krb5-2:amd64 (1.17-10) ...
Selecting previously unselected package libcom-err2:amd64.
Preparing to unpack .../libcom-err2_1.45.6-1_amd64.deb ...
Unpacking libcom-err2:amd64 (1.45.6-1) ...
Selecting previously unselected package libk5crypto3:amd64.
Preparing to unpack .../libk5crypto3_1.17-10_amd64.deb ...
Unpacking libk5crypto3:amd64 (1.17-10) ...
Selecting previously unselected package libkrb5support0:amd64.
Preparing to unpack .../libkrb5support0_1.17-10_amd64.deb ...
Unpacking libkrb5support0:amd64 (1.17-10) ...
Selecting previously unselected package libkrb5-3:amd64.
Preparing to unpack .../libkrb5-3_1.17-10_amd64.deb ...
Unpacking libkrb5-3:amd64 (1.17-10) ...
Selecting previously unselected package libkeyutils1:amd64.
Preparing to unpack .../libkeyutils1_1.6.1-2_amd64.deb ...
Unpacking libkeyutils1:amd64 (1.6.1-2) ...
Selecting previously unselected package libssl1.1:amd64.
Preparing to unpack .../libssl1.1_1.1.1h-1_amd64.deb ...
Unpacking libssl1.1:amd64 (1.1.1h-1) ...
Selecting previously unselected package libtirpc-common.
Preparing to unpack .../libtirpc-common_1.2.6-3_all.deb ...
Unpacking libtirpc-common (1.2.6-3) ...
Setting up libtirpc-common (1.2.6-3) ...
Selecting previously unselected package libnss-nisplus:amd64.
(Reading database ... 411 files and directories currently installed.)
Preparing to unpack .../libnss-nisplus_1.3-4_amd64.deb ...
Unpacking libnss-nisplus:amd64 (1.3-4) ...
dpkg: dependency problems prevent configuration of libcom-err2:amd64:
 libcom-err2:amd64 depends on libc6 (>= 2.17); however:
  Package libc6:amd64 is not configured yet.

dpkg: error processing package libcom-err2:amd64 (--configure):
 dependency problems -

Bug#973326: double-conversion: Misbuild with -O3: DoubleToStringConverter::DoubleToStringConverter() constructor dropped from exported symbols

2020-10-28 Thread Steve Langasek

Package: double-conversion
Version: 3.1.5-6
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi Mo,

Thanks for your forebearance with this string of Ubuntu bug reports.  I'm
hopeful that once we manage to resolve this one, the double-conversion
package will be in sync again between Debian and Ubuntu :)

The latest upload of double-conversion is failing to build from source on
ppc64el in Ubuntu, because Ubuntu builds ppc64el with -O3 by default instead
of -O2, and this additional optimization level somehow causes a public
constructor to be lost from the exported symbols:

[...]
dpkg-gensymbols: warning: debian/libdouble-conversion3/DEBIAN/symbols doesn't ma
tch completely debian/libdouble-conversion3.symbols
--- debian/libdouble-conversion3.symbols (libdouble-conversion3_3.1.5-6_ppc64el)
+++ dpkg-gensymbolshNCmYB   2020-10-28 15:27:33.543945019 +
@@ -36,7 +36,7 @@
  (c++)"double_conversion::DoubleToStringConverter::CreateDecimalRepresentation(
char const*, int, int, int, double_conversion::StringBuilder*) const@Base" 2.0.0
  (c++)"double_conversion::DoubleToStringConverter::CreateExponentialRepresentat
ion(char const*, int, int, double_conversion::StringBuilder*) const@Base" 2.0.0
  (c++)"double_conversion::DoubleToStringConverter::DoubleToAscii(double, double
_conversion::DoubleToStringConverter::DtoaMode, int, char*, int, bool*, int*, in
t*)@Base" 2.0.0
- (c++)"double_conversion::DoubleToStringConverter::DoubleToStringConverter(int,
 char const*, char const*, char, int, int, int, int)@Base" 3.1.5
+#MISSING: 3.1.5-6# (c++)"double_conversion::DoubleToStringConverter::DoubleToSt
ringConverter(int, char const*, char const*, char, int, int, int, int)@Base" 3.1
.5
  (c++)"double_conversion::DoubleToStringConverter::EcmaScriptConverter()@Base" 
2.0.0
  (c++)"double_conversion::DoubleToStringConverter::HandleSpecialValues(double, 
double_conversion::StringBuilder*) const@Base" 2.0.0
  (c++)"double_conversion::DoubleToStringConverter::ToExponential(double, int, d
ouble_conversion::StringBuilder*) const@Base" 2.0.0
dh_makeshlibs: error: failing due to earlier errors
[...]

  
(https://launchpad.net/ubuntu/+source/double-conversion/3.1.5-6/+build/20200598)

This problem is also reproducible on amd64 if I raise the optimization level.

This may well be a problem with the toolchain, but for the moment I've
worked around this by forcing the optimization level down to -O2 as in the
attached patch.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru double-conversion-3.1.5/debian/rules 
double-conversion-3.1.5/debian/rules
--- double-conversion-3.1.5/debian/rules2020-01-10 22:27:54.0 
-0800
+++ double-conversion-3.1.5/debian/rules2020-10-28 13:38:12.0 
-0700
@@ -2,6 +2,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+export DEB_CXXFLAGS_MAINT_APPEND += -O2
+export DEB_CXXFLAGS_MAINT_STRIP += -O3
 
 # Get compilation flags from dpkg-buildflags
 DPKG_EXPORT_BUILDFLAGS = 1

Bug#973324: qemu: CVE-2020-27617: assert failure in eth_get_gso_type

2020-10-28 Thread Salvatore Bonaccorso

Source: qemu
Version: 1:5.1+dfsg-4
Severity: important
Tags: security upstream
Forwarded: 
https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg06023.html
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2020-27617[0]:
| net: an assert failure via eth_get_gso_type

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-27617
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27617
[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg06023.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#957132: dibbler: diff for NMU version 1.0.1-1.1

2020-10-28 Thread Sudip Mukherjee

Control: tags 957132 + patch
Control: tags 957132 + pending
--

Dear maintainer,

I've prepared an NMU for dibbler (versioned as 1.0.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru dibbler-1.0.1/debian/changelog dibbler-1.0.1/debian/changelog
--- dibbler-1.0.1/debian/changelog  2015-12-10 14:02:03.0 +
+++ dibbler-1.0.1/debian/changelog  2020-10-28 20:30:23.0 +
@@ -1,3 +1,11 @@
+dibbler (1.0.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957132)
+- Thanks to Tomek Mrugalski.
+
+ -- Sudip Mukherjee   Wed, 28 Oct 2020 20:30:23 
+
+
 dibbler (1.0.1-1) unstable; urgency=low
 
   * The Akamai Technologies paid volunteer days release.
diff -Nru 
dibbler-1.0.1/debian/patches/0001-Fixed-compatibility-with-gcc-10.patch 
dibbler-1.0.1/debian/patches/0001-Fixed-compatibility-with-gcc-10.patch
--- dibbler-1.0.1/debian/patches/0001-Fixed-compatibility-with-gcc-10.patch 
1970-01-01 01:00:00.0 +0100
+++ dibbler-1.0.1/debian/patches/0001-Fixed-compatibility-with-gcc-10.patch 
2020-10-28 20:29:15.0 +
@@ -0,0 +1,46 @@
+From 6f15782cb7d559f1d7e66351a0216048693c9aac Mon Sep 17 00:00:00 2001
+From: Tomek Mrugalski 
+Date: Thu, 23 Jul 2020 23:41:25 +0200
+Subject: [PATCH] Fixed compatibility with gcc-10
+
+---
+
+upstream link: 
https://github.com/tomaszmrugalski/dibbler/commit/6f15782cb7d559f1d7e66351a0216048693c9aac
+
+ Port-linux/interface.c | 4 
+ Port-linux/interface.h | 4 ++--
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/Port-linux/interface.c b/Port-linux/interface.c
+index 3e239d3a..18777e91 100644
+--- a/Port-linux/interface.c
 b/Port-linux/interface.c
+@@ -43,6 +43,10 @@
+ #include 
+ #include 
+ 
++int interface_auto_up = 0;
++int interface_do_message = 0;
++
++
+ void daemon_log(int loglevel, const char *fmt,...)
+ {
+ char buf[255];
+diff --git a/Port-linux/interface.h b/Port-linux/interface.h
+index e986eed3..7c4a54d5 100644
+--- a/Port-linux/interface.h
 b/Port-linux/interface.h
+@@ -23,8 +23,8 @@
+ extern "C" {
+ #endif
+ 
+-int interface_auto_up;
+-int interface_do_message;
++extern int interface_auto_up;
++extern int interface_do_message;
+ 
+ typedef enum { IFSTATUS_UP, IFSTATUS_DOWN, IFSTATUS_ERR } interface_status_t;
+ 
+-- 
+2.20.1
+
diff -Nru dibbler-1.0.1/debian/patches/series 
dibbler-1.0.1/debian/patches/series
--- dibbler-1.0.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ dibbler-1.0.1/debian/patches/series 2020-10-28 20:27:27.0 +
@@ -0,0 +1 @@
+0001-Fixed-compatibility-with-gcc-10.patch

Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))

2020-10-28 Thread Robert Edmonds

Daniel Kahn Gillmor wrote:
> Hi Robert--
> 
> thanks for the followup!
> 
> On Wed 2020-10-28 02:56:55 -0400, Robert Edmonds wrote:
> > I've never been able to reproduce this bug, but your branch looks good
> > to me as far as backporting this commit to 1.9.0. It's commit
> > 225534e5ab22d16ab32fa1011733f3c69c7b28ba in the upstream repo which was
> > released in 1.9.1. I don't have any objection if you want to propose a
> > stable update for unbound with just this fix. Personally I've been
> > keeping unbound in buster-backports up to date with testing lately and I
> > don't have any buster machines running the version of unbound in buster
> > :-)
> 
> Over on https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227
> upstream suggested two different things:
> 
>  - upgrade to 1.9.2, (which incorporates this and several other bugfixes), or
> 
>  - cherry-pick a list of other commits which they think are also
>relevant to this specific fix:
> 
> 348cbab016f824a336b65d0091310fe5cd58e762
> 2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f
> 
>and four more, related to spoolbuf:
>
> 0b77c9d6763686264d44dfd926c8cb4f2f03a43a
> 6067ce6d2b82ce2e80055e578fdfd7ba3e67c523
> af6c5dea43fc63452d49b2339e607365b6652987
> a08fe8ca609b651c8d8c8379780aad508d492421

OK, I made a patch incorporating those fixes recommended by upstream and
sent them to #962459. Looks like that doesn't work at all.

> I'm assuming that the release team would prefer that we go the latter
> route (cherry-picked patches), but i haven't tried to get a direct
> verdict from them on that.

If I recall correctly, back when lenny was oldstable, a major upstream
update (1.0.2 → 1.4.6) was allowed in order to correct a security
problem that was infeasible to backport. I don't think we could justify
pushing the latest upstream version into stable, but I'm not sure
picking a random 1.9.x release is the right thing either.

Upstream recommends that users run their latest release because every
new release contains bug fixes and improvements, of course. So I'm fine
with uploading each new upstream release to unstable and then (five days
later) to buster-backports, for users that want to run the latest
upstream release on buster. I don't think there's a particularly strong
justification for Unbound users to run whatever random version was
current ~6 months before a Debian stable release other than, well,
that's what Debian stable shipped with.

> I confess i don't really understand the way that unbound's buster
> packaging is working -- i think it's neither git-dpm nor gbp -- so i
> don't exactly know how i'd assemble an update for the next buster point
> release without overhauling it.  (i'd be fine with overhauling it to use
> gbp (as i think the unstable version of the packaging is) as long as
> you're ok with that, but i also don't know whether that would make the
> changes more unpleasant for the release team.
> 
> Any suggestions?

Overhauling the packaging in the buster branch would probably make
things unpleasant for stable reviewers, so I would not recommend doing
that.

The way the packaging works in buster is that patches to the code are
directly applied to the git repository and the "single-debian-patch"
option is used. Like, if you want to make a change, you just make the
change, and the changes are stored in git, instead of using git to store
patch files that contain the changes. Apparently this is bad because
there is tooling that interacts very poorly with this style of packaging
(I think it's gbp-import-orig's '--merge-mode=replace' which
intentionally destroys all the changes outside the debian/ directory). I
think that was the root cause of #923314.

-- 
Robert Edmonds
edmo...@debian.org

Bug#973265: Acknowledgement (pulseaudio: linux-image-4.19.0-12-amd64: load-module initialization failed)

2020-10-28 Thread Allan Wind


http://sprunge.us/MZ0QsN

I ran fuser -a on /dev/snd/* after stopping pulseaudio,
so it appears something in the configuration is now conflicting.  
default.pa worked fine for over a year.


Reverted to using custom profile to select between headphone and 
speaker (hoping the issue with mono audio has been resolved since 
I tried last time).



/Allan
--
Allan Wind
Yaxto - Runs Your Business

Bug#973323: u-boot-rockchip: hangs consistently at "Booting using the fdt blob at 0x01f00000"

2020-10-28 Thread H. Muller

Package: u-boot-rockchip
Version: 2020.10+dfsg-1
Severity: important
Tags: upstream
X-Debbugs-Cc: hxmul...@gmail.com

Dear Vagrant Cascadian,

This report is specific to the RockPro64 but the Pinebook Pro is also
affected as its _defconfig is similar. This report is generated
on a Raspberry PI 3 model B v1.2 so take the automatically included
System Information below with a grain of salt.

When booting u-boot v2020.10 using the default configuration for the
RockPro64 (rockpro64-rk3399_defconfig) it is expected that it boot 
successfully everytime.

But what happens whether u-boot is installed to micro SD card or SPI
NOR flash, is that most of the time it will fail to boot and hang
at "Booting using the fdt blob at 0x01f0". If you press and hold
the power button down until the board is powered down and restart it,
and repeat, it will eventually boot the kernel and the system.

It am unsure where the actual problem lies although I strongly
suspect that the SPI configuration for the rk3399 u-boot port is the
culprit. I am too new to the u-boot code base, device tree, etc., to
be sure.

A workaround that satisfactorily allows the board to boot _everytime_
is to change environment storage location from SPI to FAT. After
running `make rockpro64-rk3399_defconfig` I ran `make menuconfig`
and made the following changes:

[ ] Enable overwriting environment
[ ] Environment is not stored
[ ] Environment in EEPROM
[*] Environment is in a FAT filesystem
[ ] Environment is in a EXT4 filesystem
[ ] Environment in flash memory
[ ] Environment in an MMC device
[ ] Environment in a NAND device
[ ] Environment in a non-volatile RAM
[ ] Environment is in OneNAND
[ ] Environment is in remote memory space
[ ] Environment is in SPI flash
(mmc) Name of the block device for the environment
(1:1) Device and partition for where to store the environemt in FAT
(uboot.env) Name of the FAT file to use for the environment
(0x8000) Environment Size
[*] Relocate gd->env_addr
(1) mmc device number
(1) mmc partition number
[ ] Create default environment from file
[ ] Add run-time information to the environment
[ ] Always append the environment with new data
[ ] Permit write access only to listed variables
[ ] Block forced environment operations
[ ] Add a 'ver' environment variable with the U-Boot version

Note that the above is specific to storing the environment on a
micro SD card. The device and partition information would necessarily
have to be modified to use eMMC.

The workaround is a good temporary solution until the real problem
can be corrected, but it would be nice to store the environment in SPI
if one wished to. I am able to boot reliably whether u-boot is
installed to SPI or micro SD card using this workaround.

I have not tested this on my Pinebook Pro yet, but I suspect it will
resolve the issues I have been having with it also (stock u-boot 
v2020.10).

Best,

H

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

Kernel: Linux 5.8.0-2-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
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

u-boot-rockchip depends on no packages.

Versions of packages u-boot-rockchip recommends:
ii  arm-trusted-firmware  2.3+dfsg-3
ii  python3   3.8.2-3
ii  u-boot-tools  2020.10+dfsg-1

u-boot-rockchip suggests no packages.

-- no debconf information

Bug#973322: thunderbird: caldav calendar missing some events and shows "!" with Assert failed: unexpected endBatch in error console

2020-10-28 Thread Ryan Nowakowski

Package: thunderbird
Version: 1:78.4.0-1~deb10u1
Severity: serious
Justification: 4

Dear Maintainer,

After upgrading to this release one of my caldav calendars(served from
davmail), some calendar events are missing.  Thunderbird consistently
shows an "!" next to it in the sidebar.  After resetarting thunderbird,
the "!" shows up after a few minutes and never goes away.


The following appears in the thunderbird "Error Console":

Assert failed: unexpected endBatch!
 calUtils.jsm:140
ASSERT resource:///modules/calendar/calUtils.jsm:140
endBatch resource:///modules/calendar/utils/calProviderUtils.jsm:534
onStopRequest resource:///modules/caldav/CalDavRequestHandlers.jsm:824
get listener/get/< resource:///modules/caldav/CalDavRequest.jsm:554
get listener/get/< resource:///modules/caldav/CalDavRequest.jsm:554
get listener/get/< resource:///modules/caldav/CalDavRequest.jsm:554


Perhaps it's correlated with the missing calendar events?

With the previous version of thunderbird(68.12.0), I did not see this
issue.

To try to resolve the issue, I've:
1. Started over with a clean config, only added the one caldav calendar
2. Deleted the cache.sqlite file
3. Restarted thunderbird

Thanks!

Ryan N

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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.8.6.1
ii  fontconfig  2.13.1-2
ii  libatk1.0-0 2.30.0-2
ii  libbotan-2-92.9.0-2
ii  libbz2-1.0  1.0.6-9.2~deb10u1
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-0+deb10u1
ii  libdbus-glib-1-20.110-4
ii  libevent-2.1-6  2.1.8-stable-4
ii  libffi6 3.2.1-9
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libjson-c3  0.12.1+ds-2+deb10u1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u1
ii  libx11-xcb1 2:1.6.7-1+deb10u1
ii  libxcb-shm0 1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.2-1
ii  x11-utils   7.7+4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-3
ii  libgtk2.0-0   2.24.32-3

-- no debconf information

Bug#962459: unbound: constantly crashing after about 3 minutes since start

2020-10-28 Thread Kebert Martin

Applied '0001-Apply-a-series-of-fixes-for-Unbound-1.9.0-suggested-.patch'

Result:
Oct 28 20:24:28 debian systemd[1]: Starting Unbound DNS server...
Oct 28 20:24:28 debian package-helper[464]: /var/lib/unbound/root.key has 
content
Oct 28 20:24:28 debian package-helper[464]: fail: the anchor is NOT ok and 
could not be fixed
Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 0: subnet
Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 1: validator
Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 2: iterator
Oct 28 20:24:28 debian systemd[1]: Started Unbound DNS server.
Oct 28 20:24:28 debian unbound[468]: [468:0] info: start of service (unbound 
1.9.0).
...
Oct 28 20:31:31 debian kernel: unbound[470]: segfault at 1b0 ip 
7fdb28876e48 sp 7fdb26fd6cf0 error 4 in 
libevent-2.1.so.6.0.2[7fdb28857000+54000]
Oct 28 20:31:31 debian kernel: Code: 00 00 41 55 41 54 41 89 d5 55 53 41 89 f4 
48 89 fb 48 83 ec 08 48 8b 05 76 51 23 00 8b 10 85 d2 0f 85 8c 00 00 00 48 8b 
6b 40 <48> 8b bd b0 01 00 00 48 85 ff 74 11 48 8b 05 2d 51 23 00 8b 00 85
Oct 28 20:31:31 debian systemd[1]: unbound.service: Main process exited, 
code=killed, status=11/SEGV
Oct 28 20:31:31 debian systemd[1]: unbound.service: Failed with result 'signal'.
Oct 28 20:31:31 debian systemd[1]: unbound.service: Service RestartSec=100ms 
expired, scheduling restart.
Oct 28 20:31:31 debian systemd[1]: unbound.service: Scheduled restart job, 
restart counter is at 1.
Oct 28 20:31:31 debian systemd[1]: Stopped Unbound DNS server.
Oct 28 20:31:31 debian systemd[1]: Starting Unbound DNS server...
Oct 28 20:31:31 debian package-helper[1994]: /var/lib/unbound/root.key has 
content
Oct 28 20:31:31 debian package-helper[1994]: success: the anchor is ok
Oct 28 20:31:31 debian unbound[1998]: [1998:0] notice: init module 0: subnet
Oct 28 20:31:31 debian unbound[1998]: [1998:0] notice: init module 1: validator
Oct 28 20:31:31 debian unbound[1998]: [1998:0] notice: init module 2: iterator
Oct 28 20:31:31 debian systemd[1]: Started Unbound DNS server.
Oct 28 20:31:31 debian unbound[1998]: [1998:0] info: start of service (unbound 
1.9.0).
...
Oct 28 20:32:41 debian kernel: unbound[2001]: segfault at 7fbb0009 ip 
560e7af6bfb0 sp 7fbb29274480 error 4 in unbound[560e7af52000+c6000]
Oct 28 20:32:41 debian kernel: Code: 24 20 0f b7 80 86 00 00 00 66 89 02 41 0f 
b6 76 20 49 8b 1e 83 e6 02 49 8b 47 28 48 8d 53 02 48 8d 0c ed 00 00 00 00 49 
89 16 <48> 8b 04 e8 48 3b 44 24 08 0f 8d 21 05 00 00 40 84 f6 0f 85 48 04
Oct 28 20:32:41 debian systemd[1]: unbound.service: Main process exited, 
code=killed, status=11/SEGV
Oct 28 20:32:41 debian systemd[1]: unbound.service: Failed with result 'signal'.
Oct 28 20:32:41 debian systemd[1]: unbound.service: Service RestartSec=100ms 
expired, scheduling restart.
Oct 28 20:32:41 debian systemd[1]: unbound.service: Scheduled restart job, 
restart counter is at 2.
Oct 28 20:32:41 debian systemd[1]: Stopped Unbound DNS server.
Oct 28 20:32:41 debian systemd[1]: Starting Unbound DNS server...
Oct 28 20:32:41 debian package-helper[2199]: /var/lib/unbound/root.key has 
content
Oct 28 20:32:41 debian package-helper[2199]: success: the anchor is ok
Oct 28 20:32:41 debian unbound[2203]: [2203:0] notice: init module 0: subnet
Oct 28 20:32:41 debian unbound[2203]: [2203:0] notice: init module 1: validator
Oct 28 20:32:41 debian unbound[2203]: [2203:0] notice: init module 2: iterator
Oct 28 20:32:41 debian systemd[1]: Started Unbound DNS server.
Oct 28 20:32:41 debian unbound[2203]: [2203:0] info: start of service (unbound 
1.9.0).



S pozdravem
Martin Kebert



Informace obsa?en? v t?to e-mailov? zpr?v? a v?ech p?ilo?en?ch souborech jsou 
d?v?rn? a jsou ur?eny pouze pro pot?ebu adres?ta. Pros?me, abyste v p??pad?, ?e 
tento e-mail obdr??te omylem, neprodlen? upozornili odes?latele a tento e-mail 
odstranili z Va?eho syst?mu. Pokud nejste zam??len?m p??jemcem, berte pros?m na 
v?dom?, ?e zve?ejn?n?, kop?rov?n?, ???en? ?i p?ijet? jak?hokoliv opat?en? v 
souvislosti s obsahem t?to zpr?vy je zak?z?no a m??e b?t protipr?vn?.

_

The information contained in this e-mail message and all attached files is 
confidential and is intended solely for the use of the individual or entity to 
whom they are addressed. Please notify the sender immediately if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is prohibited and may be unlawful.

Bug#973321: ITP: nemo-pastebin -- Nemo extension to send files to a pastebin

2020-10-28 Thread Joshua Peisach

Package: wnpp
Severity: wishlist
Owner: Joshua Peisach 
X-Debbugs-Cc: debian-de...@lists.debian.org, itzswirlz2...@outlook.com

* Package name: nemo-pastebin
  Version : 4.6.0
  Upstream Author : Clement Lefebvre 
* URL : https://community.linuxmint.com/software/view/nemo-
pastebin, https://github.com/linuxmint/nemo-extensions/blob/master/nemo-
pastebin
* License : GPL-2+
  Programming Lang: Python
  Description : Nemo extension to send files to a pastebin

 nemo-pastebin is a Nemo extension written in Python, which
 allows users to upload text-only files to a pastebin service just
 by right-clicking on them.
 .
 After sending the files, a notification will be shown and the paste
 URL copied into the clipboard.
 .
 Users can also customize the extension's behaviour just by using
 nemo-pastebin-configurator, an easy-to-use configuration tool.


I plan to maintain this by myself until I can hopefully get it into cinnamon-
team.

Bug#957686: pinfo: diff for NMU version 0.6.13-1.1

2020-10-28 Thread Bas Zoetekouw

Thanks, very much appreciated!  nfortunately I don't have much  time to
spend on this package, so all help is welcome :)

Greetings,
bas.

On 28-10-2020 20:13, Sudip Mukherjee wrote:
> Control: tags 957686 + patch
> Control: tags 957686 + pending
> --
>
> Dear maintainer,
>
> I've prepared an NMU for pinfo (versioned as 0.6.13-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should cancel it.
>
> --
> Regards
> Sudip
>
> diff -Nru pinfo-0.6.13/debian/changelog pinfo-0.6.13/debian/changelog
> --- pinfo-0.6.13/debian/changelog 2019-02-16 20:28:19.0 +
> +++ pinfo-0.6.13/debian/changelog 2020-10-28 19:06:48.0 +
> @@ -1,3 +1,10 @@
> +pinfo (0.6.13-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix ftbfs with GCC-10. (Closes: #957686)
> +
> + -- Sudip Mukherjee   Wed, 28 Oct 2020 19:06:48 
> +
> +
>  pinfo (0.6.13-1) sid; urgency=medium
>  
>* New upstream release
> diff -Nru pinfo-0.6.13/debian/patches/fix_gcc-10.patch 
> pinfo-0.6.13/debian/patches/fix_gcc-10.patch
> --- pinfo-0.6.13/debian/patches/fix_gcc-10.patch  1970-01-01 
> 01:00:00.0 +0100
> +++ pinfo-0.6.13/debian/patches/fix_gcc-10.patch  2020-10-28 
> 19:06:46.0 +
> @@ -0,0 +1,30 @@
> +Description: Fix ftbfs with GCC-10.
> +
> +Author: Sudip Mukherjee 
> +Bug-Debian: https://bugs.debian.org/957686
> +Forwarded: no
> +
> +---
> +
> +--- pinfo-0.6.13.orig/src/parse_config.h
>  pinfo-0.6.13/src/parse_config.h
> +@@ -85,8 +85,6 @@ typedef struct colours
> + colours;
> + #endif /* HAVE_CURSES_COLOR */
> + 
> +-int use_manual;
> +-
> + int parse_config (void);
> + int parse_line (char *line);
> + char *str_toupper (char *s);
> +--- pinfo-0.6.13.orig/src/utils.c
>  pinfo-0.6.13/src/utils.c
> +@@ -866,7 +866,7 @@ make_tempfile()
> + /* allocate a new string and copy the filename there */
> + len = strlen(tmpfile_template)+1;
> + filename = xmalloc(len+1); /* guarenteerd to be set to \0's */
> +-strncpy(filename, tmpfile_template, len);
> ++strcpy(filename, tmpfile_template);
> + 
> + /* close the file */
> + close(fd);
> diff -Nru pinfo-0.6.13/debian/patches/series 
> pinfo-0.6.13/debian/patches/series
> --- pinfo-0.6.13/debian/patches/series2019-02-16 20:28:19.0 
> +
> +++ pinfo-0.6.13/debian/patches/series2020-10-28 18:56:45.0 
> +
> @@ -0,0 +1 @@
> +fix_gcc-10.patch
>

Bug#973320: RFS: lilo/1:24.2-5.1 [NMU] [RC] -- LInux LOader - the classic OS boot loader

2020-10-28 Thread Ryan Finnie

Package: sponsorship-requests
Severity: important

Dear mentors,

[RFS: This NMU fixes a GCC-10 ftbfs (#957490) which has kept lilo out of
testing since August.]

I am looking for a sponsor for my package "lilo":

 * Package name: lilo
   Version : 1:24.2-5.1
   Upstream Author : Joachim Wiedorn 
 * URL : http://lilo.joonet.de/
 * License : BSD-3-clause, GPL-2+
 * Vcs : https://salsa.debian.org/joowie-guest/maintain_lilo.git
   Section : admin

It builds those binary packages:

  lilo-doc - LInux LOader - Documentation for the classic OS boot loader
  lilo - LInux LOader - the classic OS boot loader

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/l/lilo/lilo_24.2-5.1.dsc

Changes since the last upload:

 lilo (1:24.2-5.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix ftbfs with GCC-10. (Closes: #957490)

Regards,
--
Ryan Finnie



signature.asc
Description: OpenPGP digital signature

Bug#973319: RFS: puzzle-jigsaw/1.0.2+git20201007.527c529+dfsg-2 -- tile puzzle game

2020-10-28 Thread Fabio Augusto De Muzio Tobich

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "puzzle-jigsaw":

 * Package name: puzzle-jigsaw
   Version : 1.0.2+git20201007.527c529+dfsg-2
   Upstream Author : https://bitbucket.org/admsasha/puzzle-jigsaw/issues/new
 * URL : https://bitbucket.org/admsasha/puzzle-jigsaw
 * License : CC0-1.0, MIT, GPL-3+
 * Vcs : https://salsa.debian.org/debian/puzzle-jigsaw
   Section : games

It builds those binary packages:

  puzzle-jigsaw - tile puzzle game

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

  https://mentors.debian.net/package/puzzle-jigsaw/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/puzzle-jigsaw/puzzle-jigsaw_1.0.2+git20201007.527c529+dfsg-2.dsc

Changes since the last upload:

 puzzle-jigsaw (1.0.2+git20201007.527c529+dfsg-2) unstable; urgency=medium
 .
   * Upload to unstable.

Regards,
-- 
⢀⣴⠾⠻⢶⣦⠀ 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#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.syst

2020-10-28 Thread Andreas Tille

Control: forwarded -1 Bernd Rinn 

Hi,

I'd recommend reading the bug report log from here to get some hints
about recommended changes in the code:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973070#17

For the moment I've excluded the affected tests.

Kind regards

  Andreas.
   

- Forwarded message from Markus Koschany  -

Date: Wed, 28 Oct 2020 19:34:35 +0100
From: Markus Koschany 
To: Debian Java List 
Cc: 973...@bugs.debian.org
Subject: Bug#973070: Bug#973070: Help needed: Bug#973070: libsis-base-java: 
FTBFS: Could not delete the directory
targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 
exceptions: [java.io.IOException: Unable to delete file:

targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink]
X-Debian-PR-Message: followup 973070
X-Debian-PR-Package: src:libsis-base-java
X-Debian-PR-Keywords: bullseye ftbfs help sid
X-Debian-PR-Source: libsis-base-java



Am 28.10.20 um 16:01 schrieb olivier sallou:
[...]
> *dumb* patch would be to simply remove those tests from code...

Either this or you can keep the override for dh_auto_test-arch empty.

The test creates a broken symlink but then FileUtils.deleteDirectory
fails to delete the file, obviously because it is not a directory but
I'm not sure how it really handles symlinks within directories. See also
[1]. Probably upstream should switch to the java.nio.file API (they
still use java.io.File), test for the existence of symlinks and then try
File.delete instead of FileUtils.deleteDirectory first. Not tested, just
a guess.

Markus


[1] https://issues.apache.org/jira/browse/IO-576





___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


- End forwarded message -

-- 
http://fam-tille.de

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

2020-10-28 Thread Dan Davison

When time permits please let me know how I can help and what the next steps are.

I'm not an expert on packaging considerations but I note that the
package which was conflicting with delta on binary name "delta" was
removed from Debian here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961607. The ideal
would be to install delta as an executable named "delta", since that
is how the executable is referred to in upstream documentation and
current user configuration files.

On Sat, 10 Oct 2020 at 12:17, Dan Davison  wrote:
>
> Hi all, I'm the package author and maintainer; let me know if I can help.
>
> It seems that debian will need to install delta with an executable name other 
> than "delta" since that is taken: if so I suggest the installed executable 
> name should be "git-delta", since that is the proposed name of the package 
> (and is the name of the package in other package repositories). It's a little 
> unfortunate, since the tool also works on unified diff (and subversion, and 
> mercurial) input, but I'm not aware of a better solution.
>
> Linking another debian packaging ticket (now archived) for getting delta into 
> debian from last year: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946213
>
> Dan
>
> On Sat, 10 Oct 2020 08:06:01 + Franklin Yu  wrote:
> > Note that the author already have a packaging script:
> >
> > https://github.com/dandavison/delta/blob/3790009a45cc9fc99bb7ae7249e756b393d35eda/etc/ci/before_deploy.sh
> >
> > This script generates some basic Debian files. It might be a good starting
> > point.
> >

Bug#957686: pinfo: diff for NMU version 0.6.13-1.1

2020-10-28 Thread Sudip Mukherjee

Control: tags 957686 + patch
Control: tags 957686 + pending
--

Dear maintainer,

I've prepared an NMU for pinfo (versioned as 0.6.13-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru pinfo-0.6.13/debian/changelog pinfo-0.6.13/debian/changelog
--- pinfo-0.6.13/debian/changelog   2019-02-16 20:28:19.0 +
+++ pinfo-0.6.13/debian/changelog   2020-10-28 19:06:48.0 +
@@ -1,3 +1,10 @@
+pinfo (0.6.13-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957686)
+
+ -- Sudip Mukherjee   Wed, 28 Oct 2020 19:06:48 
+
+
 pinfo (0.6.13-1) sid; urgency=medium
 
   * New upstream release
diff -Nru pinfo-0.6.13/debian/patches/fix_gcc-10.patch 
pinfo-0.6.13/debian/patches/fix_gcc-10.patch
--- pinfo-0.6.13/debian/patches/fix_gcc-10.patch1970-01-01 
01:00:00.0 +0100
+++ pinfo-0.6.13/debian/patches/fix_gcc-10.patch2020-10-28 
19:06:46.0 +
@@ -0,0 +1,30 @@
+Description: Fix ftbfs with GCC-10.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957686
+Forwarded: no
+
+---
+
+--- pinfo-0.6.13.orig/src/parse_config.h
 pinfo-0.6.13/src/parse_config.h
+@@ -85,8 +85,6 @@ typedef struct colours
+ colours;
+ #endif /* HAVE_CURSES_COLOR */
+ 
+-int use_manual;
+-
+ int parse_config (void);
+ int parse_line (char *line);
+ char *str_toupper (char *s);
+--- pinfo-0.6.13.orig/src/utils.c
 pinfo-0.6.13/src/utils.c
+@@ -866,7 +866,7 @@ make_tempfile()
+   /* allocate a new string and copy the filename there */
+   len = strlen(tmpfile_template)+1;
+   filename = xmalloc(len+1); /* guarenteerd to be set to \0's */
+-  strncpy(filename, tmpfile_template, len);
++  strcpy(filename, tmpfile_template);
+ 
+   /* close the file */
+   close(fd);
diff -Nru pinfo-0.6.13/debian/patches/series pinfo-0.6.13/debian/patches/series
--- pinfo-0.6.13/debian/patches/series  2019-02-16 20:28:19.0 +
+++ pinfo-0.6.13/debian/patches/series  2020-10-28 18:56:45.0 +
@@ -0,0 +1 @@
+fix_gcc-10.patch

Bug#972183: buster-pu: package libjpeg-turbo/1:1.5.2-2+deb10u1

On Sat, Oct 24, 2020 at 07:44:12PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2020-10-13 at 22:39 +0200, Moritz Muehlenhoff wrote:
> > This fixes a number of security issues in libjpeg,
> > which don't warrant a DSA. Package has been tested on
> > a buster system.
> 
> Please go ahead.

Thanks, uploaded.

Cheers,
Moritz

Bug#943060: ifupdown-multi: Python2 removal in sid/bullseye

On Wed, Oct 28, 2020 at 02:38:14PM -0400, Robert Edmonds wrote:
> Moritz Mühlenhoff wrote:
> > On Wed, Oct 23, 2019 at 02:33:26AM +, mo...@debian.org wrote:
> > > Source: ifupdown-multi
> > > Version: 0.1.1
> > > 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
> > 
> > Hi Robert,
> > ifupdown-multi is dead upstream (last commit seven years ago), are you 
> > planning
> > to port it yourself or should it just be removed?
> 
> Hi, Moritz:
> 
> I still use this script and am the original author. I should have some
> time in the next few days to port this. Thanks for the reminder.

Great :-)

Cheers,
Moritz

Bug#962459: unbound: constantly crashing after about 3 minutes since start

2020-10-28 Thread Robert Edmonds

Kebert Martin wrote:
> Hi,
> I tried the patch "p1_and_2.diff" from #973052.
> I'm not saying it was extensive test, but 7 minutes after start I got first
> crash:
> Oct 28 17:35:26 debian systemd[1]: Started Unbound DNS server.
> Oct 28 17:35:26 debian unbound[450]: [450:0] info: start of service (unbound
> 1.9.0).
> ...
> Oct 28 17:42:26 debian systemd[1]: unbound.service: Main process exited, code=
> killed, status=11/SEGV
> Oct 28 17:42:26 debian systemd[1]: unbound.service: Failed with result
> 'signal'.
> Oct 28 17:42:26 debian systemd[1]: unbound.service: Service RestartSec=100ms
> expired, scheduling restart.
> Oct 28 17:42:26 debian systemd[1]: unbound.service: Scheduled restart job,
> restart counter is at 1.
> ...
> and 10 minutes later flood (about 30/sec) of these messages:
> ...
> Oct 28 17:52:49 debian unbound[1885]: [warn] Epoll ADD(1) on fd 52 failed. Old
> events were 0; read change was 1 (add); w
> rite change was 0 (none); close change was 0 (none): Bad file descriptor
> Oct 28 17:52:49 debian unbound[1885]: [1885:3] error: read (in tcp s): Bad 
> file
> descriptor for  port 
> ...
> 
> and "unbound" stopped responding to "unbound-control" (even simple
> "unbound-control status" hangs).
> I can't decide whether it was caused by this patch or whether it is someting
> different.
> Anyway I installed version 1.10 back which works.

Hi, Kebert:

Instead of the "p1_and_2.diff" patch, can you try the attached patch
which includes additional fixes recommended by upstream? If this works
for you we can propose updating the version of unbound in buster with
these fixes.

Thanks!

-- 
Robert Edmonds
edmo...@debian.org
>From 0bf0258a54b9e7fd7d596bed3412bbf12ba532b6 Mon Sep 17 00:00:00 2001
From: Robert Edmonds 
Date: Wed, 28 Oct 2020 13:36:17 -0400
Subject: [PATCH] Apply a series of fixes for Unbound 1.9.0 suggested by
 upstream

Per https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227#c8,
upstream recommends applying the following commits against 1.9.0:

348cbab016f824a336b65d0091310fe5cd58e762
2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f
0b77c9d6763686264d44dfd926c8cb4f2f03a43a
6067ce6d2b82ce2e80055e578fdfd7ba3e67c523
af6c5dea43fc63452d49b2339e607365b6652987
a08fe8ca609b651c8d8c8379780aad508d492421

However, commit 0b77c9d6763686264d44dfd926c8cb4f2f03a43a contains a
complete revert of the code changes in
cae8361dcd2809c8e266d259370c9ab8660c2c0e (added post-1.9.0), so I
applied that patch as well in order to avoid needing to manually resolve
the textual conflict when attempting to apply
0b77c9d6763686264d44dfd926c8cb4f2f03a43a to 1.9.0.

Most hunks applied cleanly or with a small offset, excluding the
changelog entries. The git-apply session was as follows:

$ git describe
debian/1.9.0-2+deb10u2

$ git apply --verbose --exclude=doc/Changelog \
/tmp/up/348cbab016f824a336b65d0091310fe5cd58e762.diff \
/tmp/up/2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f.diff \
/tmp/up/cae8361dcd2809c8e266d259370c9ab8660c2c0e.diff \
/tmp/up/0b77c9d6763686264d44dfd926c8cb4f2f03a43a.diff \
/tmp/up/6067ce6d2b82ce2e80055e578fdfd7ba3e67c523.diff \
/tmp/up/af6c5dea43fc63452d49b2339e607365b6652987.diff \
/tmp/up/a08fe8ca609b651c8d8c8379780aad508d492421.diff
Skipped patch 'doc/Changelog'.
Checking patch util/netevent.c...
Applied patch util/netevent.c cleanly.
Skipped patch 'doc/Changelog'.
Checking patch config.h.in...
Hunk #1 succeeded at 83 (offset -3 lines).
Hunk #2 succeeded at 167 (offset -3 lines).
Checking patch configure...
Hunk #1 succeeded at 19010 (offset -3 lines).
Checking patch configure.ac...
Hunk #1 succeeded at 1197 (offset -3 lines).
Checking patch util/ub_event.c...
Applied patch config.h.in cleanly.
Applied patch configure cleanly.
Applied patch configure.ac cleanly.
Applied patch util/ub_event.c cleanly.
Skipped patch 'doc/Changelog'.
Checking patch services/listen_dnsport.c...
Applied patch services/listen_dnsport.c cleanly.
Skipped patch 'doc/Changelog'.
Checking patch services/listen_dnsport.c...
Hunk #1 succeeded at 1779 (offset -7 lines).
Hunk #2 succeeded at 1857 (offset -7 lines).
Applied patch services/listen_dnsport.c cleanly.
Skipped patch 'doc/Changelog'.
Checking patch services/listen_dnsport.c...
Hunk #1 succeeded at 1746 (offset -6 lines).
Checking patch services/mesh.c...
Applied patch services/listen_dnsport.c cleanly.
Applied patch services/mesh.c cleanly.
Skipped patch 'doc/Changelog'.
Checking patch daemon/worker.c...
Hunk #1 succeeded at 770 (offset -2 lines).
Checking patch util/netevent.c...
Hunk #1 succeeded at 1551 (offset -16 lines).
Hunk #2 succeeded at 1617 (offset -16 lines).
Applied patch daemon/worker.c cleanly.
Applied patch util/netevent.c cleanly.
Skipped patch 'doc/Changelog'.
Checking patch services/mesh.c...
Hunk #1 succeeded at 1196 (offset 4

Bug#938150: python-ruamel.ordereddict: Python2 removal in sid/bullseye

On Fri, Aug 30, 2019 at 07:46:25AM +, Matthias Klose wrote:
> Package: src:python-ruamel.ordereddict
> Version: 0.4.14-1
> 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

Hi,
there are no reverse deps in the archive, let's remove?

Cheers,
Moritz

Bug#938438: scap-security-guide: Python2 removal in sid/bullseye

On Mon, May 11, 2020 at 09:06:01AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 08 May 2020, Jeremy Bicha wrote:
> > Maintainers, please indicate whether you are working on a fix or else
> > this package will be removed from Debian Unstable soon. (You can
> > always reintroduce the package if you remove the Python2
> > dependencies.)
> 
> I just looked at the upstream source code and it seems to support Python 3
> since quite a while.
> 
> https://github.com/ComplianceAsCode/content
> 
> Philippe, can you take care to prepare an update and get rid of Python 2?

Are you still interested in maintaining scap-security-guide or should
it rather be removed? It's been removed from testing for 9 months now.

Cheers,
Moritz

Bug#956285: Problems identified in debian/copyright

On Mon, Jul 06, 2020 at 10:14:48PM +0200, Petter Reinholdtsen wrote:
> [Michael Lustfield]
> > I noticed that this package appears to have some issues with 
> > debian/copyright.
> 
> Hi.  Any hope to have a fix for this in time for the next stable release?

JFTR, this is fixed in 1.2.9

Cheers,
Moritz

Bug#973318: dialog: Please add Multi-Arch: foreign

2020-10-28 Thread Elrond

Package: dialog
Version: 1.3-20190808-1
Severity: wishlist
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch


Hi,

It looks like dialog offers an architecture independent
(process/cli level) interface to its users.
Would you mind setting it to Multi-Arch: foreign?
It's usually a matter of adding one line to debian/control.

This would improve install options for different
architectures.  Like for example using the x32 variant on a
mixed amd64/x32 system.


Cheers

Elrond

Bug#943060: ifupdown-multi: Python2 removal in sid/bullseye

2020-10-28 Thread Robert Edmonds

Moritz Mühlenhoff wrote:
> On Wed, Oct 23, 2019 at 02:33:26AM +, mo...@debian.org wrote:
> > Source: ifupdown-multi
> > Version: 0.1.1
> > 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
> 
> Hi Robert,
> ifupdown-multi is dead upstream (last commit seven years ago), are you 
> planning
> to port it yourself or should it just be removed?

Hi, Moritz:

I still use this script and am the original author. I should have some
time in the next few days to port this. Thanks for the reminder.

-- 
Robert Edmonds
edmo...@debian.org

Bug#973070: [Debian-med-packaging] Bug#973070: Help needed: Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 exc

2020-10-28 Thread Markus Koschany



Am 28.10.20 um 16:01 schrieb olivier sallou:
[...]
> *dumb* patch would be to simply remove those tests from code...

Either this or you can keep the override for dh_auto_test-arch empty.

The test creates a broken symlink but then FileUtils.deleteDirectory
fails to delete the file, obviously because it is not a directory but
I'm not sure how it really handles symlinks within directories. See also
[1]. Probably upstream should switch to the java.nio.file API (they
still use java.io.File), test for the existence of symlinks and then try
File.delete instead of FileUtils.deleteDirectory first. Not tested, just
a guess.

Markus


[1] https://issues.apache.org/jira/browse/IO-576



signature.asc
Description: OpenPGP digital signature

Bug#943060: ifupdown-multi: Python2 removal in sid/bullseye

On Wed, Oct 23, 2019 at 02:33:26AM +, mo...@debian.org wrote:
> Source: ifupdown-multi
> Version: 0.1.1
> 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

Hi Robert,
ifupdown-multi is dead upstream (last commit seven years ago), are you planning
to port it yourself or should it just be removed?

Cheers,
Moritz

Bug#973317: RM: libaria -- RoQA; unmaintained, RC-buggy, dead upstream

2020-10-28 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal

Please remove libaria. The last maintainer upload was in 2013,
there were no followups to any of the bugs since then, the
upstream homepage vanished and it's RC-buggy/dropped from testing
since 2019.

Cheers,
Moritz

Bug#957490: lilo: ftbfs with GCC-10

2020-10-28 Thread Ryan Finnie

tags 957490 + patch
thanks

Please see attached debdiff for a NMU ftbfs fix.  Sponsorship is
requested, thank you.
diff -Nru lilo-24.2/debian/changelog lilo-24.2/debian/changelog
--- lilo-24.2/debian/changelog  2019-12-10 14:41:00.0 -0800
+++ lilo-24.2/debian/changelog  2020-10-28 11:18:45.0 -0700
@@ -1,3 +1,10 @@
+lilo (1:24.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957490)
+
+ -- Ryan Finnie   Wed, 28 Oct 2020 11:18:45 -0700
+
 lilo (1:24.2-5) unstable; urgency=medium
 
   * Add file debian/NEWS to point out that lilo package is deprecated
diff -Nru lilo-24.2/debian/patches/11_fix-gcc-10.patch 
lilo-24.2/debian/patches/11_fix-gcc-10.patch
--- lilo-24.2/debian/patches/11_fix-gcc-10.patch1969-12-31 
16:00:00.0 -0800
+++ lilo-24.2/debian/patches/11_fix-gcc-10.patch2020-10-28 
11:15:28.0 -0700
@@ -0,0 +1,51 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Ryan Finnie 
+Bug-Debian: https://bugs.debian.org/957490
+Forwarded: no
+
+---
+
+--- a/src/raid.h
 b/src/raid.h
+@@ -8,7 +8,7 @@
+  * in the source directory.
+  */
+ 
+-int do_md_install, ndisk, md_bios;
++extern int ndisk, md_bios;
+ 
+ int raid_setup(void);
+ void raid_final(void);
+--- a/src/bsect.c
 b/src/bsect.c
+@@ -54,8 +54,6 @@
+ #endif
+ 
+ 
+-int boot_dev_nr;
+-
+ static BOOT_SECTOR bsect,bsect_orig;
+ static MENUTABLE menuparams;
+ static DESCR_SECTORS descrs;
+--- a/src/identify.c
 b/src/identify.c
+@@ -19,7 +19,6 @@
+ #include "common.h"
+ #include "cfg.h"
+ 
+-char *identify;
+ static char *opt;
+ static char *first, *dflt;
+ static int idefault;
+--- a/src/raid.c
 b/src/raid.c
+@@ -41,7 +41,7 @@
+ static int raid_bios[MAX_RAID+1];
+ static int device;
+ enum {MD_NULL=0, MD_PARALLEL, MD_MIXED, MD_SKEWED};
+-int do_md_install, ndisk, md_bios;
++int ndisk, md_bios;
+ static char *raid_list[MAX_RAID];
+ static int list_index[MAX_RAID];
+ static int nlist, faulty;
diff -Nru lilo-24.2/debian/patches/series lilo-24.2/debian/patches/series
--- lilo-24.2/debian/patches/series 2019-12-10 14:32:55.0 -0800
+++ lilo-24.2/debian/patches/series 2020-10-28 11:17:12.0 -0700
@@ -6,3 +6,4 @@
 08_small-typos-in-manpages.patch
 09_fix-manpage-lilo-conf-5.patch
 10_fix-manpage-lilo-conf-5.patch
+11_fix-gcc-10.patch


signature.asc
Description: OpenPGP digital signature

Bug#973304: debsign environment variable handling broken

2020-10-28 Thread halfdog

Adam D. Barratt writes:
> On Wed, 2020-10-28 at 15:03 +, halfdog wrote:
> > According to Debian Bullseye manpage "debsign" should handle the
> > "DEBSIGN_PROGRAM" environment variable as follows:
> > 
> >DEBSIGN_PROGRAM
> >   Setting this is equivalent to giving a -p option.
>
> Well... not really.
>
> The sentences just before that quote say (emphasis mine):
>
> "The two configuration files /etc/devscripts.conf and ~/.devscripts are
> sourced in that order to set configuration variables. Command line
> options can be used to override configuration file settings.
> **Environment variable settings are ignored for this purpose.** The
> currently recognised variables are: "
>
> So debsign ignoring the setting of that variable in the environment is
> behaving precisely as documented. This is common across almost all
> variables for almost all tools in devscripts.
>
> Regards,
>
> Adam

Sorry, my fault. I did wishful, sloppy reading, hoping that environment
variables only cannot override settings already in the devscripts.conf
instead of every time.

The reason why I was trying the most obscure ways to change the
gpg program is, that there seems no way to create a "gbp buildpackage"
command line, that changes DEBSIGN_PROGRAM without the need to
have root privileges.

"gbp buildpackage" calls "debbuild" with controllable arguments
(via "--git-builder" option".

Is there any way known to influence "debsign" via "debuild" command
line arguments without touching the file system?

Bug#973286: [Pkg-fonts-devel] Bug#973286: fonts-noto: file conflict between fonts-noto-core and fonts-noto-mono

Quoting Witold Baryluk (2020-10-28 19:06:06)
> I think the issue is not fully resolved:
> 
> 
> Preparing to unpack .../fonts-noto-unhinted_20201027-2_all.deb ...
> Unpacking fonts-noto-unhinted (20201027-2) over (20200323-1) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/fonts-noto-unhinted_20201027-2_all.deb (--unpack):
>  trying to overwrite '/usr/share/fonts/truetype/noto/NotoMono-Bold.ttf', 
> which is also in package fonts-noto-mono 20201027-2

Indeed - I missed another accidental copy in the *-unhinted package.

Thanks!

 - Jonas

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

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

signature.asc
Description: signature

Bug#969477: zfs-dkms fails to compile with 5.7.0-3 kernel blocking kernel upgrade

2020-10-28 Thread Antonio Russo


Control: tag -1 normal

In an off-list discussion, the reporter has said that the issue has 
spontaneously
resolved for kernel 5.9 on Debian sid.  I am therefore reducing the severity to
normal.

If this problem reoccurs for anyone, please also show your exact kernel header
version, i.e.,

# apt-cache policy linux-headers-$(uname -r)

for the affected kernel version.

Antonio Russo


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#834129: RFP: pgadmin4

2020-10-28 Thread Michel Le Bihan

Hello,

Did you create a Salsa repo where you have started your work and
uploaded sources? That will make it easier for others to contribute to
the package.

Also, Yarn is not a minifier it's a package manager. AFAIK it can't be
used during build. All dependencies must be Debian packages. There are
many JS libs in Debian with the `libjs-` prefix. Probably some are
missing, but I didn't check yet.

Michel Le Bihan

Bug#973316: nmu: tpm2-abrmd_2.3.3-1 tpm2-tools_4.3.0-1

2020-10-28 Thread Ying-Chun Liu (PaulLiu)

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

Hello,

libtpm2-tss bump the soname of its lib. Make the package
tpm2-abrmd needs to build against the latest libtpm2-tss.
Please see #972118
We have split the tpm2-tss already so that the SONAME matches the
package name.

  nmu tpm2-abrmd_2.3.3-1 . ANY . -m 'Rebuild against the new
libtpm2-tss, see #972118.'
  nmu tpm2-tools_4.3.0-1 . ANY . -m 'Rebuild against the new
libtpm2-tss, see #972659.'

Thanks.|

Yours,
Paul

Bug#973100: prometheus-postfix-exporter: FTBFS: src/github.com/alecthomas/kingpin/i18n_init.go:13:2: cannot find package "github.com/nicksnyder/go-i18n/i18n" in any of:

2020-10-28 Thread Martina Ferrari

Hi!

On 28/10/2020 15:06, Shengjing Zhu wrote:
>> This bug is actually on the golang-github-nicksnyder-go-i18n-dev
>> package. It seems the last upload brought a new API version, which
>> changes import paths, and probably other API breaks. This should have
>> been a new binary package and not an upgrade!
> 
> The change in src:golang-github-nicksnyder-go-i18n could be reverted.
> The v2 version is already packaged as a separated source
> https://tracker.debian.org/pkg/golang-github-nicksnyder-go-i18n.v2

I missed that there was already a v2 upload.. I really don't know what
are the plans upstream, or whether this did more than changing the
import path, but I think it would be good to upload some fix to the
current situation.. In general, I think we should adopt a team policy
regarding API breakages, similar to SONAME handling.

-- 
Martina Ferrari (Tina)

Bug#973286: fonts-noto: file conflict between fonts-noto-core and fonts-noto-mono

2020-10-28 Thread Witold Baryluk

Package: fonts-noto
Version: 20201027-2
Followup-For: Bug #973286
X-Debbugs-Cc: witold.bary...@gmail.com

I think the issue is not fully resolved:


Preparing to unpack .../fonts-noto-unhinted_20201027-2_all.deb ...
Unpacking fonts-noto-unhinted (20201027-2) over (20200323-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/fonts-noto-unhinted_20201027-2_all.deb (--unpack):
 trying to overwrite '/usr/share/fonts/truetype/noto/NotoMono-Bold.ttf', which 
is also in package fonts-noto-mono 20201027-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/fonts-noto-unhinted_20201027-2_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
it  fontconfig 2.13.1-4.2amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.10.2+dfsg-4 amd64FreeType 2 font engine, 
shared library files
ii  libfreetype6:i386  2.10.2+dfsg-4 i386 FreeType 2 font engine, 
shared library files
ii  libxft2:amd64  2.3.2-2   amd64FreeType-based font drawing 
library for X
ii  libxft2:i386   2.3.2-2   i386 FreeType-based font drawing 
library for X

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
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

Bug#962459: unbound: constantly crashing after about 3 minutes since start

2020-10-28 Thread Kebert Martin

Hi,
I tried the patch "p1_and_2.diff" from #973052.
I'm not saying it was extensive test, but 7 minutes after start I got first 
crash:
Oct 28 17:35:26 debian systemd[1]: Started Unbound DNS server.
Oct 28 17:35:26 debian unbound[450]: [450:0] info: start of service (unbound 
1.9.0).
...
Oct 28 17:42:26 debian systemd[1]: unbound.service: Main process exited, 
code=killed, status=11/SEGV
Oct 28 17:42:26 debian systemd[1]: unbound.service: Failed with result 'signal'.
Oct 28 17:42:26 debian systemd[1]: unbound.service: Service RestartSec=100ms 
expired, scheduling restart.
Oct 28 17:42:26 debian systemd[1]: unbound.service: Scheduled restart job, 
restart counter is at 1.
...
and 10 minutes later flood (about 30/sec) of these messages:
...
Oct 28 17:52:49 debian unbound[1885]: [warn] Epoll ADD(1) on fd 52 failed. Old 
events were 0; read change was 1 (add); w
rite change was 0 (none); close change was 0 (none): Bad file descriptor
Oct 28 17:52:49 debian unbound[1885]: [1885:3] error: read (in tcp s): Bad file 
descriptor for  port 
...

and "unbound" stopped responding to "unbound-control" (even simple 
"unbound-control status" hangs).
I can't decide whether it was caused by this patch or whether it is someting 
different.
Anyway I installed version 1.10 back which works.


BTW. In meantime second server had installed original "debian stable" version 
of unbound-1.9.0 (to compare with patched version) with:
...
Oct 28 17:48:45 debian2 unbound[519]: [err] evmap.c:381: Assertion nread >= 0 
failed in evmap_io_del_
Oct 28 17:48:45 debian2 systemd[1]: unbound.service: Main process exited, 
code=killed, status=6/ABRT
...
Oct 28 17:55:13 debian2 unbound[2811]: [err] evmap.c:381: Assertion nread >= 0 
failed in evmap_io_del_
Oct 28 17:55:13 debian2 systemd[1]: unbound.service: Main process exited, 
code=killed, status=6/ABRT
...
Oct 28 18:01:42 debian2 unbound[3951]: [err] evmap.c:381: Assertion nread >= 0 
failed in evmap_io_del_
Oct 28 18:01:42 debian2 systemd[1]: unbound.service: Main process exited, 
code=killed, status=6/ABRT
...
Oct 28 18:07:22 debian2 unbound[5187]: [err] evmap.c:381: Assertion nread >= 0 
failed in evmap_io_del_
Oct 28 18:07:22 debian2 systemd[1]: unbound.service: Main process exited, 
code=killed, status=6/ABRT
...
Oct 28 18:18:03 debian2 unbound[6196]: [err] evmap.c:381: Assertion nread >= 0 
failed in evmap_io_del_
Oct 28 18:18:03 debian2 systemd[1]: unbound.service: Main process exited, 
code=killed, status=6/ABRT
...
Oct 28 18:22:36 debian2 unbound[8178]: [err] evmap.c:381: Assertion nread >= 0 
failed in evmap_io_del_
Oct 28 18:22:36 debian2 systemd[1]: unbound.service: Main process exited, 
code=killed, status=6/ABRT
...

I'd say it is quite consistent (although frequency might depends on amount of 
traffic).


S pozdravem
Martin Kebert

28. 10. 2020 v 2:04, Daniel Kahn Gillmor 
mailto:d...@debian.org>>:

Control: forcemerge 973052 962459

Hi Kebert--

On Mon 2020-06-08 12:28:46 +0200, Kebert Martin wrote:
unbound constantly crashing with:
[err] evmap.c:381: Assertion nread >= 0 failed in evmap_io_del_

The issue is fixed in unbound 1.9.2 but this version is not available in debian 
packages.

As a workaround I had unbound from testing but it is not possible now,
because currect testing version 1.10.1-1 relies on libpython3.8 which
relies on libc6 >= 2.29 whereas stable libc6 is 2.28-10.

Thanks for this note!  sorry i missed it when reporting 973052, but it
looks like it's the same issue.  Would you be up for trying a version of
unbound that includes the patch from 973052 and letting me know whether
the crash is still happening?

I haven't seen "consistent" failures with the workload where i
encountered the bug, so it'd be great to hear whether the patch solves
the problem for you if you've got a repeatable workload.

If you don't know how to rebuild the package with the extra patch,
please respond here and maybe one of the debian packagers who is used to
working with unbound can offer a proposed update.

Regards,

   --dkg


Informace obsa?en? v t?to e-mailov? zpr?v? a v?ech p?ilo?en?ch souborech jsou 
d?v?rn? a jsou ur?eny pouze pro pot?ebu adres?ta. Pros?me, abyste v p??pad?, ?e 
tento e-mail obdr??te omylem, neprodlen? upozornili odes?latele a tento e-mail 
odstranili z Va?eho syst?mu. Pokud nejste zam??len?m p??jemcem, berte pros?m na 
v?dom?, ?e zve?ejn?n?, kop?rov?n?, ???en? ?i p?ijet? jak?hokoliv opat?en? v 
souvislosti s obsahem t?to zpr?vy je zak?z?no a m??e b?t protipr?vn?.

_

The information contained in this e-mail message and all attached files is 
confidential and is intended solely for the use of the individual or entity to 
whom they are addressed. Please notify the sender immediately if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in

Bug#973315: dwww doesnt decompress documentation files

2020-10-28 Thread Calum McConnell

Package: dwww
Version: 1.13.5
Severity: wishlist
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Many packages gzip their README files, and even (often) their examples.  It 
saves
space, and it quite useful to me as a user, since I can (usually) just open it 
normally
(I have lesspipe installed).

However, DWWW wanted to download the Gziped readme.md I pointed it to.  Is there
any way that can be changed, so that it gets decompressed and then served?

For that matter, I would be intrested in seeing more flexibility in serving 
files.
For instance, .gz extensions could be decompressed, .md fed through kramdown (if
its installed), ect.  Even if there was just a way to define filters (if the 
following
files are accessed, send them through these programs first), usability would 
improve immensly.

Thanks!
Calum

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
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 dwww depends on:
ii  apache2 [httpd-cgi]2.4.46-1
ii  debconf [debconf-2.0]  1.5.74
ii  debianutils4.11.2
ii  doc-base   0.10.9
ii  file   1:5.38-5
ii  libc6  2.31-4
ii  libfile-ncopy-perl 0.36-2
ii  libmime-types-perl 2.17-1
ii  man-db 2.9.3-2
ii  mime-support   3.64
ii  perl   5.30.3-4
ii  sensible-utils 0.0.12+nmu1
ii  ucf3.0043

Versions of packages dwww recommends:
ii  apache2 [httpd]  2.4.46-1
ii  apt  2.1.10
ii  dlocate  1.07+nmu1
ii  info2www 1.2.2.9-24
ii  swish++  6.1.5-5

Versions of packages dwww suggests:
ii  chromium [www-browser] 83.0.4103.116-3.1
ii  doc-debian 6.4
ii  dpkg-www   2.60
ii  firefox-esr [www-browser]  78.3.0esr-2
ii  lynx [www-browser] 2.9.0dev.6-1
ii  w3m [www-browser]  0.5.3-38+b1

- -- debconf information:
  dwww/badport:
  dwww/cgiuser: www-data
  dwww/serverport: 80
  dwww/index_docs: false
  dwww/nosuchuser:
  dwww/cgidir: /usr/lib/cgi-bin
  dwww/nosuchdir:
  dwww/docrootdir: /var/www
  dwww/servername: CalumsBeastlyLaptop.computercalum.com

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl+ZrecdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzIyKxAAgGsJRU+v6zu3oMiY
q2aLYVkvWuRtRXksrOLew6LFbL+bZMoOhYq4J4BWEy+7EPsnHsooi7HStfDF3eEb
SoJYcr3mM/g7GOiBEemxMgQeleoH+v1WQD6TtEFBNgClg30Kchwq66AzisoZ3m9R
ZB+irSaT/VZgYvTFYHikPw6qOcsXvS5FN13e5LTI+2FeghcplF6uD69BHm1cjI07
eb1l7iPxRRvmnh7YDl42EuMy+2TFVSOQZ54nYqbwrqIqturSS5tXlSEitlTPEX5p
0o9635UCHYkimw967nimK4uNOYB0/MMfpA8vYoNVji/u3u0Qt5iGLhvFasFm6VYZ
PpWRXXV370RjyolJBUeYRWFXUAU6r8X5wMOZaE2I+JpXYtyWUqr8+MRVm0GC0ql0
QYvc+r2Ifoz9760bwt2ljtkXtO24huukYcuLGwJRONpX4x0RN8puaosRHsF6DXxe
zPAbLbA4WcQnKMhnlg4jGU5DENflvV7C1HoxyIMXS4dL3rNJEdkpyhQEL9RR5U62
oA/BC85esTAqR381Rh/YXvpHP/AR5SyBkwAxRvdcpZM0XTHDtl9ArqsViP/D9na0
uzOsuRhzbnverNvfuNLT4TRfwvj3HfPTqfmeXhFzRxcK8eE0rUaAIjD2JoTuQbrL
bRK5EcrBjVyRqukCUK2QS2+RS8o=
=xGLe
-END PGP SIGNATURE-

Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

2020-10-28 Thread Lucas Kanashiro

Running the same command with verbose enabled tells us that bundler 
ignores the ffi gem because it's missing extensions:


root@rubygems-test:~/test# bundle --local --verbose
Running `bundle install --local --verbose` with bundler 2.2.0.rc.1
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and 
installing your bundle
as root will break this application for all non-root users on this machine.
Found changes from the lockfile, re-resolving dependencies because the list of 
sources changed, the dependencies in your gemfile changed, you added a new 
platform to your gemfile
Source rubygems repository https://rubygems.org/ or installed locally is ignoring 
# because it 
is missing extensions
Could not find gem 'ffi' in any of the gem sources listed in your Gemfile.
Bundler::GemNotFound: Could not find gem 'ffi' in any of the gem sources listed 
in your Gemfile.
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/resolver.rb:313:in
 `block in verify_gemfile_dependencies_are_found!'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/resolver.rb:281:in
 `each'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/resolver.rb:281:in
 `verify_gemfile_dependencies_are_found!'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/resolver.rb:49:in
 `start'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/resolver.rb:22:in
 `resolve'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/definition.rb:264:in
 `resolve'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/definition.rb:175:in
 `specs'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/definition.rb:156:in
 `resolve_with_cache!'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/installer.rb:304:in
 `resolve_if_needed'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/installer.rb:84:in
 `block in run'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/process_lock.rb:12:in
 `block in lock'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/process_lock.rb:9:in
 `open'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/process_lock.rb:9:in
 `lock'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/installer.rb:73:in
 `run'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/installer.rb:25:in
 `install'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/cli/install.rb:64:in
 `run'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/cli.rb:261:in
 `block in install'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/settings.rb:121:in
 `temporary'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/cli.rb:260:in
 `install'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in
 `run'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in
 `invoke_command'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/vendor/thor/lib/thor.rb:392:in
 `dispatch'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/cli.rb:30:in
 `dispatch'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/vendor/thor/lib/thor/base.rb:485:in
 `start'
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/cli.rb:24:in
 `start'
  /usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/exe/bundle:49:in `block 
in '
  
/usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/lib/bundler/friendly_errors.rb:117:in
 `with_friendly_errors'
  /usr/share/rubygems-integration/all/gems/bundler-2.2.0.rc.1/exe/bundle:37:in 
`'
  /usr/bin/bundle:23:in `load'
  /usr/bin/bundle:23:in `'


--
Lucas Kanashiro

Bug#973062: Confirming

2020-10-28 Thread Thomas Goirand

Hi,

I confirm that the s/isAlive/is_alive/ issue was in httpretty, though
after fixing that one, cloud-init still suffered from broken tests under
Python 3.9 with OpenNebula. I've blacklisted the tests for that data
source, because I don't think anyone cares much about OpenNebula in
2020. If I'm wrong with this thinking, let me know.

Cheers,

Thomas Goirand (zigo)

Bug#973309: See also ITP bug

2020-10-28 Thread Gard Spreemann

You may also want to check out the ITP bug #923851 [1], in particular
the observation in message 10 ("780 MB and 3285 files" sounds like a
very hard packaging job).

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

 Best,
 Gard

Bug#973314: RFS: hydrapaper/2.0.2-1 -- Utility that sets background independently for each monitor

2020-10-28 Thread Francisco M Neto

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "hydrapaper":

 * Package name: hydrapaper
   Version : 2.0.2-1
   Upstream Author : Gabriele Musco 
 * URL : https://gitlab.com/gabmus/HydraPaper
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/fmneto-guest/hydrapaper
   Section : graphics

It builds those binary packages:

  hydrapaper - Utility that sets background independently for each monitor

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/h/hydrapaper/hydrapaper_2.0.2-1.dsc

Changes since the last upload:

 hydrapaper (2.0.2-1) unstable; urgency=medium
 .
   * New upstream version.
   * debian/clean: created file to force manpage cleanup.

Regards,
-- 
[]'s,

Francisco M Neto 
www.fmneto.com

3E58 1655 9A3D 5D78 9F90
CFF1 D30B 1694 D692 FBF0


0xD30B1694D692FBF0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#973313: lintian: Fix failing Lintian jobs for many if not all packages hosted on Salsa

Package: lintian
Severity: important

Hi,

Since October 22, the Lintian jobs on Salsa pipelines have failed for
many packages, including Lintian. [1] In the container, 'groff' cannot
find LC_ALL defined even though we reset the environment and
explicitly provide LC_ALL=C.UTF-8. [2] It is ineffective, and that is
the substance of this bug.

I am not sure what changed (my commit could not have done it). I only
see a recent upload for bash, but not for groff, perl or
libipc-run3-perl. I already asked on #salsci. I was told that the
runner images had not been manipulated in some time. The cause would
likely be elsewhere.

I also asked on #salsa because, on October 22, the runner base system
was upgraded to Debian 10 from 9. (That is unrelated to the images
provided by Salsa CI.) According to the Salsa admins that change
should have had no impact. For the time being we are at a loss.

Colin Watson provides a workaround below, but we will try to find the
real bug first:

"If all else fails then setting MAN_NO_LOCALE_WARNING=1 may be a
viable workaround."

This bug filing follows discussions on debian-devel@lists.d.o and IRC,
the relevant parts of which were copied below.

There is also a Salsa issue about this [3], but it's probably better
to centralize the discussion here. The bug may indeed belong to Salsa
CI but issues filed on that website seem less permanent than a bug in
the BTS. Please use this bug to comment on the issue going forward.
Thank you!

Kind regards
Felix Lechner

[1] 
https://lintian.pages.debian.net/-/lintian/-/jobs/1098261/artifacts/debian/output/lintian.html
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/checks/documentation/manual.pm#L279-281
[3] https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/182

***

Hello there!

My Salsa CI pipeline is blowing up in the lintian step, with
lots of warnings of the form:

"W: notcurses-bin: groff-message
usr/share/man/man1/notcurses-demo.1.gz can't set the locale; make sure
$LC_* and $LANG are correct"

This is printed for each man page I package. An example run is
here:

https://salsa.debian.org/debian/notcurses/-/jobs/1107065

The only reference I could find was
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606933, which
didn't seem relevant.

Is this due to having supra-ascii UTF8 characters in my man
pages? Is there anything I can do to work around this? I tried
exporting LANG to a UTF-8 locale in my salsa variables section,
but that didn't help.

I'm using pandoc to generate my man pages, and it happily
accepts UTF-8, but I can see a case for restricting them to
ASCII.

Thanks!

--
nick black -=- https://www.nick-black.com

* * *

Hi Nick,

On Sun, Oct 25, 2020 at 6:23 PM Nick Black  wrote:
>
> Is this due to having supra-ascii UTF8 characters in my man
> pages?

It's not a problem with your package. Lintian's own pipeline is
likewise affected, even though our test suite completes fine in an
unstable chroot. The issue is being tracked here:
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/182

Kind regards
Felix Lechner

* * *

Felix Lechner left as an exercise for the reader:
> It's not a problem with your package. Lintian's own pipeline is
> likewise affected, even though our test suite completes fine in an
> unstable chroot. The issue is being tracked here:
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/182

Thanks for the quick response, Felix. You say that "[you] will
probably start setting $LANG in that part of Lintian." what LANG
will you be using? Attempting to set LANG=en_US.UTF-8 in my
salsa ci variables resulted in setlocale(3) failing all over the
place, presumably due to the locale not having been generated.

--
nick black -=- https://www.nick-black.com

* * *

On Mon, 26 Oct 2020 at 00:35:45 -0400, Nick Black wrote:
> Thanks for the quick response, Felix. You say that "[you] will
> probably start setting $LANG in that part of Lintian." what LANG
> will you be using? Attempting to set LANG=en_US.UTF-8 in my
> salsa ci variables resulted in setlocale(3) failing all over the
> place, presumably due to the locale not having been generated.

C.UTF-8 is available on all Debian systems. It's the standard C/POSIX
locale, except that in the C locale the meaning of bytes 0x80-0xFF is
undefined, while in C.UTF-8 they are assumed/defined to be part of a
character encoded in UTF-8.

If you care about portability to non-Debian systems, note that C.UTF-8 is
a somewhat popular extension (I think it originated in the Fedora/Red Hat
family before it was adopted by Debian and other distros) but is far from
universally available. In particular, I'm aware of Arch Linux specifically
*not* having it. The glibc maintainers consider the implementation used
in e.g. Fedora and Debian to be a hack rather than something they want to
maintain forever, but my understanding is that they would be willing to
accept a better implementation.

en_US.UTF-8 is indeed not portable. Some OSs (Fedora, I think?) always

Bug#973309: ghidra: Request for package ghidra

2020-10-28 Thread Andrei POPESCU

Control: reassign -1 ghidra
Control: retitle -1 RFP: ghidra -- a reverse engineering framework

On Mi, 28 oct 20, 13:18:08, Lucas Cruz dos Reis wrote:
> Package: ghidra
> Version: 9.1.2
> Severity: wishlist
> Tags: newcomer
> 
> Dear Maintainer,
> I wish debian had a package for ghidra which is a reverse engeneering 
> framework
> maintained by the National Security Agency Research Directorate.
> 
> 
> -- System Information:
> Debian Release: 10.6
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.8.10 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Reassigning to correct pseudo-package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#973304: debsign environment variable handling broken

2020-10-28 Thread Adam D. Barratt

On Wed, 2020-10-28 at 15:03 +, halfdog wrote:
> According to Debian Bullseye manpage "debsign" should handle the
> "DEBSIGN_PROGRAM" environment variable as follows:
> 
>DEBSIGN_PROGRAM
>   Setting this is equivalent to giving a -p option.

Well... not really.

The sentences just before that quote say (emphasis mine):

"The two configuration files /etc/devscripts.conf and ~/.devscripts are
sourced in that order to set configuration variables. Command line
options can be used to override configuration file settings.
**Environment variable settings are ignored for this purpose.** The
currently recognised variables are: "

So debsign ignoring the setting of that variable in the environment is
behaving precisely as documented. This is common across almost all
variables for almost all tools in devscripts.

Regards,

Adam

Bug#972572: emacs-gtk: scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

2020-10-28 Thread Vincent Lefevre

Control: tags -1 upstream
Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284

I have just reported the bug upstream.

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

Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))

2020-10-28 Thread Daniel Kahn Gillmor

Hi Robert--

thanks for the followup!

On Wed 2020-10-28 02:56:55 -0400, Robert Edmonds wrote:
> I've never been able to reproduce this bug, but your branch looks good
> to me as far as backporting this commit to 1.9.0. It's commit
> 225534e5ab22d16ab32fa1011733f3c69c7b28ba in the upstream repo which was
> released in 1.9.1. I don't have any objection if you want to propose a
> stable update for unbound with just this fix. Personally I've been
> keeping unbound in buster-backports up to date with testing lately and I
> don't have any buster machines running the version of unbound in buster
> :-)

Over on https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227
upstream suggested two different things:

 - upgrade to 1.9.2, (which incorporates this and several other bugfixes), or

 - cherry-pick a list of other commits which they think are also
   relevant to this specific fix:

348cbab016f824a336b65d0091310fe5cd58e762
2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f

   and four more, related to spoolbuf:

0b77c9d6763686264d44dfd926c8cb4f2f03a43a
6067ce6d2b82ce2e80055e578fdfd7ba3e67c523
af6c5dea43fc63452d49b2339e607365b6652987
a08fe8ca609b651c8d8c8379780aad508d492421

I'm assuming that the release team would prefer that we go the latter
route (cherry-picked patches), but i haven't tried to get a direct
verdict from them on that.

I confess i don't really understand the way that unbound's buster
packaging is working -- i think it's neither git-dpm nor gbp -- so i
don't exactly know how i'd assemble an update for the next buster point
release without overhauling it.  (i'd be fine with overhauling it to use
gbp (as i think the unstable version of the packaging is) as long as
you're ok with that, but i also don't know whether that would make the
changes more unpleasant for the release team.

Any suggestions?

--dkg

signature.asc
Description: PGP signature

Bug#973311: Please include Lektor admin interface

2020-10-28 Thread Joseph Nuthalapati

Package: lektor
Severity: wishlist

Dear maintainer,

Lektor admin web interface allows a user to author web pages through a
web browser without having to learn how to edit files over SSH on the
server where the website is hosted. This greatly improves the
user-friendliness of the application.

The Debian package for Lektor is currently missing this web interface.
Please include it.

Thanks for maintaining Lektor.

-- 
Regards,
Joseph Nuthalapati



signature.asc
Description: OpenPGP digital signature

Bug#973312: gedit: Add gir1.2-tepl-5 package dependency

2020-10-28 Thread Jeffery To

Package: gedit
Version: 3.38.0-1
Severity: minor

Dear Maintainer,

(I originally reported this to Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1901446)

gedit in experimental depends on libtepl-5-0 (libtepl-4-0 in
testing/unstable), but it does not have a dependency on the GObject
introspection bindings for libtepl (gir1.2-tepl-5, gir1.2-tepl-4 for
testing/unstable).

Functionality is being moved from gedit into tepl (a "Text editor
product line" library). For instance,
gedit_utils_str_middle_truncate() was deprecated in gedit 3.36 and
removed in 3.38[1], replaced with tepl_utils_str_middle_truncate().

Please add a dependency to gir1.2-tepl-5 so that Python plugins can
reliably call functions in libtepl. (For my plugin Control Your Tabs,
I had to inline the above mentioned function[2] so that the plugin
continues to function for users of Debian and Debian-derived OSes.)

It would be great if the gedit package in testing/unstable can be
amended as well.

[1]: 
https://gitlab.gnome.org/GNOME/gedit/-/commit/b21585d0f3ff2081626f6ffb7e1dc1b7a52e
[2]: 
https://github.com/jefferyto/gedit-control-your-tabs/commit/644c2b9d9a61ffd1d8f9aba44866b301ba47bf39

Bug#973310: RM: osmalchemy -- ROM; Abandoned upstream, no rdeps

2020-10-28 Thread Dominik George

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I am both upstream an maintainer of OSMAlchemy, and OSMAlchemy never got any
traction and was only used in one project (which now uses other mechanisms).
I therefore request removal.

- -nik

-BEGIN PGP SIGNATURE-

iQJ+BAEBCgBoFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAl+ZmHQxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxgcbmF0dXJl
c2hhZG93QGRlYmlhbi5vcmcACgkQt5o8FqDE8pZIaQ/9Fg/ef1/LZXuQ44W08l5F
jCi4C/jzvVdb/v4MsaTfEX+uiBvqMq+mx55ylAQ+d+kPuNznRGvY6lY+hMy5UUHH
E7DgZZ3pjmoDWS0N06uqzVdyepg7hv5oYKFf0yHsQ/NbXYTRYj98QZRx5grfxXoF
rJ1R5GV+O3+/rEO6Ps4XK8px+HUJL8FdU9FM5UN0mBTH5lGJSuRU7dApHAk8M0ma
r/F8Odn36BF4ia4iQXZbFL/e9u5IENhKNIiMYW79YJ9uTHDpPZXQaZI29YGJaq+Y
HiJihncX5d3urNkRsxcArV60CwfUpq0w8aciFnEGdubp3Ru8zWzy6Z3jDm0AEMqp
shgTfQuLLfpRwJQ2wG49CWQjQYhvs/ycqrCj5qAyW88K9rSDrjOgcRE3L9te0EEg
dr+MdKixzYTiX99y9noHJUsqbzD91r8rkhDWu2fzpFlm1JeH+qpM5D9eUEarOBbB
0CHircKr6j111eKK/kNYQdfvT765c3GQTGY5qi1nvoHF/sRXS+RNkzgqM/vkSF0T
qlIM/ae/Y3yiFxZWzoQfF5wdWDAuN1h+QFVDFNCa1LLUiImODwVmF+TNBKF/7w8l
sU5x2eQTIrAT6IaLErhrnPMlVk1Yo9xudtxRjHqxVaLctU6Fnia7sSwhmnVG0Lbx
oAm1EbLcxdwOoYATOnv4Uz0=
=bdVe
-END PGP SIGNATURE-

Bug#973309: ghidra: Request for package ghidra

2020-10-28 Thread Lucas Cruz dos Reis

Package: ghidra
Version: 9.1.2
Severity: wishlist
Tags: newcomer

Dear Maintainer,
I wish debian had a package for ghidra which is a reverse engeneering framework
maintained by the National Security Agency Research Directorate.


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

Kernel: Linux 5.8.10 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#973259: Acknowledgement (dpkg-scanpackages: local development repos fail due to missing sha512 hashes)

2020-10-28 Thread Nicholas D Steeves

Control: found -1 dpkg/1.19.7

I'm not sure if it's a priority, but it's worth noting that buster's
dpkg-dev is also affected.

Bug#950781: r-bioc-biocstyle_2.16.0+dfsg-1_amd64.changes REJECTED

2020-10-28 Thread Andreas Tille

Hi Thorsten

On Thu, Sep 17, 2020 at 09:00:09PM +, Thorsten Alteholz wrote:
> please remove BiocStyle/inst/resources/tex/unsrturl.bst from the source 
> tarball as its license is not DFSG compatible.

this is addressed in recent upload.

Thanks for checking

 Andreas.

-- 
http://fam-tille.de

Bug#973308: lintian: Automate importation of valid archive sections via http://