date:20210215

alright, with 1.2.30 (1.2.29 was never released), we pass the
autopkgtests, huzzah.

Bug#923500: snapd: non-classic snap not confined

2021-02-15 Thread James Henstridge

I work on some parts of snapd at Canonical, so thought I'd weigh in.
I've got a few of points to add:

1. In the "snap debug confinement" output, it says
"policy:downgraded". This indicates that snapd didn't detect enough
AppArmor features to enforce the full "strict confinement" sandbox, so
it switches to a permissive policy. This was done because the
generated policies would sometimes malfunction on such systems.

We do have a system to prevent the downgrade on some systems where
we've verified that the sandbox behaves correctly:

https://github.com/snapcore/snapd/blob/cc398c14fe13c70d14b9cb2eef9873cd4b8eda1e/interfaces/apparmor/backend.go#L614-L629

I suspect current Debian probably meets this standard, so we should
add it to the exceptions list.

2. As for why Debian is not being considered for "full" support, I
suspect this is down to the out-of-tree patches to enable access
control for unix domain sockets. This will likely resolve itself when
snapd moves to use the new AppArmor 3.0 network features (which does
not rely on out of tree patches).

3. Even on systems where the full strict confined sandbox is enabled,
acess to the root directory is granted in the base template:

https://github.com/snapcore/snapd/blob/3173439195f62eacd6493cd49f257480811ed7a7/interfaces/apparmor/template.go#L444-L445

Note however that the root directory as seen within a snap's sandbox
is not the same as the root directory of the host system. Instead,
the contents of the "base snap" used by the snap. In the case of the
"hello-world" snap, the base is "core". For example, this is the
output on my system:

james@scruffy:/$ ls
bin cdrom etc liblib64 lost+found mnt proc run snap sys usr
boot devhome lib32 libx32 media opt root sbin srv tmp var
james@scruffy:/$ snap run --shell hello-world
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

james@scruffy:/$ ls
bin dev home lib64meta opt root sbinsrv tmp var
boot etc lib mediamnt proc run snapsys usr writable

You should find that the non-AppArmor parts of the sandbox are still in effect.

James.

Bug#982901: Paprius-icon-theme

2021-02-15 Thread amc252

Package: papirus-icon-theme
From: Antonio Maccagnan amc...@gmail.com
Version: 20210201-1
System: Debian Bullseye 5.10.0-3-amd64 (2021-02-06)

Hello,
I have installed the latest version of the Papirus icon theme 20210201-1.
I tried to use them on spacefm, but none of the icons work, nor they show up as 
available on lxappearance menu.
They do not work regardless of the GTK-theme I select.
I can get the papirus icons on JWM menu, but not on spacefm.
Other icon themes I have installed (breeze, adwaita, etc.) work just fine. 

--

Bug#982295: libpam0g.postinst: `installed_services` function is not systemd aware

Mostly for anyone else subscribed to the pam bug reports.

How do I want to detect a systemd native unit.  I don't think I want to
look in the filesystem; do we need to do anything more complex than
looking at the UnitState in systemctl is-enabled?

What is Debian's
preferred way to determine if a system is running under systemd.

--sam

Bug#815164: Alerte par e-mail

2021-02-15 Thread Centre de messagerie

Cher utilisateur de messagerie

Nous avons remarqué sur notre serveur de messagerie que votre compte de 
messagerie vient d'être piraté par un utilisateur inconnu, veuillez sécuriser 
votre email maintenant en cliquant sur répondre et en remplissant vos 
coordonnées email pour sécuriser rapidement votre email et éviter de perdre 
définitivement votre compte.

Cliquez sur le bouton de réponse et remplissez les détails du compte ci-dessous 
et cliquez sur envoyer pour sécuriser votre compte de messagerie.
  
   Adresse e-mail:  
 
  Nom d'utilisateur:
 
  Mot de passe:
 
 
 Sincèrement
Équipe de gestion des courriels

Bug#982900: RM: libhtml-calendarmonth-perl -- ROM; RC buggy, upstream unresponsive

2021-02-15 Thread Don Armstrong

Package: ftp.debian.org
Severity: normal

Please remove libhtml-calendarmonth-perl; it is RC buggy, has a pretty
finiky build system (which is why it fails to build), has an
unresponsive upstream, and is largely unused in the archive.

Thanks!

-- 
Don Armstrong  https://www.donarmstrong.com

"Old hypotheses never really die, they're like dormant volcanoes."
 -- John McPhee _Annals of the Former World_ p313

Bug#968606: vte: Racy NULL-ptr segfault in vte::terminal::update_repeat_timeout()

2021-02-15 Thread Bernhard Übelacker


Control: fixed -1 vte2.91/0.62.1-1


Hello,
marking fixed as mentioned in message by submitter to upstream bug [1].

Kind regards,
Bernhard

[1] https://gitlab.gnome.org/GNOME/vte/-/issues/270#note_1037042

Bug#982742: solved

Hi to all,

comparing avahi settings was much less pain then I expected.

On the installation with ipp-usb not working the file

/etc/avahi/avahi-daemon.conf

had an active (non commented out) line:

allow-interfaces=eth9


On my installation with ipp-usb working this line in the respective
file reads:

#allow-interfaces=eth0

So it is commented out and names a different interface.


After commenting out this line in the problematic installation the
printer is visible and configurable in the cups administration. As with
the other installations, two printers show up in the print menue
(Libreoffice) and I can print successfully.

I have no idea how this setting ended up in /etc/avahi/avahi-daemon.conf

Thanks to all who helped finding the flaw. Feel free to contact me if
you think I could help here in the region where I live (Aachen/Germany).

Greetings

Michael

Bug#982309: Session-Interactive-Only: no is equivalent to Session-Interactive-Only: yes

> "Lucas" == Lucas Nussbaum  writes:

Lucas> When using config snippets in /usr/share/pam-configs/, it
Lucas> seems that 'Session-Interactive-Only: no' is equivalent to
Lucas> 'Session-Interactive-Only: yes'.

I think we've missed the freeze deadline for fixing this in bullseye.
I'm bringing this up only because if you disagree and want to argue for
why a fix to this meets the freeze policy I wanted to give you a chance
to do so.
(Although I assume you would have filed at higher severity if that was
the case).


Thanks for the report, and at first glance, it does look like your
reading of the code is correct.

Bug#982899: duply: new test for decryption keys breaks symmetric encryption

2021-02-15 Thread Sean Whitton

Package: duply
Version: 2.3-1
Control: forwarded -1 https://sourceforge.net/p/ftplicity/bugs/124/
Control: fixed -1 duply/2.1-1

Dear maintainer,

The new code which checks the availability of encryption secret keys
fails when using symmetric encryption, i.e., when GPG_PW is set but
GPG_KEYS_ENC and GPG_KEY_SIGN are not set.  Looking at the new code, it
does not seem to take into account this long-supported way of using
duply, so I think this is a regression from buster.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

Hi.
So, you seem to be thinking about thnigs a bit differently than I am.
I took a few days to come up to speed.

It sounds like you're assuming that  someone will add  pam_tally or
pam_pam_tally2 using a package profile in /usr/share/pam-configs.
I was assuming someone would add pam_tally or pam_tally2 by modifying
the config in /etc/pam.d directly.

First, I'm guessing that when you talk about someone enabling pam_tally
through pam-configs  you  are talking about in a profile they wrote, not
in a package in Debian.
If there's a package in Debian that enables pam_tally we should file a
bug against that package and use a breaks relationship to avoid the
issue.

If someone has included a module they wrote in /usr/share/pam-configs, I
agree with your original approach: we should detect that module and halt
the upgrade.

