Bug#951293: marked as pending in procps

[Sven Joachim]

On 2020-02-29 01:04 +, Craig Small wrote:

> Control: tag -1 pending
>
> Hello,
>
> Bug #951293 in procps reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/debian/procps/-/commit/70da93d8a65657c24eb2f458953a8a31fd4af4e3
>
> 
> Use correct package version on removing conffile Closes: #951293
> 

Sorry, this is again not the correct version, as the obsolete conffile
will not be removed on systems which were already upgraded to
2:3.3.16-3.  See the dpkg-maintscript-helper manpage (emphasis mine):

,
| If the conffile has not been shipped for several versions, and you are
| now modifying the maintainer scripts to clean up the obsolete file,
| prior-version should be based *on the version of the package that you
| are now preparing*, not the first version of the package that lacked the
| conffile.
`

So the version you need to use in procps.maintscript is 2:3.3.16-4~, not
2:3.3.16-3~.

Cheers,
   Sven

Bug#952784: ITP: ruby-knapsack -- Parallel tests across CI server nodes

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

https://rubygems.org/gems/knapsack for gitlab autopkgtest

Bug#952111: micro crashes consistently with panic: interface conversion: interface {} is float64, not bool

[Pirate Praveen]

Control: forwarded -1 https://github.com/zyedidia/micro/issues/1548

On Wed, 26 Feb 2020 14:17:20 + Alain Ducharme
 wrote:
> This error means that your settings.json config file has been corrupted or is 
> not correctly formatted for the micro version you are using.
> Most likely scenario: you ran micro v2.x.x, which changes the setttings.json 
> format, then tried to go back to using v1.x.x.
> 
> Solution:
> rm ~/.config/micro/settings.json
> Or to start from fresh and wipe all of micro's configuration:
> rm -r ~/.config/micro
> 

I need to use both versions as I share the home directory between buster
and sid. I have opened an issue upstream for better handling of such
cases by possibly versioning the setting.config format and giving better
error message in case of unsupported versions.

Hopefully this issue will go away once micro 2.x is backported to buster.



signature.asc
Description: OpenPGP digital signature

Bug#952783: ITP: ruby-spring-commands-rspec -- rspec command for spring

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

https://rubygems.org/gems/spring-commands-rspec for gitlab autopkgtest

Bug#952782: python-dnspython: Python 2 binary should not be released with bullseye

[Scott Kitterman]

Package: python-dnspython
Version: 1.16.0-1
Severity: serious

As the primary maintianer of dnspython, I don't think it is suitable to
leave with a python2 binary for the bullseye release.

Scott K

Bug#936659: gr-hpsdr: Python2 removal in sid/bullseye

[Scott Kitterman]

On Fri, 30 Aug 2019 07:19:41 + Matthias Klose  wrote:
> Package: src:gr-hpsdr
> Version: 1.2-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.

The Fedora patch for switching to GNU Radio 3.8 and Python3 can be found here:

https://src.fedoraproject.org/rpms/gr-hpsdr/blob/master/f/gr-hpsdr-1.2-gnuradio38.patch

Scott K

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

Bug#951331: hexchat apparmor profile

[Seth Arnold]

Hello Mattia, Patrick,

Thanks so much for proposing an AppArmor profile for HexChat.

I've got a few comments; I'll paste in the entire 'main' block of the
profile, and add my comments inline.:


## Copyright (C) 2014 troubadour 
## Copyright (C) 2014 - 2019 ENCRYPTED SUPPORT LP 
## See the file COPYING for copying conditions.

   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 

This should also #include 

   deny @{PROC}/** r,

   @{HOME}/ r,
   @{HOME}/.config/** rwk,
   @{HOME}/.xchat2/ r,
   @{HOME}/.xchat2/** rwixk,
   @{HOME}/.config/ r,
   @{HOME}/.config/hexchat/ r,
   @{HOME}/.config/hexchat/** rwixk,
   @{HOME}/.kde/share/config/gtkrc-2.0 r,
   @{HOME}/.kde/share/config/oxygenrc r,
   @{HOME}/.*/lib/python*/** r,

   /bin/grep rix,
   /bin/uname rix,
   /bin/mkdir rix,
   /bin/rm rix,

   /usr/bin/grep rix,
   /usr/bin/uname rix,
   /usr/bin/mkdir rix,
   /usr/bin/rm rix,

   /dev/tty rwix,
   /dev/null rw,

   /etc/passwd r,
   /etc/group r,
   /etc/host.conf r,
   /etc/hosts r,
   /etc/resolv.conf r,
   /etc/gai.conf r,
   /etc/nsswitch.conf r,

The lines between /etc/passwd and /etc/nsswitch.conf could be removed with
abstractions/nameservice added.

   /etc/ld.so.cache r,
   /etc/machine-id r,
   /etc/os-release r,
   /etc/xdg/xfce4/helpers.rc r,
   /etc/xfce4/defaults.list r,
   /etc/python*/sitecustomize.py r,

   /lib/*-linux-gnu/** mr,

This line is very broad -- and overlaps with a lot of the libraries listed
in abstractions/base -- if you found any libraries that are DENIED because
they don't match a rule already in abstractions/base, it would be best to
list them with a specific rule.

   /usr/bin/xchat rix,
   /usr/bin/xdg-open rix,
   /usr/bin/dbus-send rix,
   /usr/bin/xprop  rix,
   /usr/bin/exo-open rix,
   /usr/bin/sensible-browser rix,
   /usr/bin/zenity rix,
   /usr/bin/torbrowser rix,
   /usr/bin/basename rix,
   /usr/bin/kde4-config rix,
   /usr/bin/aplay rix,

I'm really worried about these. I can appreciate trying to provide a
profile that lets people click on links as usual, but actually running
these applications in hexchat's profile will lead to bugs.

This also means the hexchat profile may need to be much wider, just to
accomodate these other programs.


   /usr/lib/*-linux-gnu/** mrix,

This line is also very broad -- and shouldn't be needed with
abstractions/base.

   /usr/lib/xchat/plugins/* mr,
   /usr/lib/perl*/** mr,
   /var/lib/snapd/desktop/applications/ r,

Granting permission to read this directory without permission to read the
*.desktop files is a bit wasted. What happens if this is denied?

   ## The Ux permission is too dangerous to be enabled by default.
   #/usr/lib/firefox-esr/firefox* Ux,

   /usr/lib/python*/lib-dynload/*.so mr,

   /usr/local/lib/python*/dist-packages/ r,
   /usr/local/lib/python*/dist-packages/* r,

   /usr/share/icons/** r,
   /usr/share/enchant/* r,
   /usr/share/myspell/dicts/ r,
   /usr/share/hunspell/ r,
   /usr/share/hunspell/* r,
   /usr/share/ca-certificates/** r,
   /usr/share/xfce4/helpers/* r,
   /usr/share/xfce4/applications/ r,
   /usr/share/xfce4/applications/mimeinfo.cache r,
   /usr/share/zenity/* r,
   /usr/share/fontconfig/** r,
   /usr/share/poppler/cMap/ r,
   /usr/share/poppler/cMap/** r,
   /usr/share/perl*/** mr,
   /usr/share/tcltk/tcl8.5/* r,
   /usr/share/pyshared/* r,
   /usr/share/aspell/ r,
   /usr/share/aspell/** r,

   /var/lib/aspell/* r,

   /run/*/resolv.conf r,

This shouldn't be needed with abstractions/nameservice added.


I know that the helper applications is a difficult point here. The more
secure option is to prevent them from being used. The friendliest option
is to use PUx execution rules to either launch them confined, if the user
has profiles for them, or unconfined, if the user doesn't have profiles.

But having an unconfined way out of the profile drastically reduces the
value of the profile.

Desktop applications are difficult to confine because many users want to
use them to do everything. Other users don't mind some restrictions for
security gains. And it's very hard to provide one profile for both.

It may not make sense to enable the profile by default. I'd rather have
the tighter profile, without helper applications, but that may not reflect
what most users would actually want.

Thanks


signature.asc
Description: PGP signature

Bug#935923: libmodbus: FTBFS on hppa - unit-test-server: no process found

[John David Anglin]

On 2020-02-28 11:35 a.m., Martin wrote:
> Maybe on slow™ architectures the waiting time after
> starting the unit-test-server is just too short:
>
> echo "Starting server"
> ./unit-test-server > $server_log 2>&1 &
>
> sleep 1
>
> echo "Starting client"
> ./unit-test-client > $client_log 2>&1
>
> If that is really the problem, something like that is
> probably better (untested, not even tried to compile):
>
I don't think that's the problem.  I tried increasing the sleep time and your 
patch but
neither worked.  Had to add includes for open with your patch.

-- 
John David Anglin  dave.ang...@bell.net

Bug#874812: [amora-server] Qt4 removal from Debian

[Axel Beckert]

Hi Moritz,

Moritz Mühlenhoff wrote:
> Attached is a quick-and-dirty patch to drop the amora-applet binary
> package, qt4 will soon be removed from unstable.

Thanks for the effort, but in the meanwhile I'm rather think we should
remove amora completely from Debian, at least for now.

Upstream (Cc'ed) tried to migrate to Qt5 about two years ago.
Compiling and running with Qt5 was not the big issue, but getting
Bluetooh working again — and hence core functionality:
https://github.com/amora/amora/issues/86#issuecomment-432001824

Another point is that the main client platform are Nokia Symbian
phones — which are nearly nowhere in use anymore. I still do have such
a phone, but for years the only reason to power it on was to test
amora before uploading. Haven't powered it on since the last upload...

There's IIRC code for a Qt client (Qt 4 I assume, maybe even older)
which AFAIK never was published in any app store though. If I remember
correctly I once got it running on my OpenMoko (i.e. ages ago). Or was
it on the Nokia N900? Can't remeber anymore...

We still can bring it back when the Qt5 port is working properly and
there's a client for modern mobile phones (even if only for less
popular OS like KaiOS/GerdaOS or SailfishOS).

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

Bug#952762: openstack-pkg-tools: please make the build reproducible

[Thomas Goirand]

On 2/28/20 7:15 PM, Chris Lamb wrote:
> Source: openstack-pkg-tools
> Version: 108
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Hi,
> 
> Whilst working on the Reproducible Builds effort [0] we noticed that
> openstack-pkg-tools is causing other packages to be built in an
> unreproducible manner.
> 
> In particular, the "/usr/bin/pkgos-dh_auto_install" script may 
> nondeterministically create packages with differing shebangs and binary 
> dependencies. For example, this is from src:redfishtool:
> 
> │ -#!/usr/bin/python3.7
> │ +#!/usr/bin/python3.8
> 
> […]
> 
> │ │ │ │ -Depends: python3-requests, python3.8:any, python3:any
> │ │ │ │ +Depends: python3-requests, python3.7:any, python3:any
> 
> §
> 
> This is caused by a number of layered reasons. First, we are building
> all supported Python versions (eg. Python 3.7 and Python 3.8) in
> separate directories but then seqeuentially installing them to the
> same destination, debian/${TARGET_DIR}.
> 
> However, this causes problems because if latter installations complete
> in less than one second, distutils may decide to skip copying files in
> the shared destination as it incorrectly believes them to be up-to-
> date. This will result in a package arbitrarily containing scripts
> with different version shebangs depending on the approximate total
> execution speed of installation. This is, needless to say,
> nondeterminstic.
> 
> For example, if we build for both Python 3.7 and Python 3.8 but the
> installation of the latter occurs within the same wall clock second of
> the former, the Python 3.8 version will not overwrite the Python 3.7
> verison and lead to a shebang of #!/usr/bin/python3.7 … whilst if it
> does not occur within the same second, the shebang will be overwritten
> to #!/usr/bin/python3.8.
> 
> A patch is attached that passes --force to `setup.py install [..]`
> which will avoid the underlying calls to distutils's `dep_util.newer`
> and thus will always update.
> 
>   [0] https://reproducible-builds.org/
> 
> 
> Regards,

Hi Chris!

This is very nice, but in fact, having python3.8 or python3.7, can be
considered as a bug in the packages I maintain. Indeed, what it means is
that the package is missing:

override_dh_python3:
dh_python3 --shebang=/usr/bin/python3

Without this, the package incorrectly will have python3.x as dependency
instead of python3:any.

Do I understand well that you saw this in redfishtool? In such case,
that's where the bug should be filled, IMO.

Your thoughts?
Cheers,

Thomas Goirand (zigo)

Bug#931401: syncthing: incorrect warning please upgrade to v0.14.14 or newer

[dirdi]

Package: syncthing
Version: 1.1.4~ds1-4
Followup-For: Bug #931401

Just want to confirm Joaquín's assumption that the package was built
with a wrong version string:

$ strings /usr/bin/syncthing | grep unknown-dev
_eval_args_additionalsalarm 
clockalloc_spaceaudio/basicaudit-*.logauthoritiesbad addressbad messagebad 
timedivbad verb '%broken pipebytes fieldcall of nilcgocall 
nilcircledast;clobberfreecomplement;connectionscontentionscontextmenucreated by 
crossorigincurlywedge;customtype=delete filedoubleStarsdynamicAddrempty 
fieldeqslantgtr;expected :=file existsfinal 
tokenfloat32nan2float64nan2float64nan3folderLabelformenctypegccheckmarkglobalBytesglobalFilesgtreqqless;gui-addresshash
 error:http-serverhttps_proxyi/o 
timeoutignorePermsignoreStatsinSyncBytesinSyncFilesindex-blockinuse_spaceis 
disabledisCandidatejournal-numld [x + 
%d]lessapprox;lesseqqgtr;linux-amd64listenLocallmoustache;local 
errorlocal.protolongVersionlongmapsto;lost 
mcachemSpanManualmapstodown;mapstoleft;memdb@flushmethodargs(nLeftarrow;nanosecondsneedDeletesnewestFirstnil
 contextnleftarrow;not reachednot startednsubseteqq;nsupseteqq;oldestFirston 
write topanic-*.logparse 
errorpermissionsplaceholderprecapprox;prevVersionrange_closeraw-controlreceiveonlyreflect.SetrescanIntvsretry-afterrightarrow;rmoustache;runtime:
 P runtime: p save configscheddetailsendreceivesetnonblockshort 
writesqsubseteq;sqsupseteq;stack faultstack tracestat 
after:subsetneqq;succapprox;supsetneqq;syncDir: %vtable@buildterms_closetime: 
file tls: alert(tracealloc(traffic 
updtrashcan@%punknown-devunreachableunsubscribeupuparrows;valid 
untilvarepsilon;varnothing;weak hasherzero header~syncthing~  addresses: 
(sensitive) PRIVATE KEY [recovered] allocCount  found at *( gcscandone  
m->gsignal= minTrigger= nDataRoots= nSpanRoots= pages/byte

Did one figure out a workaround?

Btw: The bug was reported upstream, too: 
https://forum.syncthing.net/t/odd-not-sending-symlinks-to-old-client-messages-on-debian/14254
But was closed since this is clearly a debian specific issue.

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

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

Versions of packages syncthing depends on:
ii  libc6  2.29-10

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Bug#952781: ITP: python-libconf -- Reader/writer for the libconfig format

[Bastian Germann]

Package: wnpp
Severity: wishlist

* Package name: python-libconf
  Upstream Author : Christian Aichinger
* License : Expat
  Description : Reader/writer for the libconfig format

 libconf is a pure-Python reader/writer for configuration files
 in libconfig format, which is often used in C/C++ projects.
 Its interface is similar to the json module.

Bug#952780: hplip: Strange dpkg-statoverride usage

[Guillem Jover]

Package: hplip
Version: 3.20.2+dfsg0-1
Severity: normal

Hi!

This package is making incorrect use of dpkg-statoverride for a
volatile pathname under /run that is not managed by dpkg. In addition
the recent migration from /var/run to /run does not include cleanup of
/var/run.

statoverrides are intended to be used on pathnames shipped by a
package that dpkg will unpack, otherwise this will have no effect if
the path did not exist at --update time. While there are plans to
add support for volatile/ghost files to dpkg, this is not the case
right now, so you need to manage this in some other way for /run,
and cleanup the statoverride for /run and /var/run to avoid leaving
cruft behind.

Thanks,
Guillem

Bug#952779: [xwayland] XWayland doesn't honor the keyboard layout

[Sergio Costas]

Package: xwayland
Version: 1.20.7-3
Severity: important

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

Programs running under XWayland doesn't honor the keyboard layout 
configured under Gnome Shell.


I have the Spanish keyboard layout configured in my system, with an 
Spanish keyboard. Under X11 everything works as expected: pressing the 
'ñ' key shows an 'ñ' letter, and all the symbols are in the right key.


Logging in Wayland, everything *seems* to work fine, and in fact, native 
Wayland applications (like Gedit) work fine and show the symbols and 
Spanish characters as expected. But applications that use XWayland 
don't, interpreting the keyboard as an American one. Even more: forcing 
GTK3 applications to use XWayland makes them fail too, like doing from a 
terminal:


    GDK_BACKEND=x11 gedit

In this case, gedit also interprets incorrectly the keyboard layout.

HOW TO REPRODUCE:

- set your keyboard layout to Spanish

- logging in Wayland

- launch Firefox

- try to type a symbol

- compare the symbol typed with the one that is inserted when pressing 
the same key in Gedit



--- System information. ---
Architecture:
Kernel: Linux 5.4.0-4-amd64

Debian Release: bullseye/sid
500 unstable-debug debug.mirrors.debian.org
500 unstable ftp.debian.org
500 suldr www.bchemnet.com
500 stable repo.skype.com
500 stable linux.teamviewer.com
500 stable dl.google.com

--- Package information. ---
Depends (Version) | Installed
==-+-
xserver-common (>= 2:1.20.7-3) | 2:1.20.7-3
libaudit1 (>= 1:2.2.1) | 1:2.8.5-2+b1
libbsd0 (>= 0.7.0) |
libc6 (>= 2.29) |
libdrm2 (>= 2.4.75) |
libepoxy0 (>= 1.0) |
libgbm1 (>= 17.1.0~rc2) |
libgcrypt20 (>= 1.8.0) |
libgl1 |
libpixman-1-0 (>= 0.30.0) |
libselinux1 (>= 2.0.82) |
libsystemd0 |
libunwind8 |
libwayland-client0 (>= 1.9.91) |
libxau6 |
libxdmcp6 |
libxfont2 (>= 1:2.0.1) |
libxshmfence1 |


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#952778: python-msgpack: Please packinge the new release

[Diane Trout]

Package: python-msgpack
Version: 0.5.6-2+b1
Severity: wishlist

Dear Maintainer,

I was trying to update python3-distributed and discovered that distributed
version 2.11 needs msgpack > 0.6.0.

I'm filing this so I can know when the next version of msgpack gets released.

Thank you,
Diane Trout



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

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

Versions of packages python-msgpack depends on:
ii  libc62.29-10
ii  python2  2.7.17-2

python-msgpack recommends no packages.

python-msgpack suggests no packages.

-- no debconf information

Bug#927703: knot: autopkgtest depends on python3-lmdb which is not in buster

[Daniel Kahn Gillmor]

Control: tags 927703 + wontfix

On Sun 2019-07-21 11:35:40 +0200, Paul Gevers wrote:
> Control: tags -1 buster
>
> On Sun, 21 Apr 2019 16:38:58 +0200 Paul Gevers  wrote:
>> I was looking into the failure of your package on the ci.debian.org
>> infrastructure when run in testing. One of your autopkgtests depends on
>> python3-lmdb, which isn't supported anymore in testing/buster. Could you
>> please have a look and fix your autopkgtest? If fixing the test itself
>> is too difficult for now, can you please add the skip-not-installable
>> restriction to the authoritative-server test, to enable proper
>> unstable-to-testing migration testing?
>
> https://tracker.debian.org/news/1043194/py-lmdb-086-11-migrated-to-testing/
>
> The issue is resolved in testing, so only exhibits itself in buster. I
> can understand it when this bug is closed as wontfix in buster.

I'm closing this issue, because it is resolved in testing.

Thanks for keeping an eye on this, Paul!

   --dkg


signature.asc
Description: PGP signature

Bug#952777: sicherboot: Sign DKMS modules

[Josef Kufner]

Package: sicherboot
Version: 0.1.5
Severity: normal

Dear Maintainer,

when installing modules via DKMS, the built modules are not signed
automatically and it is rather difficult to figure out how to sign them, and
unfortunately, the kernel refuses to load an unsigned module. It would be nice
if Sicherboot had some DKMS hook to sign the modules automatically.



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=cs:en_US:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sicherboot depends on:
ii  binutils  2.34-3
ii  efitools  1.9.2-1
ii  systemd   244.3-1
ii  uuid-runtime  2.34-0.1

sicherboot recommends no packages.

sicherboot suggests no packages.

-- Configuration Files:
/etc/kernel/postinst.d/dracut [Errno 2] Adresář nebo soubor neexistuje: 
'/etc/kernel/postinst.d/dracut'
/etc/sicherboot/sicherboot.conf changed [not included]

-- no debconf information

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

[Lisandro Damián Nicanor Pérez Meyer]

reopen 952718
forwarded 952718 https://bugreports.qt.io/browse/QTCREATORBUG-23451
tag 952718 upstream
thanks



El vie., 28 feb. 2020 19:35, Alexis Murzeau  escribió:

> Hi,
>
> On 28/02/2020 19:11, Lisandro Damián Nicanor Pérez Meyer wrote:
> >>* What outcome did you expect instead?
> >>
> >> I expect the clang code model to work out of the box with all depends
> >> and recommends dependencies of `qtcreator`.
> >> As of now, `libclang-common-8-dev` seems required by the clang code
> >> model to work correctly, but that package is not a direct or indirect
> >> dependency of `qtcreator`.
> >
> > No, you ar emixing two things here.
> >
> > The clang code model is a plugin that uses clang's API to parse a
> > source file and do checks over it, like missing headers. It does not
> > requires clang headers.>
> > What you saw is a project that needed a header not available in the
> > system (or at least not for the selected toolchain). The same could
> > happen if for example you install qtcreator but not qbase5-dev, and
> > then you open a project that needs QString.
>
> Actually, the error is about missing `stddef.h` header which should be
> available everywhere.
> It happens with a simple program like this:
> ```
> #include 
>
> int main() {
> return 0;
> }
> ```
>
> Using another computer with outdated packages, I noticed that:
>
> - When having qtcreator 4.10.2-2 and no `libclang-common-8-dev` package
> installed,
> a project with the above file in `main.cpp` configured to be compiled
> using cmake and gcc-9,
> the clang code model works fine, there is no highlighted errors.
> When I do Ctrl+Click on the stddef.h header, qtcreator opens
> /usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h
>
> - After having upgraded qtcreator to 4.11.0-2, the code model now shows
> the error
> about missing `stddef.h` for the same project and configuration (cmake +
> gcc-9).
> When I do Ctrl+Click on the stddef.h header, despite being "not found",
> qtcreator opens the same file:
> /usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h.
>
> - If I downgrade qtcreator to 4.10.2-2 again, the error about `stddef.h`
> not found goes away.
>
> I've attached a test project I used with gcc-9 compiler.
>

Great! Reopening and tagging accordingly.

Thanks a lot for the follow up!

>

Bug#952776: RFP: libprometheus-tiny-perl -- tiny module to export monitoring metrics for Prometheus

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libprometheus-tiny-perl
  Version : 0.004
  Upstream Author : Rob N ★ 
* URL : https://metacpan.org/release/Prometheus-Tiny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : tiny module to export monitoring metrics for Prometheus

 Prometheus::Tiny is a minimal metrics client for the Prometheus time-series
 database, that can be used to instrument a service so that it can export
 monitoring metrics so that Prometheus compatible servers can collect them.
 .
 It does the following things differently to Net::Prometheus:
  * No setup. No need to pre-declare metrics to get something useful.
  * Labels are passed in a hash. Positional parameters get awkward.
  * No inbuilt collectors, PSGI apps, etc. Just the metrics.
  * No different metric types. You get what you ask for.


This package makes it easier to write Prometheus clients, that need to
get metrics from external sources, otherwise you need to create your
own derived types.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, and Uploader added assuming
the Perl team wants to take it. :)

Thanks,
Guillem


libprometheus-tiny-perl_0.004-1.debian.tar.xz
Description: application/xz

Bug#951916: proftpd-mod-vroot: proftpd cannot load mod_vroot

[Hilmar Preuße]

On 2/23/20 4:27 AM, Nikolai Lusan wrote:

Hi Nikolai,

> Trying to run proftpd with mod_vroot. The following error causes
> hosts using vroot to not be loaded:
> 
I've built a package for proftpd-mod-vroot, which have a dep on
proftpd-abi-1.3.6c [1]. Let me know if it solves your issue, then I'll
trigger a rebuild of the package.

Hilmar

[1] https://freeshell.de/~hille42/proftpd/951916/
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#952767: systemd: enable systemd-pstore.service by default

[Michael Biebl]

Am 28.02.20 um 21:57 schrieb Kevin Locke:
> Package: systemd
> Version: 244.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> This morning my ThinkPad T430 failed to boot with the message:
> 
> Error: The non-volatile variable storage is about full
> Press F1 to enter Setup.
> 
> The cause was the same as #891434: the kernel had dumped dmesg in pstore
> after an oops, which created dump-type0-* efivars, which had accumulated
> sufficiently to cause UEFI pre-boot to require user action.  (Luckily my
> machine still boots, unlike in #891434.)
> 
> It appears that systemd-pstore.service should move these files to
> /var/lib/systemd/pstore/ but the service is disabled.  `systemctl status
> systemd-pstore.service` shows:
> 
> Loaded: loaded (/lib/systemd/system/systemd-pstore.service; disabled; 
> vendor preset: enabled)"
> 
> I confirmed the same state occurs in a fresh testing install in a VM and
> was not inadvertently disabled by me or a previous update.
> 
> Is there a reason systemd-pstore.service is disabled by default?  Could
> we consider enabling it to avoid causing UEFI boot issues?

At a cursory glance, this might seem like a useful service to enable by
default, but I'm not sure if it has any downsides (and if we can enable
it safely on every system).

Colin, Niels, since you've been working on #891434 I'd welcome your
feedback here.
Ben, as kernel maintainer, your feedback would be very much appreciated
as well.

https://www.freedesktop.org/software/systemd/man/systemd-pstore.html#
has some further info on this service.

Regards,
Michael




signature.asc
Description: OpenPGP digital signature

Bug#579790:

[Good New]

 Hallo,

Ich bin Azim Hashim Premji, ein indischer Wirtschaftsmagnat, Investor und
Philanthrop. Ich bin der Vorsitzende von Wipro Limited. Ich gab 25 Prozent
meines persönlichen Vermögens für wohltätige Zwecke ab. Und ich habe auch
versprochen, den Rest von 25% in diesem Jahr 2020 an Einzelpersonen zu
verschenken. Ich habe beschlossen, 50.000,00 USD an Sie zu spenden. Wenn
Sie an meiner Spende interessiert sind, kontaktieren Sie mich für weitere
Informationen: azimhashi...@gmail.com

Sie können auch mehr über mich über den Link unten lesen

http://en.wikipedia.org/wiki/A zim_Premji

Herzlicher Gruss
Geschäftsführer Wipro Limited
Azim Hashim Premji

Bug#952775: Depends on projectm

[Moritz Muehlenhoff]

Package: qmmp-plugin-projectm
Severity: serious

projectm depends on Qt4, which is up for removal. qmmp in turn also depends on
projectm, so please drop the qmmp-plugin-projectm binary package.

Cheers,
Moritz

Bug#952774: RM: python-tables-lib python-tables-dbg python-tables -- RoQA; NBS; python2 cruft

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Probably a any <=> all dependency cycle that prevents automatic cruft
removal. pytables 3.6.1-2 is already in testing.

anbe@coccia:~$ dak rm -Rn -b python-tables-lib python-tables-dbg python-tables
Will remove the following packages from unstable:

python-tables |3.5.2-4 | all
python-tables-dbg |3.5.2-4 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
python-tables-lib |3.5.2-4 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian Science Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Andreas

Bug#932564: movim: should not use composer’s autoloader at runtime

[David Prévot]

Hi,

Sorry for the late answer, it seems like you forgot to CC me.

Adding PHP PEAR (and Composer) Maintainers to CC.

On Tue, Nov 19, 2019 at 10:40:35PM +0100, Thorsten Glaser wrote:
> On Sat, 20 Jul 2019, David Prévot wrote:
> 
> > I just noticed that the movim package depends on composer. Looking
> > further, it seems to use the ClassLoader feature of Composer.
> > 
> > I’m not sure this is a proper (nor optimal) way to load classes in a
> > production system, I’m not even confident that’s a secure way to do it.
> 
> It’s good enough for now.

It’s not “good enough” on a production system.

> > I thus would like to advise the use of a tool like phpab in order to
> > generate an autoload at build time, and let movim use this static
> > autoload at run time.
> 
> This would require binNMUs every time a dependency changes.
> I’d prefer to not do this.

No (binNMU are still a no-op with Arch:all packages currently anyway). I
don’t understand where you get that idea. If your autoload loads its
dependencies (and those dependencies load there dependencies), you don’t
need to update your own autoload when a dependency get updated (even if
that dependency updates its own set of dependencies in order to load
them).

> If I get a really good reason to write an own autoloader implementation
> similar to composer’s and use it instead, I might just do that, but I
> looked at the implementation, and it’s suitable for now.

I disagree it’s suitable for production use: this basically makes
accessible any package installed in /usr/share/php/ via the dynamic
loader. As long as everything behaves properly, you’re fine, but as soon
as you’re victim of an exploit, you open every doors.

Even Composer does not make use of it’s own dynamic loader when
providing an autoload the “normal” way (especially for production use).

> > Maybe some movim dependencies are affected by a similar issue, I didn’t
> 
> No, we’re installing them into /usr/share/php/ in a way that
> the include path contains them correctly, which we use in the
> composer autoloader invocation:
> 
>   $movim_autoloader->setUseIncludePath(true);

I’m explicitly seeing php-robmorgan-phinx and php-defuse-php-encryption
(and civicrm-common) depending on composer, that’s what I’m referring to
(not cloning this current bug there, no need to split the discussion).

> > I’d like to advise hosting those dependencies under the “Debian PHP
> > PEAR (and Composer) Maintainers” umbrella by the way.
> 
> Are you kidding me? We’ve asked the PHP maintainers, ahead of
> time, multiple times, and never got *any* kind of usable reply,
> nor any kind of assistance regarding the way we should install
> and use the libraries.

I apologize for not using enough of my volunteer time for answering to
every request made to the team.

> It’s a bit surprising you complain *now*
> about *both* the way we use them (autoloader) *and* where they
> are hosted, when the PHP packagers have been extremely unhelpful
> when we asked.

I’m sorry to propose to offer help only now. I’m still willing to
provide a patch or a MR for this issue. I’m simply pointing that I would
probably have already pushed a fix for the above PHP libraries if they
where hosted with the other PHP libraries.

> We would have liked to have them maintained by people who know
> what they’re doing, but it turned out that it’s better to do it
> ourselves, perhaps not in the same style but not too badly, than
> to be under the umbrella of an unresponsive team.

I’m definitely not volunteering to maintain myself packages that you
need for your projects, but I still believe that having all PHP
libraries handled in the same team makes sense. It help working towards
more homogeneity and allow people to actually co-maintain those
packages.

Regards

David


signature.asc
Description: PGP signature

Bug#874812: [amora-server] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Mon, Jan 20, 2020 at 08:27:41PM +0100, Moritz Mühlenhoff wrote:
> On Thu, Sep 12, 2019 at 11:48:46PM +0200, Axel Beckert wrote:
> > > or we're moving forward with the Qt4 removal.
> > 
> > Just move forward. IIRC amora already has been removed from testing,
> > so it really shouldn't be an issue for the Qt4 removal.
> 
> Quick status update: qt4 is now removed from testing and we're
> planning to remove it from unstable by end of Februrary (along
> with whatever rdeps (currently 15) remain by that date).

Attached is a quick-and-dirty patch to drop the amora-applet binary
package, qt4 will soon be removed from unstable.

Cheers,
Moritz
diff -Naur amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.dirs amora-server-1.2~svn+git2015.04.25/debian/amora-applet.dirs
--- amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.dirs	2015-03-16 20:29:23.0 +0100
+++ amora-server-1.2~svn+git2015.04.25/debian/amora-applet.dirs	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-usr/bin
-usr/share/applications
diff -Naur amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.docs amora-server-1.2~svn+git2015.04.25/debian/amora-applet.docs
--- amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.docs	2015-03-16 20:29:23.0 +0100
+++ amora-server-1.2~svn+git2015.04.25/debian/amora-applet.docs	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-amora-applet/README
-debian/README.source
diff -Naur amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.install amora-server-1.2~svn+git2015.04.25/debian/amora-applet.install
--- amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.install	2015-03-16 20:29:23.0 +0100
+++ amora-server-1.2~svn+git2015.04.25/debian/amora-applet.install	1970-01-01 01:00:00.0 +0100
@@ -1,4 +0,0 @@
-# qmake-qt4's generated install target has the path hardwired. So we
-# do it manually.
-amora-applet/amorad-gui usr/bin
-debian/amorad-gui.desktop usr/share/applications
diff -Naur amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.menu amora-server-1.2~svn+git2015.04.25/debian/amora-applet.menu
--- amora-server-1.2~svn+git2015.04.25.orig/debian/amora-applet.menu	2015-03-16 20:29:23.0 +0100
+++ amora-server-1.2~svn+git2015.04.25/debian/amora-applet.menu	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-?package(amora-applet):needs="X11" section="Applications/Mobile Devices"\
-  title="Amora Daemon (systray applet)" command="/usr/bin/amorad-gui"
diff -Naur amora-server-1.2~svn+git2015.04.25.orig/debian/control amora-server-1.2~svn+git2015.04.25/debian/control
--- amora-server-1.2~svn+git2015.04.25.orig/debian/control	2015-04-26 02:24:42.0 +0200
+++ amora-server-1.2~svn+git2015.04.25/debian/control	2020-02-26 12:52:33.293657036 +0100
@@ -10,12 +10,10 @@
libbluetooth-dev,
libdbus-1-dev,
libimlib2-dev,
-   libqt4-dev,
libtool-bin,
libx11-dev,
libxtst-dev,
-   pkg-config,
-   qt4-qmake
+   pkg-config
 Standards-Version: 3.9.6
 Homepage: https://github.com/amora/amora#readme
 Vcs-Git: git://github.com/amora/amora.git
@@ -48,28 +46,3 @@
  The client has to be installed on the mobile phone and is not
  contained in the package. It can be downloaded from the home page of
  the project.
-
-Package: amora-applet
-Provides: amora-server
-Architecture: any
-Depends: ${misc:Depends},
- ${shlibs:Depends}
-Description: use a bluetooth device as X remote control (systray applet)
- Amora (A mobile remote assistant) is an application that enables you
- to control your desktop using your mobile phone. It uses bluetooth to
- send mouse and keyboard events to the X session. With it, you can
- control your presentations, movies or any other application which
- mainly uses mouse and cursor keys.
- .
- Amora also has a screenshot feature, where you can see a thumbnail of
- the currently focused window on the mobile phone.
- .
- Currently only Symbian Series 60 mobile phones are supported. A Java
- client implementation is under development. A proof of concept client
- for Linux based mobile device like the Nokia Internet Tablets and the
- OpenMoko FreeRunner is available.
- .
- This package contains the Qt-based system tray applet version of the
- daemon running on the to be remote controlled computer. The client
- has to be installed on the mobile phone and is not contained in the
- package. It can be downloaded from the home page of the project.
diff -Naur amora-server-1.2~svn+git2015.04.25.orig/debian/rules amora-server-1.2~svn+git2015.04.25/debian/rules
--- amora-server-1.2~svn+git2015.04.25.orig/debian/rules	2015-03-16 20:29:23.0 +0100
+++ amora-server-1.2~svn+git2015.04.25/debian/rules	2020-02-26 12:52:49.545755336 +0100
@@ -13,8 +13,6 @@
 override_dh_auto_configure:
 	cd amora-cli && autoreconf -f -i
 	dh_auto_configure -D amora-cli
-	# Does qmake-qt4 

Bug#952772: RM: hydrogen -- RoQA; Depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove hydrogen. It depends on Qt4, which is being removed. It can be 
reintroduced
when/if ported to Qt5.

Cheers,
Moritz

Bug#952773: RM: puddletag -- RoQA; Depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove puddletag. It depends on Qt4, which is being removed. It can be 
reintroduced
when/if ported to Qt5.

Cheers,
Moritz

Bug#926242: [rb-general] Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

[Chris Lamb]

Chris Lamb wrote:

> > > So, I heard a vague rumour that this "buster" thing was released? I
> > > was thus wondering whether we could apply my patch from:
> > > 
> > >   https://bugs.debian.org/926242#127
> > >   
> > > :)
> > 
> > My current plan is (1) breathing a little, (2) getting the needed
> > bugfixes into 10.1.
> 
> Whoops, I'm afraid I totally neglected to followup on this so I
> apologise this got stalled. Anyway, anything I can do to help?

I've made an initial step of taking my patch from:

  https://bugs.debian.org/926242#127

… and submitting it as a MR on salsa here:

  https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/13


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#952771: dojo: CVE-2019-10785

[Salvatore Bonaccorso]

Source: dojo
Version: 1.15.0+dfsg1-1
Severity: important
Tags: security upstream
Control: found -1 1.14.2+dfsg1-1

Hi,

The following vulnerability was published for dojo.

CVE-2019-10785[0]:
| dojox is vulnerable to Cross-site Scripting in all versions before
| version 1.16.1, 1.15.2, 1.14.5, 1.13.6, 1.12.7 and 1.11.9. This is due
| to dojox.xmpp.util.xmlEncode only encoding the first occurrence of
| each character, not all of them.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10785
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10785
[1] https://github.com/dojo/dojox/security/advisories/GHSA-pg97-ww7h-5mjr
[2] https://snyk.io/vuln/SNYK-JS-DOJOX-548257

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#952769: isc-dhcp-client: Package "isc-dhcp-client" is not installable in the Debian SID PowerPC Port. Unmet dependencies: "libdns1107" and "libisc1104"

[Hugo Melder]

Package: isc-dhcp-client
Version: 4.4.1-2.1
Severity: grave
Tags: d-i a11y
Justification: renders package unusable



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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.9.1
ii  iproute2   5.5.0-1
ii  libc6  2.29-10
ii  libdns-export1107  1:9.11.14+dfsg-3
ii  libisc-export1104  1:9.11.14+dfsg-3

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

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information

Bug#952770: adacontrol: ./src/./src/pfni.adb:228: undefined reference to `thick_queries__full_name_image'