However, if there are no modules that enable pam_tally from pam-configs
but there are entries in /etc/pam.d/* think we should comment
those entries out.

This may disable future automatic updates depending on where the changes
are in the pam.d files
but I think that's a better outcome than upgrading to a
known-wont-let-you-login configuration.

We'd want to display a note to this effect if we make any changes.


I think I can implement the above once we're agreed on the approach.
I'd appreciate  feedback on whether that is the right approach.

Bug#982898: Failed to update md5sums on template change

package: libpam-runtime
version: 1.4.0-3
severity: important

When I made modifications to the common-* templates, I needed to update
the list of md5sums in pam-auth-update to avoid breaknig future
upgrades.
Fortunately, as I read the code, this ca nbe fixed in a future version
without ill effects for that version.

Bug#982897: ITP: ncdc -- file sharing program using Direct Connect protocols

2021-02-15 Thread Boris Pek

Package: wnpp
Severity: wishlist
Owner: Boris Pek 
X-Debbugs-Cc: tehn...@debian.org

* Package name: ncdc
  Version : 1.22.1
  Upstream Contact: Yoran Heling 
* URL : https://dev.yorhel.nl/ncdc
* License : MIT (Expat)
  Programming Lang: C, ncurses
  Description : file sharing program using Direct Connect protocols

Ncdc is a lightweight direct connect client with a friendly ncurses interface.
It is compatible with EiskaltDC++, DC++, AirDC++, FlylinkDC++ and other DC
clients. Ncdc also interoperates with all common DC hub software that uses the
Direct Connect and Advanced Direct Connect protocols.
.
Program is NOT designed for using as daemon, but it may be used in combination
with a separate terminal multiplexer (screen, tmux) or detach utility (dtach)
if user needs such feature.

Bug#982840: linux-image-5.10.0-3-arm64: requesting scsi_debug.ko for arm64/armhf helping systemd autopkgtest

2021-02-15 Thread Ryutaroh Matsumoto

The lack of scsci_debug.ko for arm64 also makes the autopkgtest-virt-qemu
testsuite fail with udisks2.
Ryutaroh

Bug#981159: marked as done (extra-cmake-modules: drop unused qt Build-Depends)

close #981159


On Mon, Feb 15, 2021 at 11:09 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Mon, 15 Feb 2021 23:04:26 +
> with message-id 
> and subject line Bug#981159: fixed in extra-cmake-modules 5.79.0-1
> has caused the Debian Bug report #981159,
> regarding extra-cmake-modules: drop unused qt Build-Depends
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 981159: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981159
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Helmut Grohne 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 27 Jan 2021 07:09:00 +0100
> Subject: extra-cmake-modules: drop unused qt Build-Depends
> Source: extra-cmake-modules
> Version: 5.78.0-3
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> extra-cmake-modules participates in dependency loops relevant to
> architecture bootstrap. Instead of looking into such a difficult
> problem, I looked for easily droppable dependencies and found that its
> qt dependencies are unused - presumably since its test suite is
> disabled. Please consider applying the attached patch to drop the
> relevant dependencies. Alternatively, consider enabling the tests.
>
> Helmut
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 981159-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 15 Feb 2021 23:04:26 +
> Subject: Bug#981159: fixed in extra-cmake-modules 5.79.0-1
> Source: extra-cmake-modules
> Source-Version: 5.79.0-1
> Done: Norbert Preining 
>
> We believe that the bug you reported is fixed in the latest version of
> extra-cmake-modules, which is due to be installed in the Debian FTP
> archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 981...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Norbert Preining  (supplier of updated
> extra-cmake-modules package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Tue, 16 Feb 2021 06:45:26 +0900
> Source: extra-cmake-modules
> Architecture: source
> Version: 5.79.0-1
> Distribution: experimental
> Urgency: medium
> Maintainer: Debian Qt/KDE Maintainers 
> Changed-By: Norbert Preining 
> Closes: 981159
> Changes:
>  extra-cmake-modules (5.79.0-1) experimental; urgency=medium
>  .
>[ Norbert Preining ]
>* Drop unused qt build deps (Closes: #981159).
>* New upstream release (5.79.0).
> Checksums-Sha1:
>  d79331485114e66f58aff3a57ca9161a34b0c9a6 2464
> extra-cmake-modules_5.79.0-1.dsc
>  1754af5c687f2a9426467c300af9eadc49a64872 356596
> extra-cmake-modules_5.79.0.orig.tar.xz
>  54e5a55d504edda09e2df9be7c0c0e34e87d9bd2 488
> extra-cmake-modules_5.79.0.orig.tar.xz.asc
>  9c01e9b1387df5f77920f5bc33c4e3af5dee9fd6 12556
> extra-cmake-modules_5.79.0-1.debian.tar.xz
>  c0366200b3befe0792f816c2cb1057a876474fa2 8170
> extra-cmake-modules_5.79.0-1_source.buildinfo
> Checksums-Sha256:
>  7c731c3198fec4fff1115451e09338c1aa34957a2ccb62e0895726021afa20c0 2464
> extra-cmake-modules_5.79.0-1.dsc
>  b29602db99c566d88fa92106abe114bd57b7ffc6ca20773426f896ffde68bed8 356596
> extra-cmake-modules_5.79.0.orig.tar.xz
>  1edbfc662464d999b6b3043d2d2391b7ac96596af3ad129a5ac3bc0730f72576 488
> extra-cmake-modules_5.79.0.orig.tar.xz.asc
>  7d13de1eed74fd9ce6e353eb895f88fcac229587a2b859dbb0180644eaaa6147 12556
> extra-cmake-modules_5.79.0-1.debian.tar.xz
>  ba82294e31b561f179c4cbfceea6ef2d2e0146224753a97c941c4c9876ac1852 8170
> extra-cmake-modules_5.79.0-1_source.buildinfo
> Files:
>  0008aace2dde7d7d1149f2cbd61d57b2 2464 devel optional
> extra-cmake-modules_5.79.0-1.dsc
>  020c6267046a065ee505c9b03d1bbe56 356596 devel optional
> extra-cmake-modules_5.79.0.orig.tar.xz
>  785e0a21bf80e7d42f3bd8514d5aae64 488 devel optional
> extra-cmake-modules_5.79.0.orig.tar.xz.asc
>  92399b413dcda0398592b6672350755a 12556 devel optional
> extra-cmake-modules_5.79.0-1.debian.tar.xz
>  ec819d4f78afaca021cf105139960ce2 8170 devel optional
> extra-cmake-modules_5.79.0-1_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCgAdFiEE68ws0vrA2voQX53I2A4JsIcUAGYFAmAq95MACgkQ2A4JsIcU
>

Bug#981864: marked as done (libinih: Please provide libinih1-udeb)

close #981864

On Mon, Feb 15, 2021 at 11:03 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Mon, 15 Feb 2021 23:00:29 +
> with message-id 
> and subject line Bug#981864: fixed in libinih 53-1
> has caused the Debian Bug report #981864,
> regarding libinih: Please provide libinih1-udeb
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 981864: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981864
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Bastian Germann 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 4 Feb 2021 18:17:29 +0100
> Subject: libinih: Please provide libinih1-udeb
> Source: libinih
> Severity: important
> Control: block 981662 by -1
>
> xfsprogs recently became a reverse dependency of your package.
> #981662 documents that for the xfsprogs' udeb variant, a libinih1-udeb
> to link against is needed. Please provide that package.
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 981864-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 15 Feb 2021 23:00:29 +
> Subject: Bug#981864: fixed in libinih 53-1
> Source: libinih
> Source-Version: 53-1
> Done: Yangfl 
>
> We believe that the bug you reported is fixed in the latest version of
> libinih, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 981...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Yangfl  (supplier of updated libinih package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Tue, 09 Feb 2021 18:47:19 +0800
> Source: libinih
> Binary: libinih-dev libinih1 libinih1-dbgsym libinih1-udeb libinireader0
> libinireader0-dbgsym
> Architecture: source amd64
> Version: 53-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Yangfl 
> Changed-By: Yangfl 
> Description:
>  libinih-dev - simple .INI file parser (development files)
>  libinih1   - simple .INI file parser
>  libinih1-udeb - simple .INI file parser - udeb (udeb)
>  libinireader0 - simple .INI file parser for C++
> Closes: 981864 982351
> Changes:
>  libinih (53-1) unstable; urgency=medium
>  .
>* New upstream release (Closes: #982351)
>* Add libinih1-udeb for Debian Installer (Closes: #981864)
> Checksums-Sha1:
>  99e3bc2b049ac312819ab09ae9b7d8c3b649bdde 2031 libinih_53-1.dsc
>  9924ce7fba763f4faa7e63fc11f84a655b73020b 16984 libinih_53.orig.tar.gz
>  141aa1d6411ab39493ee55a46a24f7ef83b54ae5 9336 libinih_53-1.debian.tar.xz
>  3f02301cf7e5d1875b087c1be51edfa094d87fec 20036 libinih-dev_53-1_amd64.deb
>  707a632147c80c9562d7b584dd0883b5ad23aa7f 8304
> libinih1-dbgsym_53-1_amd64.deb
>  d01a26ea8dfd74b1f337cdc8e9fb436629426bf2 4136
> libinih1-udeb_53-1_amd64.udeb
>  3f14b97b0431aeecb1d7b2cb2ebbf0905f0348c8 6508 libinih1_53-1_amd64.deb
>  e90472d773f6adf62d5cd71377d9190b303f1433 7768 libinih_53-1_amd64.buildinfo
>  e2b8346d7c8b203a30f655ac8bd396646734ef5e 73396
> libinireader0-dbgsym_53-1_amd64.deb
>  8df08bff92bec97690508bb241e4ed61e43001ce 10056
> libinireader0_53-1_amd64.deb
> Checksums-Sha256:
>  0affd7b286eab810496c44d1401fb6c077c21de6068e1e334bf4b55b0020c211 2031
> libinih_53-1.dsc
>  01b0366fdfdf6363efc070c2f856f1afa33e7a6546548bada5456ad94a516241 16984
> libinih_53.orig.tar.gz
>  77f5fbf0f79b96e6c923a2cdc329e2b23d4ad1eb9b15a44ea370bd0f13676543 9336
> libinih_53-1.debian.tar.xz
>  c36b18e40a0a44b1b264e865418c55e688876387574e11ff54428e24837712a7 20036
> libinih-dev_53-1_amd64.deb
>  4eeb08ee8f6cf644b41dad4c09854e134c73a3dfdb242c4451f485df3f567189 8304
> libinih1-dbgsym_53-1_amd64.deb
>  05182d7b9e145b3e9cde2a92344230462757845d50700999391ec8c95829b122 4136
> libinih1-udeb_53-1_amd64.udeb
>  6bf68a0fb6b2c1552f7d7a1bf4e687846d8ff1d65e8b9acbf5b222347bb8964a 6508
> libinih1_53-1_amd64.deb
>  cc2465cab60478f6587573f0d13738c89a55d66644b8aa2b85c9b27396abba30 7768
> libinih_53-1_amd64.buildinfo
>  126fc9c9141ad9f6ef33d68c020091ae37ab09d0e04fc2bf82c07ce862c166bb 73396
> libinireader0-dbgsym_53-1_amd64.deb
>  44331dcc5164eb834ec3036c2bcb1582642207457496c8c0a8b872f882da3d98 10056
>

Bug#251673: marked as done (parsechangelog fails if Maintainer: formatted wrong)

close #251673

On Mon, Feb 15, 2021 at 11:45 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Tue, 16 Feb 2021 00:43:48 +0100
> with message-id <20210215234347.cnjfyfwgtoopm...@sym.noone.org>
> and subject line Re: Bug#251673: equivs: produces badly formatted default
> changelog
> has caused the Debian Bug report #251673,
> regarding parsechangelog fails if Maintainer: formatted wrong
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 251673: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251673
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Ingo Strüwing" 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 30 May 2004 09:31:52 +0200
> Subject: equivs: produces badly formatted default changelog
> Package: equivs
> Version: 2.0.6-0.1
> Severity: normal
> Tags: sid
>
> The control file j2re1.4.ctl looks like:
>
> Section: misc
> Priority: optional
> Standards-Version: 3.5.10
>
> Package: j2re1.4
> Version: 1.4
> Maintainer: ingo.struew...@web.de
> Depends: j2re
> Description: Dummy package to include SUN's java
>  Dummy package to include SUN's java
>
>
> The build messages are:
>
> $ equivs-build j2re1.4.ctl
> dh_testdir
> touch build-stamp
> dh_testdir
> dh_testroot
> dh_clean -k
> # Add here commands to install the package into debian/tmp.
> touch install-stamp
> dh_testdir
> dh_testroot
> dh_installdocs
> dh_installchangelogs
> parsechangelog/debian: error: badly formatted trailer line, at changelog
> line 5
> dh_installchangelogs: changelog parse failure
> make: *** [binary-arch] Fehler 1
> Error during the build process: Unpassender IOCTL (I/O-Control) für das
> Gerät at /usr/bin/equivs-build line 180,  line 33.
>
>
> The file equivs/debian/changelog looks like:
>
> j2re1.4 (1.4) unstable; urgency=low
>
>   * First version
>
>  -- ingo.struew...@web.de  Sun, 30 May 2004 08:58:58 +0200
>
>
> Obviously, parsechangelog/debian needs a name *AND* an email address.
> So I suggest that equivs checks that before executing the scripts, as
> the error messages are of little precision and give the impression that
> the tool(s) is(are) badly smashed.
>
>
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers unstable
>   APT policy: (990, 'unstable')
> Architecture: i386 (i686)
> Kernel: Linux 2.6.6
> Locale: LANG=de_DE, LC_CTYPE=de_DE
>
> Versions of packages equivs depends on:
> ii  debhelper 4.2.10 helper programs for
> debian/rules
> ii  devscripts2.7.95.1   Scripts to make the life of a
> Debi
> ii  dpkg-dev  1.10.21Package building tools for
> Debian
> ii  fakeroot  0.9.5  Gives a fake root environment
> ii  make  3.80-7 The GNU version of the "make"
> util
> ii  perl [perl5]  5.8.4-2Larry Wall's Practical
> Extraction
>
> -- no debconf information
>
>
>
>
> -- Forwarded message --
> From: Axel Beckert 
> To: "Ingo Strüwing" , 251673-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 16 Feb 2021 00:43:48 +0100
> Subject: Re: Bug#251673: equivs: produces badly formatted default changelog
> Version: 2.1.0
>
> Hi,
>
> Ingo Strüwing wrote:
> > The control file j2re1.4.ctl looks like:
> >
> > Section: misc
> > Priority: optional
> > Standards-Version: 3.5.10
> >
> > Package: j2re1.4
> > Version: 1.4
> > Maintainer: ingo.struew...@web.de
> > Depends: j2re
> > Description: Dummy package to include SUN's java
> >  Dummy package to include SUN's java
>
> This control file builds fine with the current version of equivs
> 2.3.1. I assume that this actually has been fixed in 2.1.0 from 2017
> where I replace the usage dpkg-parsechangelog completely.
>
> Full changelog entry from back then:
>
> equivs (2.1.0) unstable; urgency=low
>
>   [ Axel Beckert ]
>   * Adopt equivs under the Debian Perl Group umbrella. (Closes: #852223)
>   * Import package history into a Git repository and add Vcs-*
> headers. (Closes: #663424)
> + Add a .gitignore file.
>   * Apply wrap-and-sort.
>   * Switch debian/rules to minimal dh v7 style.
> + Use debian/install instead calling cp inside debian/rules.
> + Remove obsolete variables.
> + Replace usage of dpkg-parsechangelog with $SOURCE_DATE_EPOCH. Fixes
>   lintian warning debian-rules-parses-dpkg-parsechangelog.
>   * Rename debian/equivs.* to debian/*.
>   * Move documentation files from debian/*.pod to *.pod.
>   * Move man page generation from debian/rules to a new

Bug#982786: growlight: autopkgtest regression

not so fast! while this does indeed fix the segfault when run
without TERM, i still get an autopkgtest failure, this one
tracked down to stdout being redirected =[. so i'm gonna address
that as well. how embarrassing.

Bug#982786: growlight: autopkgtest regression

Here's the upstream bug: https://github.com/dankamongmen/growlight/issues/139
Here's the (obvious, trivial) fix:
https://github.com/dankamongmen/growlight/commit/297f487a8be84441ff75a22b5fa63305931cae70

A real brown-bagger =[.

I'm going to cut 1.2.29 and upload it to unstable. If I ought
prepare this patch as a debian patch for testing, as said, I can
do that as well. Otherwise, I'm perfectly content to let this
flow through unstable->testing.

Bug#982885: apt: refuses to update, citing certificate that won't be valid for several hours

2021-02-15 Thread David Kalnischkies

Hi,

please show us the complete output of apt – not just the error message
or even worse just paraphrasing the message. This bugreport is otherwise
not actionable and would need to be closed.

As a first semi-random suggestion: Ensure that your system has the right
date and time set. I know multiple people who have accidentally set
their computer to the wrong day while looking up dates in the calendar.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#982896: modem-manager-gui: Wrong units such as "Kb" instead of "kB" (and kbit/s in German!)

2021-02-15 Thread Jens Seidel

Package: modem-manager-gui
Version: 0.0.19.1-2
Severity: minor
Tags: patch

Hi,

I observed that the data download in modem-manager-gui was off by a
factor of 8 as bit and bytes were confused with each other. This was
noticed in the German translation but the problem is the obscure use
of units in the English source code.

The connection speed was provided with "Gbps" which is OK (but hard to
decipher) but for the total amount of received and transmitted data
units such as "Kb" was used which confused the translator. Two
characters but 3 errors in it: It should mean kilo bytes, the SI unit
for kilo is "k" and for byte "B" (b stands for bits but is not
officially defined as unit). And as we all know in computer area kilo
is not kilo but kibi so it should be "KiB" (now again indeed with
capital K). This is maybe a little bit unusual but it is used more and
more and is the proper one.

To avoid confusion I used also "Kibit/s" instead of "kbps" and
replaced two times "sec" by it's SI unit "s".

I attached a patch which addresses this and updated/unfuzzied the
German translation (which was up-to-date except 2 or 3 strings).

What I also noticed during my tests: There is an xgettext error in
src/strformat.c:105 and :109 in two strings which is reported by
"ninja meson-modem-manager-gui-update-po" (which works only after
adding po/POTFILES). The reason is that xgettext parses the C source
code to extract translations and does not know macros such as
G_GUINT64_FORMAT. The solution would be to provide translators a
replacement string using maybe %u and to replace it after the gettext
call. I was not doing so as string handling is difficult in C, sorry.

Two further trivial changes: The string "Disabled" occurs a few times
but at least in the German language two different translations are
required (which differ only in capitalization). That's why a
translation context was given once. Further the text '"%"
G_GUINT64_FORMAT " day(s)"' was transferred into a plural rule so that
it reads either "1 day" or "n days" (but xgettext had trouble with the
macro in the old version already).

All very minor stuff but maybe worth a Debian patch if upstream does
not fix it fast ...
It is also fully OK for me if parts of the patch ("Gibit/s" :-)) are
rejected. Contact me in this case and I will update po/de.po.

Jens
commit bb13e8853116ecd092699d3f3d189be38a44c27e
Author: Jens Seidel 
Date:   Mon Feb 15 23:12:58 2021 +0100

Fix wrong units such as "Kb" into "KiB"

diff --git a/resources/ui/modem-manager-gui.ui b/resources/ui/modem-manager-gui.ui
index 579f21e..9bb8369 100644
--- a/resources/ui/modem-manager-gui.ui
+++ b/resources/ui/modem-manager-gui.ui
@@ -4415,9 +4415,9 @@ Umidjon Almasov u.alma...@gmail.com
 False
 center
 
-  Mb
-  Gb
-  Tb
+  MiB
+  GiB
+  TiB
 
   
   
diff --git a/src/strformat.c b/src/strformat.c
index cec6dd8..776af21 100644
--- a/src/strformat.c
+++ b/src/strformat.c
@@ -36,23 +36,23 @@ gchar *mmgui_str_format_speed(gfloat speed, gchar *buffer, gsize bufsize, gboole
 	
 	if (speed < 1024.0) {
 		if (small) {
-			g_snprintf(buffer, bufsize, _("%.3f kbps"), speed);
+			g_snprintf(buffer, bufsize, _("%.3f Kibit/s"), speed);
 		} else {
-			g_snprintf(buffer, bufsize, _("%.3f kbps"), speed);
+			g_snprintf(buffer, bufsize, _("%.3f Kibit/s"), speed);
 		}
 	} else if ((speed >= 1024.0) && (speed < 1048576.0)) {
 		fpvalue = speed / (gdouble)(1024.0);
 		if (small) {
-			g_snprintf(buffer, bufsize, _("%.3g Mbps"), fpvalue);
+			g_snprintf(buffer, bufsize, _("%.3g Mibit/s"), fpvalue);
 		} else {
-			g_snprintf(buffer, bufsize, _("%.3g Mbps"), fpvalue);
+			g_snprintf(buffer, bufsize, _("%.3g Mibit/s"), fpvalue);
 		}
 	} else {
 		fpvalue = speed / (gdouble)(1048576.0);
 		if (small) {
-			g_snprintf(buffer, bufsize, _("%.3g Gbps"), fpvalue);
+			g_snprintf(buffer, bufsize, _("%.3g Gibit/s"), fpvalue);
 		} else {
-			g_snprintf(buffer, bufsize, _("%.3g Gbps"), fpvalue);
+			g_snprintf(buffer, bufsize, _("%.3g Gibit/s"), fpvalue);
 		}
 	}
 	
@@ -84,9 +84,9 @@ gchar *mmgui_str_format_time(guint64 seconds, gchar *buffer, gsize bufsize, gboo
 	
 	if (seconds < 60) {
 		if (small) {
-			g_snprintf(buffer, bufsize, _("%u sec"), (guint)seconds);
+			g_snprintf(buffer, bufsize, _("%u s"), (guint)seconds);
 		} else {
-			g_snprintf(buffer, bufsize, _("%u sec"), (guint)seconds);
+			g_snprintf(buffer, bufsize, _("%u s"), (guint)seconds);
 		}
 	} else if ((seconds >= 60) && (seconds < 3600)) {
 		if (small) {
@@ -102,9 +102,13 @@ gchar *mmgui_str_format_time(guint64 seconds, gchar *buffer, gsize bufsize, gboo
 		}
 	} else {
 		if (small) {
-			g_snprintf(buffer, bufsize, _("%"

Bug#981407: sysv-generator is really annoying with an eccessive verbosity

2021-02-15 Thread Michael Biebl


Am 02.02.21 um 10:11 schrieb Francesco P. Lovergine:
Well, the truly annoying thing is that it warns even for init scripts 
disabled, but never removed (sometimes on purpose, sometimes due to 
package errors). I discovered a few of them still around since years, 
and reduced

a bit the noisei by purging.


But isn't this a good thing, that it shows you that there is old cruft?

 For sure this system is up since 28th of

Jan and dmesg shows
only messages after 30th of Jan currently. So generally, at every restart
of services the syslog is populated with those warnings in good quantity.

Any system upgraded several times and/or used for development will present
tons of this warnings during its life cycle. I know upstream already 
refused to take in consideration the possibility of on/off that warns by 
option. At least, using debug priority would move those warns to a 
different log file in default configuration, not too bad.


Fwiw, I don't think either that an On/Off switch would be a good idea.

Assuming we remove the old SysV generator at some point, we do need to 
warn users in advance, so they can prepare. If we downgrade those 
messages to debug, I fear users will never see them and take appropriate 
steps.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#982895: ITP: r-cran-pingr -- A CRAN R package, pingr, which is used to check if a remote computer is up. It can either call the system ping command, or check a specified TCP port.

2021-02-15 Thread Eric Brown

Package: wnpp
Severity: wishlist
Owner: Eric Brown 
X-Debbugs-Cc: debian-de...@lists.debian.org, e...@ericebrown.com

* Package name: r-cran-pingr
  Version : 2.0.1
  Upstream Author : Gábor Csárdi 
* URL : https://github.com/r-lib/pingr#readme
* License : MIT
  Programming Lang: R
  Description : A CRAN R package, pingr, which is used to check if a remote 
computer is up. It can either call the system ping command, or check a 
specified TCP port.

This R package is an important dependency for other important 
R packages, such as shinytest and codemetaR and is suggested 
by major packages such as remotes and devtools.

The package will be maintained by the Debian R package
maintainers team.

I will seek a sponsor from the Debian R package maintainers
team.

Bug#982786: growlight: autopkgtest regression

Alright, I've got it locked down to the absence of a TERM
environment variable in the autopkgtest environment. If I run
the same command outside of autopkgtest, after running
`unset TERM`, i get the exact same failure.

So, this failure is IMHO definitely worth fixing, and I intend
to do so now, but this is also a very atypical configuration.
Users will generally have a TERM environment variable. I.e., I
do not think this would have been reported as a bug were it not
for the test. So hopefully this won't be a problem despite soft
freeze. I'm preparing the fix now.

Thanks to Antonio Terceiro and Daniel Leidert for their
assistance on debian-devel in working with autopkgtest/debci!
I really appreciate it.

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

Am Tue, 16 Feb 2021 01:11:32 +0300
schrieb Alexander Pevzner :

Hi Alexander. Thanks for helping here.

>
> As I'm not very familiar with Avahi troubleshooting, any help or
> ideas are welcome.
>

Do you suspect some configuration issue or anything which leaves traces
within the file system?

If so, is there a way (other than comparing file by file looking at it)
to compare the avahi settings (or whatever) of my working installation
with to one not working?
I could mount one system somewhere into the other. Is there a
software or command to compare the relevant directories? Would this
help at all?

Or would it help to purge avahi* together with the few depending
packages and reinstall them?

Greetings

Michael

Bug#982894: isc-dhcp-client: Empty /etc/resolv.conf if root partition is full

2021-02-15 Thread Johannes Weißl

Package: isc-dhcp-client
Version: 4.4.1-2
Severity: important
Tags: patch

The Debian version of /sbin/dhclient-script creates a temporary file next to
/etc/resolv.conf, and fills it with information. Then it replaces
/etc/resolv.conf with the temporary file. So far so good.

The problem appears when the root partition is full. The temporary file is
creates, but filling it with informations is not possible anymore (echo "..." >
temporary_resolv_conf fails). BUT: Instead of aborting, dhclient-script still
replaced the perfectly good /etc/resolv.conf with an empty one.

This problem appears a lot on AWS EC2 instances (are configured using DHCP,
despite being servers).



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

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils4.8.6.1
ii  iproute2   4.20.0-2+deb10u1
ii  libc6  2.28-10
ii  libdns-export1104  1:9.11.5.P4+dfsg-5.1+deb10u2
ii  libisc-export1100  1:9.11.5.P4+dfsg-5.1+deb10u2

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.1-2

Versions of packages isc-dhcp-client suggests:
ii  avahi-autoipd 0.7-4+b1
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information
diff -Naur isc-dhcp-4.4.1.old/debian/dhclient-script.hurd 
isc-dhcp-4.4.1.new/debian/dhclient-script.hurd
--- isc-dhcp-4.4.1.old/debian/dhclient-script.hurd  2018-12-11 
04:55:12.0 +0100
+++ isc-dhcp-4.4.1.new/debian/dhclient-script.hurd  2021-02-15 
23:45:10.628260983 +0100
@@ -26,7 +26,7 @@
 rm -f $new_resolv_conf
 
 if [ -n "$new_domain_name" ]; then
-echo domain ${new_domain_name%% *} >>$new_resolv_conf
+echo domain ${new_domain_name%% *} >>$new_resolv_conf || exit 1
 fi
 
 if [ -n "$new_domain_search" ]; then
@@ -42,17 +42,17 @@
 new_domain_search="$new_domain_name 
$new_domain_search"
 fi
 fi
-echo "search ${new_domain_search}" >> $new_resolv_conf
+echo "search ${new_domain_search}" >> $new_resolv_conf || exit 1
 elif [ -n "$new_domain_name" ]; then
-echo "search ${new_domain_name}" >> $new_resolv_conf
+echo "search ${new_domain_name}" >> $new_resolv_conf || exit 1
 fi
 
 if [ -n "$new_domain_name_servers" ]; then
for nameserver in $new_domain_name_servers; do
-   echo nameserver $nameserver >>$new_resolv_conf
+   echo nameserver $nameserver >>$new_resolv_conf || exit 1
 done
 else # keep 'old' nameservers
-sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf
+sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf || exit 1
 fi
 
 chown --reference=/etc/resolv.conf $new_resolv_conf
@@ -64,15 +64,15 @@
 rm -f $new_resolv_conf
 
 if [ -n "$new_dhcp6_domain_search" ]; then
-echo "search ${new_dhcp6_domain_search}" >> $new_resolv_conf
+echo "search ${new_dhcp6_domain_search}" >> $new_resolv_conf || 
exit 1
 fi
 
 if [ -n "$new_dhcp6_name_servers" ]; then
 for nameserver in $new_dhcp6_name_servers; do
-echo nameserver $nameserver >>$new_resolv_conf
+echo nameserver $nameserver >>$new_resolv_conf || exit 1
 done
 else # keep 'old' nameservers
-sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf
+sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p 
/etc/resolv.conf >>$new_resolv_conf || exit 1
 fi
 
 chown --reference=/etc/resolv.conf $new_resolv_conf
diff -Naur isc-dhcp-4.4.1.old/debian/dhclient-script.linux 
isc-dhcp-4.4.1.new/debian/dhclient-script.linux
--- isc-dhcp-4.4.1.old/debian/dhclient-script.linux 2018-12-11 
04:55:12.0 +0100
+++ isc-dhcp-4.4.1.new/debian/dhclient-script.linux 2021-02-15 
23:45:10.156260808 +0100
@@ -51,7 +51,7 @@
 rm -f $new_resolv_conf
 
 if [ -n "$new_domain_name" ]; then
-echo domain ${new_domain_name%% *} >>$new_resolv_conf
+echo domain ${new_domain_name%% *} >>$new_resolv_conf || exit 1
 fi
 
 if [ -n "$new_domain_search" ]; then
@@ -67,17 +67,17 @@
 new_domain_search="$new_domain_name $new_domain_search"

Bug#977542: golang-github-revel-revel: Depends on network in tests

2021-02-15 Thread Reinhard Tartler

Dear Golang Team,

On Mon, Feb 15, 2021 at 1:23 PM Paul Gevers  wrote:

> On 15-02-2021 15:08, Reinhard Tartler wrote:
> > Control: severity -1 important
>
> I agree with this. The Debian infra allows for use of the internet (if
> not used to download programs, that's forbidden by ftp-master [1].)
> [...]
> > The package itself appears to be fine. The tests fail if and only if the
> > test setup doesn't provide (proper) internet connectivity. In fact, it
> > tries at test time to reach http://httpbin.org/get
> >  - a service aimed at developing and debugging
> > programs that do HTTP/REST calls.
> [...]
> Please a the "needs-internet" restriction. It's there for this reason.
> Your package seems to have never failed in testing, so, from the Debian
> side of things, it looks you're fine.

[...]
>
> 1) test that require internet to test if certain API's out there work
> are fine *if* annotated with the needs-internet restriction. Personally,
> I consider using on-line frameworks for that acceptable if the effort to
> fake is high (that's often the case for maintainers in downstreams like
> Debian)
> 2) if possible, those tests should be in a separate autopkgtest
> paragraph, such then when needs-internet tests are skipped (e.g. because
> the infra doesn't provide access, like in Ubuntu) the rest of the tests
> are still run.
>

This package doesn't (like most golang-packages) install a
debian/tests/control file,
but instead has a field 'Testsuite: autopkgtest-pkg-go' in debian/control
instead.

How to add the 'needs-internet' restriction to this testsuite?

-- 
regards,
Reinhard

Bug#982786: growlight: autopkgtest regression

I can now reproduce this locally, and expect to have a fix this
evening. I've looked over the rules for the Soft Freeze, and
understand that it'll be acceptable to cut a new upstream
release (I'm the upstream author) with this fix only (there have
been no other changes since this release), upload that to
unstable, and let it proceed (possibly slowly) to testing.

If I instead need to make a debian-specific patch against
1.2.28-1, and release it as 1.2.28-2, that's also fine.

Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures

2021-02-15 Thread Jean-Franois Paris

On Thu, 17 Dec 2020 14:30:56 +0200 George Kadianakis  
wrote:
> Bernhard Übelacker  writes:
> 
> > Hello Peter,
> >
> > Am 16.12.20 um 11:08 schrieb Peter Palfrader:
> >> Hi Bernhard!
> >
> >> Can you try to rebuild tor with __attribute__((aligned(8))) for the
> >> keccak_state as suggested in
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
> >> and then let us know if the issue is still there?
> >> 
> >
> > I rebuilt the tor package with this change [1] below (I hope I
> > placed it correctly).
> >
> > With this I found "disassemble /r keccak_finalize" produces the
> > exact same instructions, but now the pointer given to keccak_finalize
> > seems to be aligned at a 8 byte boundary.
> >
> > Now the strd placed at armv5tel the same sequence as
> > on armv7 to the "a" member [3].
> >
> > And I guess hostname contains now the expected value:
> >
> >  $ cat hs/hostname
> >  upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion
> >
> > Kind regards,
> > Bernhard
> >
> 
> Thanks a lot for the diagnosis and testing, Bernhard and Arnd.
> 
> I submitted a patch for this here:
>   https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/243
> 
> Thanks again!
> 
> 
Hi Peter

Tested the 4.5.5-rc that was uploaded into the buster-backports
All seems to be in working perfectly

Cheers

Bug#982893: ITP: gcc-or1k-elf -- GNU C compiler for the Open RISC 1000 processors

2021-02-15 Thread Nicolas Boulenguez

Package: wnpp
Severity: wishlist
Owner: Nicolas Boulenguez 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gcc-or1k-elf
* URL : https://salsa.debian.org/debian/gcc-or1k-elf
* License : GPL-3+
  Description : GNU C compiler for the Open RISC 1000 processors

 This package provides GNU C compiler for a specific hardware and
 operating system combination.  You don’t need it unless you plan to
 cross-compile programs for it from another operating system.
 .
 This package targets the Open RISC 1000 processors.

The package is native and build-depends on gcc-10-source.
It is a prerequisite for crust-firmware.

Bug#982892: ITP: binutils-or1k-elf -- GNU binary utilities for the Open RISC 1000 processors

2021-02-15 Thread Nicolas Boulenguez

Package: wnpp
Severity: wishlist
Owner: Nicolas Boulenguez 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: binutils-or1k-elf
* URL : https://salsa.debian.org/debian/binutils-or1k-elf
* License : GPL-3+
  Description : GNU binary utilities for the Open RISC 1000 processors

This package provides GNU assembler, linker and binary utilities for
a specific hardware and operating system combination.  You don’t need
it unless you plan to cross-compile programs for it from another
operating system.
.
This package targets the Open RISC 1000 processors.

The package is native and build-depends on gcc-10-source.
It is a prerequisite for gcc-or1k-elf.

Bug#982891: ITP: oauth2-proxy -- A reverse proxy that provides authentication with Google, Github or other providers.

2021-02-15 Thread Daniel Kessler

Package: wnpp
Severity: wishlist
Owner: Daniel Kessler 

* Package name: oauth2-proxy
  Version : 7.0.1-1
  Upstream Author : OAuth2 Proxy
* URL : https://github.com/oauth2-proxy/oauth2-proxy
* License : Expat
  Programming Lang: Go
  Description : A reverse proxy that provides authentication with Google, 
Github or other providers.

 GoDoc (https://godoc.org/github.com/oauth2-proxy/oauth2-proxy)
 .
 A reverse proxy and static file server that provides authentication using
 Providers (Google, GitHub, and others) to validate accounts by email,
 domain or group.

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

2021-02-15 Thread Alexander Pevzner


Hi,

with a help of Michael, I've investigated this problem down to its root 
cause, which appeared to be a misbehabing Avahi daemon.


If in one console the following command is being running:
avahi-publish -s test _test._tcp 0

The following command running in another console prints nothing:
avahi-browse -rt _test._tcp

As I'm not very familiar with Avahi troubleshooting, any help or ideas 
are welcome.


--

Wishes, Alexander Pevzner (p...@apevzner.com)

Bug#982886: php-memcached: Should depend on php-igbinary and php-msgpack

2021-02-15 Thread David Prévot

Control: clone -1
Control: reassign -1 php-redis 5.3.2+4.3.0-2
Control: retitle -1 php-redis: Should depend on php-igbinary

Le Mon, Feb 15, 2021 at 10:32:19PM +0300, Grigory Ivanov a écrit :
> Package: php-memcached
> Version: 3.1.5+2.2.0-5
> Severity: grave
> Justification: renders package unusable
[…]
> Package php-memcached in version 3.1.5+2.2.0-5 no longer depends on php-
> igbinary and php-msgpack, but in fact it does, despite ldd could say.
> Dependencies of previous version, 3.1.4+2.2.0-1+b1, specified in deb
> package, are fine.

Ditto for php-redis and php-igbinary.

Regards

David


signature.asc
Description: PGP signature

Bug#982865: meson: diff for NMU version 0.57.0+really0.56.2-0.1

2021-02-15 Thread Jussi Pakkanen

On Mon, 15 Feb 2021 at 23:21, Sebastian Ramacher  wrote:

> Silently breaking hardening build flags of roughly 430 packages is
> definitely a large and disruptive change.

The rc was uploaded to experimental a week ago so that people could
use it to flush out problems like these. Apparently no-one did. Would
it be possible to set up an automatic gating system of some kind for
build-essential packages so these sort of things will never happen
again in the future?

Bug#982889: dahdi-tools: With #969072 fixed in man-db, the 1:3.1.0-2 workaround can be reverted

2021-02-15 Thread Adrian Bunk

Source: dahdi-tools
Version: 1:3.1.0-2
Severity: normal

#969072 has been fixed in man-db, please revert
the workaround introduced in 1:3.1.0-2.

Bug#982321: cdparanoia: diff for NMU version 3.10.2+debian-13.1

2021-02-15 Thread Sebastian Ramacher

Control: tags 982321 + pending

Dear maintainer,

I've prepared an NMU for cdparanoia (versioned as 3.10.2+debian-13.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru cdparanoia-3.10.2+debian/debian/changelog cdparanoia-3.10.2+debian/debian/changelog
--- cdparanoia-3.10.2+debian/debian/changelog	2018-01-30 06:28:04.0 +0100
+++ cdparanoia-3.10.2+debian/debian/changelog	2021-02-15 22:37:56.0 +0100
@@ -1,3 +1,11 @@
+cdparanoia (3.10.2+debian-13.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/libcdparanoia-dev.install: Do not install unused utils.h (Closes:
+#982321)
+
+ -- Sebastian Ramacher   Mon, 15 Feb 2021 22:37:56 +0100
+
 cdparanoia (3.10.2+debian-13) unstable; urgency=medium
 
   * debian/control: Update Vcs-*.
diff -Nru cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install
--- cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install	2018-01-30 06:28:04.0 +0100
+++ cdparanoia-3.10.2+debian/debian/libcdparanoia-dev.install	2021-02-15 22:37:23.0 +0100
@@ -1,3 +1,3 @@
-/usr/include
+/usr/include/cdda_*
 /usr/lib/*/*.a
 /usr/lib/*/*.so


signature.asc
Description: PGP signature

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

Am Tue, 16 Feb 2021 00:00:47 +0300
schrieb Alexander Pevzner :

> Hi Michael,
>
> On 2/15/21 11:45 PM, mh wrote:
> > Thanks. Let me know any time how I can help.
>
> Thanks for logs. Looks like something goes wrong with Avahi. To
> check, please do the following experiment.
>
> 1. From one console, run: avahi-publish -s test _test._tcp 0
>
> This command should print "Established under name 'test'", and should
> not exit.

That's how it is.

>
> 2. From another console, run: avahi-browse -rt _test._tcp
>
> I want to see output of this command.

No output:
# avahi-browse -rt _test._tcp
~#

>
> And one more question: what Debian version do you use

it is Debian/sid(uction) up to date, booted with

# uname -r
5.10.0-3-amd64

standard Debian Kernel. (this siduction installation was made based on a
siduction live-ISO years ago)

Siduction is pure Debian/sid with some artwork and own kernel (not
booted here).

> and what Avahi
> version do you use?
>

avahi-daemon:
  Installiert:   0.8-5

avahi-utils:
  Installiert:   0.8-5


Thanks

Michael

Bug#982868: dpkg-cross generates erronous conflicts on like libc6-amd64:x32-i386-cross

2021-02-15 Thread Helmut Grohne

Control: tags -1 + patch
Control: severity -1 serious
Control: clone -1 -2
Control: reassign -2 src:cross-toolchain-base

On Mon, Feb 15, 2021 at 06:01:45PM +0100, Julian Andres Klode wrote:
> Package: libc6-amd64-i386-cross
> Conflicts: libc0.1-i386-i386-cross, libc6-amd64:x32-i386-cross,
> 
> The second one is wrong.

Yes, the mangling of arch qualified dependencies is wrong. The cross
suffix is appended to the architecture rather than the package name. I'm
attaching a patch that makes it correctly process arch qualified
dependencies.

> Would be good to get fixed, is RC if those conflicts are really
> needed, but otherwise marking it as important, since not sure.

I concur that it should be fixed for bullseye and thus raise the
severity to serious. Wookey, please downgrade if you disagree.

I'm also cloning a bug for c-t-b as it vendors dpkg-cross including this
bug.

Helmut
diff --minimal -Nru dpkg-cross-2.6.15/debian/changelog 
dpkg-cross-2.6.15/debian/changelog
--- dpkg-cross-2.6.15/debian/changelog  2020-06-22 05:55:01.0 +0200
+++ dpkg-cross-2.6.15/debian/changelog  2021-02-15 17:36:34.0 +0100
@@ -1,3 +1,9 @@
+dpkg-cross (2.6.15-3.2) UNRELEASED; urgency=medium
+
+  * Fix converstion of arch qualified relations. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 15 Feb 2021 17:36:34 +0100
+
 dpkg-cross (2.6.15-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru dpkg-cross-2.6.15/dpkg-cross dpkg-cross-2.6.15/dpkg-cross
--- dpkg-cross-2.6.15/dpkg-cross2020-06-21 21:28:46.0 +0200
+++ dpkg-cross-2.6.15/dpkg-cross2021-02-15 17:36:34.0 +0100
@@ -1358,7 +1358,12 @@
my $name = $1;
return () if grep { $_ eq $name } @removedeps;
return $str if grep { $_ eq $name } @keepdeps;
-   $str =~ s/^([^ (]+)/$name-$arch-cross/;
+   if ($name =~ /^([^:]*):(.*)/) {
+   my $replacement = "$1-$2-cross";
+   $str =~ s/^[^ (]+/$replacement/;
+   } else {
+   $str =~ s/^([^ (]+)/$name-$arch-cross/;
+   }
return $str;
 }

Bug#982887: libruby2.7: separate rbconfig.rb for cross building

2021-02-15 Thread Helmut Grohne

Package: libruby2.7
Version: 2.7.2-4
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:ruby-json

ruby-json (and many others) fail to cross build from source in the same
way. dh_ruby runs ruby ... extconf.rb, which configures for the build
architecture and then some dependency (usually ruby/config.h) goes
missing as it is only installed for the host architecture.

As far as I can tell, the root cause is the extconf.rb invocation. For
cross compiling, one should pass -I /somepath to ruby such that
/somepath contains the host's rbconfig.rb. Unfortunately, we cannot just
pass -I /usr/lib//ruby/2.7.0 here, because doing so results in
ruby attempting to load foreign extension modules. We need a different
path here.

Let me give a little excursion into other ecosystems to give you a
better idea what is needed here:

Perl has a file that is similar to rbconfig.rb and it is simply called
Config.pm. It normally resides in /usr/lib/x86_64-linux-gnu/perl-base.
Using this path would have the same issue. Therefore, there also is
/usr/lib/x86_64-linux-gnu/perl/5.32.1 containing a symlink.

Python has a similar file _sysconfigdata.py. Rather than disambiguating
the containing directory, Python renames it and arrives at things like
_sysconfigdata__x86_64-linux-gnu.py. Rather than specifying a directory
to to search for modules, a separate environment variable can specify
its location.

The Ruby way is like Perl. I suggest copying this approach. To that end,
I request that ruby2.7-dev adds a new, architecture-dependent directory
that contains a symlink to the matching rbconfig.rb. Then dh_ruby can
pass that directory via -I and things should work.

Does that sound good to you? Do you have any preference on the naming?

No, this is not meant for bullseye.

Helmut

Bug#982884: Bug#930005: regina-rexx: rexxutil error

2021-02-15 Thread Agustin Martin

El lun, 15 feb 2021 a las 20:55, Agustin Martin
() escribió:
>
>
> There is a pending thing about multiarch, the handling of
> regina-config is not yet multiarch friendly. An $arch version should
> be installed in an arch dependent dir and /usr/bin/regina-config be
> made a wrapper to it, considering the architecture for which the
> package is built (this is important e.g. when building for amd64/i386
> from the other arch). Once I have something ready I will submit an
> additional patch to this bug report, to be appplied after debhelper
> migration changes.
>

Find attached proposed patch for regina-rexx wrapper under multiarch.

-- 
Agustin
From af56bdfa735531a564be53dd436cd51988d34225 Mon Sep 17 00:00:00 2001
From: Agustin Martin 
Date: Mon, 15 Feb 2021 21:49:26 +0100
Subject: [PATCH] Handle multiarch with regina-config.

regina-config must be *exactly* the same across architectures.
Auto-generated regina-config may have different stuff like
libraries for some co-installable architectures.

Install arch dependent regina-config in libregina3 under arch
specific dir and a regina-config wrapper in libregina3-dev,
which will call arch specific regina-config.

Signed-off-by: Agustin Martin 
---
 debian/libregina3.install |   1 +
 .../2000_regina-config_use-wrapper.diff   |  22 
 debian/patches/series |   1 +
 debian/regina-config  | 112 +-
 4 files changed, 55 insertions(+), 81 deletions(-)
 create mode 100644 debian/patches/2000_regina-config_use-wrapper.diff

diff --git a/debian/libregina3.install b/debian/libregina3.install
index 6a3f187..463c2ef 100644
--- a/debian/libregina3.install
+++ b/debian/libregina3.install
@@ -1,2 +1,3 @@
 usr/lib/*/regina-rexx/*/*
 usr/lib/*/libregina.so.*
+usr/lib/*/regina-rexx/regina-config
diff --git a/debian/patches/2000_regina-config_use-wrapper.diff b/debian/patches/2000_regina-config_use-wrapper.diff
new file mode 100644
index 000..d16d3b7
--- /dev/null
+++ b/debian/patches/2000_regina-config_use-wrapper.diff
@@ -0,0 +1,22 @@
+Index: regina-rexx-debhelper/Makefile.in
+===
+--- regina-rexx-debhelper.orig/Makefile.in	2021-02-15 21:34:08.402245272 +0100
 regina-rexx-debhelper/Makefile.in	2021-02-15 21:34:29.202369805 +0100
+@@ -1206,6 +1206,9 @@
+ 	$(INSTALL) -m 644 -c $(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI) $(libdir)/$(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI)
+ 	$(LN_S) -f $(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI) $(libdir)/$(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI_MAJOR)
+ 	$(INSTALL) -m 644 -c $(SHLPRE)regutil$(MODPST) $(libdir)/regina-rexx/$(ABI)/$(SHLPRE)regutil$(MODPST)
++#	regina-config here is arch dependent.
++	$(INSTALL) -m 755 -d $(libdir)/regina-rexx/
++	$(INSTALL) -m 755 -c ./regina-config $(libdir)/regina-rexx/regina-config
+ 
+ install-dev: $(LIBPRE)$(LIBFILE)$(LIBPST)
+ # header file
+@@ -1216,7 +1219,6 @@
+ # libregina.so.x -> libregina.so
+ 	$(LN_S) -f $(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI) $(libdir)/$(SHLPRE)$(SHLFILE)$(SHLPST)
+ # regina-config
+-	$(INSTALL) -m 755 -c ./regina-config $(prefix)/bin/regina-config
+ 	$(INSTALL) -c -m 644 $(srcdir)/regina-config.1 $(prefix)/share/man/man1/regina-config.1
+ 
+ install-rexx: rexx$(EXE) regina$(EXE)
diff --git a/debian/patches/series b/debian/patches/series
index d6565de..39a24b0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ az-patch-01
 _Makefile.in_set-DESTDIR.diff
 _Makefile.in_libdir.diff
 _Makefile.in_sharedir.diff
+2000_regina-config_use-wrapper.diff
diff --git a/debian/regina-config b/debian/regina-config
index fe95aef..8f0791f 100644
--- a/debian/regina-config
+++ b/debian/regina-config
@@ -1,85 +1,35 @@
 #!/bin/sh
 #
-# The idea to this kind of setup info script was stolen from numerous
-# other packages, such as neon, libxml and gnome.
+# Generic multiarch wrapper for regina-config
 #
-prefix=/usr
-exec_prefix=${prefix}
-includedir=${prefix}/include
-libdir=${exec_prefix}/lib
-
-
-usage()
-{
-echo "Usage: regina-config [OPTION]"
-echo ""
-echo "Available values for OPTION include:"
-echo ""
-echo "  --help display this help and exit"
-echo "  --cflags   pre-processor and compiler flags"
-echo " [-I$includedir]"
-echo "  --multithread  yes; if thread-safe library is available; no otherwise"
-echo " [yes]"
-echo "  --libs library linking information"
-echo " [-lregina]"
-echo "  --libs_ts  library linking information for thread-safe library"
-echo " [-lregina]"
-echo "  --prefix   Regina install prefix"
-echo " [$prefix]"
-echo "  --version  output version information"
-echo " ["3.5"]"
-exit $1
-}
-
-if test $# -eq 0; then
-usage 1
+# This file must be *exactly* the same across architectures.
+# Auto-generated regina-config

Bug#816289: #816289 luit: unable to use advertised conversion charset

2021-02-15 Thread Thomas Dickey

That works with luit 2.0 (which is older than this bug report).
I don't expect that cc'ing Juliusz  Chroboczek as mentioned had much
effect, since he's not been involved with luit for about 15 years.

https://invisible-island.net/luit/luit.html

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


signature.asc
Description: PGP signature

Bug#982842: open-iscsi: do not use iscsistart in the boot process

2021-02-15 Thread Lee Duncan

On 2/15/21 6:48 AM, Ritesh Raj Sarraf wrote:
> Control: tag -1 +help
> 
> On Mon, 2021-02-15 at 09:46 +0100, Heinrich Schuchardt wrote:
>> An upstream maintainer suggested that Debian should not use
>> iscsistart
>> for booting from an iSCSI volume but instead include iscsid and
>> iscsiadm
>> in the initrd. The same is already done in SUSE.
>>
>> Please, consider such a change for Debian Bookworm.
> 
> Yes. But usually, you don't need the iscsid daemon in initrd. Because
> most usual cases, users would be mapping data LUNs only.
> 
> Only in exceptional cases, where you have root on iSCSI, you need to
> establish the connections early. And to do that we used iscsistart,
> which would establish only a single connection, effectively making it
> prone to hangs if that single connection went down.
> 
> But the time from when iscsistart establishes the connection and
> fetched the root LUN, to the time when real init starts and the actual
> iscsid daemon is run, is not a very large time. That has been the
> assumption so far and the integration was built accordingly.
> 
> The other reason I can recollect is that you could have a very large
> number of LUNs mapped to your initiator along with your root LUN. If
> you push everything to be processed in initrd:
> 
> 1. The boot would be much slower, depending on how many LUNs are mapped
> 2. I don't know how the initiator would behave if some of the LUNs,
> from some of the targets, are temporarily unavailable.
> 
> These days, I only work on storage as a hobby. So this feature should
> be better and early co-ordinated, by users and derivatives that want to
> see it follow the path. And we could definitely leverage on what Suse
> has already done.
> 

I cannot access this bug, so I will reply to all here ...

In general, you do not set up initrd to boot into all iSCSI targets,
only the ones with "startup" set to "onboot". Then, later, as part of
the system coming up, once the real root is established and networking
is up, do you log into all "automatic" targets using open-iscsi.

So the idea isn't to log into all targets at initrd time, just the same
ones you log into now (i.e. "onboot" targets, needed to boot) using
iscsid/iscsiadm instead of iscsistart. Note that SUSE only supports the
root and /usr partitions being remote at boot time. If you have
something like /opt you want to mount, it has to be done later (in our
systems).

I hope this clarification helps.

Bug#982678: systemd: journalctl does not repect SYSTEMD_COLORS=0 - colors are still shown

2021-02-15 Thread Brian Potkin

On Sat 13 Feb 2021 at 15:43:12 +0200, Jari Aalto wrote:

> It's Debian mainter's job to forward bugs to upstream.

If there are jobs to apportion out, yours is to assist a
maintainer, especially one as assiduous in their *volunteer*
work as Michael Biebl, in every possible way.

So - get on with it. Push the issue upstream. You'll feel
better for it and be awarded points :).

-- 
Brian.

Bug#982612: marked as done (python3-patsy: DeprecationWarning: collections -> collections.abc)

close #982612

On Mon, Feb 15, 2021 at 7:06 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Mon, 15 Feb 2021 19:03:30 +
> with message-id 
> and subject line Bug#982612: fixed in patsy 0.5.1-3
> has caused the Debian Bug report #982612,
> regarding python3-patsy: DeprecationWarning: collections -> collections.abc
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 982612: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982612
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Julian Gilbey 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 12 Feb 2021 14:14:47 +
> Subject: python3-patsy: DeprecationWarning: collections -> collections.abc
> Package: python3-patsy
> Version: 0.5.1-2
> Severity: normal
>
> While running a test on another package that uses patsy, I received
> the following DeprecationWarning:
>
> /usr/lib/python3/dist-packages/patsy/constraint.py:13: DeprecationWarning:
> Using or importing the ABCs from 'collections' instead of from
> 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop
> working
>
> Should be very easy to fix!
>
> Best wishes,
>
>Julian
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 982612-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 15 Feb 2021 19:03:30 +
> Subject: Bug#982612: fixed in patsy 0.5.1-3
> Source: patsy
> Source-Version: 0.5.1-3
> Done: Nilesh Patra 
>
> We believe that the bug you reported is fixed in the latest version of
> patsy, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 982...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Nilesh Patra  (supplier of updated patsy package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Tue, 16 Feb 2021 00:02:49 +0530
> Source: patsy
> Architecture: source
> Version: 0.5.1-3
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Med Packaging Team <
> debian-med-packag...@lists.alioth.debian.org>
> Changed-By: Nilesh Patra 
> Closes: 982612
> Changes:
>  patsy (0.5.1-3) unstable; urgency=medium
>  .
>* Use collections.abc to remove deprecation warning
>  (Closes: #982612)
>* Add myself to uploaders
>* Declare compliance with policy 4.5.1
>* Bump watch version to 4
> Checksums-Sha1:
>  1a6e0fd52a003662dc4edf46829c60b576879a87 2328 patsy_0.5.1-3.dsc
>  6ee70bff338e4103e8045f4091fe6b1200331e2f 9856 patsy_0.5.1-3.debian.tar.xz
>  14c4a5e3d0395a5fc4960e87e02afe5f8cde8f90 8702
> patsy_0.5.1-3_amd64.buildinfo
> Checksums-Sha256:
>  1ae8737f1caca9f64afed8b26ab7aceb5d39895f6300ff2102601a111d77e42f 2328
> patsy_0.5.1-3.dsc
>  150d2dcd349ef26f21bcdb17b53906ad245ad862805cdd8b83c2c37ecc988cad 9856
> patsy_0.5.1-3.debian.tar.xz
>  e6ca4a95062718666519970cdcc0b4188d4a615f74610be58e9dd6128e6da02e 8702
> patsy_0.5.1-3_amd64.buildinfo
> Files:
>  b340ee32de8beacbccb2c4cb1a5e00ff 2328 python optional patsy_0.5.1-3.dsc
>  c5826ab707dcd8b9680419d18f77c9d4 9856 python optional
> patsy_0.5.1-3.debian.tar.xz
>  eb16248ef5bd1f836b5bd2b7c9581e02 8702 python optional
> patsy_0.5.1-3_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQJIBAEBCgAyFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmAqwH0UHG5wYXRyYTk3
> NEBnbWFpbC5jb20ACgkQALrnSzQzafFcfRAAp7bUDpQbEYhK6sQaJuaD+RhtX/Oh
> S2kmDZsEMzYkFjA57i0gIUXiKM/zSYgpFmFLXyMhxsNBpLh3EmQ7TU1dhqqNaJjJ
> ozlLigKAmsyg+FqYcF9xnAOJ/zLDZfHrnXW+/zJ73xgIBRy4tq4cbaQWiI07zEMB
> fzITqpe7ixKXO8twkQJ+FAgF6IJ5qEyn9imgOEAanf0An9j5BTS8XNjqq1KDwVX+
> P6yqGyU9UUGgwjigSQNkljbUQ79dGVeYSyWrOjJKTEgGO2E6uWrPgXAT5XByvgUY
> xOV8Kh1+9D2ui2n7tL8GOuJdKFBd4i+MbUL2/JoBzf/k6g9MFgqSdI/tllGhN4DV
> Jouw8oYwK8BIow6vFBZiP3MxqSHPgG+72+NStJMcn+ZNQ6C2fXNs3gbrwXMKTb8Q
> T97lhArWCNHMDeJp+qXgs8WyWu7e4r7/7+0K0XmLrZjztspmuivgoMqo1RQ7aBez
> Ao+wR6lin6qwxCW+WMTpPLpFOxd65FD8r68aZMdaSKorWDK5y80KtoA25AACuky9
> 9eZY0qoK/PdkAkdi4grcZjX3f1hwv2OjwSnXBzJlFaZTZwgB/MhXY8gRx/jYLL6w
> dRBTcWikrXef1/jIN7I+3SR0k2IM50m1RHUQ32HnR+6cwxMy+4HiO3pLvE0x51dV
> 1gVVNkO/re/1+I8=
> =wfnK
> -END PGP SIGNATURE-

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

2021-02-15 Thread Brian Potkin

On Mon 15 Feb 2021 at 19:36:29 +0100, mh wrote:

> Am Mon, 15 Feb 2021 15:12:49 +
> schrieb Brian Potkin :
> 
> Only for curiosity:
> On systems where there is NO problem, why do I see one printer in cups
> config (network printer) resulting in two printers in the printing menu?

Possibly because one is a manual queue and one a cups-browsed queue.

  https://wiki.debian.org/CUPSDriverlessPrinting#dups

Follow our wiki advice or purge cups-browsed.
 
> > This is the concerning part. Why do some commands like ippfind,
> > lpstat -e and avahi-browse give empty outputs on Debian unstable? Are
> > the Debian and Live ISO versions of ipp-usb the same?
> 
> It is all Debian/unstable. And it does not depend on the version of
> ipp-usb ( 0.9.16-1  and 0.9.17-1 ). Both work on live-iso (from
> 2021.02, the 2020.07 version didn't ship ipp-usb ) or new installation
> (2021.02 dist-upgraded), neither work with my old installation. I know
> this for a fact because the problem persist longer than 0.9.17-1 exists.
> 
> I can live without ipp-usb working on this installation. But if someone
> tells me how to investigate the flaw, I am happy to investigate, too.

I have asked for a little bit of information about lpstat in another
post. Maybe the ipp-usb logs Alex requested logs may help. Otherwise,
I am at a loss to suggest a good debugging technique.

Awaiting inspiration!

Brian.

Bug#981492: linux-source-5.10: Module-only builds failing since 39a8b293

2021-02-15 Thread Robert Schlabbach

Hello 小太,

just to let you know that your bug report was useful anyway:

I ran into the same issue, and needed the same fix. In fact, my build script had
the "make modules_prepare" commented out, with a "# TODO: is this needed?" 
comment
above. Apparently, it wasn't needed until Linux 5.10.

So thank you very much for posting this bug and the solution, and including the
full error message in the description - that led me to this bug report, and 
saved
me hours of hunting down the issue.

Best Regards,
-Robert

On Mon, 15 Feb 2021 22:39:36 +1100 =?UTF-8?B?4oCN5bCP5aSq?=  
wrote:
> Apologies - I jumped to conclusions in my original bug report
> 
> After applying your patch and seeing it did not fix the issue, I did a bit
> of investigation myself.
> It turns out the problem wasn't in the linked commit, but actually part of
> the upstream kernel:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.11=596b0474d3d9b1242eab713f84d8873f9887d980
> 
> The real problem isn't in the code however, but in my Makefile.
> I didn't run the "modules_prepare" target before trying to build a module,
> despite it being documented:
> https://www.kernel.org/doc/Documentation/kbuild/modules.txt
> 
> Adding that target to my Makefile resolved the issue, without any changes
> to the linux-source package.
> So this bug is now invalid

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

Am Mon, 15 Feb 2021 18:57:44 +
schrieb Brian Potkin :

> ...
> siduction is based on Debian unstable, so, if (A) and (B) are fully
> uo to date, the printing systems should be identical. You have shown
> that ipp-usb works fine on the siduction installation. That is what
> (to me at least) is so puzzling.

The same goes for me. That's the situation which drove me crazy the
last year. I was about to buy a new printer ... until, as a
last-ditch attempt I wrote this bug report. So thanks again.
> 
> I realise you are now happy with your printing situation, so thanks
> for continuing to engage with this ipp-usb issue.

Sure. See above ;-)
But the thing that makes me hesitant is the following: I migrated his
installation multiple times from one partition and disk to another. And
it once had serious systemd problems during a dist-upgrade due to the
drive giving up slowly. I could
repair/overwrite/reinstall/whatever-one-would-call-it this installtion
years ago. And it worked since. But I can't exclude there's a sutble
flaw hidden in some corner.
On the bright side: The printer worked the first years.

> ...
> > (B) There is a flaw somewhere within this installation which
> > *affects* ipp-usb without ipp-usb neccessarily being the cause.  
> 
> A fair assessment.

> ... 

> > The same on the problematic installation (B) with ipp-usb
> > reinstalled and rebooted:
> > 
> > $  lp -d OKI_B432_010E46_USB_ ~/.bashrc
> > lp: Error - The printer or class does not exist.
> > 
> > ~$ lp -d OKI_DATA_CORP_B432 ~/.bashrc
> > Anfrage-ID ist OKI_DATA_CORP_B432-5 (1 Datei(en))
> > 
> > but NO print. And in the cups joblist the same long known error:
> > 
> > "Warte darauf dass der Drucker verfügbar wird."
> > Waiting for the printer to become available
> > 
> > And the printer's little LCD is showing: Ready to print.
> > 
> > And the moment I purge ipp-usb again, the printer starts to
> > print without the job being sent again.  
> 
> Just to clear up something: would you stop ipp-usb on (B):
> 
>   systemctl stop ipp-usb
> 
> Do you get an output from 'lpstat -l -e'?

# systemctl stop ipp-usb
~#

# lpstat -l -e
OKI_DATA_CORP_B432 permanent
ipp://localhost/printers/OKI_DATA_CORP_B432
usb://OKI%20DATA%20CORP/B432?serial=AK76039718


> ...

> The file I downloaded has the PPDs under the General Public License.

Didn't know PPD is text. You are right. That's in contrast to what the
linked document on the website says. All the better. I updated my
wishlist bug accordingly.

> 
> Cheers,
> 
> Brian.


Thanks

Michael

Bug#980211: libextractor: FTBFS (flaky tests)

2021-02-15 Thread John Scott

On Wed, 10 Feb 2021 21:02:47 +0100 Bertrand Marc 
wrote:
> Indeed, the original issue reported in this bug was fixed in 1.11-1.
> However, the general issue of flaky tests is still there: 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libextractor.html
> 
> Would you consider this bug as fixed?

I hadn't seen the failure at reproducible builds; indeed that's not
looking good.

I've built libextractor about a dozen times and can't reproduce the
test_html failure. Perhaps it happens so seldom that it won't happen on
a buildd, or is specific to the Reproducible Builds environment.

I personally regard the issue fixed, since the original issue was
mitigated and the test_html failure seems to be within other margins of
failure. Usually a second build is tried before an FTBFS bug is
warranted, and none of the applicable dependencies have had any change.

Note that the bug submitter was not filing a conventional FTBFS on
behalf of QA or the Release Team, but instead was concerned with the
librpm9 transition.

Let me know if there's anything particular I can do to help, and thanks
for your careful maintainership.

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

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

Am Mon, 15 Feb 2021 15:12:49 +
schrieb Brian Potkin :

> On Mon 15 Feb 2021 at 14:27:59 +0100, mh wrote:
>
> > Am Mon, 15 Feb 2021 10:26:52 +
> > schrieb Brian Potkin :
> >
> > > On Sun 14 Feb 2021 at 20:31:28 +0100, mh wrote:
> > >
> > > [...]
> > >
> > > > # ippfind -T 5
> > > > ~#
> > >
> > > An IPP printer is not found. This would fit the observation that
> > > cups-browsed has not set up a print queue. I have come to the
> > > conclusion that the B432 does not implement IPP-over-USB
> > > correctly.
> >
> > First: Thanks for your help and for all your efforts. But further
> > investigation and tests based on the new knowledge provided by you
> > lets me come to a different conclusion (see below). I didn't know
> > about ipp-usb, how it works and what it does and it automagically
> > being configured.
>
> I've tried to help with understanding by quoting a wiki link.

Yes. Thanks for that. I only wanted to point out I wasn't aware of
what actually happens during cups config. I have a better
understanding.

>
> > > A queue set up with a vendor PPD will not function while ipp-usb
> > > is active,

Only for curiosity:
On systems where there is NO problem, why do I see one printer in cups
config (network printer) resulting in two printers in the printing menu?

> so purge it and proceed as you did with the Live ISO.
> > > Also see #982190:
> > >
> > >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982190
> > >
> > > Cheers,
> > >
> > > Brian.
> >
> > Purging ipp-usb instantly made the cups webinterface showing my
> > printer. So I could configure it using the vendor PPD file. Printing
> > menue (Libreoffice) shows one OKI printer. Print succeeded.
> > Thanks.
>
> The printer would have shown under Local Printers. With ipp-usb
> active it shows under Discovered Network Printers. This is because
> IPP-over-USB effectively treats the printer as a network connected
> device, not a USB connected device.
>
>   https://wiki.debian.org/SystemPrinting#The_CUPS_Web_Interface
>
> > So the main issue is solved as I can print from within my
> > default system. From what I've seen during configuration and
> > printing, the printer setup seems stabel, the printer showed up
> > immediately, the print job is carried out without much delay.
>
> Good.

> ...

>
> > I then investigated the LIVE-ISO. To my surprise ipp-usb is
> > installed within the LIVE-ISO. All the commands which failed/did
> > have an empty output on my default system work here with the
> > expected output (I guess), except for # avahi-browse -rt _ipp._tcp
> > due to avahi-browse not being installed:
>
> This is the concerning part. Why do some commands like ippfind,
> lpstat -e and avahi-browse give empty outputs on Debian unstable? Are
> the Debian and Live ISO versions of ipp-usb the same?

It is all Debian/unstable. And it does not depend on the version of
ipp-usb ( 0.9.16-1  and 0.9.17-1 ). Both work on live-iso (from
2021.02, the 2020.07 version didn't ship ipp-usb ) or new installation
(2021.02 dist-upgraded), neither work with my old installation. I know
this for a fact because the problem persist longer than 0.9.17-1 exists.

I can live without ipp-usb working on this installation. But if someone
tells me how to investigate the flaw, I am happy to investigate, too.


> ...

> You would submit a wishlist bug against printer-driver-oki.

I will.

>
> Thank you for your detailed report.
>
> Brian.

Thank you for all your help.

Michael

Bug#982886: php-memcached: Should depend on php-igbinary and php-msgpack

2021-02-15 Thread Grigory Ivanov

Package: php-memcached
Version: 3.1.5+2.2.0-5
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: grun...@ololo.cc

Dear Maintainer,

Package php-memcached in version 3.1.5+2.2.0-5 no longer depends on php-
igbinary and php-msgpack, but in fact it does, despite ldd could say.
Dependencies of previous version, 3.1.4+2.2.0-1+b1, specified in deb
package, are fine.

If one tries to load this module without that dependands, it would lead
to following errors:

PHP Warning:  PHP Startup: Unable to load dynamic library 'memcached.so'
(tried: /usr/lib/php/20190902/memcached.so
(/usr/lib/php/20190902/memcached.so:
undefined symbol: php_msgpack_serialize),
/usr/lib/php/20190902/memcached.so.so
(/usr/lib/php/20190902/memcached.so.so: cannot open shared object file:
No such file or directory)) in Unknown on line 0

in case of php-msgpack absence, and

PHP Warning:  PHP Startup: Unable to load dynamic library 'memcached.so'
(tried: /usr/lib/php/20190902/memcached.so
(/usr/lib/php/20190902/memcached.so:
undefined symbol: igbinary_serialize), /usr/lib/php/20190902/memcached.so.so
(/usr/lib/php/20190902/memcached.so.so: cannot open shared object file:
No such file or directory)) in Unknown on line 0

in case of php-igbinary absence.

So this module would not load and would not be available for PHP.

If one installs such dependencies manually, module would work fine.

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

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

Versions of packages php-memcached depends on:
ii  libapache2-mod-php7.4 [phpapi-20190902]  7.4.15-3
ii  libc62.31-9
ii  libmemcached11   1.0.18-4.2
ii  libsasl2-2   2.1.27+dfsg-2.1
hi  php-common   2:76
ii  php7.4-cli [phpapi-20190902] 7.4.15-3
ii  ucf  3.0043
ii  zlib1g   1:1.2.11.dfsg-2

php-memcached recommends no packages.

php-memcached suggests no packages.

Bug#982885: apt: refuses to update, citing certificate that won't be valid for several hours

2021-02-15 Thread allen

Package: apt
Version: 2.1.15
Severity: important
X-Debbugs-Cc: phuckthis...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? I am pretty sure that I have a hacker on our
network
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I have tried to change the configurations based on what I
have found online and have been unable to.
   * What was the outcome of this action? nothing has happened
   * What outcome did you expect instead? I would  like someone to help me
figure out what I can't get this a-hole off my network



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-.*-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-.*-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-13-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.9\.0-kali5-amd64$";
APT::NeverAutoRemove:: "^postgresql.*-13";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w 
/var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then 
/usr/lib/cnf-update-db > /dev/null; fi";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";

Bug#982122: redis: experimental package OOMs s390x buildds

2021-02-15 Thread Adam D. Barratt

Hi Chris,

On Mon, 2021-02-15 at 18:28 +, Chris Lamb wrote:
> Ah, indeed, the failure mode means that the log never made it to
> > buildd.d.o.
> 
> Curious, not heard of that failure mode — is there someplace I can
> learn about that? No worries if not.

I'm not sure if it's documented, but in this case I think enough of the
system was unresponsive or killed to make the connection back to
buildd.d.o fail.

> > I've attached a copy of the log from zani.
> 
> Ah, thanks. Unfortunately, it does not point us straight to the
> solution. I note that you titled this bug "package OOMs" — I point
> this out because the "OOM" text the log is actually the name of the
> test. As in, here is tests/integration/corrupt-dump.tcl:
> 
[...]
> Do we have confirmation somewhere that the build is actually OOMing,
> rather than it just timing out on a test that was designed to test
> *for* an OOM condition. This OOM-related bug *should* be fixed by
> virtue of them adding the test to begin with (!) but if we can show
> that it is still OOMing, I suspect that upstream will be able to
> address it quickly.

I don't know how much context would be needed, but the machine
definitely OOMed:

Feb  3 20:45:22 zani/zani kernel: redis-server invoked oom-killer: 
gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0
Feb  3 20:45:22 zani/zani kernel: redis-server cpuset=/ mems_allowed=0
Feb  3 20:45:22 zani/zani kernel: CPU: 0 PID: 45952 Comm: redis-server Not 
tainted 4.19.0-14-s390x #1 Debian 4.19.171-2
Feb  3 20:45:22 zani/zani kernel: Hardware name: IBM 8561 LT1 400 (z/VM 7.1.0)
Feb  3 20:45:22 zani/zani kernel: Call Trace:
Feb  3 20:45:22 zani/zani kernel: ([<00113f2a>] show_stack+0x5a/0x78)
Feb  3 20:45:22 zani/zani kernel:  [<00802d1a>] dump_stack+0x8a/0xb8 
Feb  3 20:45:22 zani/zani kernel:  [<00800962>] dump_header+0x82/0x2c0 
Feb  3 20:45:22 zani/zani kernel:  [<002b46fe>] 
oom_kill_process+0xde/0x380 
Feb  3 20:45:22 zani/zani kernel:  [<002b550c>] 
out_of_memory+0x24c/0x3b8 
Feb  3 21:07:50 zani/zani kernel:  [<002bd032>] 
__alloc_pages_nodemask+0x10b2/0x1160 
Feb  3 21:07:50 zani/zani kernel:  [<0012b0c6>] 
page_table_alloc+0x15e/0x2c8 
Feb  3 21:07:50 zani/zani kernel:  [<002f8b76>] __pte_alloc+0x2e/0xf8 
Feb  3 21:07:50 zani/zani kernel:  [<002ff258>] 
__handle_mm_fault+0xfc0/0x11c0 
Feb  3 21:07:50 zani/zani kernel:  [<002ff584>] 
handle_mm_fault+0x12c/0x298 
Feb  3 21:07:50 zani/zani kernel:  [<00123a12>] 
do_dat_exception+0x182/0x440 
Feb  3 21:07:50 zani/zani kernel:  [<0080d9d4>] 
pgm_check_handler+0x190/0x1e4 
...
Feb  3 21:07:50 zani/zani kernel: sshd invoked oom-killer: 
gfp_mask=0x7080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null), order=2, 
oom_score_adj=-1000
Feb  3 21:07:50 zani/zani kernel: sshd cpuset=/ mems_allowed=0
Feb  3 21:07:50 zani/zani kernel: CPU: 0 PID: 1463 Comm: sshd Not tainted 
4.19.0-14-s390x #1 Debian 4.19.171-2
Feb  3 21:07:50 zani/zani kernel: Hardware name: IBM 8561 LT1 400 (z/VM 7.1.0)
Feb  3 21:07:50 zani/zani kernel: Call Trace:
Feb  3 21:07:50 zani/zani kernel: ([<00113f2a>] show_stack+0x5a/0x78)
Feb  3 21:07:50 zani/zani kernel:  [<00802d1a>] dump_stack+0x8a/0xb8 
Feb  3 21:07:50 zani/zani kernel:  [<00800962>] dump_header+0x82/0x2c0 
Feb  3 21:07:50 zani/zani kernel:  [<002b46fe>] 
oom_kill_process+0xde/0x380 
Feb  3 21:07:50 zani/zani kernel:  [<002b550c>] 
out_of_memory+0x24c/0x3b8 
Feb  3 21:07:50 zani/zani kernel:  [<002bd032>] 
__alloc_pages_nodemask+0x10b2/0x1160 
Feb  3 21:07:50 zani/zani kernel:  [<0013e414>] 
copy_process.part.4+0x24c/0x1fb0 
Feb  3 21:07:50 zani/zani kernel:  [<00140550>] _do_fork+0xf0/0x430 
Feb  3 21:07:50 zani/zani kernel:  [<001409ce>] sys_clone+0x3e/0x50 
Feb  3 21:07:50 zani/zani kernel:  [<0080d630>] system_call+0xd8/0x2bc 
...
Feb  3 21:07:50 zani/zani kernel: oom_reaper: reaped process 45952 
(redis-server), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
...
Feb  3 21:07:50 zani/zani kernel: sshd invoked oom-killer: 
gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, 
oom_score_adj=0
...
Feb  3 21:07:50 zani/zani kernel: munin-node invoked oom-killer: 
gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, 
oom_score_adj=0
...
Feb  3 21:07:50 zani/zani kernel: oom_reaper: reaped process 36654 (schroot), 
now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
...
Feb  3 21:07:50 zani/zani kernel: oom_reaper: reaped process 34994 (sbuild), 
now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
...
Feb  3 21:07:50 zani/zani kernel: oom_reaper: reaped process 1508 (syslog-ng), 
now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
...
Feb  3 21:07:50 zani/zani kernel: oom_reaper: reaped process 1863 (samhain), 
now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
...
Feb  3 21:07:50 zani/zani kernel: dpkg-buildpackage invoked oom-killer:

Bug#982871: lintian-brush: Should not set "Testsuite: autopkgtest-pkg-perl" if debian/tests/control is present

2021-02-15 Thread gregor herrmann

On Mon, 15 Feb 2021 20:29:51 +0100, Axel Beckert wrote:

> Jelmer Vernooĳ wrote:
> > > So please stop adding "Testsuite:" headers if debian/tests/control is
> > > already present.
> > > 
> > > Luckily the testsuite declared in debian/tests/control was still run, so
> > > it didn't completely break autopkgtest for this package, but at least
> > > caused unnecessary tests being tried to run, but then skipped.
> > Thanks for the bug report.
> > 
> > It looks like this is also a bug in lintian, since it reports
> > team/pkg-perl/testsuite/no-team-tests for equivs:
> > 
> > https://lintian.debian.org/tags/team/pkg-perl/testsuite/no-team-tests.html
> 
> Hmmm, I have recently worked on debsums (similar case of a native
> pkg-perl-team package which also has a debian/tests/control file) and
> I can't remember having seen that warning. Then again I had the
> feeling that the lintian tags on the web are often outdated.
> 
> Just checked: Yeah, it's overridden there. (Overridden by myself in
> 2015. :-)

Heh :)

I think that's a know, hm, behaviour lintian. I thought there even
was a bug report about it but I can't find it right now.
 
> Will file a bug report against lintian, too. Thanks for these hints!

Cool, thanks.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Featuring The Dubliners, The Fureys And Davey Arthur Etc.: Dublin 
Town, Brendan Grace


signature.asc
Description: Digital Signature

Bug#982124: New upstream version 3.38.1 - Please package

2021-02-15 Thread Marc Meledandri

Upgrading the severity to important as note-sorting functionality is
intrinsic to the usability of gnote.

This is broken in bullseye. I verified version 3.38.1 fixes the
ability to sort notes on my Arch box.

Thanks!

Bug#982883: report when fixes were skipped because of overrides

2021-02-15 Thread Jelmer Vernooij

Package: lintian-brush
Version: 0.95
Severity: wishlist

lintian-brush should mention the number of skipped fixes due to overrides in 
its output,
rather than silently skipping them and pretending there was nothing that could 
be fixed.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.5
ii  ognibuild0.0.1~git20201031.4cbc8df-1.1
ii  python3  3.9.1-1
ii  python3-breezy   3.1.0-8
ii  python3-debian   0.1.39
ii  python3-debmutate0.20
ii  python3-distro-info  1.0
ii  python3-dulwich  0.20.15-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.12-2
ii  python3-upstream-ontologist  0.1.9-1

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.27-1
ii  libdebhelper-perl13.3.3
ii  lintian  2.104.0
ii  python3-asyncpg  0.21.0-1+b2
ii  python3-bs4  4.9.3-1
ii  python3-levenshtein  0.12.2-1
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
pn  breezy-debian  
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
ii  postgresql-common  225

-- no debconf information

Bug#967340: firefox: depends on deprecated GTK 2

2021-02-15 Thread Andres Salomon

Firefox 85 dropped support for flash, so this gtk2 dependency can
probably be dropped now.

Bug#930005: regina-rexx: rexxutil error

2021-02-15 Thread Agustin Martin

Package: regina-rexx
Version: 3.6-2.2
Severity: wishlist

El lun, 15 feb 2021 a las 13:40, Alen Zekulic () escribió:
>
> On Mon, Feb 15, 2021 at 13:16:58 +0100, Agustin Martin wrote:
>
> > I think I have something close to be ready for migration to debhelper.
>
> Me too. :)
>
> > ¿What do you prefer, a commit to salsa or a patch in the BTS?
>
> For now I prefer a patch in the BTS.

FIne, Alen,

I am filing a new bug report about this with wishlist severity, and
attaching a git patch with my changes. This is only about migration to
old-style debhelper from 3.5-2.2. It includes the migration itself and
making most of the package multiarch ready. As a bonus this fixes the
timestamp issues in #854294.

There is a pending thing about multiarch, the handling of
regina-config is not yet multiarch friendly. An $arch version should
be installed in an arch dependent dir and /usr/bin/regina-config be
made a wrapper to it, considering the architecture for which the
package is built (this is important e.g. when building for amd64/i386
from the other arch). Once I have something ready I will submit an
additional patch to this bug report, to be appplied after debhelper
migration changes.

Regards,

-- 
Agustin
From 389c9685789a9799477c09285c378b784f87bd51 Mon Sep 17 00:00:00 2001
From: Agustin Martin 
Date: Mon, 15 Feb 2021 20:29:39 +0100
Subject: [PATCH] Migrate to old-style debhelper from regina-rexx 3.6-2.2

* Migration to old-style debhelper. This also includes:
  - Make package multiarch.
  - Fix the timestamp issues in #854294.
* Remove autotools-dev Build-Dep, it is pulled by debhelper.

Signed-off-by: Agustin Martin 
---
 debian/control|  20 +-
 debian/libregina3-dev.install |   5 +
 debian/libregina3-dev.manpages|   1 +
 debian/libregina3.install |   2 +
 debian/md5_sums   |  19 --
 debian/patches/_Makefile.in_libdir.diff   |  32 +++
 .../patches/_Makefile.in_set-DESTDIR.diff |  17 ++
 debian/patches/_Makefile.in_sharedir.diff |  25 +++
 debian/patches/az-patch-01|  18 --
 debian/patches/series |   4 +
 debian/postinst   |   8 -
 debian/postrm |   8 -
 debian/postrm-dev |   8 -
 debian/regina-rexx.examples   |   2 +
 debian/regina-rexx.install|   5 +
 debian/regina-rexx.links  |   1 +
 debian/regina-rexx.manpages   |   3 +
 debian/rules  | 190 +++---
 18 files changed, 186 insertions(+), 182 deletions(-)
 create mode 100644 debian/libregina3-dev.install
 create mode 100644 debian/libregina3-dev.manpages
 create mode 100644 debian/libregina3.install
 delete mode 100644 debian/md5_sums
 create mode 100644 debian/patches/_Makefile.in_libdir.diff
 create mode 100644 debian/patches/_Makefile.in_set-DESTDIR.diff
 create mode 100644 debian/patches/_Makefile.in_sharedir.diff
 delete mode 100644 debian/postinst
 delete mode 100644 debian/postrm
 delete mode 100644 debian/postrm-dev
 create mode 100644 debian/regina-rexx.examples
 create mode 100644 debian/regina-rexx.install
 create mode 100644 debian/regina-rexx.links
 create mode 100644 debian/regina-rexx.manpages

diff --git a/debian/control b/debian/control
index 0413a05..bc66464 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,8 @@ Source: regina-rexx
 Section: libs
 Priority: optional
 Maintainer: Alen Zekulic 
-Build-Depends: libncurses5-dev, autotools-dev
+Build-Depends: libncurses5-dev,
+	   debhelper-compat (=12)
 Standards-Version: 4.4.1
 Homepage: http://regina-rexx.sourceforge.net/
 Vcs-Git: https://salsa.debian.org/debian/regina-rexx.git
@@ -10,7 +11,8 @@ Vcs-Browser: https://salsa.debian.org/debian/regina-rexx
 
 Package: libregina3
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends},
+	 ${misc:Depends} 
 Conflicts: regina3
 Replaces: regina3
 Description: Regina REXX interpreter, run-time library
@@ -25,9 +27,14 @@ Description: Regina REXX interpreter, run-time library
 Package: libregina3-dev
 Section: libdevel
 Architecture: any
-Depends: ${regver:Depends}, libc6-dev, cpp
-Conflicts: regina2-dev, regina3-dev
-Replaces: regina2-dev, regina3-dev
+Depends: ${misc:Depends},
+	 libregina3 (= ${binary:Version}),
+	 libc6-dev,
+	 cpp
+Conflicts: regina2-dev,
+	   regina3-dev
+Replaces: regina2-dev,
+	  regina3-dev
 Description: Regina REXX interpreter, development files
  Regina is an ANSI compliant REXX interpreter for multiple platforms.
  .
@@ -41,7 +48,8 @@ Description: Regina REXX interpreter, development files
 Package: regina-rexx
 Section: interpreters
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends},
+	 ${misc:Depends} 
 Description: Regina REXX interpreter
  Regina is an ANSI compliant REXX interpreter for

Bug#982882: stellarium FTBFS on armel and mipsel

2021-02-15 Thread Paul Gevers

Source: stellarium
Version: 0.20.4-1
Severity: serious
Tags: ftbfs

Hi Maintainer,

Your last upload FTBFS on mipsel and armel.

Paul

https://buildd.debian.org/status/package.php?p=stellarium

make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi'
[ 24%] Built target translations-stellarium
[ 24%] Generating ../../translations/stellarium-skycultures/zh_CN.qm
cd /<>/obj-arm-linux-gnueabi/po/stellarium-skycultures &&
/usr/lib/qt5/bin/lconvert -i
/<>/po/stellarium-skycultures/zh_CN.po -o
/<>/obj-arm-linux-gnueabi/translations/stellarium-skycultures/zh_CN.qm
[ 24%] Generating ../../translations/stellarium-skycultures/zh_HK.qm
cd /<>/obj-arm-linux-gnueabi/po/stellarium-skycultures &&
/usr/lib/qt5/bin/lconvert -i
/<>/po/stellarium-skycultures/zh_HK.po -o
/<>/obj-arm-linux-gnueabi/translations/stellarium-skycultures/zh_HK.qm
[ 24%] Generating ../../translations/stellarium-skycultures/zh_TW.qm
cd /<>/obj-arm-linux-gnueabi/po/stellarium-skycultures &&
/usr/lib/qt5/bin/lconvert -i
/<>/po/stellarium-skycultures/zh_TW.po -o
/<>/obj-arm-linux-gnueabi/translations/stellarium-skycultures/zh_TW.qm
make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi'
[ 24%] Built target translations-stellarium-skycultures
make[2]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[1]: *** [Makefile:174: all] Error 2
make[1]: Leaving directory '/<>/obj-arm-linux-gnueabi'
dh_auto_build: error: cd obj-arm-linux-gnueabi && make -j4
"INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:7: build-arch] Error 25



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977410: Acknowledgement (rmlint: shell script ignores recheck (-p) result)

2021-02-15 Thread benjamin . kaestner


Hi,

is there anything missing for the patch to be merged? The current source 
in sid/bullseye is also affected.


I'm more than happy to add any missing information if necessary.

Bug#982875: Acknowledgement (cups-printer-oki: could PPD file for okiB432 be included?)