[Sebastian Ramacher]

Source: adacontrol
Version: 1.21r6b-2
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

adacontrol failed to build on i386:
| /usr/bin/gnatgcc -c -x ada -gnatA -g -O2 -gnatws -gnat12 -gnato -gnatf -g -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -gnatwa 
-gnatec=/tmp/GNAT-TEMP-15.TMP -gnatem=/tmp/GNAT-TEMP-16.TMP 
/<>/src/rules-assignments.adb
| gnatgcc ptree.o -Wl,-z,relro -Wl,-z,now -Wl,--no-undefined b__ptree.o 
/<>/src/binary_map.o /<>/src/generic_file_iterator.o 
/<>/src/options_analyzer.o /<>/src/project_file.o 
/<>/src/implementation_options.o 
/<>/src/project_file-adp.o 
/<>/src/project_file-dummy.o 
/<>/src/project_file-gpr.o 
/<>/src/project_file-factory_full.o 
/<>/src/project_file-factory.o /<>/src/utilities.o 
/<>/src/thick_queries.o /<>/src/a4g_bugs.o 
/<>/src/elements_set.o -L/usr/lib/i386-linux-gnu/ -lgnatcoll 
-lgnatprj -lxmlada_schema -lxmlada_dom -lxmlada_sax -lxmlada_input 
-lxmlada_unicode -lasis -lgnatvsn -g -ldl -L/<>/src/ 
-L/<>/src/ -L/usr/lib/i386-linux-gnu/ada/adalib/asis/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/gnatvsn/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/gnatcoll/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/gnatprj/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/xmlada_schema/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/xmlada_dom/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/xmlada_sax/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/xmlada_input/ 
-L/usr/lib/i386-linux-gnu/ada/adalib/xmlada_unicode/ 
-L/usr/lib/gcc/i686-linux-gnu/9/adalib/ -shared-libgcc -lgnat-9 -lutil -ldl 
-Wl,-rpath-link,/usr/lib/gcc/i686-linux-gnu/9//adalib -o /<>//ptree
| /usr/bin/ld: pfni.o: in function `pfni__print_name':
| ./src/./src/pfni.adb:228: undefined reference to 
`thick_queries__full_name_image'
| /usr/bin/ld: ./src/./src/pfni.adb:263: undefined reference to 
`thick_queries__static_expression_value_image'
| /usr/bin/ld: ./src/./src/pfni.adb:270: undefined reference to 
`thick_queries__discrete_constraining_values'
| /usr/bin/ld: ./src/./src/pfni.adb:273: undefined reference to 
`thick_queries__nil_extended_biggest_int_list'
| /usr/bin/ld: ./src/./src/pfni.adb:273: undefined reference to 
`thick_queries__Oeq'
| /usr/bin/ld: ./src/./src/pfni.adb:273: undefined reference to 
`thick_queries__Oeq'
| /usr/bin/ld: ./src/./src/pfni.adb:279: undefined reference to 
`thick_queries__biggest_int_img'
| /usr/bin/ld: ./src/./src/pfni.adb:286: undefined reference to 
`thick_queries__biggest_int_img'

… and many more linking errors. The full log is available at 
https://buildd.debian.org/status/fetch.php?pkg=adacontrol=i386=1.21r6b-2=1582752946=0

Best
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#952768: libxslt1-dev amd64 and i386 no longer multi-arch coinstallable

[Christian Klein]

Package: libxslt1-dev
Version: 1.1.34-3
Severity: normal

Starting with libxslt 1.1.34-2 and later, the -dev packages for amd64 and i386
can no longer be installed together.

Unpacking libxslt1-dev:i386 (1.1.34-3) ...
dpkg: error processing archive
/var/cache/apt/archives/libxslt1-dev_1.1.34-3_i386.deb (--unpack):
 trying to overwrite shared '/usr/bin/xslt-config', which is different from
other instances of package libxslt1-dev:i386
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libxslt1-dev_1.1.34-3_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

The problem is caused by the re-inclusion of xslt-config.
Unlike the version that shipped until 1.1.32-2.2, the new file contains the
libdir, which is different for both architectures.
The old xslt-config did not contain a libdir and was the same for both
architectures.

$  diff -Naur amd64/usr/bin/xslt-config i386/usr/bin/xslt-config
--- amd64/usr/bin/xslt-config   2020-02-22 15:28:46.0 +0100
+++ i386/usr/bin/xslt-config2020-02-22 15:28:46.0 +0100
@@ -4,7 +4,7 @@
 exec_prefix=${prefix}
 exec_prefix_set=no
 includedir=${prefix}/include
-libdir=${prefix}/lib/x86_64-linux-gnu
+libdir=${prefix}/lib/i386-linux-gnu

 usage()
 {
$



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

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

Versions of packages libxslt1-dev depends on:
ii  libxml2-dev  2.9.10+dfsg-4
ii  libxslt1.1   1.1.34-3

libxslt1-dev recommends no packages.

libxslt1-dev suggests no packages.

Bug#938410: rpm: diff for NMU version 4.14.2.1+dfsg1-1.1

[Boyuan Yang]

Control: tags 938410 + patch
Control: tags 938410 + pending

Dear maintainer,

I've prepared an NMU for rpm (versioned as 4.14.2.1+dfsg1-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru rpm-4.14.2.1+dfsg1/debian/changelog rpm-
4.14.2.1+dfsg1/debian/changelog
--- rpm-4.14.2.1+dfsg1/debian/changelog 2019-02-17 03:19:38.0 -0500
+++ rpm-4.14.2.1+dfsg1/debian/changelog 2020-02-28 13:52:17.0 -0500
@@ -1,3 +1,23 @@
+rpm (4.14.2.1+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
++ Bump Standards-Version to 4.5.0.
++ Bump debhelper compat to v12.
+- Drop python-rpm package and python2 support. (Closes: #938410)
++ Use secure URI for homepage information.
++ Let librpm-dev depends on libzstd-dev. Please see #940114.
+  * debian/rules:
++ Let buildtools.mk to provide proper $PKG_CONFIG.
++ Use architecture.mk instead of manual dpkg-architecture
+  invocation.
+- Drop dh_strip override, migration is now complete.
++ Use "dh_missing --fail-missing".
+  * debian/patches: Add patch 0012 to force using python3 in shebang
+for pythondeps.sh.
+
+ -- Boyuan Yang   Fri, 28 Feb 2020 13:52:17 -0500
+
 rpm (4.14.2.1+dfsg1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru rpm-4.14.2.1+dfsg1/debian/compat rpm-4.14.2.1+dfsg1/debian/compat
--- rpm-4.14.2.1+dfsg1/debian/compat2016-07-07 06:04:15.0 -0400
+++ rpm-4.14.2.1+dfsg1/debian/compat1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-9
diff -Nru rpm-4.14.2.1+dfsg1/debian/control rpm-4.14.2.1+dfsg1/debian/control
--- rpm-4.14.2.1+dfsg1/debian/control   2019-02-17 03:19:07.0 -0500
+++ rpm-4.14.2.1+dfsg1/debian/control   2020-02-28 13:35:40.0 -0500
@@ -3,14 +3,8 @@
 Uploaders: Michal Čihař 
 Section: admin
 Priority: optional
-Build-Depends: debhelper (>= 9.20160114),
-   dh-autoreconf,
-   dh-python,
-   libtool,
-   autoconf,
-   automake,
-   autotools-dev,
-   autopoint,
+Build-Depends: debhelper-compat (= 12),
+   dh-sequence-python3,
zlib1g-dev,
libbz2-dev,
libpopt-dev,
@@ -23,7 +17,6 @@
libcap-dev [linux-any],
libdbus-1-dev,
libsqlite3-dev,
-   python-all-dev,
python3-all-dev,
binutils-dev,
bzip2,
@@ -39,10 +32,10 @@
libdb-dev,
liblua5.2-dev,
libsemanage1-dev [linux-any]
-Standards-Version: 4.3.0
+Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/pkg-rpm-team/rpm
 Vcs-Git: https://salsa.debian.org/pkg-rpm-team/rpm.git
-Homepage: http://rpm.org/
+Homepage: https://rpm.org/
 
 Package: rpm
 Architecture: any
@@ -53,7 +46,7 @@
  debugedit (= ${binary:Version}),
  rpm-common (= ${binary:Version})
 Suggests: alien,
-  python,
+  python3,
   elfutils,
   rpmlint,
   rpm2html,
@@ -176,6 +169,7 @@
  zlib1g-dev,
  libxml2-dev,
  libreadline-dev,
+ libzstd-dev,
  libselinux1-dev [linux-any],
  libsqlite3-dev,
  ${misc:Depends}
@@ -188,30 +182,6 @@
  libraries and header files necessary to build programs that use 
  librpm.
 
-Package: python-rpm
-Architecture: any
-Section: python
-Priority: optional
-Depends: ${misc:Depends},
- ${shlibs:Depends},
- ${python:Depends},
- librpm8 (= ${binary:Version}),
- librpmio8 (= ${binary:Version}),
- librpmbuild8 (= ${binary:Version}),
- librpmsign8 (= ${binary:Version}),
- rpm-common (= ${binary:Version})
-Breaks: ${python:Breaks}
-Provides: ${python:Provides}
-Description: Python bindings for RPM
- The RPM Package Manager (RPM) is a command-line driven package
- management system capable of installing, uninstalling, verifying,
- querying, and updating computer software packages.
- .
- This package includes the Python bindings for librpm, allowing Python
- scripts to manipulate RPM packages and the RPM database.
- .
- This package installs the library for Python 2.
-
 Package: python3-rpm
 Architecture: any
 Section: python
diff -Nru rpm-4.14.2.1+dfsg1/debian/patches/0012-pythondistdeps.py-Use-
python3-in-shebang.patch rpm-4.14.2.1+dfsg1/debian/patches/0012-
pythondistdeps.py-Use-python3-in-shebang.patch
--- rpm-4.14.2.1+dfsg1/debian/patches/0012-pythondistdeps.py-Use-python3-in-
shebang.patch   1969-12-31 19:00:00.0 -0500
+++ rpm-4.14.2.1+dfsg1/debian/patches/0012-pythondistdeps.py-Use-python3-in-
shebang.patch   2020-02-28 13:52:04.0 -0500
@@ -0,0 +1,18 @@
+From: Boyuan Yang 
+Date: Fri, 28 Feb 2020 13:52:02 -0500
+Subject: pythondistdeps.py: Use python3 in shebang
+
+---
+ scripts/pythondistdeps.py | 2 +-
+ 1 file changed, 1 

Bug#859509: partman-auto uses memory size to determine disk partitioning and fails on high ram installs

[Raymond Burkholder]

On 2020-02-28 1:41 p.m., Jelle de Jong wrote:
So I hit this issue installing on my HP server while with the same 
preseed succesfully installed on a few other systms


So I made a virtual machine put 20GB ram in there and an 8GB drive and 
could reproduce the problem.


How can we force partman-auto to not use memory size in its calculation.


Sometimes you  can't use partman-auto.  Sometimes you have to perform 
your own partition management.  This doesn't solve your problem, but 
does show how an example customized partitioning scheme might be 
configured.  This scheme does away with a swap partition. More ideas can 
be found at 
https://blog.raymond.burkholder.net/index.php?/archives/662-Using-Debian-PreSeed-files-and-a-PXEBoot-Server-to-Auto-Build-Hosts.html


There are many example schemes you can find with a search.

## **
# Partitioning scheme:
# Choices:
#partman-auto   partman-auto/choose_recipe  select
d-i partman-auto/choose_recipe  select  custom1

## **
# for internal use; can be preseeded
d-i partman-auto/expert_recipe  string  \
  custom1 ::  \
75 1000 100 ext4\
  $primary{ } $bootable{ }  \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /boot }   \
  . \
1000 4000 5000 ext4 \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ / }   \
  . \
5000 1 10 btrfs \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ btrfs } \
  mountpoint{ /var }\
  . \
4000 8000 1 ext4\
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /home }   \
  . \
1000 1000 4000 ext4 \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /tmp }\
  .





I found out it tries to make swap the same size as memory for suspend, 
but how to disable this??


d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
#d-i partman-swapfile/size string"{{ swap | default('512') }}"

Kind regards,

Jelle de Jong

Bug#952767: systemd: enable systemd-pstore.service by default

[Kevin Locke]

Package: systemd
Version: 244.3-1
Severity: normal

Dear Maintainer,

This morning my ThinkPad T430 failed to boot with the message:

Error: The non-volatile variable storage is about full
Press F1 to enter Setup.

The cause was the same as #891434: the kernel had dumped dmesg in pstore
after an oops, which created dump-type0-* efivars, which had accumulated
sufficiently to cause UEFI pre-boot to require user action.  (Luckily my
machine still boots, unlike in #891434.)

It appears that systemd-pstore.service should move these files to
/var/lib/systemd/pstore/ but the service is disabled.  `systemctl status
systemd-pstore.service` shows:

Loaded: loaded (/lib/systemd/system/systemd-pstore.service; disabled; 
vendor preset: enabled)"

I confirmed the same state occurs in a fresh testing install in a VM and
was not inadvertently disabled by me or a previous update.

Is there a reason systemd-pstore.service is disabled by default?  Could
we consider enabling it to avoid causing UEFI boot issues?

Thanks,
Kevin


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-5
ii  libapparmor1 2.13.3-7
ii  libaudit11:2.8.5-2+b1
ii  libblkid12.34-0.1
ii  libc62.29-10
ii  libcap2  1:2.32-1
ii  libcryptsetup12  2:2.2.2-3
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.12-2
ii  libgpg-error01.37-1
ii  libidn2-02.2.0-2
ii  libip4tc21.8.4-3
ii  libkmod2 27-1
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.2-2
ii  libselinux1  3.0-1+b1
ii  libsystemd0  244.3-1
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.136
ii  libnss-systemd   244.3-1
ii  libpam-systemd   244.3-1
ii  udev 244.3-1

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/system.conf changed [not included]

-- no debconf information

Bug#951907: Suggested Stable Fix

[Salvatore Bonaccorso]

Hi Scott,

On Fri, Feb 28, 2020 at 03:30:01PM -0500, Scott Kitterman wrote:
> On Thursday, February 27, 2020 8:11:32 AM EST Salvatore Bonaccorso wrote:
> > Hi Scott,
> > 
> > On Thu, Feb 27, 2020 at 01:41:44PM +0100, Salvatore Bonaccorso wrote:
> > > Hi,
> > > 
> > > On Thu, Feb 27, 2020 at 01:18:55PM +0100, Salvatore Bonaccorso wrote:
> > > > I think though we mgiht need to revisit the assessment that older
> > > > versions are not affected. Look at the this quick and dirty test
> > > 
> > > > deduced from the testsuite:
> > > So I think versions before are as well vulnerable but a fix will
> > > become not so easy. First back in b07814e0753c ("Extract all html5lib
> > > things into a shim module") in v3.0.0 did split some code from
> > > bleach.sanitizer to bleach.html5lib_shim, and before in 67afdf8ae7d3
> > > ("Prevent HTMLTokenizer from unescaping entities") in v2.1 was quite
> > > refactored.
> > > 
> > > Now I'm not entirely sure how we should fix that for stretch.
> > 
> > Additional point, in earlier version the package depended on html5lib,
> > then the code was vedored out to bleach itself, and then further
> > modified as above. So while it is true one can argue the affected code
> > is not in bleach, the bleach.clean still does not properly sanitize
> > leading to the issue.
> > 
> > It is possibly to hard to actually fix the issue for stretch (and for
> > LTS interest as well in jessie)?
> 
> I don't think so.  I think the lowest risk approach, other than leaving it as 
> is, would be to backport 3.1.1 and use the vendored html5lib.  I gave that a 
> quick try and it doesn't work out of the box.  If that is something the 
> security team would consider, please let me know and I'll spend some time 
> investigating if I can make that work on stretch.

I feared that. Let's not take this risk and ignore the issue for
stretch then, altough it's not optimal. The advisory talks as well of
possible workarounds which might be possible for affected
users/applications for users in stretch.

So will go ahead for the DSA for buster only.

Many thanks for taking time to analyze the situation and reporting
back, much appreciated!

Regards,
Salvatore

Bug#859509: partman-auto uses memory size to determine disk partitioning and fails on high ram installs

[Jelle de Jong]

So I hit this issue installing on my HP server while with the same 
preseed succesfully installed on a few other systms


So I made a virtual machine put 20GB ram in there and an 8GB drive and 
could reproduce the problem.


How can we force partman-auto to not use memory size in its calculation.

I found out it tries to make swap the same size as memory for suspend, 
but how to disable this??


d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
#d-i partman-swapfile/size string"{{ swap | default('512') }}"

Kind regards,

Jelle de Jong

Bug#952452: initramfs-tools: prefers serial console over framebuffer console

[Ben Hutchings]

On Fri, 2020-02-28 at 17:59 +0300, Alper Nebi Yasak wrote:
> On 27/02/2020 02:10, Ben Hutchings wrote:
> > A device that is intended to be used with keyboard and video display
> > should not have this in the device tree for production units.  If we
> > ship the device tree then we can correct that.  If not, then the boot
> > loader should be configured to override it, and the installer could do
> > that by default.
> 
> I'm using rk3399-gru-kevin.dtb from the Debian package. The stdout-path 
> property comes from arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi in the 
> kernel tree. Setting a serial console this way seems to be ordinary, a 
> lot of other devices have it too.

I think most devices for which the kernel provides the device tree are
development boards, so a serial console is a fairly sensible default
for them.  It sounds like this should be changed for the "kevin" board.

> For the bootloader (part of the firmware), I don't know if there is a 
> way to make it change that property in the device-tree file.

Yes, it is normal for the boot loader to modify the device tree after
loading it.  For example, to set the kernel command line or memory
size.

> Meanwhile 
> I've added "console=tty0" to the default cmdline my bootloader-handler 
> project uses, so everything should be fine for now.
> 
> > I don't think it makes sense for initramfs-tools to do this, as the
> > wrong default console will still affect other software.
> 
> I intended to say that maybe initramfs-tools should correct the default 
> console to the virtual console not just for itself but for the entire 
> userspace. (I don't even know if that's possible.)

Right, but I don't think it is possible.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.




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

Bug#951907: Suggested Stable Fix

[Scott Kitterman]

On Thursday, February 27, 2020 8:11:32 AM EST Salvatore Bonaccorso wrote:
> Hi Scott,
> 
> On Thu, Feb 27, 2020 at 01:41:44PM +0100, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Thu, Feb 27, 2020 at 01:18:55PM +0100, Salvatore Bonaccorso wrote:
> > > I think though we mgiht need to revisit the assessment that older
> > > versions are not affected. Look at the this quick and dirty test
> > 
> > > deduced from the testsuite:
> > So I think versions before are as well vulnerable but a fix will
> > become not so easy. First back in b07814e0753c ("Extract all html5lib
> > things into a shim module") in v3.0.0 did split some code from
> > bleach.sanitizer to bleach.html5lib_shim, and before in 67afdf8ae7d3
> > ("Prevent HTMLTokenizer from unescaping entities") in v2.1 was quite
> > refactored.
> > 
> > Now I'm not entirely sure how we should fix that for stretch.
> 
> Additional point, in earlier version the package depended on html5lib,
> then the code was vedored out to bleach itself, and then further
> modified as above. So while it is true one can argue the affected code
> is not in bleach, the bleach.clean still does not properly sanitize
> leading to the issue.
> 
> It is possibly to hard to actually fix the issue for stretch (and for
> LTS interest as well in jessie)?

I don't think so.  I think the lowest risk approach, other than leaving it as 
is, would be to backport 3.1.1 and use the vendored html5lib.  I gave that a 
quick try and it doesn't work out of the box.  If that is something the 
security team would consider, please let me know and I'll spend some time 
investigating if I can make that work on stretch.

Scott K

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

Bug#952766: puma: CVE-2020-5247

[Salvatore Bonaccorso]

Source: puma
Version: 3.12.0-4
Severity: important
Tags: security upstream
Control: found -1 4.3.1-1
Control: found -1 3.12.0-2

Hi,

The following vulnerability was published for puma.

CVE-2020-5247[0]:
| In Puma (RubyGem) before 4.3.2 and 3.12.2, if an application using
| Puma allows untrusted input in a response header, an attacker can use
| newline characters (i.e. `CR`, `LF` or`/r`, `/n`) to end the header
| and inject malicious content, such as additional headers or an
| entirely new response body. This vulnerability is known as HTTP
| Response Splitting. While not an attack in itself, response splitting
| is a vector for several other attacks, such as cross-site scripting
| (XSS). This is related to CVE-2019-16254, which fixed this
| vulnerability for the WEBrick Ruby web server. This has been fixed in
| versions 4.3.2 and 3.12.3 by checking all headers for line endings and
| rejecting headers with those characters.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-5247
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5247
[1] https://github.com/puma/puma/security/advisories/GHSA-84j7-475p-hp8v

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#952251: sympy: FTBFS: make[2]: python: Command not found

[Steve Langasek]

Package: sympy
Followup-For: Bug #952251
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

This should be addressed by fixing the upstream build rules to invoke
python3 instead of python.  Please find attached a patch which has been
uploaded to Ubuntu to fix this failure.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sympy-1.5.1/debian/patches/python3-not-python.patch 
sympy-1.5.1/debian/patches/python3-not-python.patch
--- sympy-1.5.1/debian/patches/python3-not-python.patch 1969-12-31 
16:00:00.0 -0800
+++ sympy-1.5.1/debian/patches/python3-not-python.patch 2020-02-28 
09:23:34.0 -0800
@@ -0,0 +1,17 @@
+Author: Steve Langasek 
+Description: invoke python3 for building, not the deprecated python.
+Last-Update: 2020-02-28
+Bug-Debian: https://bugs.debian.org/952251
+
+Index: sympy-1.5.1/doc/Makefile
+===
+--- sympy-1.5.1.orig/doc/Makefile
 sympy-1.5.1/doc/Makefile
+@@ -1,6 +1,6 @@
+ # Makefile for Sphinx documentation
+ #
+-PYTHON   = python
++PYTHON   = python3
+ RST2HTML = rst2html
+ 
+ # You can set these variables from the command line.
diff -Nru sympy-1.5.1/debian/patches/series sympy-1.5.1/debian/patches/series
--- sympy-1.5.1/debian/patches/series   2020-02-07 09:53:35.0 -0800
+++ sympy-1.5.1/debian/patches/series   2020-02-28 09:23:34.0 -0800
@@ -3,3 +3,4 @@
 03_sphinx_conf.patch
 04_doc_makefile.patch
 05_sphinx_math_dollar.patch
+python3-not-python.patch

Bug#952765: calendarserver: Should be removed from Debian

[Boyuan Yang]

Source: calendarserver
Version: 9.2+dfsg-1
Tags: sid
Severity: serious
X-Debbugs-CC: amaramra...@users.sourceforge.net

Dear calendarserver maintainer,

Unfortunately the upstream of package calendarserver (Apple Inc.) has
terminated the development of this software and had the github source code
repo archived. This is a python2-only software and is affected by python2
removal in Debian.

I guess it's high time for us to remove it from Debian. I will submit a
removal request 7 days later (on March 06, 2020). If you have any doubts,
please let me know ASAP.

-- 
Best Regards,
Boyuan Yang


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

Bug#870835:

[Zainab Mohamm]

  Hello

Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin

[jnqnfe]

On Fri, 2020-02-28 at 16:41 +0100, Guilhem Moulin wrote:
> On Fri, 28 Feb 2020 at 05:40:10 +, jnq...@gmail.com wrote:
> 
> As I wrote previously, adding the break isn't the only thing that
> would
> have made your upgrade you smooth, the postinst script would like
> need
> to be adapted too. 
> 
> While the side effect isn't intentional, not having the Breaks: on
> older
> cryptsetups causes dpkg to fail, which I'd argue is better than
> ending
> up with a broken (unbootable) systems.  Sure, we could test upgrade
> paths from very old src:cryptsetups, but I'm not personally
> interested
> in working on something that we as a project don't support.  Not keen
> about the extra clutter either.  So right now I'm leaning towards
> closing this as ‘wontfix’. :-P

Ok. Fair enough :)

Bug#952761:

[Tyler Weldon]

Apologies, just found out updates are done every 6 hours. Thanks!

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Timo Aaltonen]

On 28.2.2020 18.50, Domenico Cufalo wrote:
> This is my output:
> 
> $ gsettings get org.gnome.desktop.input-sources sources
> [('xkb', 'it'), ('xkb', 'gr'), ('xkb', 'de')]
> 
> Obviously the command "setxkbmap it" solves the problem, at least for
> the current session.
> 
> In Italian keyboard, for example, round brackets are above the numbers 8
> and 9, instead of 9 and 0.
> 
> The issue arose after updating the following packages:
> 
> Start-Date: 2020-02-28  00:30:26
> Commandline: apt upgrade
> Requested-By: domenico (1000)
> Upgrade: libqt5test5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> qt5-gtk-platformtheme:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5dbus5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5sql5-sqlite:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5widgets5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), xkb-data:amd64
> (2.26-2, 2.29-1), libqt5xml5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5printsupport5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5concurrent5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5gui5:amd64
> (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5core5a:amd64 (5.12.5+dfsg-8,
> 5.12.5+dfsg-9), libxml2:amd64 (2.9.10+dfsg-3, 2.9.10+dfsg-4),
> libqt5network5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5sql5:amd64
> (5.12.5+dfsg-8, 5.12.5+dfsg-9)
> End-Date: 2020-02-28  00:30:33
> 
> In the meantime, I think I will downgrade the package...
> 
> Regards,
> Domenico
> 

I'm pretty sure the reason for the failure is that our xkbcomp is too
old, the newer versions ignore errors caused by having keycodes above
255.. and launching Xwayland in weston clearly shows a bunch of errors
from xkbcomp. Our version (1.4.0) is almost 2y old and this was fixed
upstream in 1.4.1 in June 2018.

So I'll update x11-xkb-utils, thanks for the patience..


-- 
t

Bug#952761: Version 3.8.2-2

[Tyler Weldon]

Version 3.8.2-2 does not appear to have been uploaded.

Bug#948834: closed by Simon McVittie (Re: Bug#948834: glib2.0: FTBFS: gio/tests/gsocketclient-slow.c: Error resolving ?localhost?: Name or service not known)

[Simon McVittie]

On Fri, 28 Feb 2020 at 18:34:53 +0100, Mattia Rizzolo wrote:
> TBH, I haven't spotted any other package failing for this...

With hindsight, dbus is the other one I'm aware of. As discussed on IRC,
I thought that was a pbuilder bug, and it probably *was* a pbuilder bug -
but after fixing the pbuilder bug, if I hadn't already worked around the
FTBFS by using 127.0.0.1, dbus would still have failed in pbuilder for
the same reasons that glib2.0 did.

smcv

Bug#952764: ITP: python-django-libsass -- django-compressor filter using libsass

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-libsass
  Version : 0.8
  Upstream Author : Matt Westcott 
* URL : https://github.com/torchbox/django-libsass/
* License : BSD-3-clause
  Programming Lang: Python
  Description : django-compressor filter using libsass

 A django-compressor filter to compile Sass files using libsass.  It builds on
 libsass-python to make @import paths aware of Django's staticfiles mechanism,
 and provides a filter module for django-compressor which uses the
 libsass-python API directly, avoiding the overheads of calling an external
 executable to do the compilation.

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

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl5ZaFgRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqyTgf+MpKlYbBsY6wJe41VmqSLhhn5WIIPNB+d
jmq1si+HsnGSbdTVa6orfrhEGW8XeWYRpRc6K3prnJQgMeDaTMXrWou+1HrcQprp
fm+y2jy+xpwOaqaxZQNQo8Ei5W+Y8UGjhxRm1AEsLJkCLV4fpnO+hMivFnMLKDZ4
SLkAcw25c7Le0s5+As6FciPSb128Spwd9/vC11r/XWDsHNTuDkYDS62rkpA9oTx6
7e/Q4kvfbCtiswfSCz7E2dKdspPO7NjwYqp7udL/ho6JEMIgyTVqAdH8qs7xD5CS
lQOzCYiFKmClb3KkyNekr7b74QXLr3v523Abn8MIAssMGY9nBoFo5w==
=yHRq
-END PGP SIGNATURE-

Bug#952763: One-page print jobs to foo2zjs printers are empty

[Didier 'OdyX' Raboud]

Package: cups-filters
Version: 1.27.1-1
Severity: serious
Tags: bullseye

1.27.1 is affected by a serious bug, fixed in 1.27.2:

- foomatic-rip: Zero-page-job handling changes made the last
  page of PostScript files not printed, also turning one-page
  jobs into zero-page jobs (Issue #200, Issue #206, Issue
  #208, Pull request #209, Pull request #210, Pull request
  #211).

As maintainer, I'm therefore filing this bug to let the BTS know, and
accelerate the transition of fixed versions.

I'll send the -done immediately when I get the bugnumber.

Bug#949171: linux: Please, enable COMPACTION for armel/marvell to mitigate OOMs

[Luca Olivetti]

El 17/1/20 a les 19:31, Rogério Brito ha escrit:

Source: linux
Version: 4.19.67-2+deb10u2
Severity: important
X-Debbugs-CC: debian-...@lists.debian.org

Hi, Ben and others.

I've been getting some OOM errors on my armel/kirkwood device running Debian
stable. One of the reasons for this is, according to the dmesg logs, that
COMPACT (memory compaction) is tried, but not available:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ grep -i compact /boot/config-4.19.0-6-marvell
# CONFIG_COMPACTION is not set
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


I'm running debian stretch on a lacie network space 2 (armel/kirkwood) 
and lately I'm seeing a lot of OOM errors, however I'm not sure it's 
just a problem of CONFIG_COMPACTION: the previous kernel had it not set 
either and I don't remember experiencing that many OOM.
I'm seeing them just after the latest kernel update I made on February 9 
2020. It's possible that I just missed them previously, though I doubt 
it since this machine is doing too many things and I would have noticed 
if some vital process stopped.


The remnant of the kernel (3.16.0) in jessie that I still have on this 
machine had CONFIG_COMPACTION enabled.



$  grep -i compact /boot/config*
/boot/config-3.16.0-8-kirkwood:CONFIG_COMPACTION=y
/boot/config-4.9.0-11-marvell:# CONFIG_COMPACTION is not set
/boot/config-4.9.0-12-marvell:# CONFIG_COMPACTION is not set


Bye
--
Luca

Bug#952748: libreoffice: Printer and queue attributes not available

[Brian Potkin]

On Fri 28 Feb 2020 at 19:26:09 +0100, Rene Engelhard wrote:

> Hi,

Hello Rene,
 
> On Fri, Feb 28, 2020 at 06:17:21PM +, Brian Potkin wrote:
> > On Fri 28 Feb 2020 at 16:29:58 +0100, Rene Engelhard wrote:
> > 
> > > Keeping the bug explicitely out of the loop.
> > 
> > I do not understand why.
> 
> Because of my first point.

I make my share of slip ups in bug reports. It happens.
 
> > The subject matter is of legitimate concern.
> 
> I didn't say otherwise.
> 
> > Rene Engelhard's opinion is that this is not an important bug and the
> > severity could be reduced to as low as wishlist.
> 
> No, I said 
> 
> "It would be good to" is (imho) not a important bug though, but maybe
> normal or minor or even wishlist.

I am given to gentle persuasion. How about my substituting "LibreOffice
should...".
 
> > The essence of the report's content was not addressed.
> 
> True. One step at a time. I also didn't say it wouldn't be adressed.
> (In any case, this would be upstream who needed to address it in any
> case.)

Fine.

Regards,

Brian.

Bug#951420: RFS: sane-backends/1.0.29-1~experimental1 -- API library for scanners -- utilities

[Adam Borowski]

On Sun, Feb 16, 2020 at 12:19:44PM +0100, Jörg Frings-Fürst wrote:
>Package name: sane-backends
>Version : 1.0.29-1~experimental1

> Changes since the last upload:
["War and Peace" skipped]

> The build with sbuild (sbuild --no-arch-all && sbuild --no-arch-any &&
> sbuild) and pdebuild are ok. The tests with lintian and piuparts and
> the autopkgtest are also ok.

Alas, it fail autopkgtests for me:

autopkgtest [19:12:30]: test start-net: [---
+ /bin/sed -i /localhost/d /etc/sane.d/saned.conf
+ echo localhost
+ /bin/sed -i s/^#\(pnm\)$/\1/ /etc/sane.d/dll.conf
+ /bin/sed -i s/^# \(localhost\)$/\1/ /etc/sane.d/net.conf
+ /usr/bin/scanimage -d net -L
+ /bin/grep net:+ 
/usr/bin/wc -l
Created directory: /var/lib/snmp/mib_indexes
+ CNT=0
+ [ 0 -eq 2 ]
+ exit 100
autopkgtest [19:12:35]: test start-net: ---]
autopkgtest [19:12:35]: test start-net:  - - - - - - - - - - results - - - - - 
- - - - -
start-netFAIL non-zero exit status 100

Full log at http://ix.io/2cUE


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#952761: 3.8.2-2

[Tyler Weldon]

Think this needs to be released:
https://tracker.debian.org/news/1105519/accepted-python3-stdlib-extensions-382-2-source-into-unstable/

Bug#952744: MySQL tests fail

[GCS]

Hi Robie,

On Fri, Feb 28, 2020 at 12:30 PM Robie Basak  wrote:
> I noticed that the test suite during the build is currently failing,
> including on the Debian buildds, but this isn't causing the package
> built to fail. Regardless, attached is the fix for the failures
> themselves.
 Thanks for your work. Please note that Debian uses MariaDB instead of
MySQL. It fails testing for a different reason. Still, going to fix it
for Debian. You will need to replace it with the fix you provided for
MySQL in Ubuntu.

Regards,
Laszlo/GCS

Bug#818377: maildrop: Any update?

[Lucio Crusca]

Package: maildrop
Followup-For: Bug #818377

Is the current situation still as described in the last comment?

Last time I tried, this bug pervented maildrop to be used with Courier when 
configured with virtual accounts. I've been avoiding Courier and maildrop 
Debian packages since then.

As for setuid root, yes, as far as I understand source code and manpage 
(https://www.courier-mta.org/maildrop.html#security), HAVE_COURIER builds of 
maildrop do need to run setuid root in order to provide the -D feature, which 
Courier uses to deliver messages to virtual accounts (and maybe other cases 
too).

A quick glance at the source code makes me believe a patch to make HAVE_COURIER 
dynamic is not that hard to write. If you confirm that this bug is still 
unresolved I could try to write the patch and submit it upstream.

Besides, I think it's overkill to check at runtime for setuid in order to 
behave like if HAVE_COURIER was present at build time: it's enough to check if 
the -D option is specified (the code to check that is already there) and, in 
that case, proceed assuming we are running with setuid root and with 
HAVE_COURIER at build time. If maildrop is not actually setuid root it will 
simply fail providing the -D feature (it only needs to be documented in the 
manpage), otherwise it will just work as intended by Courier. 

There are only two problems I see with this approach:

1) HAVE_COURIER declares an additional global variable before we can check for 
-D (namely "const char *numuidgid = 0;"), so we need to declare that variable 
regardless and use it only in -D case. I think this is not grave at all.

2) Users that want to run maildrop with Courier will need to setuid root the 
maildrop binary themselves, after the usual "apt install", so it does not work 
out of the box. I don't know if a manual setuid root operation is acceptable 
under all the Debian packaging guidelines and rules and whatever.

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

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

Versions of packages maildrop depends on:
pn  courier-authlib  
ii  libc62.29-10
pn  libcourier-unicode4  
ii  libgcc-s1 [libgcc1]  10-20200211-1
ii  libgcc1  1:9.2.1-25
ii  libgdbm6 1.18.1-5
ii  libpcre3 2:8.39-12+b1
ii  libstdc++6   9.2.1-25

Versions of packages maildrop recommends:
ii  lsb-invalid-mta [mail-transport-agent]  4.1+Debian13+nmu1

maildrop suggests no packages.

Bug#952748: libreoffice: Printer and queue attributes not available

[Brian Potkin]

found 952748 1:6.4.1-1
thanks



On Fri 28 Feb 2020 at 16:29:58 +0100, Rene Engelhard wrote:

> Keeping the bug explicitely out of the loop.

I do not understand why. The subject matter is of legitimate concern.
I have little intention of conducting a private exchange on the issue
so am sending to the bug. At the same time, I am reluctant to quote
what appears to be a private mail to me, so will merely outline the
important portion in my own words.

Rene Engelhard's opinion is that this is not an important bug and the
severity could be reduced to as low as wishlist. The essence of the
report's content was not addressed.

How is it intended a user is made aware of the capabilities of an IPP
printer and take advantage of them without cups-browsed on hand?

Regards,

Brian.

Bug#952748: libreoffice: Printer and queue attributes not available

[Rene Engelhard]

Hi,

On Fri, Feb 28, 2020 at 06:17:21PM +, Brian Potkin wrote:
> On Fri 28 Feb 2020 at 16:29:58 +0100, Rene Engelhard wrote:
> 
> > Keeping the bug explicitely out of the loop.
> 
> I do not understand why.

Because of my first point.

> The subject matter is of legitimate concern.

I didn't say otherwise.

> Rene Engelhard's opinion is that this is not an important bug and the
> severity could be reduced to as low as wishlist.

No, I said 

"It would be good to" is (imho) not a important bug though, but maybe
normal or minor or even wishlist.  

> The essence of the report's content was not addressed.

True. One step at a time. I also didn't say it wouldn't be adressed.
(In any case, this would be upstream who needed to address it in any
case.)

Regards,

Rene

Bug#952762: openstack-pkg-tools: please make the build reproducible

[Chris Lamb]

Source: openstack-pkg-tools
Version: 108
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
openstack-pkg-tools is causing other packages to be built in an
unreproducible manner.

In particular, the "/usr/bin/pkgos-dh_auto_install" script may 
nondeterministically create packages with differing shebangs and binary 
dependencies. For example, this is from src:redfishtool:

│ -#!/usr/bin/python3.7
│ +#!/usr/bin/python3.8

[…]

│ │ │ │ -Depends: python3-requests, python3.8:any, python3:any
│ │ │ │ +Depends: python3-requests, python3.7:any, python3:any

§

This is caused by a number of layered reasons. First, we are building
all supported Python versions (eg. Python 3.7 and Python 3.8) in
separate directories but then seqeuentially installing them to the
same destination, debian/${TARGET_DIR}.

However, this causes problems because if latter installations complete
in less than one second, distutils may decide to skip copying files in
the shared destination as it incorrectly believes them to be up-to-
date. This will result in a package arbitrarily containing scripts
with different version shebangs depending on the approximate total
execution speed of installation. This is, needless to say,
nondeterminstic.

For example, if we build for both Python 3.7 and Python 3.8 but the
installation of the latter occurs within the same wall clock second of
the former, the Python 3.8 version will not overwrite the Python 3.7
verison and lead to a shebang of #!/usr/bin/python3.7 … whilst if it
does not occur within the same second, the shebang will be overwritten
to #!/usr/bin/python3.8.

A patch is attached that passes --force to `setup.py install [..]`
which will avoid the underlying calls to distutils's `dep_util.newer`
and thus will always update.

  [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/build-tools/pkgos-dh_auto_install 
b/build-tools/pkgos-dh_auto_install
index 130ac59..2c639d9 100755
--- a/build-tools/pkgos-dh_auto_install
+++ b/build-tools/pkgos-dh_auto_install
@@ -37,7 +37,7 @@ fi
 
 if [ "${PKGOS_USE_PY2}" = "yes" ] ; then
for pyvers in ${PYTHONS}; do
-   python${pyvers} setup.py install --install-layout=deb --root 
$(pwd)/debian/python-${PY_MODULE_NAME}
+   python${pyvers} setup.py install --install-layout=deb --force 
--root $(pwd)/debian/python-${PY_MODULE_NAME}
done
 fi
 
@@ -48,7 +48,7 @@ if [ "${PKGOS_USE_PY3}" = "yes" ] ; then
TARGET_DIR=python3-${PY_MODULE_NAME}
fi
for pyvers in ${PYTHON3S}; do
-   python${pyvers} setup.py install --install-layout=deb --root 
$(pwd)/debian/${TARGET_DIR}
+   python${pyvers} setup.py install --install-layout=deb --force 
--root $(pwd)/debian/${TARGET_DIR}
done
 fi
 rm -rf $(pwd)/debian/python*/usr/lib/python*/dist-packages/*.pth

Bug#952761: python3-distutils: Dependencies broken, required version of Python not available.

[Tyler Weldon]

Package: python3-distutils
Version: 3.8.2-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Cannot install referenced package. Depends on Python3 >= 3.8.0-1~, however only 
Python3 3.7.5-3 is available. Possibly due to 
https://salsa.debian.org/cpython-team/python3-stdlib/-/commit/6aa4a17f1ec6cc2c37b6ee73e3a1f8d720e0610d
 ?

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

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

Versions of packages python3-distutils depends on:
ii  python3  3.7.5-3
pn  python3-lib2to3  

python3-distutils recommends no packages.

python3-distutils suggests no packages.

Bug#952760: RM: libmicrodns -- ROM; no longer used

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal

vlc no longer requires libmicrodns and it has no other reverse
dependencies. So please remove libmicrodns from unstable.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#948834: closed by Simon McVittie (Re: Bug#948834: glib2.0: FTBFS: gio/tests/gsocketclient-slow.c: Error resolving ?localhost?: Name or service not known)

[Mattia Rizzolo]

> On Wed, 26 Feb 2020 at 11:33:29 +, Simon McVittie wrote:
> > The good news is that GLib 2.63.x should fix this, because GLib 2.63.x
> > implements
> > 
> > and hard-codes "localhost" to resolve to 127.0.0.1 and/or ::1 (depending
> > on the requested address family).
> 
> This appears to work on reproducible-builds, so I'm closing this bug
> as fixed in experimental. The first GLib stable release with this in,
> 2.64.0, has just been released, so a fixed version should be on its way
> to unstable fairly soon.

That's great!

> I've opened a separate glibc bug report to query whether this is
> considered to be a glibc bug - I don't think fixing it in every consumer
> of the getaddrinfo() API is something that can scale.

TBH, I haven't spotted any other package failing for this...
I reckon glib2.0 has a much more extensive testuite than most packages
though…

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#952708: pagure: Please depend on httpd-wsgi3 instead of a particular WSGI server implementation

[Sergio Durigan Junior]

On Thursday, February 27 2020, Michael Fladischer wrote:

> Dear Maintainer,

Hi Michael,

Thanks for the report.

> there is a virtual package for Python3 WSGI servers called httpd-wsgi3. Right
> now only libapache2-mod-wsgi-py3 provides it but I have filed bugs against the
> other WSGI servers in the archive.
>
> This way installing pagure is not tied to a particular WSGI server 
> implementation.

I'm preparing an upload that will address this bug, but I have to say
that upstream doesn't officially support alternative (i.e., nginx/uwsgi)
implementations for now.  There was an attempt to get a working nginx
configuration, and some people even managed to do that, but that's been
2 years ago and I was told that the configuration doesn't work nowadays:

https://pagure.io/pagure/issue/2518
https://pagure.io/pagure/issue/1983

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Domenico Cufalo]

This is my output:

$ gsettings get org.gnome.desktop.input-sources sources
[('xkb', 'it'), ('xkb', 'gr'), ('xkb', 'de')]

Obviously the command "setxkbmap it" solves the problem, at least for the
current session.

In Italian keyboard, for example, round brackets are above the numbers 8
and 9, instead of 9 and 0.

The issue arose after updating the following packages:

Start-Date: 2020-02-28  00:30:26
Commandline: apt upgrade
Requested-By: domenico (1000)
Upgrade: libqt5test5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
qt5-gtk-platformtheme:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
libqt5dbus5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5sql5-sqlite:amd64
(5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5widgets5:amd64 (5.12.5+dfsg-8,
5.12.5+dfsg-9), xkb-data:amd64 (2.26-2, 2.29-1), libqt5xml5:amd64
(5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5printsupport5:amd64 (5.12.5+dfsg-8,
5.12.5+dfsg-9), libqt5concurrent5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
libqt5gui5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5core5a:amd64
(5.12.5+dfsg-8, 5.12.5+dfsg-9), libxml2:amd64 (2.9.10+dfsg-3,
2.9.10+dfsg-4), libqt5network5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
libqt5sql5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9)
End-Date: 2020-02-28  00:30:33

In the meantime, I think I will downgrade the package...

Regards,
Domenico

Bug#950772: Patch: swupdate: FTBFS during separate arch/indep builds

[林上智]

Hi Germann,

Iwamatsu-san and I have reviewed and merged the MR today, thank you
for the patch.

Regarding the MR in mtd-utils, I've merged the MR[1] as well.

[1] https://salsa.debian.org/debian/mtd-utils/merge_requests/5

Hi Iwamatsu-san,

Thank you for your branch clean-up today.

I think we need to keep "dfsg" in the version number since we need to
repack the source and remove minified JavaScript objects which
violated DFSG from upstream files.

SZ

Bastian Germann  於 2020年2月24日 週一 下午9:37寫道：
>
> When you take a closer look, please also consider my changes in #911821
> (mtd-utils).

Bug#952732: recode: Incorrect encoding of some characters when recoding to HTML_1.1

[Paul Courbis]

Le ven. 28 févr. 2020 à 15:45, Reuben Thomas  a écrit :

> On Fri, 28 Feb 2020 at 09:00, Paul Courbis BV 
> wrote:
>
>>* What was the outcome of this action?
>>Incorrect HTML code :
>>
>>
>
> As far as I can tell from looking at the code, these names are correct for
> HTML 1.1. The new names are used in HTML 1.2 (
> https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt) and later (and
> recode generates them correctly for those versions too, though recode only
> recognises version 2, not 1.2).
>
> I'm afraid I can't find a spec for HTML 1.1 online; it seems to be so old
> that it's not really considered a standard at all, and in any case there's
> no reason to be using it. I'm reluctant to make any changes without
> definitive documentation: looking at the code, this coding in recode has
> not changed since recode 3.4 in 1994, and François Pinard was pretty
> careful about this sort of thing (and both those letters are in his first
> language).
>

My bad
These characters where defined by https://tools.ietf.org/html/rfc1866 for
HTML 2.0
 and echo "î" | recode UTF_8..HTML_2.0 gives the correct answer

Sorry about that

Bug#952759: libsass-python: New upstream release available

[Michael Fladischer]

Source: libsass-python
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

right now there is 0.19.4 available from upstream. Would you consider uploading
an updated package to the archive?

Cheers,
Michael


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

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

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl5ZQfIRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wp0CAf/Qw7XsN1lXBnbsN3Bl0bFIT4HNWLlT3N2
PvZeW7wuZw7JZjfT+teu+X3HgUSRGj0V8+J+lSTDPFNRDsHCHCJIlnExE535b+sN
66/xOpW4KZ093AcuK45zlhachsz0dUH9U3manYWRj9PLNMRUSJD0QsvwoIKZNEqS
BuD2ZVuQQZfaLeaMSrpkx8IQJcM9nNYxjWlVhn7Ukmy912oAu+k7Fqs89lTgayeC
vJJn9Bi7P9olCCQ6ZFvlJqJEp3a3JWIre+/zTPALBMsf8Rk5h8VRqLlB8l+RCIqQ
z9cyR0agAOHu9GWg5IrcS9WlkcDNA53y3Dt93N3skWfh6PFt8IcOkg==
=A0zj
-END PGP SIGNATURE-

Bug#935923: libmodbus: FTBFS on hppa - unit-test-server: no process found

[Martin]

Maybe on slow™ architectures the waiting time after
starting the unit-test-server is just too short:

echo "Starting server"
./unit-test-server > $server_log 2>&1 &

sleep 1

echo "Starting client"
./unit-test-client > $client_log 2>&1

If that is really the problem, something like that is
probably better (untested, not even tried to compile):

--- a/tests/unit-test-server.c
+++ b/tests/unit-test-server.c
@@ -110,6 +110,9 @@
 }
 }

+int ready = open("READY", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666);
+close(ready);
+
 for (;;) {
 do {
 rc = modbus_receive(ctx, query);
--- a/tests/unit-tests.sh
+++ b/tests/unit-tests.sh
@@ -6,9 +6,13 @@
 rm -f $client_log $server_log

 echo "Starting server"
+rm -f READY
 ./unit-test-server > $server_log 2>&1 &

-sleep 1
+while [ ! -f READY ]; do
+sleep 1
+done
+rm -f READY

 echo "Starting client"
 ./unit-test-client > $client_log 2>&1

Bug#952758: RFS: dh-runit/2.8.15 [ITA] -- debhelper add-on to handle runit runscripts

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dh-runit"

 * Package name: dh-runit
   Version : 2.8.15
   Upstream Author : Dmitry Bogatov
 * URL : https://salsa.debian.org/debian/dh-runit
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/dh-runit
   Section : admin

It builds those binary packages:

  dh-runit - debhelper add-on to handle runit runscripts
  runit-helper - dh-runit implementation detail

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

  https://mentors.debian.net/package/dh-runit

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.8.15.dsc

Changes since the last upload:

   [ Dmitry Bogatov ]
   * Make dh-runit Multi-Arch: foreign (Closes: #939631)
 .
   [ Lorenzo Puliti ]
   * Remove log dir on purge (Closes: #941924)
   * Use .link to mark a service as disabled (Closes: #942323)
   * Adopt dh-runit package
   * Revert "Temporary disable testsuite due build-dependency transition"
   * Bump Standards Version to 4.5.0
 - use '_runit-log' user in logscripts instead of 'runit-log'
 - breaks and conflicts with runit << 2.1.2-36

NOTE: 
* the package is not officially listed as orphaned but the maintainer resigned 
after the GR, see
   
http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-December/002888.html
* updated salsa git repo
  https://salsa.debian.org/Lorenzo.ru.g-guest/dh-runit/-/tree/release-2.8.15
* should be uploaded toghether with runit 2.1.2-36


Regards,

--
  Lorenzo Puliti

Bug#952756: RFS: runit/2.1.2-36 [ITA] -- system-wide service supervision

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: runit
   Version : 2.1.2-36
   Upstream Author : Gerrit Pape 
 * URL : http://smarden.org/runit/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/runit
   Section : admin

It builds those binary packages:

  runit - system-wide service supervision
  runit-systemd - system-wide service supervision (systemd integration)
  runit-sysv - system-wide service supervision (sysv integration)
  getty-run - runscripts to supervise getty processes
  runit-init - system-wide service supervision (as init system)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-36.dsc

Changes since the last upload:

   * Use dot-symlink to mark a service as disabled (Closes: #942320)
   * Minor improvements to invoke-run (Closes: #943395)
   * Add finish-default (Closes: #943397)
   * Update invoke-run manpage for finish-default
   * Bump Standards Version to 4.5.0:
 - Create '_runit-log' user
   * New maintainer
   * Add a lintian override for runit

NOTE: 
* the package is not officially listed as orphaned but the maintainer resigned 
after the GR, see
   
http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-December/002888.html
* updated salsa git repo
   https://salsa.debian.org/Lorenzo.ru.g-guest/runit/-/tree/2.1.2-36-release
* should be uploaded toghether with dh-runit 2.8.15

Regards,

--
  Lorenzo Puliti

Bug#952757: mypy(1): build errors in man page

[rharwood]

Package: mypy
Version: 0.761-1
Severity: minor

Dear Maintainer,

The mypy man page (mypy(1)) has a lot of what appar to be build errors from
tranlation from rst to nroff.  Here's the first one:

```
   The directories are checked recursively to find Python source files.

   System Message: ERROR/3 (debian/mypy_options.rst:, line 3)
 Unknown directive type "program".

  .. program:: mypy

OPTIONS
```

Thanks,
--Robbie

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

Kernel: Linux 5.4.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mypy depends on:
ii  python3   3.7.5-3
ii  python3-mypy  0.761-1

mypy recommends no packages.

Versions of packages mypy suggests:
pn  mypy-doc  

-- no debconf information

Bug#936630: Re: Bug#936630: gnumed-client: upstream has (unreleased) py3 support

[Karsten Hilbert]

On Wed, Feb 05, 2020 at 11:17:39AM -0500, Scott Talbert wrote:

> BTW, the gnumed website seems to be having some problems.

I'm working on it.

https://www.gnumed.de/

Suitable for the watch file could be

https://www.gnumed.de/downloads/gnumed-versions.txt

or

https://www.gnumed.de/documentation/

or

https://www.gnumed.de/downloads/

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#952755: adminer: missing configuration files in stable

[Leonardo Canducci]

Package: adminer
Version: 4.7.5-1~bpo10+1
Severity: normal

Dear Maintainer,

adminer from stable is missing configuration (and docs) files. I just
installed the version from the backports repository and now I have:
- a README.Debian file that helps in the setup
- a con file in /etc/adminer
- a file in /etc/apache2/conf-available
- a working adminer install
I guess this package needs a fix to be useful in debian stable.

Thanks!
Leonardo

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

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

Versions of packages adminer depends on:
ii  libapache2-mod-php  2:7.3+69
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.14-1~deb10u1
ii  php 2:7.3+69
ii  php-fpm 2:7.3+69
ii  php-mysql   2:7.3+69
ii  php-pgsql   2:7.3+69
ii  php-sqlite3 2:7.3+69
ii  php7.3 [php]7.3.14-1~deb10u1
ii  php7.3-fpm [php-fpm]7.3.14-1~deb10u1
ii  php7.3-pgsql [php-pgsql]7.3.14-1~deb10u1
ii  php7.3-sqlite3 [php-sqlite3]7.3.14-1~deb10u1

Versions of packages adminer recommends:
ii  apache2 [httpd]   2.4.38-3+deb10u3
ii  php-cli   2:7.3+69
ii  php-mysql 2:7.3+69
ii  php-pgsql 2:7.3+69
ii  php-sqlite3   2:7.3+69
ii  php7.3-cli [php-cli]  7.3.14-1~deb10u1
ii  php7.3-pgsql [php-pgsql]  7.3.14-1~deb10u1
ii  php7.3-sqlite3 [php-sqlite3]  7.3.14-1~deb10u1

Versions of packages adminer suggests:
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.22-0+deb10u1
ii  sqlite3 3.27.2-3

-- no debconf information

Bug#952754: Acknowledgement (Remove reference to python-gdcm)

[Mathieu Malaterre]

fixed 952754 1.4.1-1
thanks

sorry for the noise

On Fri, Feb 28, 2020 at 4:45 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 952754: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952754.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Med Packaging Team 
>
> If you wish to submit further information on this problem, please
> send it to 952...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 952754: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952754
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Jean-Luc Coulon (f5ibh)]

Le 28/02/2020 à 15:55, Gunnar Hjalmarsson a écrit :
> On 2020-02-28 15:20, Michael Meskes wrote:
>> Anyway, it seems all layouts are not working, for me it's "de". A
>> manual "setxkbmap de" does fix the issue, though.
> 
> That makes me suspect that there is some issue in some GNOME package on
> Debian, which is not present on Ubuntu for some reason.
> 
> @Jean-Luc: Can you please run:
> 
> setxkbmap fr -variant oss
>
> and let us know if that workaround makes a difference for you too.
>

This is overwritten by gnome.

If I enter the connand it works for the session. If I reboot, I've the
keyboard is back to us.

I already tried that before reporting the bug.

--- From an other message 
>
> I see from the gsettings command output that you have two layouts
> enabled, and both those layouts work as expected for me.
>
> Can you please switch to "French (legacy, alt.)" and then back to >
"French (alt.)" and let us know if it makes a difference. Can you also
>check if the "French (legacy, alt.)" layout works as expected.

Nope, it is the same.

J-L

Bug#952754: Remove reference to python-gdcm

[Mathieu Malaterre]

Source: pydicom
Version: 1.2.1-1

python-gdcm is gone, please remove all reference to it (d/control).

Thanks

Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin

[Guilhem Moulin]

On Fri, 28 Feb 2020 at 05:40:10 +, jnq...@gmail.com wrote:
> edit: ah, so I see there were two reorganisations, one in June 2018 and
> one more in June 2019...

More precisely, one two-steps reorganisation with a Debian release in
between ;-)
 
> Indeed if I had performed a stable->stable->stable upgrade then I would
> not have encountered the error. I only question whether limiting
> upgrade compatibility so strictly is the best idea. Especially when a
> couple of breaks entries is a such a tiny things for a package to carry
> and enhances robustness.

As I wrote previously, adding the break isn't the only thing that would
have made your upgrade you smooth, the postinst script would like need
to be adapted too. 

While the side effect isn't intentional, not having the Breaks: on older
cryptsetups causes dpkg to fail, which I'd argue is better than ending
up with a broken (unbootable) systems.  Sure, we could test upgrade
paths from very old src:cryptsetups, but I'm not personally interested
in working on something that we as a project don't support.  Not keen
about the extra clutter either.  So right now I'm leaning towards
closing this as ‘wontfix’. :-P

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#952752: gajim-syntaxhighlight: d/copyright implies d/syntax_highlight.png is copyright by the Debian maintainer

[Sean Whitton]

control: retitle -1 gajim-syntaxhighlight: d/copyright implies 
d/syntax_highlight.svg is copyright by the Debian maintainer

Hello,

On Fri 28 Feb 2020 at 07:57AM -07, Sean Whitton wrote:

> Package: gajim-syntaxhighlight
> Version: 1.1.4-2
>
> ... but it is actually copyright upstream.

Of course, I meant debian/syntax_highlight.svg.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952753: python3-cassandra-doc: missing Breaks+Replaces: python3-cassandra (<< 3.20)

[Andreas Beckmann]

Package: python3-cassandra-doc
Version: 3.20.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-cassandra-doc_3.20.2-2_all.deb ...
  Unpacking python3-cassandra-doc (3.20.2-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-cassandra-doc_3.20.2-2_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/python3-cassandra/README.rst.gz', which 
is also in package python3-cassandra 3.16.0-2+b1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-cassandra-doc_3.20.2-2_all.deb


cheers,

Andreas


python3-cassandra=3.16.0-2+b1_python3-cassandra-doc=3.20.2-2.log.gz
Description: application/gzip

Bug#952732: recode: Incorrect encoding of some characters when recoding to HTML_1.1

[Reuben Thomas]

On Fri, 28 Feb 2020 at 09:00, Paul Courbis BV 
wrote:

>* What was the outcome of this action?
>Incorrect HTML code :
>
>

As far as I can tell from looking at the code, these names are correct for
HTML 1.1. The new names are used in HTML 1.2 (
https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt) and later (and
recode generates them correctly for those versions too, though recode only
recognises version 2, not 1.2).

I'm afraid I can't find a spec for HTML 1.1 online; it seems to be so old
that it's not really considered a standard at all, and in any case there's
no reason to be using it. I'm reluctant to make any changes without
definitive documentation: looking at the code, this coding in recode has
not changed since recode 3.4 in 1994, and François Pinard was pretty
careful about this sort of thing (and both those letters are in his first
language).

-- 
https://rrt.sc3d.org

Bug#942563: Workaround for older chips

[sixerjman]

This workaround from the Debian iwlwifi wiki seems to have fixed the
problem on my WiFi 5100 Link adapter:

Troubleshooting

Slow WiFi problems when using Bluetooth

Some devices like the 6235 do include a Bluetooth device in the same card,
which may lead into radio conflict. Newer devices (7200 and up) try to
solve them intelligently, but it is not the case of older ones.

If your WiFi is slow when using Bluetooth, try adding the following to
/etc/modprobe.d/iwlwifi.conf and reboot:

   -

   options iwlwifi bt_coex_active=0 swcrypto=1 11n_disable=8


https://wiki.debian.org/iwlwifi

Bug#952452: initramfs-tools: prefers serial console over framebuffer console

[Alper Nebi Yasak]

On 27/02/2020 02:10, Ben Hutchings wrote:

A device that is intended to be used with keyboard and video display
should not have this in the device tree for production units.  If we
ship the device tree then we can correct that.  If not, then the boot
loader should be configured to override it, and the installer could do
that by default.


I'm using rk3399-gru-kevin.dtb from the Debian package. The stdout-path 
property comes from arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi in the 
kernel tree. Setting a serial console this way seems to be ordinary, a 
lot of other devices have it too.


For the bootloader (part of the firmware), I don't know if there is a 
way to make it change that property in the device-tree file. Meanwhile 
I've added "console=tty0" to the default cmdline my bootloader-handler 
project uses, so everything should be fine for now.



I don't think it makes sense for initramfs-tools to do this, as the
wrong default console will still affect other software.


I intended to say that maybe initramfs-tools should correct the default 
console to the virtual console not just for itself but for the entire 
userspace. (I don't even know if that's possible.)

Bug#952751: eyes17: missing Breaks+Replaces: python3-expeyes (<< 4.6.1-2)

[Andreas Beckmann]

Package: eyes17
Version: 4.6.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../eyes17_4.6.2-1_all.deb ...
  Unpacking eyes17 (4.6.2-1) ...
  dpkg: error processing archive /var/cache/apt/archives/eyes17_4.6.2-1_all.deb 
(--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/eyes17/Peripherals.py', 
which is also in package python3-expeyes 4.4.4+dfsg-4
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/eyes17_4.6.2-1_all.deb

4.6.1-2 was the version that shuffled the modules around according
to the changelog.


cheers,

Andreas


python3-expeyes=4.4.4+dfsg-4_eyes17=4.6.2-1.log.gz
Description: application/gzip

Bug#952752: gajim-syntaxhighlight: d/copyright implies d/syntax_highlight.png is copyright by the Debian maintainer

[Sean Whitton]

Package: gajim-syntaxhighlight
Version: 1.1.4-2

... but it is actually copyright upstream.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Gunnar Hjalmarsson]

On 2020-02-28 15:20, Michael Meskes wrote:

Anyway, it seems all layouts are not working, for me it's "de". A
manual "setxkbmap de" does fix the issue, though.


That makes me suspect that there is some issue in some GNOME package on 
Debian, which is not present on Ubuntu for some reason.


@Jean-Luc: Can you please run:

setxkbmap fr -variant oss

and let us know if that workaround makes a difference for you too.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#952707: uwsgi-plugin-python3: Please provide httpd-wsgi3 virtual package

[Michael Fladischer]

Am 28.02.2020 um 14:25 schrieb Thomas Goirand:

Except uwsgi, which other package would provide httpd-wsgi3?


Right now, gunicorn and libapache2-mod-wsgi-py3. I have a filed a bug 
(#952705) for chaussette to also provide it.


Cheers,
Michael

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Gunnar Hjalmarsson]

Thanks for additional info, Jean-Luc.

On 2020-02-28 14:14, Jean-Luc Coulon (f5ibh) wrote:

Well, maybe it is difficult to explain as everything is… in French
;)


You can start Settings by pressing + and enter:

env LANGUAGE=en_US gnome-control-center

to get it temporarily in English.


but please see the attached screenshot of what I get from the gnome
preferences.


Just did. Looks good to me.


I suppose "Français(variante)" is "French(alt.)"


It is.


If I use 2.29, I get the same layout from the preferences but the
actual keybord is a us (at least qwerty) layout.


I see from the gsettings command output that you have two layouts 
enabled, and both those layouts work as expected for me.


Can you please switch to "French (legacy, alt.)" and then back to 
"French (alt.)" and let us know if it makes a difference. Can you also 
check if the "French (legacy, alt.)" layout works as expected.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#949576: libiptc-dev: Breaks/Replaces missing between libiptc-dev and libip4tc-dev

[Jamie Strandboge]

Package: iptables
Version: 1.8.4-3
Followup-For: Bug #949576
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear Maintainer,

The Breaks/Replaces added to fix this bug were not quite correct (we saw this
in Ubuntu: https://launchpad.net/bugs/1865055). I've adjusted the
Breaks/Replaces in the attached patch to follow case 9 of
https://wiki.debian.org/PackageTransition and it fixes the issue.

The Ubuntu changelog entry:

  * debian/control: correct Breaks/Replaces for ipt_kernel_headers.h
move from libiptc-dev to libip4tc-dev (LP: #1865055)


Thanks for considering the patch.


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

Kernel: Linux 5.4.0-14-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru iptables-1.8.4/debian/control iptables-1.8.4/debian/control
--- iptables-1.8.4/debian/control   2020-02-13 16:23:25.0 -0600
+++ iptables-1.8.4/debian/control   2020-02-28 08:16:32.0 -0600
@@ -1,8 +1,7 @@
 Source: iptables
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Netfilter Packaging Team 

+Maintainer: Debian Netfilter Packaging Team 

 Uploaders: Arturo Borrero Gonzalez ,
Alberto Molina Coballes ,
Laurence J. Lane 
@@ -100,7 +99,6 @@
 Depends: libip4tc-dev (=${binary:Version}),
  libip6tc-dev (=${binary:Version}),
  ${misc:Depends}
-Replaces: libip4tc-dev (<< 1.8.4-2)
 Breaks: libip4tc-dev (<< 1.8.4-2)
 Section: libdevel
 Description: Common development files for libiptc
@@ -133,8 +131,8 @@
 Pre-Depends: ${misc:Pre-Depends}
 Depends: libip4tc2 (=${binary:Version}),
  ${misc:Depends}
-Replaces: iptables-dev (<< 1.6.0-3)
-Breaks: iptables-dev (<< 1.6.0-3)
+Replaces: iptables-dev (<< 1.6.0-3), libiptc-dev (<< 1.8.4-2)
+Breaks: iptables-dev (<< 1.6.0-3), libiptc-dev (<< 1.8.4-2)
 Section: libdevel
 Description: Development files for libip4tc
  The iptables/xtables framework has been replaced by nftables. You should

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Michael Meskes]

> Sorry to hear that, but I wonder if this is actually triggered by
> something else.. at least I'm not able to reproduce it with .fi layout
> on ubuntu focal..

Even if the package is exactly the same I don't see how a "I cannot reproduce
on Ubuntu" is helpful, sorry. There may be any number of packages that make it
work there but not here. 

Anyway, it seems all layouts are not working, for me it's "de". A manual
"setxkbmap de" does fix the issue, though. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#952750: python3-jenkinsapi: missing (unversioned) Breaks+Replaces: python-jenkinsapi

[Andreas Beckmann]

Package: python3-jenkinsapi
Version: 0.3.11-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-jenkinsapi_0.3.11-1_all.deb ...
  Unpacking python3-jenkinsapi (0.3.11-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-jenkinsapi_0.3.11-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/jenkins_invoke', which is also in package 
python-jenkinsapi 0.2.30-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-jenkinsapi_0.3.11-1_all.deb

Since the binary package python-jenkinsapi is gone, the
Breaks+Replaces can be unversioned.


cheers,

Andreas


python-jenkinsapi=0.2.30-1_python3-jenkinsapi=0.3.11-1.log.gz
Description: application/gzip

Bug#947754: Follow-up 947754

[Er_Maqui]

Package: gitlab
Version: 12.6.7-1+fto10+1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Bug is still present (and checked) on 12.6.7.
I haven't done any configuration changes.

https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYf0F71OtDykDsKZdCU2zE9sy6H8FAl5ZDz0ACgkQCU2zE9sy
6H/T+hAAterVOsUsTM17jZeuyOORJaVpjq+y9//zheA0GA+jBk43K4zzS1+x4j0U
80yqPmF2vyt63nzhX6q+Pwvfa0A3JOk1tmKuGivdRGCRWnQ/dnmvWkbGZHC/UAAR
pTHOINdAum+2p4UZByXrBCm88dZHVD9N0d6OL/+SbIWi7s2MqHbjKQBW+CvlRzG7
Tj2m4Q/RBpZr/Sj0yDS5pCRCk9pQ4m83uiCWKuVb1KvZBBcqJ95Of8tjC62aLFzl
SrW1d0+xh4hAIh6u40j5QZftpCaJUwCWK345likslD6NnH3wKRMZObnKoW5ya+3D
YpRNMnGLfNYW6Z3sZbNQYdpLLLayhRsF5MYPf2qMh3V5kENIWDWOeKATVbklvbz9
kgw47gJ79MBjmjNehLFB1V7OoT6sEbqM7yPH2dvvWg+9pOWPG2v460YupCyt7OZ/
RA3ATjIM3sAgyy/QPVgntXVEiidlRywx5+dRmqfd9WvsjYdM3D6emKP5u7weTSmT
cRlC7j7xB68ZXk7uW7+Im2sMNrdyfQpEVH9YsD0xcF5qi/y8k4p1mzrGMJGMerZy
CFkL97qQRTADT8cZCpsUNjHNLlVwcP2qe5zON4+rem5v3/tKSwneDF+IaX0gy9+Q
lcOFEMsFkaNlCTxBX0A1gGYHVhFJNKld1nCU9XOwrneUbMP9x6k=
=LfI5
-END PGP SIGNATURE-

Bug#952749: texlive-extra-utils: bibtexu segfault

[Philipp Klaus Krause]

Package: texlive-extra-utils
Version: 2019.202000218-1
Severity: important

bibtexu segfaults for me (bibtex works for the same files):

(gdb) run
Starting program: /usr/bin/bibtexu zshg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
The top-level auxiliary file: zshg.aux
The style file: plain.bst
Database file #1: zshg.bib

Program received signal SIGSEGV, Segmentation fault.
0x77b54942 in ucnv_fromUnicode_UTF8_63 () from /usr/lib/x86_64-linux-
gnu/libicuuc.so.63

.aux and .bib files to reproduce the issue:

http://colecovision.eu/stuff/zshg.aux
http://colecovision.eu/stuff/zshg.bib



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Jul  6  2017 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 317 Jul  6  2017 /etc/texmf/ls-R
-rw-r--r-- 1 root root 1791 Feb 23 10:42 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Dec  3 11:04 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Feb 17 23:37 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Feb 17 23:37 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Dec  9 09:52 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 17 23:37 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
-rw-r--r-- 1 root root 0 Nov  8  2017 /etc/texmf/web2c/updmap.cfg
-rw-r--r-- 1 root root 4177 Feb 23 10:42 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 17  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Dec  9 09:52 texmf.cnf
-rw-r--r-- 1 root root   0 Nov  8  2017 updmap.cfg
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-extra-utils depends on:
ii  libunicode-linebreak-perl  0.0.20190101-1+b2
ii  python33.7.5-3
ii  tex-common 6.13
ii  texlive-base   2019.20200218-1
ii  texlive-binaries   2019.20190605.51237-3
ii  texlive-latex-base 2019.20200218-1

Versions of packages texlive-extra-utils recommends:
ii  ghostscript9.50~dfsg-5
ii  libfile-homedir-perl   1.004-1
ii  liblog-log4perl-perl   1.49-1
pn  libyaml-tiny-perl  
ii  ruby   1:2.5.2
ii  texlive-latex-recommended  2019.20200218-1

Versions of packages texlive-extra-utils suggests:
pn  chktex  
pn  dvidvi  
ii  dvipng  1.15-1.1+b1
pn  fragmaster  
pn  lacheck 
pn  latexdiff   
pn  latexmk 
pn  purifyeps   
pn  xindy   

Versions of packages 

Bug#945936: haskell-enummapset-th: Removal notice: unused Haskell library

[Ilias Tsitsimpis]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: haskell-enummapset-th -- ROM; unused
Control: severity -1 normal

Hi,

Please remove haskell-enummapset-th from Debian. This Haskell library
has not been updated since 2016 and does not build with newer GHC (we
use custom patches for this). Also, it is not on Stackage and has no
reverse dependencies.

Thanks,

-- 
Ilias

Bug#945935: haskell-hackage-mirror: Removal notice: unmaintained

[Ilias Tsitsimpis]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: haskell-hackage-mirror -- ROM; broken and unmaintained
Control: severity -1 normal

Hi,

Please remove haskell-hackage-mirror from Debian. This package is no
longer maintained upstream. For more information see:

  https://github.com/fpco/hackage-mirror/blob/master/README.md

Thanks,

-- 
Ilias

Bug#952748: libreoffice: Printer and queue attributes not available

[Brian Potkin]

Package: libreoffice
Version: 1:6.4.1~rc1-2
Severity: important


I have an up-to-date unstable system with CUPS and cups-filters
installed. cups-browsed is not installed.

The print dialog has two entries: ENVY4500 and LaserJet_300_desktop.
The ENVY is an IPP printer on the network and the LaserJet is an
advertised queue on a remote CUPS server. The enumeration is done via
DNS-SD from the printer and the server and both devices are capable of
two-sided printing. All ok up to there.

Looking under Properties/Device the only option is "Manual feed". This
means that a user cannot set values for Media Type, Color Model
and Print Quality when these attributes are available on printer or
queue. Here is an output from querying the printer:

brian@cupstest:~$ lpoptions -p envy4500 -l
PageSize/Media Size: 100x150mm 111.76x152.4mm 3.5x5 3.5x5.Borderless 3x5
   4x6 4x6.Borderless 5x7 5x7.Borderless 
5x8 8x10 8x10.Borderless *A4
 A4.Borderless A5 A6 A6.Borderless B5 Env10 EnvA2 EnvC5 EnvC6 EnvChou3  
EnvChou4 EnvDL EnvMonarch EnvPersonal 
Executive ISOB5 Legal Letter
 Letter.Borderless Postcard Postcard.Borderless Statement Custom.WIDTHxHEIGHT
MediaType/Media Type: *Stationery PhotographicGlossy
ColorModel/Output Mode: *RGB Gray Gray16 DeviceGray DeviceRGB AdobeRGB
Duplex/Duplex: *None DuplexNoTumble DuplexTumble
cupsPrintQuality/cupsPrintQuality: Draft *Normal High
brian@cupstest:~$

If the printer or print queue is printed to, CUPS forms a temporary,
local queue and a PPD is generated in /etc/cups/ppd from the queries
made. This queue exists for a minute and during that time Device is
populated and attributes from the PPD are made available in the print
dialog.

It seems to me that the dialog is not querying either printer or queue
to get their attributes to display, but, OTOH, is happy to deal with
local queues, which is what cups-browsed supplies. It would be good to
take full advantage of what CUPS offers and fix this unsatisfactory
behaviour.

Regards,

Brian.

Bug#945013: haskell-gnuidn: Removal notice: unmaintained

[Ilias Tsitsimpis]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: haskell-gnuidn -- ROM; broken and unmaintained
Control: severity -1 normal
Control: block -1 945012

Hi,

Please remove haskell-gnuidn from Debian. This package seems to be
unmaintained upstream[1]. Its last upload was at 2015, and the home
page[2] returns 404.

[1] https://hackage.haskell.org/package/gnuidn
[2] https://john-millikin.com/software/haskell-gnuidn/

It is also not on Stackage and has no reverse dependencies (other than
haskell-network-protocol-xmpp, but see #945012).

Thanks,

-- 
Ilias

Bug#945012: haskell-network-protocol-xmpp: Removal notice: unmaintained

[Ilias Tsitsimpis]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: haskell-network-protocol-xmpp -- ROM; unused
Control: severity -1 normal

Hi,

Please remove haskell-network-protocol-xmpp from Debian. It is unused,
has no reverse dependencies and depends on unmaintained software
(haskell-gnuidn).

Thanks,

-- 
Ilias

Bug#950585: binutils-dev: included log files introduce reproducibility issues

[Matthias Klose]

On 2/24/20 11:09 PM, Vagrant Cascadian wrote:
> On 2020-02-22, Matthias Klose wrote:
>>> I'm not sure what the rationale for including these test logs in the
>>> package is, but from a reproducible builds perspective, ideally these
>>> would simply not be included at all.
>>
>> that's not an option.  this is all useful information for debugging purposes,
>> and you'll find that in the GCC packages as well.  Having it turned off by
>> default defeats the purpose.
> 
> So, my attempt at sanitizing them removed too much information; ok.
> 
> Why can't these test logs be output to the build log instead of being
> embedded in the package? What's the use-case that needs them to be in
> the package itself?
> 
> From what I recall, binutils was reproducible in debian testing for a
> while before these logs were added. While GCC was not ever reproducible
> thus far, it is another core part of the toolchain that I would hope
> could one day be made reproducible.

cat'ing to stdout is possible, yes, however that will add to the log size.
gcc-N-test-results is a 13MB compressed package. This doesn't scale.

>> I think I filed a bug report that builds should be
>> able to generate their own artifacts, as the autopkg tests are doing that,
>> however that probably will take a while to implement.
> 
> I would be very interested in this bug report; against what package?

hmm, that was Ubuntu only:
https://bugs.launchpad.net/launchpad/+bug/1845159

Feel free to forward that. sbuild, pbuilder?

>> Or you could add a override database for files which are expected to differ.
> 
> This is considerably more complicated than running a checksum on the
> resulting .deb files and is another opportunity for bugs to lead to
> incorrect reproducibility results... which I think has actually happened
> when trying this kind of approach in the past, though I don't have a
> reference off the top of my head.
> 
> Exploring avenues to put files like this into some separate artifact for
> things that are not reproducible might be one avenue; I know that the
> debian-installer packages ship some artifacts which are not
> .deb/.dbgsym/.udeb... but this still makes it more difficult to compare
> the resulting objects... worried about how to get that right, but maybe
> we, as reproducible builds, need to explore that an an option?
> 
> 
> live well,
>   vagrant
> 

Bug#945011: haskell-cabal-helper: Removal notice: unused Haskell library

[Ilias Tsitsimpis]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: haskell-cabal-helper -- ROM; unused Haskell library
Control: severity -1 normal

Hi,

Please remove haskell-cabal-helper from Debian. This Haskell library is
not part of Buster, is not on Stackage and is already ignored on our
package-plan.

Thanks,

-- 
Ilias