Bug#914489: [Pkg-nagios-devel] Bug#914489: nagios-nrpe-plugin: SSL connections to "old" (as in Jessie) nagios-nrpe-server(s) broken
On Sat, Nov 24, 2018 at 08:45:21AM +0100, Sebastiaan Couwenberg wrote: > tags 914489 wontfix > thanks > > Hi Alberto, > > On 11/23/18 9:26 PM, Alberto Gonzalez Iniesta wrote: > > After updating nagios-nrpe-plugin in my monitoring host to > > 3.2.1-1~bpo9+1 most of my monitored instances fail to be checked. > > That is due to changes in openssl, we have no control over that. > > For machines with an old openssl you need to disable SSL with -n. > > Kind Regards, > > Bas > Hi Sebastiaan, Please consider adding a warning regarding this (openssl) issue to the nagios-nrpe-plugin package so that users don't have to struggle finding this out when they upgrade. Thanks for your work! Regards, Alberto -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico mailto/sip: a...@inittab.org | en GNU/Linux y software libre Encrypted mail preferred| http://inittab.com Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55
Bug#904009: closed by Sandro Tosi (Re: Bug#904009: reportbug: Backspace, arrow keys and more thing like ctrl+c are not working in some programs)
I am sorry, I don't understand the explanation for closing this bug. It happens out of the box (fresh install) for various applications, on different machines without having any user modifications done. So I have to assume some more global issue. How can the average user be expected to dig out a solution for this or asking for it not having the slightest clue where it is coming from. It shouldn't happen in the first place. Due to some lucky incident I stumbled last week across an older Ubuntu question very similar to mine and it appeared to be the same issue, it is said there that the problem is somehow caused by gtk ibus and I was able to make a workaround by setting input method to scim. Maybe this helps to identify what's going on there. ~Jochen On 11/24/18 7:30 AM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the reportbug package: #904009: reportbug: Backspace, arrow keys and more thing like ctrl+c are not working in some programs It has been closed by Sandro Tosi . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Sandro Tosi by replying to this email.
Bug#864079: ITP: backuppc-rsync -- rsync optimised for BackupPC backup utility
On Fri, Nov 16, 2018 at 03:14:36AM +0100, Axel Beckert wrote: > Hi, > > Tobias Frost wrote: > > Yes, we're are on it (however, I hoped to dedicate a bit more time to > > this week) > > Before creating a VCS repo for it: I wonder why the package is ITP'ed > as "backuppc-rsync" despite upstream calls the software "rsync-bpc". > > Shouldn't we name the package then "rsync-bpc", too? > Hi, In fact this version of rsync can only work with backuppc. So I think it would be better to keep this name, to reduce possible confusions. Best regards, -- Ludovic Drolez. https://drolez.com/web - Marketing automation and Web dev https://chezsandro.com - A cool place in Cape Verde :)
Bug#864079: ITP: backuppc-rsync -- rsync optimised for BackupPC backup utility
> So shall we start with 3.0.9.12 or 3.1.2.beta0? (I tend to stay on the > safe side and start with 3.0.9.12, but then we at least should try to > apply all security updates against rsync 3.0.9 in Wheezy.) I think you can use rsync 3.1.2, in my git I had a working version based on 3.1.2: https://github.com/ldrolez/backuppc-rsync Have a nice day, -- Ludovic Drolez. https://bwebmarket.com - Marketing automation and Web dev https://chezsandro.com - A cool place in Cape Verde :)
Bug#914512: php-apcu: Rename to php7.2-apcu?
Package: php-apcu Version: 5.1.12+4.0.11-2 Severity: normal Dear Maintainer, Most of the other PHP packages are prefixed with the version number, for example "php7.2-gd", "php7.2-curl", etc. This allows multiple PHP versions to be installed side-by-side. However, the APCU package is just called "php-apcu". Is there a reason for this difference? It means I'm unable to have PHP 7.1 and 7.2 installed side-by-side each with a packaged version of apcu, and instead need to build from source. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages php-apcu depends on: ii libc62.27-8 ii php-common 1:62 ii php7.3-cli [phpapi-20180731] 7.3.0~rc4-1 ii php7.3-phpdbg [phpapi-20180731] 7.3.0~rc4-1 Versions of packages php-apcu recommends: ii php-apcu-bc 1.0.4-3 Versions of packages php-apcu suggests: ii php7.1-gd [php-gd] 7.1.16-1 ii php7.2-gd [php-gd] 7.2.4-1 -- no debconf information
Bug#914456: qemu: new qemu 3.0.0
> > Please consider to upgrade to the current upstream version of qemu > (3.0.0). > Actually IMHO we are just 11 days away from 3.1 [1] Maybe do the work just once and directly prep 3.1 instead of doing ->3.0 and then ->3.1 later? [1]: https://wiki.qemu.org/Planning/3.1
Bug#914513: [boost1.67] make Python links consistent
Package: boost1.67
Version: 1.67.0-10
Severity: important
Hi,
the symbolic links created in Python-related Boost packages are
currently inconsistent, both with the past and between themselves. While
some change was actually intended to happen, the current situation does
not seem ideal. This bug is to discuss what Boost maintainers want to
happen with Python libraries and associated symbolic links.
The following is my proposal; other Boost maintainers and other
interested parties, please comment on it, so that Boost maintainers can
take a final decision reasonably quickly.
There are currently three Python-related packages in Boost, which are
"python", "mpi-python" and "numpy". The variable PACKAGE will iterate on
their underscore versions (which are "python", "mpi_python" and
"numpy"). The variable BOOST_VERSION will contain the Boost version,
currently "1.67.0". The variable PY2_VERSION and PY3_VERSION will
iterate on the supported Python 2 and 3 dotless versions (currently
"27", "36" and "37" if I am not mistaken). The variable PY2_DEFAULT and
PY3_DEFAULT will take the value of the default Python 2 and 3 versions
(currently "27" and "36").
All files are of course installed in /usr/lib/triplet.
The library packages install the following file, which is the actual
compiled shared object:
libboost_${PACKAGE}${PY2_VERSION}.so.${BOOST_VERSION}
libboost_${PACKAGE}${PY3_VERSION}.so.${BOOST_VERSION}
(the mpi-python package additionally installs actual Python extensions,
which are managed by dh_python* scripts and thus are not relevant here)
The development packages install the following file, which is the
statically compiled library:
libboost_${PACKAGE}${PY2_VERSION}.a
libboost_${PACKAGE}${PY3_VERSION}.a
Additionally, they install the following symbolic links:
libboost_${PACKAGE}.so
-> libboost_${PACKAGE}${PY2_DEFAULT}.so
libboost_${PACKAGE}2.so
-> libboost_${PACKAGE}${PY2_DEFAULT}.so
libboost_${PACKAGE}3.so
-> libboost_${PACKAGE}${PY3_DEFAULT}.so
libboost_${PACKAGE}${PY2_VERSION}.so
-> libboost_${PACKAGE}${PY2_VERSION}.so.${BOOST_VERSION}
libboost_${PACKAGE}${PY3_VERSION}.so
-> libboost_${PACKAGE}${PY3_VERSION}.so.${BOOST_VERSION}
libboost_${PACKAGE}.a
-> libboost_${PACKAGE}${PY2_DEFAULT}.a
libboost_${PACKAGE}2.a
-> libboost_${PACKAGE}${PY2_DEFAULT}.a
libboost_${PACKAGE}3.a
-> libboost_${PACKAGE}${PY3_DEFAULT}.a
They also install the following symbolic links, meant for compatibility
with previous Boost package versions in Debian:
libboost_${PACKAGE}-py${PY2_VERSION}.so
-> libboost_${PACKAGE}${PY2_VERSION}.so
libboost_${PACKAGE}-py${PY3_VERSION}.so
-> libboost_${PACKAGE}${PY3_VERSION}.so
libboost_${PACKAGE}-py${PY2_VERSION}.a
-> libboost_${PACKAGE}${PY2_VERSION}.a
libboost_${PACKAGE}-py${PY3_VERSION}.a
-> libboost_${PACKAGE}${PY3_VERSION}.a
Is this ok for everybody? Once a decision is taken, I can proceed to fix
the package.
Thanks, Giovanni.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
signature.asc
Description: OpenPGP digital signature
Bug#914514: atop: should use logrotate for log rotation
Package: atop Version: 2.3.0-1+b1 Severity: normal Dear Maintainer, In managing my log directory and customize logrotate, I discovered limitations in the way atop handles log files (which are different from text files since they are process accounting files,, to my understanding). Can this package use logrotate like other debian packages? It's confusing, and then to discover that /usr/share/atop/atop.daily is executed from a shell script in the background, made me think that atop log handling could be greatly improved. There are other bugs related to log file handling: #877148 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877148 I had to directly modify the /usr/share/atop/atop.daily to achieve my temporary goal (accumulate more logfiles) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core) 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: SELinux: enabled - Mode: Enforcing - Policy name: default Versions of packages atop depends on: ii libc62.27-8 ii libncurses6 6.1+20181013-1 ii libtinfo66.1+20181013-1 ii lsb-base 9.20170808 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages atop recommends: ii cron [cron-daemon] 3.0pl1-130 atop suggests no packages. -- no debconf information
Bug#914140: pytango FTBFS with boost 1.67
Hi, Il 22/11/18 20:39, Adrian Bunk ha scritto: > I don't know, adding the boost maintainers to Cc for that. I posted a new bug to discuss the issue of Python links. Please, follow the discussion there and bring your contribution if necessary. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914513 Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#914515: dpkg: please provide an interface to bootstrap dpkg from zero
Package: dpkg Version: 1.19.2 Severity: wishlist Hi, lintian recently tagged mmdebstrap with uses-dpkg-database-directly because mmdebstrap contains the string "/var/lib/dpkg" in several places. Instead of overwriting the lintian tag in mmdebstrap, dpkg could also gain an interface which avoids mmdebstrap having to do anything with /var/lib/dpkg inside the chroot. Specifically, what mmdebstrap does is the following: - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info, /var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg throws an error if these directories are not present - an empty /var/lib/dpkg/status because dpkg refuses to work without the file being present - adds architectures to /var/lib/dpkg/arch because $(dpkg --add-architecture) doesn't work without any packages inside the chroot - cleans up leftover /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock This could be avoided if: - dpkg would not complain anymore about non-existing directories but instead create them if they don't exist yet - dpkg would not complain about a non-existing status file but create an empty one if it doesn't exist yet - allow $(dpkg --add-architecture) to work in places other than / - add an interface to clean up /var/lib/dpkg Thanks! cheers, josch
Bug#907178: gimp-plugin-registry: resynthesizer not appearing in menu Filters/Enhance
Package: gimp-plugin-registry Version: 9.20180625 Followup-For: Bug #907178 Dear Maintainer, indeed, it seems resynthesize is currently broken, one cannot use the "Heal" filters. That's a bummer, these filters are the only reason I have gimp-plugin-registry installed to begin with. Kind regards, Ralf -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp-plugin-registry depends on: ii gimp 2.10.6-3 ii libatk1.0-0 2.30.0-1 ii libbabl-0.1-00.1.58-1 ii libc62.27-8 ii libcairo21.16.0-1 ii libfontconfig1 2.13.1-1 ii libfreetype6 2.8.1-2 ii libfribidi0 1.0.5-3 ii libgcc1 1:8.2.0-9 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libgegl-0.4-00.4.10-1 ii libgimp2.0 2.10.6-3 ii libglib2.0-0 2.58.1-2 ii libgtk2.0-0 2.24.32-3 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjson-glib-1.0-0 1.4.4-1 ii liblcms2-2 2.9-3 ii liblqr-1-0 0.4.2-2.1 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpangoft2-1.0-01.42.4-3 ii libstdc++6 8.2.0-9 ii libtiff-tools4.0.9+git181026-1 ii libtiff5 4.0.9+git181026-1 ii python 2.7.15-3 ii xdg-utils1.1.3-1 Versions of packages gimp-plugin-registry recommends: ii gimp-gmic 1.7.9+zart-4.1+b1 Versions of packages gimp-plugin-registry suggests: ii icc-profiles 2.1-2 -- no debconf information
Bug#914516: transition: hunspell
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition hunspell 1.7 was finally released. It includes a load of fixes we miss e.g. in LibreOffice because instead of using the patched-internal version we use the system version. Cleared NEW just now. So I'd like to get this transition done asap after icu/boost/python3.7-as-default is done :) Did a rebuild using ratt and (almost) all packages built fine, except some otherwise failing packages (mudlet and plume-creator (both sid only) because of #907159 and #887534) I skipped firefox, too; firefox-esr is fine. (And libreoffice, but libreoffice is "of course" fine, too) Ben file: title = "hunspell"; is_affected = .depends ~ "libhunspell-1.6-0" | .depends ~ "libhunspell-1.7-0"; is_good = .depends ~ "libhunspell-1.7-0"; is_bad = .depends ~ "libhunspell-1.6-0"; (or auto-hunspell) Regards, Rene
Bug#914516: transition: hunspell
Hi, On Sat, Nov 24, 2018 at 11:07:25AM +0100, Rene Engelhard wrote: > Did a rebuild using ratt and (almost) all packages built fine, except > some otherwise failing packages (mudlet and plume-creator (both sid > only) because of #907159 and #887534) Sorry, missed one: aegisub (also sid-only): #873327 Regards, Rene
Bug#914050: python-casacore FTBFS with boost 1.67
Control: tags -1 pending This is fixed by applying the Ubuntu patch; see https://salsa.debian.org/debian-astro-team/python-casacore/commit/e9c03147 However, it currently does not build due to another problem connected with the recent casacore transition.
Bug#863602: nginx: Restart should check conf files before stopping service
Op vr 23 nov. 2018 om 10:55 schreef Christos Trochalakis : > >What about ExecStartPre? > > It's already at `ExecStartPre=` [0], the problem is that in `systemd > restart nginx` ExecStartPre is executed **after** the service is > stopped, not in the start of the sequence. In that case, does it make sense to use ExecStartPre after all? Just trying to start nginx would be simpler. > [0] $ systemctl cat nginx.service|grep ^ExecStartPre= > > > >> ExecStartPre=, ExecStartPost= > > > >> Additional commands that are executed before or after the command in > >> ExecStart=, respectively. Syntax is the same as for ExecStart=, except > >> that multiple command lines are allowed and the commands are executed one > >> after the other, serially. > > > >> If any of those commands (not prefixed with "-") fail, the rest are not > >> executed and the unit is considered failed. > >> > >> >Perhaps even better, but I'm not sure if systemd and nginx supports > >> >this, would be for the new instance to be fully started before the old > >> >one is stopped. > >> > > >> > >> This can be done (in both sysvinit & systemd) systems by running > >> `/etc/init.d/nginx upgrade` but in your case a binary upgrade is not > >> needed, just a config reload (nginx -s reload). > > > >Could "service nginx restart" use this same logic? > >Users and packages probably don't know about nginx upgrade and will be > >using the standard interfaces... > > No, service restart just calls systemctl restart on systemd systems. > I think that both nginx restart & upgrade are commands that are rarely > needed in my experience: `service nginx reload` is what you usually need > and luckily that works as expected on both systemd & sysvinit. Makes sense. -- Olaf
Bug#914373: octave-statistics: accessing installed functions is needlessly obscure
[Moving this discussion from Bug#914373 into debian-octave.] * James Van Zandt [2018-11-22 13:34]: [snip] Please provide a file /usr/share/doc/octave-statistics/README.Debian with a note something like By default installed packages are not available from the Octave prompt. The functions from this package can be added to the Octave path by typing pkg load statistics at the Octave command line. [snip] The bug reporter also suggests to add README.Debian files for all other OF packages. Do the other members of the DOG agree with this change? Rafael
Bug#910506: split package into architecture dependent and independent ones
Note, that the package split has been reverted in 0.11~hg20181007.7c1cdf5f9f83-2, because other team members objected.
Bug#914373: octave-statistics: accessing installed functions is needlessly obscure
Le samedi 24 novembre 2018 à 11:43 +0100, Rafael Laboissière a écrit : > [Moving this discussion from Bug#914373 into debian-octave.] > > * James Van Zandt [2018-11-22 13:34]: > > > > [snip] > > > > Please provide a file /usr/share/doc/octave- > > statistics/README.Debian > > with a note something like > > > > By default installed packages are not available from the Octave > > prompt. The functions from this package can be added to the > > Octave > > path by typing > > > > pkg load statistics > > > > at the Octave command line. > > > > [snip] > > The bug reporter also suggests to add README.Debian files for all > other OF packages. > > Do the other members of the DOG agree with this change? That seems excessive to me. The fact that OF packages are not auto- loaded is the consequence of a global setting (in Octave itself), so it does not make sense to document it in individual packages. I would rather update the README.Debian of octave. It currently tells never to use the "pkg" command, which is bad advice, since that command is needed to load the packages. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#911154: Bug#912120: Bug#911154: netkit-ntalk misses the generator for configure
Adrian Bunk wrote... > Any update on that? As I wrote in the previous message, allow me until end of November to create the fixes. This still is my plan. Christoph signature.asc Description: PGP signature
Bug#902025: Any news on the emacs 26 front ?
Well, it's too late for turkey stuffing. Any hopes for stockings ? What is the "copyright question" you're alluding to ? I also noted that there does not seem to be any unversioned version of the docs (emacs-common-non-dfsg) : the package is known to dpkg, but uninstallable. One has to install emacs25-common-non-dfsg. This is a problem : emacs is too large a piece of software to go without a manual. Since the software is now unversioned, the manual should be also. Would it be helpfulto file a bug against this ? Cordially, -- Emmanuel Charpentier Le jeudi 11 octobre 2018 à 15:08 -0500, Rob Browning a écrit : > Emmanuel Charpentier writes: > > > an no news since... > > > > Is there any hope to get emacs 26.1 as, say, stockings filler ? Or > > as > > turkey stuffing ? > > I'd certainly hope so, but right now we're blocked on some copyright > questions, in particular with respect to some of the unicode.org > files > that Emacs includes. I've contacted them, and my understanding is > that > they're looking in to it, but we haven't heard back yet. > > Once that's resolved, the remaining work shouldn't take too long. > > Thanks
Bug#914499: RFS: wxmaxima/18.11.0-1
Control: tags -1 moreinfo On Sat, Nov 24, 2018 at 12:34:52AM +0100, Gunter Königsmann wrote: >... > Changes since the last upload: > > * New upstream release that drastically improves the drawing speed, provides > a better lisp mode, >improves the loop of the program and fixes many bugs lintian is unhappy about 18.11.2-1: W: wxmaxima: debian-changelog-has-wrong-day-of-week 2018-10-24 is a Wednesday Please provide a fixed package (same version is fine). > Regards, >Gunter. > cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#914518: wxmaxima: Homepage field is outdated
Package: wxmaxima Version: 18.10.2-1 Severity: minor The Homepage filed points to a no longer exisiting page, current upstream seems to be http://wxmaxima-developers.github.io/wxmaxima/
Bug#914519: nmu: dovecot-antispam_2.0+20171229-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu The following packages have unmet dependencies: dovecot-antispam : Depends: dovecot-abi-2.3.abiv3 but it is not installable nmu dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "Rebuild against dovecot 2.3.4"
Bug#827672: Bug #827672: WDM crashes after user logged in if selinux is enabled (and in permissive mode)
Dear Maintainer, hello Klaus Ethgen,
I just tried to get some more information out of this bug.
I could not reproduce it with a stretch testing or unstable
as of date 2016-07-20 inside a i386 qemu VM.
As far as I see is the problematic function in WDM:
(gdb) list ManageSession# wdm-1.28/src/wdm/session.c
...
522 static Bool
523 StartClient (
524 struct verify_info *verify,
525 struct display *d,
526 int *pidp,
527 char*name,
528 char*passwd)
529 {
...
627 #ifdef WITH_SELINUX
628 if (is_selinux_enabled())
629 {
630 security_context_t scontext;
631 if (get_default_context(name,NULL,&scontext))
632 WDMError("Failed to get default security
context"
633 " for %s.", name);
634 WDMDebug("setting security context to %s",
scontext);
635 if (setexeccon(scontext))
636 {
637 freecon(scontext);
638 WDMError("Failed to set exec security
context %s "
639 "for %s.", scontext, name);
640 }
641 freecon(scontext);
642 }
643 #endif
There it looks like function get_default_context failed - the message
"Failed to get default security context" appears in the log.
Therefore variable scontext may have stayed uninitilized,
which led to the observed crash in line 637, when trying to free
that uninitilized pointer.
(gdb) list freecon # libselinux-2.5/src/freecon.c
5
6 void freecon(char * con)
7 {
8 free(con);
9 }
I think this crash may happen with current testing version of wdm too,
when get_default_context fails.
But why in the first place the get_default_context may have failed I cannot say.
Does this problem still occour?
Or is it known if there was a selinux misconfiguration on this machine at that
time?
Was there any other selinux configuration done?
Attached file shows some notes about the debugging attempts.
Kind regards,
Bernhard
wdm: *** Error in `-:0 ': free(): invalid pointer: 0x80101d24 ***
wdm: === Backtrace: =
wdm: /lib/i386-linux-gnu/libc.so.6(+0x6929b)[0xb738a29b] |
0x...29b |
wdm: /lib/i386-linux-gnu/libc.so.6(+0x6f527)[0xb7390527] |
0x...527 |
wdm: /lib/i386-linux-gnu/libc.so.6(+0x6fcd1)[0xb7390cd1] |
0x...cd1 |
wdm: /lib/i386-linux-gnu/libselinux.so.1(freecon+0x18)[0xb750a698] |
0x...698 | 0xb7df7698: 0xb7df7693 :call 0xb7df25b0
wdm: -:0 (+0xd104)[0x800f4104] |
0x...104 | 0x8000d104: 0x8000d0ff : call 0x80002d80
; 637 freecon(scontext);
wdm: -:0 (+0x8450)[0x800ef450] |
0x...450 | 0x80008450: 0x8000844b : call 0x8000c9b0
wdm: -:0 (+0x8828)[0x800ef828] |
0x...828 | 0x80008828: 0x80008826 : call *%esi
wdm: -:0 (+0x8077)[0x800ef077] |
0x...077 | 0x80008077: 0x80008072 : call 0x80008800
wdm: -:0 (+0xe24e)[0x800f524e] |
0x...24e | 0x8000e24e: 0x8000e249 :call 0x80007b60
wdm: -:0 (main+0x1a5)[0x800e9ff5] |
0x...ff5 | 0x80002ff5: 0x80002ff0 : call 0x8000e200
wdm: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xb7339517] |
0x...517 |
wdm: -:0 (+0x3327)[0x800ea327] |
0x...327 |
# starting with current Stretch i386
apt install devscripts dpkg-dev xserver-xorg wdm gdb
wget
http://snapshot.debian.org/archive/debian/20160507T220956Z/pool/main/w/wdm/wdm_1.28-19_i386.deb
wget
http://snapshot.debian.org/archive/debian-debug/20160507T215014Z/pool/main/w/wdm/wdm-dbgsym_1.28-19_i386.deb
wget
http://snapshot.debian.org/archive/debian/20160517T222057Z/pool/main/libs/libselinux/libselinux1_2.5-3_i386.deb
wget
http://snapshot.debian.org/archive/debian-debug/20160517T215638Z/pool/main/libs/libselinux/libselinux1-dbgsym_2.5-3_i386.deb
dpkg -i *.deb
mkdir wdm/orig -p
cdwdm/orig
dget
http://snapshot.debian.org/archive/debian-debug/20160507T215014Z/pool/main/w/wdm/wdm_1.28-19.dsc
cd ../..
mkdir libselinux/orig -p
cdlibselinux/orig
dget
http://snapshot.debian.org/archive/debian-debug/20160517T215638Z/pool/main/libs/libselinux/libselinux_2.5-3.dsc
cd ../..
benutzer@debian:~$ gdb -q --args /usr/bin/wdm
Reading symbols from
Bug#914520: cppcheck FTBFS on architectures where char is unsigned
Source: cppcheck Version: 1.85-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=cppcheck&suite=sid ... Testing Complete Number of tests: 3289 Number of todos: 208 Tests failed: 2 test/testsymboldatabase.cpp:5164: Assertion failed. Expected: 1 Actual: 0 _ test/testsymboldatabase.cpp:5185: Assertion failed. Expected: 1 Actual: 0 _ make[2]: *** [Makefile:248: test] Error 1
Bug#914521: cdo FTBFS on 32bit: undefined reference to `pstreamInqGRIBinfo(int, int*, float*, long*)'
Source: cdo Version: 1.9.6~rc4-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=cdo&suite=sid ... /usr/bin/ld: cdo-Gradsdes.o: in function `Gradsdes(void*)': ./src/Gradsdes.cc:1293: undefined reference to `pstreamInqGRIBinfo(int, int*, float*, long*)' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:1079: cdo] Error 1
Bug#914188: [debian-mysql] Bug#914188: mariadb-server: Upgrade faild due to 'unknown variable': 'server_audit_file_path=/path/to/audit.log'
Hello Faustin, I had the same issue. Then commented out the audit plugin lines in the configuration file, finished the upgrade and un-commented them again. These are my configuration files (with some info removed): # cat /etc/mysql/mariadb.cnf | grep -v ^# [client-server] !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mariadb.conf.d/ and # cat /etc/mysql/mariadb.conf.d/50-server.cnf | grep -v ^# [server] [mysqld] user= mysql pid-file= /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port= 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking open_files_limit = 24000 server_audit_events=CONNECT,TABLE,QUERY_DCL server_audit_logging=on server_audit_output_type=syslog server_audit_syslog_facility=LOG_LOCAL2 bind-address= REMOVED key_buffer_size = 16M max_allowed_packet = 16M thread_stack= 192K thread_cache_size = 8 myisam_recover_options = BACKUP query_cache_limit = 1M query_cache_size= 16M log_error = /var/log/mysql/error.log expire_logs_days= 10 max_binlog_size = 100M ssl-ca=REMOVED.pem ssl-cert=REMOVED.pem ssl-key=REMOVED.pem ssl=on character-set-server = utf8mb4 collation-server = utf8mb4_general_ci [embedded] [mariadb] [mariadb-10.1] These are server audit variables: SHOW GLOBAL VARIABLES LIKE '%server_audit%'; +---+-+ | Variable_name | Value | +---+-+ | server_audit_events | CONNECT,TABLE,QUERY_DCL | | server_audit_excl_users | | | server_audit_file_path| server_audit.log| | server_audit_file_rotate_now | OFF | | server_audit_file_rotate_size | 100 | | server_audit_file_rotations | 9 | | server_audit_incl_users | | | server_audit_logging | ON | | server_audit_mode | 0 | | server_audit_output_type | syslog | | server_audit_query_log_limit | 1024| | server_audit_syslog_facility | LOG_LOCAL2 | | server_audit_syslog_ident | mysql-server_auditing | | server_audit_syslog_info | | | server_audit_syslog_priority | LOG_INFO| +---+-+ Maybe the issue happens with "server_audit_events" enabled? I installed this Debian stable system in March 2018, no previous mysql or mariadb versions before that. Best regards, Marco Il 22/11/18 20:06, Faustin Lammler ha scritto: Marc, I am not able to reproduce this. Here are my steps: - installation of mariadb-server-10.1_10.1.26-0+deb9u1; - load and activation of the audit plugin: $ cat /etc/mysql/my.cnf | grep -v ^# [mysqld] plugin_load=server_audit=server_audit.so server_audit_file_path=/var/log/mysql/mariadb_server_audit.log server_audit_logging=ON [client-server] !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mariadb.conf.d/ - restart mariadb and check that plugin is loaded and activated; - upgrade to mariadb-server-10.1_10.1.37-0+deb9u1; $ sudo apt-get dist-upgrade - check that audit plugin is still activated; Can you give me the content of you /etc/mysql/my.cnf file? Is it possible that on your system a previous version of mariadb/mysql was installed (before 10.1.26)?
Bug#914522: sigil: Uninstallable as it depends on Python << 3.7
Package: sigil Version: 0.9.10+dfsg-1 Severity: serious Hi, for a few days now, the python3 metapackage is at 3.7.1-… and since then sigil became uninstallable in Sid due to its dependency on "python3 (<< 3.7)". A rebuild/BinNMU against the newer python3 package might already fix this. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages sigil depends on: ii libc6 2.27-8 ii libgcc11:8.2.0-10 ii libhunspell-1.6-0 1.6.2-2 ii libhunspell-dev1.6.2-2 ii libjs-jquery-scrollto 2.1.2+dfsg-5 ii libjs-mathjax 2.7.4+dfsg-1 ii libminizip11.1-8+b1 ii libpcre16-32:8.39-11 ii libpython3.6 3.6.7-1 ii libqt5concurrent5 5.11.2+dfsg-7 ii libqt5core5a 5.11.2+dfsg-7 ii libqt5gui5 5.11.2+dfsg-7 ii libqt5printsupport55.11.2+dfsg-7 ii libqt5webkit5 5.212.0~alpha2-17+b1 ii libqt5widgets5 5.11.2+dfsg-7 ii libstdc++6 8.2.0-10 ii python33.6.7-1 ii python3-lxml 4.2.5-1 ii sigil-data 0.9.10+dfsg-1 Versions of packages sigil recommends: ii python3-chardet3.0.4-1 ii python3-cssselect 1.0.3-1 ii python3-cssutils 1.0.2-1 ii python3-html5lib 1.0.1-1 ii python3-pil5.3.0-1 ii python3-pyqt5 5.11.3+dfsg-1+b1 ii python3-regex 0.1.20180609-1+b1 ii python3-six1.11.0-2 sigil suggests no packages. -- no debconf information
Bug#914518: wxmaxima: Homepage field is outdated
Wow... ...your message coincided with a report of a bad bug I had to correct, too => mentors now contains an updated package with a new service release of wxMaxima. Thanks a lot! and Kind regards, Gunter. On 24.11.18 13:02, Adrian Bunk wrote: > Package: wxmaxima > Version: 18.10.2-1 > Severity: minor > > The Homepage filed points to a no longer exisiting page, > current upstream seems to be > http://wxmaxima-developers.github.io/wxmaxima/
Bug#914522: sigil: Uninstallable as it depends on Python << 3.7
Hi, Axel Beckert wrote: > for a few days now, the python3 metapackage is at 3.7.1-… and since then > sigil became uninstallable in Sid due to its dependency on "python3 (<< > 3.7)". > > A rebuild/BinNMU against the newer python3 package might already fix > this. JFTR: I see quite some issues like this, but no transition hints in neither the PTS nor the Package Tracker. And there was also no announcement on d-d-a like for the (compared to this very smooth) Perl transition. (If I would have seen a hint on a such a transition, I wouldn't have filed that bug report.) Is this an uncoordinated transition? 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#910607:
Per upstream; this seems to be a kernel bug which is fixed in 4.18.20. Unclear whether the fix (1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00) can be cherrypicked back to current stable / bpo kernels; investigating.
Bug#911625: libboost-python1.62.0: insufficient python dependencies allow early upgrade, breaking stretch->buster upgrades
Hi, Il 22/10/18 20:59, Andreas Beckmann ha scritto: > Just an idea, do not know if this can be implemented efficiently: > > If libboost-python1.62.0 provides pythonX.Y-libboost-python1.62.0 > and the consumers depend on pythonX.Y-libboost-python1.62.0 instead of > (or in addition to) libboost-python1.62.0, everything should be fine. I see the problem, thanks for bringing this up. I agree with your solution: basically we let Boost.Python expose the Python versions it is compiled with, so that packages can depend on the right version. It seems reasonable. I would just change the provided package name, because calling something "pythonX.Y-name" seems to imply that there is an actual Python extension called "name" inside, which is not the case here. I would use something like "libboost-python1.62.0-pyXY". Also, I'll do the same for boost1.67, which would have the same problem. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#914523: RM: rarian -- RoM; RoQA; unmaintained, no longer used
Package: ftp.debian.org X-Debbugs-Cc: rar...@packages.debian.org Affects: src:rarian Tags: moreinfo Control: block -1 by 885638 Please remove rarian from Debian. Its last release was a decade ago. .omf files are no longer needed for displaying DocBook help files. There is one package still using rarian so I added the moreinfo tag. I'll remove the tag once the fixed package has built in unstable. On behalf of the Debian GNOME team, Jeremy Bicha
Bug#914522: sigil: Uninstallable as it depends on Python << 3.7
Hi Mattia, Mattia Rizzolo wrote: > > JFTR: I see quite some issues like this, but no transition hints in > > neither the PTS nor the Package Tracker. And there was also no > > announcement on d-d-a like for the (compared to this very smooth) Perl > > transition. (If I would have seen a hint on a such a transition, I > > wouldn't have filed that bug report.) Is this an uncoordinated > > transition? > > It's coordinated, it started 3 days ago, but since then pochu have yet > to trigger the rebuilds... IIRC pochu also did parts (if not most) of the near-perfect Perl 5.28 transition I was refering, too. > https://release.debian.org/transitions/html/python3.7-default.html Oh, ok, then sorry for the noise. Maybe there's an issue with propagating the transitions to or displaying them in the PTS and Package Tracker then? For sigil, there's only a QtBase and a hunspell transition listed in both, PTS and Package Tracker. 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#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Hi, On 11/24/18 2:19 AM, Cesare Leonardi wrote: > > On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg > wrote: >> You didn't share any part of your logging. Can you share a part of dmesg >> logging that shows Oops in it? > > Here it is, attached to this message. > Previously I didn't attached it because to me it looks substantially the > same as the one I attached in the opening message of this bug (#913119). Thanks. Your logging indeed also only shows the 'task [...] blocked for more than 120 seconds', and no actual OOPS messages. >> If a task hangs while doing disk IO, it might cause messages like these >> in dmesg: >> >> INFO: task kthxbye:1157 blocked for more than 120 seconds. >> Not tainted blah #1 Debian someversion >> [...] >> >> >> These are 'just' informational messages. The process will still wait >> until it can continue. >> >> A kernel Oops is something really different. It usually means that some >> data structures or code to be executed are corrupt and there's a real >> problem going on, it's not just stalled and waiting. > > Thank you very much for this explanation: I didn't know this difference > and indeed I realized that I didn't know what a oops really is. I'm unfortunately not the person who can fix this issue. Anyway, it's good to confirm there is no actual real oops in your log. :) Hans
Bug#914522: sigil: Uninstallable as it depends on Python << 3.7
On Sat, Nov 24, 2018 at 02:55:20PM +0100, Axel Beckert wrote: > > It's coordinated, it started 3 days ago, but since then pochu have yet > > to trigger the rebuilds... > > IIRC pochu also did parts (if not most) of the near-perfect Perl 5.28 > transition I was refering, too. Yes, pochu deals with pretty much all library transitions, the other RT memembers rarely do anything in that regards. > > https://release.debian.org/transitions/html/python3.7-default.html > > Oh, ok, then sorry for the noise. > > Maybe there's an issue with propagating the transitions to or > displaying them in the PTS and Package Tracker then? > > For sigil, there's only a QtBase and a hunspell transition listed in > both, PTS and Package Tracker. Possibly. TBH I have no idea how the tracker/PTS finds the ongoing transitions... -- 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#914126: svtplay-dl: bugs out on urplay.se
On Fri, 23 Nov 2018, Olof Johansson wrote:
> On 18-11-19 18:37 +0100, Cristian Ionescu-Idbohrn wrote:
> > This is what I see:
> ...
> > requests.exceptions.SSLError:
> > HTTPSConnectionPool(host='streaming-loadbalancer.ur.se', port=443): Max
> > retries exceeded with url: /loadbalancer.json (Caused by
> > SSLError(SSLError("bad handshake: Error([('SSL routines',
> > 'ssl_choose_client_version', 'unsupported protocol')],)",),))
> >
> > when trying to download:
> >
> > https://urplay.se/program/204949-roster-fran-australiens-aboriginer
> >
> > for example. Works fine when playing it in chromium, though.
> >
> > Downloading from svtplay.se works fine, though.
>
> Thanks for the report, I have been postponing upgrading to the
> new 2.0+ version, but should get on that asap. Hopefully that
> should solve it.
Doesn't seem so :( I tested with master (2.1-14-g72143b7). Similar
problem. Attaching a trace done with that version.
Cheers,
--
Cristian$ ~/DEVEL/svtplay-dl/svtplay-dl --verbose -P hls -g
https://urplay.se/program/204949-roster-fran-australiens-aboriginer
DEBUG [1543056480.152882]
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/utils/getmedia.py/get_media: version:
2.1-14-g72143b7
DEBUG [1543056480.1539545]
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/service/__init__.py/__init__: service:
urplay
DEBUG [1543056480.1540117]
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/utils/http.py/request: HTTP getting
'https://urplay.se/program/204949-roster-fran-australiens-aboriginer'
DEBUG [1543056480.155448]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting
new HTTPS connection (1): urplay.se:443
DEBUG [1543056480.2892246]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_make_request:
https://urplay.se:443 "GET /program/204949-roster-fran-australiens-aboriginer
HTTP/1.1" 200 16422
DEBUG [1543056480.292382]
~/DEVEL/svtplay-dl/svtplay-dl/svtplay_dl/utils/http.py/request: HTTP getting
'https://streaming-loadbalancer.ur.se/loadbalancer.json'
DEBUG [1543056480.2933757]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting
new HTTPS connection (1): streaming-loadbalancer.ur.se:443
DEBUG [1543056480.3410475]
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented
Retry for (url='/loadbalancer.json'): Retry(total=4, connect=5, read=5,
redirect=None, status=None)
WARNING [1543056480.341197]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying
(Retry(total=4, connect=5, read=5, redirect=None, status=None)) after
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines',
'ssl_choose_client_version', 'unsupported protocol')],)",),)':
/loadbalancer.json
DEBUG [1543056480.3413193]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting
new HTTPS connection (2): streaming-loadbalancer.ur.se:443
DEBUG [1543056480.3939955]
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented
Retry for (url='/loadbalancer.json'): Retry(total=3, connect=5, read=5,
redirect=None, status=None)
WARNING [1543056480.994881]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying
(Retry(total=3, connect=5, read=5, redirect=None, status=None)) after
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines',
'ssl_choose_client_version', 'unsupported protocol')],)",),)':
/loadbalancer.json
DEBUG [1543056480.9951062]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting
new HTTPS connection (3): streaming-loadbalancer.ur.se:443
DEBUG [1543056481.0753078]
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented
Retry for (url='/loadbalancer.json'): Retry(total=2, connect=5, read=5,
redirect=None, status=None)
WARNING [1543056482.2757819]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying
(Retry(total=2, connect=5, read=5, redirect=None, status=None)) after
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines',
'ssl_choose_client_version', 'unsupported protocol')],)",),)':
/loadbalancer.json
DEBUG [1543056482.2761137]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting
new HTTPS connection (4): streaming-loadbalancer.ur.se:443
DEBUG [1543056482.3429654]
/usr/lib/python3/dist-packages/urllib3/util/retry.py/increment: Incremented
Retry for (url='/loadbalancer.json'): Retry(total=1, connect=5, read=5,
redirect=None, status=None)
WARNING [1543056484.7437494]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/urlopen: Retrying
(Retry(total=1, connect=5, read=5, redirect=None, status=None)) after
connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines',
'ssl_choose_client_version', 'unsupported protocol')],)",),)':
/loadbalancer.json
DEBUG [1543056484.7439423]
/usr/lib/python3/dist-packages/urllib3/connectionpool.py/_new_conn: Starting
new HTTPS connection (5): str
Bug#914524: sogo: SSL problem(?) causes 'An error occurred during object publishing' in webmail
Package: sogo Version: 4.0.4-1 Severity: important Dear Maintainer, * What led up to the situation? New installation of sogo on a clean debian buster machine * What exactly did you do (or not do) that was effective (or ineffective)? Configured sogo with ldap backend and mail capabilities. When opening ghe wemail interface sogo replies with 'An error occurred during object publishing - the requested object could not be found!' In the log there are error messages: Error (objc-load):/usr/lib/GNUstep/SOGo/MailPartViewers.SOGo/MailPartViewers: undefined symbol: SSL_load_error_strings Error (objc-load):/usr/lib/GNUstep/SOGo/MailerUI.SOGo/MailerUI: undefined symbol: __objc_class_name_UIxMailSizeFormatter Nov 16 04:08:48 sogod [18909]: [so-product-registry] could not load product: MailPartViewers Nov 16 04:08:48 sogod [18909]: [so-product-registry] could not load product: MailerUI -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sogo depends on: ii adduser 3.118 ii gnustep-base-runtime 1.25.1-4+b1 ii libc6 2.27-8 ii libcurl3-gnutls 7.61.0-1 ii libgcc1 1:8.2.0-9 ii libglib2.0-0 2.58.1-2 ii libgnustep-base1.25 1.25.1-4+b1 ii libgnutls30 3.5.19-1+b1 ii liblasso3 2.6.0-2+b2 ii libmemcached111.0.18-4.2 ii libobjc4 8.2.0-9 ii libsbjson2.3 2.3.2-3+b1 ii libsope1 4.0.4-1 ii lsb-base 9.20170808 ii memcached 1.5.6-1 ii sogo-common 4.0.4-1 ii systemd 239-13 ii zip 3.0-11+b1 sogo recommends no packages. Versions of packages sogo suggests: ii postgresql 11+197 -- Configuration Files: /etc/cron.d/sogo changed [not included] /etc/sogo/sogo.conf changed [not included] -- no debconf information
Bug#914525: mosquitto: fails to build on non-linux
Source: mosquitto Version: 1.5.4-1 Severity: normal Tags: patch Dear Maintainer, I noticed the new version of mosquitto failed to build on hurd. My thoughts was that this was because of the long-standing breakage in libsystemd-dummy that no non-linux porter seems to have had time to fix (see #830935). I fixed up libsystemd-dummy to verify this but unfortunately all the blame can not be put on non-linux porters this time. (I'll upload the fixed version shortly.) Apparently conf.mk hard-codes the linker flags instead of using pkg-config to retrieve them (which would end up blank with libsystemd.pc from libsystemd-dummy). Thus there are two options to fix mosquitto build on hurd: 1. start using pkg-config and replace the hardcoded -lsystemd 2. include special-casing in debian/rules The attached patch does the latter as it seemed easiest and least controversial. Please note the patch has only been (build-)tested on hurd, so you might want to give it a spin yourself (on linux) and verify the correct configure arguments are used. Regards, Andreas Henriksson diff -Nru mosquitto-1.5.4/debian/changelog mosquitto-1.5.4/debian/changelog --- mosquitto-1.5.4/debian/changelog2018-11-08 13:34:59.0 + +++ mosquitto-1.5.4/debian/changelog2018-11-24 13:41:32.0 + @@ -1,3 +1,12 @@ +mosquitto (1.5.4-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * debian/rules: Only enable WITH_SYSTEMD=yes on linux +- this is needed as mosquitto build system doesn't use pkg-config + and instead hardcodes systemd linker flags. + + -- Andreas Henriksson Sat, 24 Nov 2018 13:41:32 + + mosquitto (1.5.4-1) unstable; urgency=medium * New upstream release (Closes: #911104). diff -Nru mosquitto-1.5.4/debian/rules mosquitto-1.5.4/debian/rules --- mosquitto-1.5.4/debian/rules2018-11-08 13:34:59.0 + +++ mosquitto-1.5.4/debian/rules2018-11-24 13:41:32.0 + @@ -1,8 +1,10 @@ #!/usr/bin/make -f +include /usr/share/dpkg/architecture.mk + export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed export prefix=/usr -export libdir=/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +export libdir=/usr/lib/$(DEB_HOST_MULTIARCH) %: dh $@ @@ -14,7 +16,10 @@ # Don't process CMake rules, CMakeLists.txt is only included for Windows/Mac support. override_dh_auto_build: - make WITH_BUNDLED_DEPS=no WITH_ADNS=yes WITH_WRAP=yes WITH_WEBSOCKETS=yes WITH_STRIP=no WITH_SYSTEMD=yes +ifneq (,$(findstring linux,$(DEB_HOST_ARCH_OS))) + CONFARGS="WITH_SYSTEMD=yes" +endif + make WITH_BUNDLED_DEPS=no WITH_ADNS=yes WITH_WRAP=yes WITH_WEBSOCKETS=yes WITH_STRIP=no $(CONFARGS) override_dh_auto_test:
Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes
Michael Biebl: fwiw, this is why I suggested to provide a C implementation of init-d-script which can be used as an interpreter That's how it was addressed in 2007. * https://github.com/OpenRC/openrc/commit/5af58b45146ab5253ca964738f4e45287bf963d4 * http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2018-November/000340.html The OpenRC people have already learned many of the lessons through experience here, long since. There are the difficulties in handling rc scripts that people have symbolically linked to a common worker script, for example. They also went through the exit code of the interpreter thing in a minor way with exit 0 when starting a service in 2008 and again in more detail in 2011. * https://bugs.gentoo.org/show_bug.cgi?id=351160
Bug#914526: linux-image-4.18.0-0.bpo.1-amd64: Invalidating filesystems can corrupt dentry table leading to busy loop in kernel.
Package: src:linux Version: 4.18.6-1~bpo9+1 Severity: important Tags: upstream patch Please see https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-linus - invalidating filesystems can cause dentry table corruption leading to busy loop in kernel. Easily triggered from userspace (observed triggers using NFS, XFS and ZFS). Patch supplied upstream; please consider cherrypicking this to BPO kernel. Thanks. -- Package-specific info: ** Version: Linux version 4.18.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.18.6-1~bpo9+1 (2018-09-13) ** Command line: BOOT_IMAGE=/boot@/boot/vmlinuz-4.18.0-0.bpo.1-amd64 root=ZFS=rpool/boot ro ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: product_name: product_version: chassis_vendor: chassis_version: bios_vendor: Intel Corporation bios_version: MYBDWi30.86A.0038.2016.0913.1446 board_vendor: Intel Corporation board_name: NUC5i3MYBE board_version: H47781-206 ** Loaded modules: xt_nat cfg80211 xt_tcpmss ipt_MASQUERADE xt_limit xt_recent ip6table_nat nf_nat_ipv6 ip6t_REJECT nf_reject_ipv6 ip6table_mangle ip6table_raw nf_conntrack_ipv6 nf_defrag_ipv6 nf_log_ipv6 ip6table_filter ip6_tables xt_comment iptable_nat nf_nat_ipv4 ipt_REJECT nf_reject_ipv4 xt_addrtype bridge xt_mark iptable_mangle xt_TCPMSS xt_tcpudp xt_CT iptable_raw xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack xt_NFLOG xt_LOG nf_log_ipv4 nf_log_common nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack libcrc32c crc32c_generic iptable_filter nfnetlink_queue nfnetlink_log nfnetlink bluetooth drbg ansi_cprng ecdh_generic rfkill crc16 pppoe pppox ppp_generic slhc binfmt_misc nls_ascii nls_cp437 vfat fat intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt iTCO_vendor_support evdev kvm i915 irqbypass crct10dif_pclmul crc32_pclmul pl2303 drm_kms_helper usbserial ghash_clmulni_intel sg drm intel_cstate mei_me mei intel_uncore lpc_ich pcspkr efi_pstore intel_rapl_perf efivars video button acpi_pad pcc_cpufreq bonding 8021q garp mrp stp llc efivarfs ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) sd_mod crc32c_intel ahci libahci libata igb i2c_algo_bit scsi_mod dca aesni_intel xhci_pci ehci_pci xhci_hcd ehci_hcd aes_x86_64 crypto_simd i2c_i801 cryptd glue_helper usbcore e1000e usb_common fan thermal ** PCI devices: not available ** USB devices: Bus 001 Device 002: ID 8087:8001 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 2109:0813 VIA Labs, Inc. Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303] Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 002 Device 002: ID 2109:2813 VIA Labs, Inc. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (700, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.18.0-0.bpo.1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.130 ii kmod23-2 ii linux-base 4.5 Versions of packages linux-image-4.18.0-0.bpo.1-amd64 recommends: ii apparmor 2.11.0-3+deb9u2 ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2.3 Versions of packages linux-image-4.18.0-0.bpo.1-amd64 suggests: pn debian-kernel-handbook ii grub-efi-amd64 2.02~beta3-5+deb9u1 pn linux-doc-4.18 Versions of packages linux-image-4.18.0-0.bpo.1-amd64 is related to: ii firmware-amd-graphics 20180825+dfsg-1~bpo9+1 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas ii firmware-linux-nonfree20180825+dfsg-1~bpo9+1 ii firmware-misc-nonfree 20180825+dfs
Bug#914527: dwarves: update package description
package: dwarves severity: minor x-debbugs-cc: Domenico Andreoli , debian-de...@lists.debian.org On Sat, Nov 24, 2018 at 03:28:37PM +0100, Domenico Andreoli wrote: > after some ~7 years of inactivty I've been able to put a new upstream > release of dwarves together. It's at https://salsa.d.o/debian/dwarves. this made me read the package description which reads/starts: Description-en: set of advanced DWARF utilities This package contains tools that use the DWARF debugging information inserted in ELF binaries by the compiler. This information is already used by debuggers (e.g. GDB), and more recent tools such as systemtap. I'd suggest you update this to Description-en: set of advanced DWARF utilities This package contains tools that use the DWARF debugging information inserted in ELF binaries by the compiler. This information is used by debuggers (e.g. GDB), and other tools such as systemtap. or some such. > In the meanwhile that I resurrect my old 1024 bits key, sign the new one > and also get some signatures I might have somewhere, I need a sponsor > to upload this package. Any volunteer? sorry, not me. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#914528: game-data-packager: kyrandia1: Add support for new GOG installer
Package: game-data-packager Version: 61 Hello, Here is a simple patch for Kyrandia 1 adding support for a GOG installer. Mew, >From 514f3e7ee4f1ee0fa8e823766e6a605368e34664 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?cacato=C3=A8s?= Date: Sat, 24 Nov 2018 15:20:50 +0100 Subject: [PATCH] kyrandia1: Add support for new GOG installer --- data/kyrandia1.yaml | 9 + 1 file changed, 9 insertions(+) diff --git a/data/kyrandia1.yaml b/data/kyrandia1.yaml index 730560b5..41095dee 100644 --- a/data/kyrandia1.yaml +++ b/data/kyrandia1.yaml @@ -56,6 +56,14 @@ files: - assets english - manual.pdf + setup_legend_of_kyrandia_2.0.0.11.exe: +unpack: + format: innoextract +provides: +- assets common +- assets english +- manual.pdf + setup_legend_of_kyrandia_1.1_(20270).exe: unpack: format: innoextract @@ -99,6 +107,7 @@ files: groups: archives: | 53747640 562a149d31069f70c3ab92f05aca96e0 setup_legend_of_kyrandia_2.1.0.14.exe + 55844432 0001370b8bb598b9a9289a2c3d29 setup_legend_of_kyrandia_2.0.0.11.exe 54434128 03b283612879edeb4eecfd111662d0ee setup_legend_of_kyrandia_1.1_(20270).exe 53761456 087261e9ec6de9b395fee90b028f6e8b setup_legend_of_kyrandia_german_2.1.0.14.exe 54438336 49d9bd9f8cc0476e6477dc69253fd2f4 setup_legend_of_kyrandia_1.1_(german)_(20270).exe -- 2.19.1
Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2
[ note how I removed 914347 from the recipients and kept only 914483 ] On Fri, Nov 23, 2018 at 09:43:10PM +0100, Gert Wollny wrote: > Am Freitag, den 23.11.2018, 20:14 +0100 schrieb Mattia Rizzolo: > > Hi, > > > > so, if you don't particularly mind, I'm happy to just take the least > > and fix all the involved packages here, so src:vtk7 > I just uploaded vtk7, I knew where to look because I did the changes > that made the libraries go away, and the python thing was not so > difficult after all. Thanks, that one looks good to me. > > Gert: you mention you gave up on symbols, but at least in gdcm's > > changelog I don't see anything about that. Had you had troubles > > there as well? > TBH I never tried with gdcm, I think I started to upload the package > when it was already at version 2.4 and I didn't even note that there is > a script for the symbols there (which points at 2.2). regardless of that script (I don't particularly like pkgkde-symbolshelper tbh, also I don't think that script is doing that much to help…), I notice that the libgdcm2.8 library is indeed not nice... I tried to compared the symbols exported between several versions, and they all differ. And not just from some templates or stuff leaked from the std library; for example between 2.8.7-1 and 2.8.7-2 stuff like this disappered from libgdcmDSED.so.2.8: _ZN10gdcmstrict7DataSet6RemoveERKN4gdcm3TagE@Base and many others... I haven't looked deep so I couldn't quite understand where that is coming from, but given that this happens quite frequently but clearly nothing breaks badly all the time I guess it's just something that shouldn't have been exported in the first place? > When I started packaging some of my software (mia) that has lots of > templates I just noted that getting symbols right there is kind of an > infinite task because each arch would need its own file because of > templates that on 64 bit use some types that are not available, and > were not instanciated on 32 bit systems. Maybe the tools are better > now, but at that time (2012) it was all kind of wired. If it's only 32/64 bits difference, that's easy to do since there is an arch-bits filter you can use. But I acknowledge that for many c++ libraries where their developers don't explicitly try to keep their exported ABI tidy is very easy to get a mess. This line is from a diff between libgdcm2.8 2.8.7-2 vs 2.8.7-5: - gdcm::Attribute<(unsigned short)32, (unsigned short)17, 512, 1>::GetAsDataElement() const@Base 2.8.7 + gdcm::Attribute<(unsigned short)32, (unsigned short)19, 512, 1>::GetAsDataElement() const@Base 2.8.7 That's clearly something that shouldn't have leaked here... But that kind of things make impossible even thoughts like "I'll keep a .symbols only for amd64" (which is a valid idea to have). At the same time, libvtkgdcm is much more tidy, so at least I will start adding a .symbols file to that one... > > What I would welcome your help with is explaining the camitk FTBFS on > > i386. > Just had as peek, my guess is that this will help: > > ifeq ($(DEB_BUILD_ARCH),i386) Note that here you probably meant DEB_HOST_ARCH, not build arch. > export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store > endif > > The same was needed for ITK because they write tests with floating > point values apparently comparing with high accuracy, and on i386 > optimizations can lead to the used of intermediate 80 bit floating > point values that then result in test failures because the references > were tuned for 64 bit floating point values. Adding above flag makes > sure that intermediate results are not keps in these 80 bit FPU > registers. ACK, thanks. -- 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#614775: bash-completion: perl -d inhibits filename completion
Thanks for the patch. I adpated it for current sources and forwarded it upstream as https://github.com/scop/bash-completion/pull/258. I'll apply it to Debian's bash-completion for the next upload.
Bug#914529: lua-dbi: please provide a lua5.2 version in stretch-backports
Source: lua-dbi Version: 0.7.1-1 Severity: wishlist To provide a stable backport of prosody 0.11.0, some lua packages need lua5.2 support via backports, too. Just backporting the testing version of lua-dbi is probably the way to go. I'll do the backport myself, if nobody objects.
Bug#913756: tootle: Tootle window opens and closes immediately
Temporary workaround: download the package for your architecture from https://snapshot.debian.org/package/granite/5.1.0-2/\#libgranite5_5.1.0-2 and install it with sudo dpkg -i -- Federico
Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes
Dmitry Bogatov: I believe I already wrote in init-d-script(5) correct invocation: #!/usr/bin/env /lib/init/init-d-script That's not what was in the skeleton that you just got rid of; which had more attention paid to it than the example in the manual page had, I suspect. The next portability bump on this road, discussed many times over the years, is to hit platforms where env is not in /usr/bin. This is not the case with Debian operating systems, though, fortunately. And I doubt that you'll have many dealings with FreeBSD kernels from before 2005, where the #! mechanism was more like MacOS. (-: * https://unix.stackexchange.com/questions/29608/ * https://unix.stackexchange.com/questions/111802/ * https://unix.stackexchange.com/questions/361794/
Bug#914373: octave-statistics: accessing installed functions is needlessly obscure
Control: severity -1 wishlist Control: reassign -1 octave 4.0.3-3 Control: retitle -1 octave: Document the need for pkg load * Sébastien Villemot [2018-11-24 11:56]: Le samedi 24 novembre 2018 à 11:43 +0100, Rafael Laboissière a écrit : [snip] Do the other members of the DOG agree with this change? That seems excessive to me. The fact that OF packages are not auto- loaded is the consequence of a global setting (in Octave itself), so it does not make sense to document it in individual packages. I share your opinion. Adding a README.Debian for each package is excessive and would be a maintenance burden, as well. Besides that, this is not really a bug. I am hereby decreasing the severity of this bug report from normal to wishlist. I would rather update the README.Debian of octave. It currently tells never to use the "pkg" command, which is bad advice, since that command is needed to load the packages. Yes, documenting it in the README.Debian of octave is the sensible thing to do. I am hereby reassigning this bug report to the octave package and adjusting its title. I think that the current advice in the README.Debian of octave regards the use of "pkg install". At any rate, the wording is wrong and must be fixed. Rafael
Bug#914530: prosody: broken LDAP support
Package: prosody Version: 0.11.0-1 Severity: grave (I'm abusing the "grave" severity here to prevent prosody going to testing, "important" would be correct. If there were a prosody-ldap package, that one would deserve the "grave" severity bug.) As long as lua-ldap does not support lua5.2 (#814218), LDAP support cannot work. This will break prosody installations, that depend on that feature, such as Debians.
Bug#914533: neutron-vpnaas: [INTL:nl] Dutch translation of debconf messages
Package: neutron-vpnaas Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of neutron-vpnaas debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Regards, Frans Spiesschaert nl.po.gz Description: application/gzip signature.asc Description: This is a digitally signed message part
Bug#914532: neutron: [INTL:nl] Dutch translation of debconf messages
Package: neutron Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of neutron debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip signature.asc Description: This is a digitally signed message part
Bug#914534: neutron-fwaas: [INTL:nl] Dutch translation of debconf messages
Package: neutron-fwaas Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of neutron-fwaas debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Regards, Frans Spiesschaert nl.po.gz Description: application/gzip signature.asc Description: This is a digitally signed message part
Bug#914535: nova: [INTL:nl] Dutch translation of debconf messages
Package: nova Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of nova debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Regards, Frans Spiesschaert nl.po.gz Description: application/gzip signature.asc Description: This is a digitally signed message part
Bug#914531: shim-signed: [INTL:nl] Dutch translation of debconf messages
Package: shim-signed Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch translation of shim-signed debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Regards, Frans Spiesschaert nl.po.gz Description: application/gzip signature.asc Description: This is a digitally signed message part
Bug#914536: lua-cyrussasl: Package built only for lua 5.1
Package: lua-cyrussasl Version: 1.0.0-6 Severity: important Dear Maintainer, your package seems built only for lua 5.1, so does not work with lua 5.2. Please, rebuild it also for lua 5.2 (and lua 5.3, indeed), or at least rename it 'lua5.1-cyrussasl'. Thanks. -- System Information: Debian Release: 8.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lua-cyrussasl depends on: ii libc6 2.19-18+deb8u10 ii libsasl2-2 2.1.26.dfsg1-13+deb8u1 ii multiarch-support 2.19-18+deb8u10 lua-cyrussasl recommends no packages. lua-cyrussasl suggests no packages. -- no debconf information
Bug#914537: openmw: segfault at start
Package: openmw Version: 0.44.0-1+b1 Severity: grave Justification: renders package unusable Dear Maintainer, The latest build of this package (0.44.0-1+b1) makes the game crash at start on my system (please see provided crash.log) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openmw depends on: ii libavcodec587:4.0.3-1 ii libavformat58 7:4.0.3-1 ii libavutil56 7:4.0.3-1 ii libboost-filesystem1.67.0 1.67.0-10 ii libboost-program-options1.67.0 1.67.0-10 ii libboost-system1.67.0 1.67.0-10 ii libbullet2.87 2.87+dfsg-3 ii libc6 2.27-8 ii libgcc1 1:8.2.0-9 ii libgl1 1.1.0-1 ii libmyguiengine3debian1v53.2.2+dfsg-2+b1 ii libopenal1 1:1.19.1-1 ii libopenscenegraph-3.4-131 3.4.1+dfsg1-4 ii libopenthreads203.2.3+dfsg1-2+b9 ii libqt5core5a5.11.2+dfsg-4 ii libqt5gui5 5.11.2+dfsg-4 ii libqt5widgets5 5.11.2+dfsg-4 ii libsdl2-2.0-0 2.0.8+dfsg1-6 ii libstdc++6 8.2.0-9 ii libswresample3 7:4.0.3-1 ii libswscale5 7:4.0.3-1 ii libtinyxml2.6.2v5 2.6.2-4 ii openmw-data 0.44.0-1 Versions of packages openmw recommends: ii openmw-launcher 0.44.0-1+b1 openmw suggests no packages. -- no debconf information *** Fatal Error *** Segmentation fault (signal 11) Address: (nil) System: Linux debiananas 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) x86_64 Executing: gdb --quiet --batch --command=/tmp/gdb-respfile-i5hVPW [New LWP 2002] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x7f31a65e424a in __waitpid (pid=2004, stat_loc=0x560a480fc78c, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30 * Loaded Libraries >FromTo Syms Read Shared Object Library 0x7f31a8bad3b0 0x7f31a8d2cfac Yes (*) /usr/lib/x86_64-linux-gnu/libosg.so.131 0x7f31a8ac6460 0x7f31a8ac77f8 Yes (*) /usr/lib/x86_64-linux-gnu/libOpenThreads.so.20 0x7f31a8a850f0 0x7f31a8ab148f Yes (*) /usr/lib/x86_64-linux-gnu/libosgParticle.so.131 0x7f31a890ae70 0x7f31a8a0d468 Yes (*) /usr/lib/x86_64-linux-gnu/libosgUtil.so.131 0x7f31a878bb60 0x7f31a882768b Yes (*) /usr/lib/x86_64-linux-gnu/libosgDB.so.131 0x7f31a8673cd0 0x7f31a86e9f22 Yes (*) /usr/lib/x86_64-linux-gnu/libosgViewer.so.131 0x7f31a85b81b0 0x7f31a85eb6d2 Yes (*) /usr/lib/x86_64-linux-gnu/libosgGA.so.131 0x7f31a8562130 0x7f31a8563259 Yes (*) /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 0x7f31a854a8f0 0x7f31a855860b Yes (*) /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0 0x7f31a84e5360 0x7f31a852b045 Yes (*) /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.67.0 0x7f31a83de870 0x7f31a842b161 Yes (*) /usr/lib/x86_64-linux-gnu/libopenal.so.1 0x7f31a6f486b0 0x7f31a788e2d2 Yes (*) /usr/lib/x86_64-linux-gnu/libavcodec.so.58 0x7f31a6cbb220 0x7f31a6e3d9ee Yes (*) /usr/lib/x86_64-linux-gnu/libavformat.so.58 0x7f31a6c126e0 0x7f31a6c514e0 Yes (*) /usr/lib/x86_64-linux-gnu/libavutil.so.56 0x7f31a6b73220 0x7f31a6be8ddc Yes (*) /usr/lib/x86_64-linux-gnu/libswscale.so.5 0x7f31a6b532b0 0x7f31a6b679cc Yes (*) /usr/lib/x86_64-linux-gnu/libswresample.so.3 0x7f31a69ac2c0 0x7f31a6af1e41 Yes (*) /usr/lib/libMyGUIEngine.so.3debian1 0x7f31a6829ae0 0x7f31a68ecf3d Yes (*) /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 0x7f31a65fae40 0x7f31a6602dc4 Yes (*) /usr/lib/x86_64-linux-gnu/libtinyxml.so.2.6.2 0x7f31a65d8530 0x7f31a65e6101 Yes /lib/x86_64-linux-gnu/libpthread.so.0 0x7f31a6589b30 0x7f31a65c0e58 Yes (*) /usr/lib/x86_64-linux-gnu/libosgText.so.131 0x7f31a6492a20 0x7f31a654a17f Yes (*) /usr/lib/x86_64-linux-gnu/libBulletCollision.so.2.87 0x7f31a64326d0 0x7f31a64463ba Yes (*) /usr/lib/x86_64-linux-gnu/libLinearMath.so.2.87 0x7f31a63dc220 0x7f31a63df5df Yes (*) /usr/lib/x86_64-linux-gnu/libGL.so.1 0x7f31a5e92ab0 0x7f31a6210705 Yes (*) /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 0x7f31a588be50 0x7f31a5c51cee Yes (*) /usr/lib/x86_64-linux-gnu/li
Bug#833401: debian-policy: virtual packages: dbus-session-bus, default-dbus-session-bus
On Sat, 03 Nov 2018 at 14:07:18 -0700, Sean Whitton wrote: > On Thu 04 Aug 2016 at 01:43PM +0100, Simon McVittie wrote: > >> Other options > > I note that no such binary package exists right now. Does this issue > remain unresolved? I also note recent discussion on d-devel. Kindly > update this bug with the present state of play. The routes that I described as "other options" were not taken. The current situation is that we have the two virtual packages that I proposed in the original bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833401#5 modulo the rename of dbus-default-session-bus to default-dbus-session-bus as mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833401#10 (trying to continue/establish a convention that the preferred implementation of a virtual package foo is default-foo). So: * dbus-session-bus: anything providing the D-Bus well-known session bus for most or all user login sessions. If dbus-session-bus is installed, then programs in at least graphical login sessions can rely on seeing the $DBUS_SESSION_BUS_ADDRESS environment variable, the $XDG_RUNTIME_DIR/bus Unix socket, or some other way to discover a session bus that is supported by all the major D-Bus client libraries. * default-dbus-session-bus: Debian's preferred implementation of dbus-session-bus, possibly architecture-specific. Programs and desktop environments that require a D-Bus session bus and cannot work without one should normally declare: Depends: default-dbus-session-bus | dbus-session-bus unless they have more specific requirements. Programs with weaker dependencies can use a Recommends or a Suggests. (Implementation detail: default-dbus-session-bus is currently provided by dbus-user-session on Linux, and by dbus-x11 on non-Linux ports. On Linux, dbus-x11 is a non-default implementation of dbus-session-bus, to be used by people who prefer to have one session bus per X11 display, or who don't want systemd or systemd-logind.) smcv
Bug#858045: Bug #858045: xcircuit: The File List Window can crash XCircuit
Dear Maintainer, hello Gonçalo,
I tried to have a look at this issue, and could
reproduce it in a jessie and buster amd64 qemu VM.
As far as I see xcircuit tries to draw all files into one big pixmap.
(gdb) list filelist.c:480
477 pixheight = flfiles * FILECHARHEIGHT + 25;
478 if (pixheight < textheight) pixheight = textheight;
479
480 flistpix = XCreatePixmap(dpy, areawin->window, textwidth,
pixheight,
481DefaultDepthOfScreen(xcScreen(w)));
(gdb) print pixheight
$1 = 42039
(gdb) print textheight
$2 = 98
(gdb) print flfiles
$3 = 3001
Unfortunately, depending on the font size, we get then a height
of e.g. 42039, that is not allowed in the xserver:
(gdb) list ProcCreatePixmap
1392int
1393ProcCreatePixmap(ClientPtr client)
...
1415if (stuff->width > 32767 || stuff->height > 32767) {
1416/* It is allowed to try and allocate a pixmap which is
larger than
1417 * 32767 in either dimension. However, all of the
framebuffer code
1418 * is buggy and does not reliably draw to such big pixmaps,
basically
1419 * because the Region data structure operates with signed
shorts
1420 * for the rectangles in it.
1421 *
1422 * Furthermore, several places in the X server computes the
1423 * size in bytes of the pixmap and tries to store it in an
1424 * integer. This integer can overflow and cause the
allocated size
1425 * to be much smaller.
1426 *
1427 * So, such big pixmaps are rejected here with a BadAlloc
1428 */
1429return BadAlloc;
1430}
So a check like in filelist.c:478 could be added
to limit pixheight to 32767, or give a error message like
in the "(Invalid Directory)" case.
Kind regards,
Bernhard
Client:
(gdb) bt
#0 XCreatePixmap (dpy=0x561a0f1f4f60, d=8389047, width=339, height=42039,
depth=24) at ../../src/CrPixmap.c:50
#1 0x7f67bfa7d020 in listfiles (w=0x561a0f846e00,
okaystruct=0x561a0fa27f60, calldata=0x0) at filelist.c:480
#2 0x7f67bfa7d51a in newfilelist (w=0x561a0f846e00,
okaystruct=0x561a0fa27f60) at filelist.c:547
#3 0x7f67bfafaec2 in xctk_fileselect (clientData=0x561a0fa27f60,
eventPtr=0x70ef86f0) at tclxcircuit.c:9567
#4 0x7f67c19c7ff5 in Tk_HandleEvent
(eventPtr=eventPtr@entry=0x70ef86f0) at ./unix/../generic/tkEvent.c:1352
#5 0x7f67c19bb3b0 in HandleEventGenerate
(interp=interp@entry=0x561a0f46b6f0, mainWin=mainWin@entry=0x561a0f624180,
objc=objc@entry=4, objv=objv@entry=0x561a0f486840) at
./unix/../generic/tkBind.c:3458
#6 0x7f67c19baaf1 in Tk_EventObjCmd (clientData=0x561a0f624180,
interp=0x561a0f46b6f0, objc=6, objv=0x561a0f486830) at
./unix/../generic/tkBind.c:2413
#7 0x7f67c1608a96 in TclNRRunCallbacks
(interp=interp@entry=0x561a0f46b6f0, result=0, rootPtr=0x0) at
./generic/tclBasic.c:4435
#8 0x7f67c1607ecf in Tcl_EvalObjv (interp=interp@entry=0x561a0f46b6f0,
objc=objc@entry=6, objv=objv@entry=0x561a0f486830, flags=flags@entry=2097168)
at ./generic/tclBasic.c:4165
#9 0x7f67c160964a in TclEvalEx (interp=0x561a0f46b6f0,
script=0x70ef8af0 "event generate .filelist.listwin.win
-button 2 ; event generate .filelist.listwin.win -button 2",
numBytes=, flags=, line=line@entry=1,
clNextOuter=clNextOuter@entry=0x0, outerScript=0x70ef8af0 "event generate
.filelist.listwin.win -button 2 ; event generate
.filelist.listwin.win -button 2") at ./generic/tclBasic.c:5304
#10 0x7f67c16090f3 in Tcl_EvalEx (interp=,
script=, numBytes=, flags=) at
./generic/tclBasic.c:4969
#11 0x7f67c19b9705 in Tk_BindEvent (bindPtr=,
eventPtr=eventPtr@entry=0x561a0f9f3aa0, tkwin=tkwin@entry=0x561a0f84c020,
numObjects=, numObjects@entry=4, objectPtr=,
objectPtr@entry=0x70ef8d20) at ./unix/../generic/tkBind.c:1505
#12 0x7f67c19bff4d in TkBindEventProc
(winPtr=winPtr@entry=0x561a0f84c020, eventPtr=eventPtr@entry=0x561a0f9f3aa0) at
./unix/../generic/tkCmds.c:319
#13 0x7f67c19c8173 in Tk_HandleEvent
(eventPtr=eventPtr@entry=0x561a0f9f3aa0) at ./unix/../generic/tkEvent.c:1374
#14 0x7f67c19c8920 in WindowEventProc
(evPtr=evPtr@entry=0x561a0f9f3a90, flags=flags@entry=-3) at
./unix/../generic/tkEvent.c:1764
#15 0x7f67c16d0e17 in Tcl_ServiceEvent (flags=flags@entry=-3) at
./generic/tclNotify.c:670
#16 0x7f67c16d1066 in Tcl_DoOneEvent (flags=-3) at
./generic/tclNotify.c:903
#17 0x7f67c19c8d72 in Tk_MainLoop () at ./unix/../generic/tkEvent.c:2148
#18 0x7f67c19d741a in Tk_MainEx (argc=, argv=, appInitProc=0x561a0d485b30, interp=0x561a0f195f00) at
./unix/../generic/tkMain.c:390
#19 0x561a0d485a0c in ?? ()
#20 0x7f67c07e7b17 in __libc_start_main (
Bug#914538: lintian: false positives with make prefixes on dh
Package: lintian
Version: 2.5.113
Severity: normal
Tags: patch
Dear Maintainer,
When debian/rules includes a make prefix in front of dh, the use of dh
isn’t recognised and lintian reports
package-does-not-use-debhelper-or-cdbs.
The attached patch fixes this.
Regards,
Stephen
-- System Information:
Debian Release: 9.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'),
(100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100,
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lintian depends on:
ii binutils 2.28-5
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii dpkg 1.18.25
ii dpkg-dev 1.18.25
ii file 1:5.30-1+deb9u2
ii gettext 0.19.8.1-2
ii gnupg [gpg] 2.1.18-8~deb9u3
ii intltool-debian 0.35.0+20060710.4
ii libapt-pkg-perl 0.1.32
ii libarchive-zip-perl 1.59-1+deb9u1
ii libcgi-pm-perl4.35-1
ii libclass-accessor-perl0.34-1
ii libclone-perl 0.38-2+b1
ii libdigest-sha-perl5.96-1+b1
ii libdpkg-perl 1.18.25
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.07-1
ii libipc-run-perl 0.94-1+deb9u1
ii liblist-moreutils-perl0.416-1+b1
ii libparse-debianchangelog-perl 1.2.0-12
ii libperl5.24 [libdigest-sha-perl] 5.24.1-3+deb9u4
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii liburi-perl 1.71-1
ii libxml-simple-perl2.22-1
ii libyaml-libyaml-perl 0.63-2
ii man-db2.7.6.1-2
ii patchutils0.3.4-2
ii perl 5.24.1-3+deb9u4
ii t1utils 1.39-2
ii xz-utils 5.2.2-1.2+b1
Versions of packages lintian recommends:
ii libperlio-gzip-perl 0.19-1+b2
Versions of packages lintian suggests:
pn binutils-multiarch
ii libhtml-parser-perl3.72-3
ii libtext-template-perl 1.46-1
-- no debconf information
>From a36de5d0924aa9df78dba247d2b778951aa44a0f Mon Sep 17 00:00:00 2001
From: Stephen Kitt
Date: Sat, 24 Nov 2018 16:25:48 +0100
Subject: [PATCH] Avoid false positives with make prefixes on dh
debian/rules which use a - or + prefix on dh trigger
package-does-not-use-debhelper-or-cdbs. This patch allows - or + in
front of dh and includes appropriate unit tests.
Signed-off-by: Stephen Kitt
---
checks/debhelper.pm| 4 ++--
.../debian/debian/control.in | 14 ++
.../debian/debian/rules| 7 +++
.../desc | 6 ++
.../tags | 2 ++
.../debian/debian/control.in | 14 ++
.../debian/debian/rules| 7 +++
.../debhelper-package-uses-debhelper-with-prefix-plus/desc | 6 ++
.../debhelper-package-uses-debhelper-with-prefix-plus/tags | 2 ++
9 files changed, 60 insertions(+), 2 deletions(-)
create mode 100644
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/debian/debian/control.in
create mode 100755
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/debian/debian/rules
create mode 100644
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/desc
create mode 100644
t/tests/debhelper-package-uses-debhelper-with-prefix-minus/tags
create mode 100644
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/debian/debian/control.in
create mode 100755
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/debian/debian/rules
create mode 100644
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/desc
create mode 100644
t/tests/debhelper-package-uses-debhelper-with-prefix-plus/tags
diff --git a/checks/debhelper.pm b/checks/debhelper.pm
index 3b3c67e7b..810226f00 100644
--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -87,7 +87,7 @@ sub run {
}
next if /^\s*\#/;
-if (m/^\s+-?(dh_\S+)/) {
+if (m/^\s+[@+-]?(dh_\S+)/) {
my $dhcommand = $1;
$build_systems{'debhelper'} = 1
if not exists($build_systems{'dh'});
@@ -131,7 +131,7 @@ sub run {
}
$see
Bug#914539: [20181124] mirrors.tecnoera.com: out of date
Package: mirrors User: mirr...@packages.debian.org Usertags: mirror-problems Hi! It seems http://mirrors.tecnoera.com/debian/ is out of date https://mirror-master.debian.org/status/mirror-info/mirrors.tecnoera.com.html Please investigate. o If you sync off kernel.org, you might want to pick a different site (do not use ftp.*.debian.org names, only http is guaranteed at those names and they do switch around.) https://mirror-master.debian.org/status/mirror-hierarchy.html might help you pick. (Also, you might want to move from an arch-exclude to an arch-include config.) -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#911180: [Pkg-freeradius-maintainers] Bug#911180: Bug#911180: freeradius: freeradius refuses to start - missing libs
Dimitri, friendly ping? Would you prefer if I took care of this? If I don’t hear back from you over the next week, I’ll go ahead :). (An affected user just asked me in person about the status of this issue.) On Tue, Nov 6, 2018 at 4:51 PM Michael Stapelberg wrote: > Thanks for the reminder. It’s hard to keep track of everything that’s > going on. > > The lintian tag description states: > > > The only time a binary or shared library in a Debian package should set > RPATH or RUNPATH is if it is linked to private shared libraries in the same > package. In that case, place those private shared libraries in > /usr/lib/package. Libraries used by binaries in other packages should be > placed in /lib or /usr/lib as appropriate, with a proper SONAME, in which > case RPATH/RUNPATH is unnecessary. > > It seems like this is exactly what’s happening here? > > Can we try removing the rpath from where it can be removed, and overriding > the lintian tag for the legitimate cases? > > I’d prefer to not open libraries to the public unless coordinated with > upstream, as they need to be aware of the stability guarantees (e.g. when > to bump the SONAME). > > Thanks! > > On Tue, Nov 6, 2018 at 4:27 PM Dimitri John Ledkov > wrote: > >> Hey, >> >> On Mon, 5 Nov 2018 at 21:07, Michael Stapelberg >> wrote: >> > >> > I still don’t quite understand why you stripped the rpaths to begin >> with. Can you explain? I think that’d be good to understand before making a >> decision :) >> > >> >> Please recall that when you last tried to upload freeradius it got >> autorejected by ftp masters due to rpath email from 2nd of June >> from you to me >> >> """ >> freeradius-postgresql: lintian output: 'binary-or-shlib-defines-rpath >> usr/lib/freeradius/rlm_sql_postgresql.so /usr/lib/x86_64-linux-gnu', >> automatically rejected package. >> freeradius-postgresql: If you have a good reason, you may override >> this lintian tag. >> freeradius-iodbc: lintian output: 'binary-or-shlib-defines-rpath >> usr/lib/freeradius/rlm_sql_iodbc.so /usr/lib', automatically rejected >> package. >> freeradius-iodbc: If you have a good reason, you may override this >> lintian tag. >> freeradius-python2: lintian output: 'binary-or-shlib-defines-rpath >> usr/lib/freeradius/rlm_python.so /usr/lib/python2.7/config', >> automatically rejected package. >> freeradius-python2: If you have a good reason, you may override this >> lintian tag. >> """ >> >> And spot checking this revealed that rpath is redundant for most of >> the modules shipped - hence i stripped rpath from them all. >> However, clearly that was false for all of them as some of them do use >> private lib as now analyzed. >> >> My preference is to not have rpath set on any of these, and simply >> expose libfreeradius-dhcp.so and libfreeradius-eap.so as public >> libraries. >> >> Also i'm pondering how come freeradius does not set ldpath when trying >> to dlopen the plugins from the plugin dir cause that would also >> work without rpath set on every plugin. >> >> Regards, >> >> Dimitri. >> >> >> >> > On Mon, Nov 5, 2018 at 9:06 PM Dimitri John Ledkov >> wrote: >> >> >> >> Hello, >> >> >> >> On Mon, 5 Nov 2018 at 18:19, Michael Stapelberg >> wrote: >> >> > >> >> > Sorry, didn’t see the merge request. I fixed my notification >> settings, merged the MR, and gave you permission to the repository. >> >> > >> >> >> >> No worries. I myself only starting to figure out how to correctly use >> >> salsa. It is quite new in how everything works. >> >> >> >> So about the bug, here is the full scope of affected files: >> >> >> >> /usr/lib/freeradius# readelf -d *.so | grep -e '\[libfreeradius' -e >> File: >> >> File: libfreeradius-dhcp.so >> >> File: libfreeradius-eap.so >> >> File: libfreeradius-radius.so >> >> File: libfreeradius-server.so >> >> File: proto_dhcp.so >> >> 0x0001 (NEEDED) Shared library: >> [libfreeradius-dhcp.so] >> >> File: proto_vmps.so >> >> File: rlm_always.so >> >> File: rlm_attr_filter.so >> >> File: rlm_cache.so >> >> File: rlm_cache_memcached.so >> >> File: rlm_cache_rbtree.so >> >> File: rlm_chap.so >> >> File: rlm_counter.so >> >> File: rlm_cram.so >> >> File: rlm_date.so >> >> File: rlm_detail.so >> >> File: rlm_dhcp.so >> >> 0x0001 (NEEDED) Shared library: >> [libfreeradius-dhcp.so] >> >> File: rlm_digest.so >> >> File: rlm_dynamic_clients.so >> >> File: rlm_eap.so >> >> 0x0001 (NEEDED) Shared library: >> [libfreeradius-eap.so] >> >> File: rlm_eap_fast.so >> >> 0x0001 (NEEDED) Shared library: >> [libfreeradius-eap.so] >> >> File: rlm_eap_gtc.so >> >> 0x0001 (NEEDED) Shared library: >> [libfreeradius-eap.so] >> >> File: rlm_eap_leap.so >> >> 0x0001 (NEEDED) Shared library: >> [libfreeradius-eap.so] >> >> File: rlm_eap_md5.so >> >> 0x0001 (NEEDED) Shared library: >> [libfreeradius-eap.so] >> >> File: rlm_eap
Bug#909266: [git-buildpackage/master] buildpackage, export-orig: support version substitution for --git-tarball-dir
tag 909266 pending thanks Date: Thu Sep 6 18:34:13 2018 +0200 Author: Luca Boccassi Commit ID: e5aedb16548a6a83223862b96ba2112e0c02c126 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=e5aedb16548a6a83223862b96ba2112e0c02c126 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=e5aedb16548a6a83223862b96ba2112e0c02c126 buildpackage, export-orig: support version substitution for --git-tarball-dir Add support for passing %(version), %(hversion) and %(version%A%B) in buildpackage --git-tarball-dir and export-orig --tarball-dir. Closes: #909266 Signed-off-by: Luca Boccassi
Bug#914540: [20181124] mirrors.ocf.berkeley.edu: out of date, ftpsync-version
Package: mirrors User: mirr...@packages.debian.org Usertags: mirror-problems Hi! It seems http://mirrors.ocf.berkeley.edu/debian/ is out of date https://mirror-master.debian.org/status/mirror-info/mirrors.ocf.berkeley.edu.html Please investigate. o If you sync off kernel.org, you might want to pick a different site (do not use ftp.*.debian.org names, only http is guaranteed at those names and they do switch around.) https://mirror-master.debian.org/status/mirror-hierarchy.html might help you pick. o Also, maybe update your ftpsync version. http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#914175: lightning is not installable after binNMUs
Control: tags -1 pending
Hello Adrian,
Am 20.11.18 um 08:52 schrieb Adrian Bunk:
> Package: lightning
> Version: 1:60.3.0-1
> Severity: serious
>
> thunderbird : Breaks: lightning (< 1:60.3.0-1+b1) but 1:60.3.0-1 is to be
> installed
>
> lightning is binary-all, ${source:Version} should be used
> for Breaks and Recommends.
indeed, good catch!
Thanks for raising this problem! Will get fixed by the next upload.
--
Regards
Carsten Schoenert
Bug#914541: [libpam-modules-bin] unix_chkpwd should be SUID instead of SGID, otherwise kscreen_locker does not work
Package: libpam-modules-bin Version: 1.1.8-3.8 Severity: important --- Please enter the report below this line. --- I ran into that quite a while ago, but wasn't using a screen locker or KDE since, so I forgot about it. Now, with KDE and mostly hibernating my system, it came back. unix_chkpwd is installed SGID (2755) in all currently available libpam-modules-bin versions: 1.1.8-3.2ubuntu2 1.1.8-3.2ubuntu2.1 1.1.8-3.2ubuntu3 1.1.8-3.2ubuntu3.1 1.1.8-3.6 1.1.8-3.6ubuntu2 1.1.8-3.8 With these permissions correct passwords fail in newer KDE screen locker versions. I tested libkscreenlocker5 versions: 5.13.5-1 5.8.6-2 5.12.6-0ubuntu0.1 5.12.4-0ubuntu1 for a recent occurance of the issue see here: https://www.reddit.com/r/kde/comments/8w7uqq/screen_wont_unlock/e1wbilp/?context=8&depth=9 I found a discussion about SUID vs. SGID for unix_chkpwd here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155583 Note, I am not an expert in security related things, but the reasoning in the discussion doesn't look logical, so I'll try to explain my view as a user. There probably was a reason why it was SUID before. Obviously nobody is talking about that decision. The discussion about switching to SGID seems to be about explicit packages that fail and solutions for them. But as I understand this, it doesn't say, there cannot be or can never be other packages that need unix_chkpwd to be SUID. May be, this is totally obvious to you and it doesn't need to be discussed. But at least the KDE screen locker is an example. Also, bashing NIS doesn't help, especially if there could be other software. So, one question is, why is SGID better than SUID? is it worth breaking packages if you don't know, why SUID was part of the design? The other question is, why does another package need unix_chkpwd SUID? is it insecure or otherwise bad code in some way? That said, the problem could also be in the code of the screen locker. --- System information. --- Architecture: Kernel: Linux 4.18.0-2-amd64 Debian Release: buster/sid 990 stable security.debian.org 900 xenial-security archive.ubuntu.com 900 testing debian.netcologne.de 900 stable kxstudio.linuxaudio.org 900 stable dl.google.com 900 stable debian.netcologne.de 900 bionic-security archive.ubuntu.com 900 artful-security archive.ubuntu.com 500 xenial ppa.launchpad.net 500 wilyppa.launchpad.net 500 trusty ppa.launchpad.net 500 lucid ppa.launchpad.net 500 gcc5kxstudio.linuxaudio.org 500 bionic ppa.launchpad.net 500 artful ppa.launchpad.net 100 xenial-updates archive.ubuntu.com 100 xenial-backports archive.ubuntu.com 100 xenial archive.ubuntu.com 100 unstable packages.siduction.org 100 unstabledebian.netcologne.de 100 experimentaldebian.netcologne.de 100 bionic-updates archive.ubuntu.com 100 bionic-backports archive.ubuntu.com 100 bionic archive.ubuntu.com 100 artful-updates archive.ubuntu.com 100 artful-backports archive.ubuntu.com 100 artful archive.ubuntu.com --- Package information. --- Depends (Version) | Installed =-+-== libaudit1(>= 1:2.2.1) | 1:2.8.4-2 libc6 (>= 2.14) | libpam0g(>= 0.99.7.1) | libselinux1 (>= 1.32) | Package's Recommends field is empty. Package's Suggests field is empty.
Bug#914542: dict-jargon: Merging with src:jargon and src:jargon-text
Package: dict-jargon Severity: wishlist Dear Maintainer, There is three source packages in Debian, that contain Jargon File * `dict-jargon' (v4.4.7) * `jargon-text' (v4.4.7) -- orphaned * `jargon' (v4.0.0) -- out-of-date, as written in description Hereby I propose to combine functionality of those packages in single source package, probably yours `dict-jargon', as most actively maintained. It would mean to * copy Makefile from `jargon-text' to generate HTML and plain text formats * apply patch for `jargon-text' to additionally generate fortunes file. * invent a way to convert source xml into GNU Info format, to supersede `jargon' package. After that we could RM src:jargon-text and src:jargon. If you agree, I volonteer to prepare patch.
Bug#914543: meson adds both -fPIE and -fPIC options in LTO compiles with gcc-8
Source: meson Severity: normal Dear Maintainer, The systemd package fails to build on hppa and x32. This is caused by both -fPIE and -fPIC options being added to various compilation commands. Only -fPIC is being recorded in the LTO options section of the object. The gcc-8 LTO plugin merges -fPIC + -fPIE to nothing. So, the compilations done by the plugin are not position-independent and fail to link with -pie. I have not found a way to change the addition of these options within systemd. My understanding is -fPIE should be used when creating objects for a PIE executable. -fPIC should be used when creating objects for a shared library. Only one is recorded when -flto is specified. For more details, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909396 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88185 Regards, Dave Anglin -- System Information: Debian Release: buster/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 4.14.81+ (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#866653: RFS: thawab 4.1-1 [UPDATE]
Let me clarify: You could upload thawab yourself today [1] as long as you make sure to do a full source-and-binaries upload. You won't be able to do a source-only upload until you get confirmation that autobuild has been turned on for thawab. I could upload othman today (it will need to go through the NEW queue) but I prefer to wait until after you start the autobuild process. That way, we will not have this issue again for othman. [1] https://ftp-master.debian.org/dm.txt Thanks, Jeremy Bicha
Bug#914126: svtplay-dl: bugs out on urplay.se
On Sat, 24 Nov 2018, Cristian Ionescu-Idbohrn wrote:
> On Fri, 23 Nov 2018, Olof Johansson wrote:
> > On 18-11-19 18:37 +0100, Cristian Ionescu-Idbohrn wrote:
> > > This is what I see:
> > ...
> > > requests.exceptions.SSLError:
> > > HTTPSConnectionPool(host='streaming-loadbalancer.ur.se', port=443): Max
> > > retries exceeded with url: /loadbalancer.json (Caused by
> > > SSLError(SSLError("bad handshake: Error([('SSL routines',
> > > 'ssl_choose_client_version', 'unsupported protocol')],)",),))
> > >
> > > when trying to download:
> > >
> > > https://urplay.se/program/204949-roster-fran-australiens-aboriginer
> > >
> > > for example. Works fine when playing it in chromium, though.
> > >
> > > Downloading from svtplay.se works fine, though.
> >
> > Thanks for the report, I have been postponing upgrading to the
> > new 2.0+ version, but should get on that asap. Hopefully that
> > should solve it.
>
> Doesn't seem so :( I tested with master (2.1-14-g72143b7). Similar
> problem. Attaching a trace done with that version.
FWIW, `curl' is showing a similar error when attempting to download:
$ curl -v https://streaming-loadbalancer.ur.se/loadbalancer.json
* Trying 130.242.59.74...
* TCP_NODELAY set
* Connected to streaming-loadbalancer.ur.se (130.242.59.74) port 443
(#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported
protocol
* Closing connection 0
curl: (35) error:1425F102:SSL
routines:ssl_choose_client_version:unsupported protocol
But `wget' manages to do it:
$ wget -O - --quiet
https://streaming-loadbalancer.ur.se/loadbalancer.json;echo
{"geoip_country_code":"SE","redirect":"streaming4.ur.se"}
`svtplay-dl` 1.9.1-0.1 on stretch manages to download:
$ svtplay-dl --verbose -P hls -g
https://urplay.se/program/204949-roster-fran-australiens-aboriginer
DEBUG [1543070399.9]
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting
'https://urplay.se/program/204949-roster-fran-australiens-aboriginer'
DEBUG [1543070400.01]
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting
u'https://streaming-loadbalancer.ur.se/loadbalancer.json'
DEBUG [1543070400.11]
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting
u'http://streaming4.ur.se/urplay/_definst_/mp4:se/204000-204999/204949-11.mp4/playlist.m3u8'
DEBUG [1543070400.3]
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/request: HTTP getting
u'http://streaming4.ur.se/urplay/_definst_/mp4:se/204000-204999/204949-5.mp4/playlist.m3u8'
DEBUG [1543070400.72]
/usr/bin/svtplay-dl/svtplay_dl/utils/__init__.py/protocol_prio: Protocol
priority scores (higher is better): {'dash': 5, 'hds': 3, 'hls': 4, 'http': 2,
'rtmp': 1}
https://streaming4.ur.se/urplay/_definst_/mp4:se/204000-204999/204949-5.mp4/chunklist_w64863179.m3u8
So, it seems the problem might very well be openssl both in buster and
sid, but I may be wrong.
On sid:
$ openssl s_client -connect streaming-loadbalancer.ur.se:443;echo $?
CONNECTED(0003)
140235689968640:error:1425F102:SSL
routines:ssl_choose_client_version:unsupported
protocol:../ssl/statem/statem_lib.c:1940:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 86 bytes and written 327 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
fails. See Bug#912737 too. But it succedes if I force TLS down to
TLSv1:
$ openssl s_client -tls1 -connect streaming-loadbalancer.ur.se:443;echo
$?
CONNECTED(0003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte
RSA CA 2018
verify return:1
depth=0 C = SE, L = Stockholm, O = Sveriges Utbildningsradio AB, OU =
IT, CN = *.ur.se
verify return:1
139650269000704:error:141A318A:SSL routines:tls_process_ske_dhe:dh key
too small:../ssl/statem/statem_clnt.c:2160:
---
Certificate chain
0 s:C = SE, L = Stockholm, O = Sveriges Utbildningsradio AB, OU = IT,
CN = *.ur.se
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA
CA 2018
1 s:C = US, O
Bug#914544: xss-lock: Fails to run locker with -n and cycle time 0
Package: xss-lock Version: 0.3.0-5 Severity: normal Tags: upstream When the X screensaver extension cycle time (as in 'xset s TIMEOUT CYCLE') is set to 0 and xss-lock is run with a notification command (the -n option), the locker command is not being run at all when timeout is reached. This of course has some security implications. This would perhaps not be a big problem, but xfce4-power-manager seems to really want to set the screensaver cycle time to 0 on startup, or whenever the 'Blank after' time is changed on the GUI. I think the correct behaviour in the case of cycle time = 0 would be to run the notification and locker commands one after the other. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-8-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xss-lock depends on: ii libc62.24-11+deb9u3 ii libglib2.0-0 2.50.3-2 ii libxcb-screensaver0 1.12-1 ii libxcb-util0 0.3.8-3+b2 ii libxcb1 1.12-1 xss-lock recommends no packages. xss-lock suggests no packages. -- no debconf information
Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object
On 2018-11-18 3:08 p.m., Michael Biebl wrote: Unfortunately not. You could talk to Jussi Pakkanen, our meson maintainer and upstream of meson, maybe he can help here. I created two bug reports: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914543 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88185 Dave -- John David Anglin dave.ang...@bell.net
Bug#914546: ruby-oj FTBFS on 32bit: test failure
Source: ruby-oj
Version: 3.7.1-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/package.php?p=ruby-oj&suite=sid
...
┌──┐
│ Run tests for ruby2.5 from debian/ruby-tests.rb │
└──┘
RUBYLIB=/<>/debian/ruby-oj/usr/lib/i386-linux-gnu/ruby/vendor_ruby/2.5.0:/<>/debian/ruby-oj/usr/lib/ruby/vendor_ruby:.
GEM_PATH=debian/ruby-oj/usr/share/rubygems-integration/2.5.0:/var/lib/gems/2.5.0:/usr/lib/i386-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
ruby2.5 debian/ruby-tests.rb
running test/tests.rb test ---
Run options: --seed 12044
# Running:
.{}
E.
Finished in 0.091600s, 5098.2310 runs/s, 9530.5261 assertions/s.
1) Error:
Juice#test_time_neg:
ArgumentError: time out of system range
/<>/test/test_various.rb:419:in `dump'
/<>/test/test_various.rb:419:in `test_time_neg'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:265:in `time_it'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:360:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:960:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:334:in `run_one_method'
/usr/lib/ruby/vendor_ruby/minitest.rb:321:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:320:in `each'
/usr/lib/ruby/vendor_ruby/minitest.rb:320:in `block in run'
/usr/lib/ruby/vendor_ruby/minitest.rb:360:in `on_signal'
/usr/lib/ruby/vendor_ruby/minitest.rb:347:in `with_info_handler'
/usr/lib/ruby/vendor_ruby/minitest.rb:319:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `block in __run'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `map'
/usr/lib/ruby/vendor_ruby/minitest.rb:159:in `__run'
/usr/lib/ruby/vendor_ruby/minitest.rb:136:in `run'
/usr/lib/ruby/vendor_ruby/minitest.rb:63:in `block in autorun'
467 runs, 873 assertions, 0 failures, 1 errors, 0 skips
E: Test test/tests.rb has failed.
running test/tests_mimic.rb test ---
Loaded suite test/tests_mimic
Started
..O
===
Omission: mimic_JSON [test_deep_const_get(JSONCommonInterfaceTest)]
/<>/test/json_gem/json_common_interface_test.rb:55:in
`test_deep_const_get'
===
...
Finished in 0.127731524 seconds.
---
82 tests, 1966 assertions, 0 failures, 0 errors, 0 pendings, 1 omissions, 0
notifications
100% passed
---
641.97 tests/s, 15391.66 assertions/s
running test/tests_mimic_addition.rb test ---
Loaded suite test/tests_mimic_addition
Started
...
Finished in 0.004811668 seconds.
---
11 tests, 42 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0
notifications
100% passed
---
2286.11 tests/s, 8728.78 assertions/s
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-oj returned
exit code 1
make: *** [debian/rules:15: binary-arch] Error 1
Bug#914545: sympow FTBFS: error: 'GP' undeclared
Source: sympow Version: 2.023.5-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=sympow&suite=sid ... gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-result -O3 -std=gnu17 -fno-fast-math -mfpmath=sse -ffp-contract=on -DFPUCONTROLH -c -o generate.o generate.c generate.c: In function 'new_data': generate.c:234:32: error: 'GP' undeclared (first use in this function) execlp(SH,SH,newdatascript,SH,GP,ARGS,NULL);} ^~ generate.c:234:32: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [Makefile:45: generate.o] Error 1
Bug#901583: ITP: golang-github-danverbraganza-varcaser
Alright. refreshing this old ITP as I'm ready to give it another try.
Bug#814218: lua-ldap: Add support for Lua 5.2
Hi Martin, On Fri, 23 Nov 2018 14:24:52 +0100 "W. Martin Borgert" wrote: > any progress in finding a new or the right upstream? the more or less official looking successor repo on LuaRocks seems to be: https://luarocks.org/modules/devurandom/lualdap Which points to: https://github.com/lualdap/lualdap > The problem becomes a little bit more pressing now: > I plan to upload prosody 0.11 to unstable soon, maybe today. > Prosody 0.11 uses Lua 5.2 instead of 5.1 as recommended by upstream. Prosody 0.11 seems to be the last version to still support Lua 5.1, so using Lua 5.1 may seem like a workaround, at least for stretch- backports? Kind regards, Dan smime.p7s Description: S/MIME cryptographic signature
Bug#914524: Quick-and-Dirty fix that makes the problem go away
Greetings,
to get our sogo running, and to verify that the gnutls/openssl issue is
in fact the main culprit, I did this quick-and-dirty workaround:
--- sogo-4.0.4.orig/UI/MailPartViewers/UIxMailPartSignedViewer.m
+++ sogo-4.0.4/UI/MailPartViewers/UIxMailPartSignedViewer.m
@@ -169,11 +169,12 @@
if (err)
{
#ifdef HAVE_GNUTLS
- const char* sslError;
- ERR_load_crypto_strings();
- SSL_load_error_strings();
- sslError = ERR_reason_error_string(err);
- validationMessage = [[self labelForKey: [NSString
stringWithUTF8String: sslError ? sslError : @"No error information
available"]] retain];
+// const char* sslError;
+// ERR_load_crypto_strings();
+// SSL_load_error_strings();
+// sslError = ERR_reason_error_string(err);
+// validationMessage = [[self labelForKey: [NSString
stringWithUTF8String: sslError ? sslError : @"No error information
available"]] retain];
+ validationMessage = [[self labelForKey: @"No error information
available"] retain];
#elif OPENSSL_VERSION_NUMBER < 0x1010L
const char* sslError;
ERR_load_crypto_strings();
With this patch sogo starts again without errors and the mail ui loads.
Regards,
Nis Wechselberg
signature.asc
Description: OpenPGP digital signature
Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2
On Sat, Nov 24, 2018 at 03:41:36PM +0100, Mattia Rizzolo wrote: > > > Gert: you mention you gave up on symbols, but at least in gdcm's > > > changelog I don't see anything about that. Had you had troubles > > > there as well? > > TBH I never tried with gdcm, I think I started to upload the package > > when it was already at version 2.4 and I didn't even note that there is > > a script for the symbols there (which points at 2.2). … > At the same time, libvtkgdcm is much more tidy, so at least I will start > adding a .symbols file to that one... I've now uploaded a version to experimental with a .symbols file for libvtkgdcm2.8 only, to check that the symbols don't vary further across architectures… The only differences I notice between amd64 and i386 are that some vtk-related functions change from long long on amd64 to int in i386. I pushed everything to git, including my proposal to rename the package to a wip branch, which I'll upload tomorrow if the builds in experimental are alright (hopefully I'll get some ftp-master to fast-track it as well). Gert: I notice several tags are missing in the gdcm repository, could you push them? > > > What I would welcome your help with is explaining the camitk FTBFS on > > > i386. > > Just had as peek, my guess is that this will help: > > > > ifeq ($(DEB_BUILD_ARCH),i386) > > Note that here you probably meant DEB_HOST_ARCH, not build arch. > > > export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store > > endif > > > > The same was needed for ITK because they write tests with floating > > point values apparently comparing with high accuracy, and on i386 > > optimizations can lead to the used of intermediate 80 bit floating > > point values that then result in test failures because the references > > were tuned for 64 bit floating point values. Adding above flag makes > > sure that intermediate results are not keps in these 80 bit FPU > > registers. > > ACK, thanks. -- 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#904009: closed by Sandro Tosi (Re: Bug#904009: reportbug: Backspace, arrow keys and more thing like ctrl+c are not working in some programs)
On Sat, Nov 24, 2018 at 3:06 AM develo...@oldunreal.com wrote: > > I am sorry, I don't understand the explanation for closing this bug. It reportbug is the tool Debian uses to report bugs. if you file a bug against it, it means there is a bug in reportbug itself; it's not just a generic placeholder to report bugs that are not trivial to pinpoint to a specific issue. > happens out of the box (fresh install) for various applications, on > different machines without having any user modifications done. So I have > to assume some more global issue. > How can the average user be expected to dig out a solution for this or > asking for it not having the slightest clue where it is coming from. It if that's the case, reportbug is not the tool you should be using, but instead you should seek advice on a user support forum, such as https://lists.debian.org/debian-user/ ,as i pointed out when closing the report. Please refer to that mailing list for further questions. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Bug#614775: bash-completion: perl -d inhibits filename completion
On Sat, 24 Nov 2018 12:53:38 -0200 "Gabriel F. T. Gomes" wrote: > > I'll apply it to Debian's bash-completion for the next upload. Now in the git repository [1]. I'll wait for more changes (or more time) before doing a new upload. [1] https://salsa.debian.org/debian/bash-completion/commit/5506a39b0f16cee692f44c209a0d1a3b98fa969f
Bug#914547: virtualbox is not installable. Depends: python3 (< 3.7) but 3.7.1-2 is to be installed
Package: virtualbox Version: 5.2.20-dfsg-3 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Dist-upgrade on sid/unstable introduced an unmet python3 dependency. Virtualbox depends on version < 3.7 but python3 is currently installed with version 3.7.1-2 * What exactly did you do (or not do) that was effective (or ineffective)? Performed a dist-upgrade on sid/unstable * What was the outcome of this action? The package got removed due to the unmet dependency. * What outcome did you expect instead? Expected the package to be kept installed. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-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 virtualbox depends on: ii adduser 3.118 ii iproute2 4.18.0-2 ii libc6 2.27-8 ii libcurl3-gnutls 7.62.0-1 ii libdevmapper1.02.12:1.02.145-4.1 ii libgcc1 1:8.2.0-10 pn libgsoap-2.8.60 ii libpng16-16 1.6.34-2 ii libpython3.6 3.6.7-1 ii libsdl1.2debian 1.2.15+dfsg2-4 ii libssl1.1 1.1.1a-1 ii libstdc++68.2.0-10 pn libvncserver1 ii libx11-6 2:1.6.7-1 ii libxcursor1 1:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxml2 2.9.4+dfsg1-7+b2 ii libxmu6 2:1.1.2-2 ii libxt61:1.1.5-1 ii procps2:3.3.15-2 ii python3 3.7.1-2 ii python3.6 3.6.7-1 ii virtualbox-dkms [virtualbox-modules] 5.2.22-dfsg-1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages virtualbox recommends: ii libgl1 1.1.0-1 ii libqt5core5a5.11.2+dfsg-7 ii libqt5opengl5 5.11.2+dfsg-7 ii libqt5widgets5 5.11.2+dfsg-7 pn virtualbox-qt Versions of packages virtualbox suggests: pn vde2 pn virtualbox-guest-additions-iso
Bug#913287: Bug#912925: Is the SONAME the same for all the related libs?
On Fri, Nov 23, 2018 at 10:07:47AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi Julian! > > El jueves, 22 de noviembre de 2018 21:54:30 -03 Julian Gilbey escribió: > > On Sun, Nov 18, 2018 at 03:35:11PM +, Julian Gilbey wrote: > > > On Sun, Nov 18, 2018 at 09:01:19AM -0300, Lisandro Damián Nicanor Pérez > Meyer wrote: > > > > Yesterday I've uploaded qtbase with this fix, please try it. > > > > > > Excellent, thanks! I just built it on my testing machine, and it > > > worked perfectly with the Python script in this bug report and the > > > simplebrowser example. > > > > Hi Lisandro, > > > > Upstream have now patched what-I-presume-will-become 5.12.1 with > > almost this patch. But it's gone through several iterations, and now > > the patch also deletes a couple of #include's. See patch set #7 at > > https://codereview.qt-project.org/#/c/245294/ > > > > I doubt it's worth uploading a new version just for this, but when you > > are doing the next qtbase upload, you might consider making this > > change. > > That's exactly the patch with which I closed this bug. This is already in the > archive. Enjoy! Hi Lisandro, Version 7 of the patch is slightly different from the one you applied to the archive: it also removes some conditional #includes. But it is probably unimportant for Debian. Best wishes, Julian
Bug#861781: www.debian.org: updating Debian memberships in other organisations information
Debian is also an affiliate member of the Open Source Initiative. I removed Desktop Linux Consortium and added the OSI to the membership page: https://salsa.debian.org/webmaster-team/webwml/merge_requests/44 Cheers, Molly
Bug#551707: Processed: Re: dlocate does not complete filenames
On Sun, 27 Dec 2009 23:35:15 +0100 David Paleino wrote: > On Sunday 27 December 2009 23:27:33, Craig Sanders wrote: > > how should we handle this? should I release a new dlocate without > > completion first, or will you divert the completion file to your > > package? > > It would be best if you released a dlocate without completion, and next I > release a package Conflicting with dlocate (<< new_version). > I think that's sufficient. Any other idea? Hi, Craig, Are you still willing to move the completion file for dlocate from the dlocate package to bash-completion (upstream and downstream)? If so, I'll prepare a patch for upstream bash-completion, as well as an upload for downstream bash-completion and wait for your upload removing it from dlocate. > For the upstream team: the conflict is obviously only related to the Debian > package, to avoid file conflicts on installation. This conflict is not really necessary anymore, because completion files are now installed under /usr/share/bash-completion/completions, and dlocate still uses the obsolete dir, i.e.: /etc/bash_completion.d/, thus, there would be no installation conflicts. Thanks, Gabriel
Bug#888479: tcsh 6.20.00-7 crashes when entering non-ascii characters
Yes a proper diff or patch file would be great. -- regards Thomas
Bug#914549: Segmentation fault for some videos (assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed)
Package: gstreamer1.0-plugins-base Version: 1.14.4-dmo1 Hi, When I try to open some videos, totem crashes at startup. Here is an exemple of message I got : "(totem:4264): GStreamer-CRITICAL **: 18:59:54.407: gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed Erreur de segmentation" And if I try to display Nautilus video properties panel for this file, I also get a crash, with Nautilus : "(nautilus:4922): GStreamer-CRITICAL **: 19:18:32.282: gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed Erreur de segmentation" Reading the file with VLC is OK. From VLC I get this video file properties : Xvid MPEG-4 VIDEO & MPEG Audio layer 3. And it's an AVI file. Notice that : - some other Xvid MPEG-4 VIDEO & MPEG Audio layer 3 & AVI file work fine. - files that don't work have this particularity that can be seen from VLC codecs panel : video resolution and buffer dimension are not the same (i.e. 720x404 & 720x416, or 624x300 & 624x320). I have this bug for some months now, and it's still there and I can't find any related bug, therefore here's my report. Thanks ! --- Here is my configuration : * Software : Linux HAL 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-11-02) x86_64 GNU/Linux libc6 2.27-8 totem 3.26.2-1 nautilus 3.30.3-1 gstreamer1.0-plugins-bad 1:1.14.4-dmo2 gstreamer1.0-plugins-good 1.14.4-dmo1 gstreamer1.0-plugins-ugly 1:1.14.4-dmo1 * Hardware 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09) Subsystem: ASRock Incorporation Motherboard [1849:0162] Kernel driver in use: i915
Bug#914550: borgbackup needs to be rebuilt for python 3.7
Package: borgbackup Version: 1.1.7-1 Severity: grave Justification: renders package unusable Dear Maintainer, since the update to python 3.7 in debian unstable, borg is uninstable. a simple rebuild of the package seems to be enough to get a working package. regards, albert dengg -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-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 borgbackup depends on: ii fuse 2.9.8-2 ii libacl12.2.52-3+b1 ii libb2-10.98-1 ii libc6 2.27-8 ii liblz4-1 1.8.2-1 ii libssl1.1 1.1.1-2 ii libzstd1 1.3.5+dfsg-1 ii python33.7.1-2 ii python3-llfuse 1.3.5+dfsg-1 ii python3-msgpack0.5.6-1+b1 ii python3-pkg-resources 40.5.0-1 borgbackup recommends no packages. Versions of packages borgbackup suggests: pn borgbackup-doc -- no debconf information
Bug#914384: sysstat: CVE-2018-19416: the remap_struct function in sa_common.c has an out-of-bounds read during a memmove call
Hi, On Thu, 22 Nov 2018 21:35:39 +0100 Salvatore Bonaccorso wrote: > Source: sysstat > Version: 12.0.1-1 > Severity: important > Tags: security upstream > Forwarded: https://github.com/sysstat/sysstat/issues/196 > > Hi, > > The following vulnerability was published for sysstat. [...] I can't reproduce the issue on Jessie. By executing the POC with sadf stack_oob I get Invalid system activity file: stack_oob File created by sar/sadc from sysstat version 48.48.48.48 Current sysstat version can no longer read the format of this file (0x2175) Looking closer at the affected source code I see that the vulnerable function remap_struct was first introduced on 22.9.2017. https://github.com/sysstat/sysstat/commit/65ac30359e49ee717397e39950d7c24a6610d57c#diff-cccb0877d1539c562536a98e0d17428f Hence I think Jessie is not affected. If I am correct then Stretch should be safe as well, double-checking that would be appreciated. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#914547: Same issue here
Hello, I've the same issue: aruhuno@mufasa:~$ sudo apt install virtualbox Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Certains paquets ne peuvent être installés. Ceci peut signifier que vous avez demandé l'impossible, ou bien, si vous utilisez la distribution unstable, que certains paquets n'ont pas encore été créés ou ne sont pas sortis d'Incoming. L'information suivante devrait vous aider à résoudre la situation : Les paquets suivants contiennent des dépendances non satisfaites : virtualbox : Dépend: python3 (< 3.7) mais 3.7.1-2 devra être installé Recommande: virtualbox-qt (= 5.2.22-dfsg-1) mais ne sera pas installé Recommande: libqt5opengl5 (>= 5.0.2) mais ne sera pas installé E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ». aruhuno@mufasa:~$ apt policy python3 python3: Installé : 3.7.1-2 Candidat : 3.7.1-2 Table de version : *** 3.7.1-2 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status aruhuno@mufasa:~$ cat /etc/debian_version buster/sid Thanks for your work!
Bug#914551: tootle: segfaults in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
Package: tootle Version: 0.2.0-1 Severity: normal Dear Maintainer, after having being running all night and exhibiting bug #911075 and then having a manual refresh (user icon->refresh) tootle segfaulted. #0 0x7f3b48d999f5 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f3b48d9ad0d in g_logv () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f3b48d9aedf in g_log () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f3b48fc1f78 in () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x7f3b48e79749 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #5 0x7f3b48e7b224 in g_object_new_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #6 0x7f3b48e7b559 in g_object_new () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #7 0x7f3b48a167e0 in () at /usr/lib/x86_64-linux-gnu/libgranite.so.5 #8 0x7f3b48a16a5c in granite_date_time_get_relative_datetime () at /usr/lib/x86_64-linux-gnu/libgranite.so.5 #9 0x55e3d8beb518 in tootle_status_widget_rebind (self=self@entry=0x55e3dc2da990) at ../../src/Widgets/StatusWidget.vala:218 #10 0x55e3d8bebae1 in tootle_status_widget_construct (object_type=, status=status@entry=Python Exception Variable 'static_fundamental_type_nodes' not found.: ) at ../../src/Widgets/StatusWidget.vala:196 #11 0x55e3d8bec005 in tootle_status_widget_new (status=status@entry=Python Exception Variable 'static_fundamental_type_nodes' not found.: ) at ../../src/Widgets/StatusWidget.vala:125 #12 0x55e3d8bf53dc in tootle_timeline_view_append (self=0x55e3da4a24a0, status=Python Exception Variable 'static_fundamental_type_nodes' not found.: , first=0) at ../../src/Views/TimelineView.vala:58 #13 0x55e3d8bf55f6 in ___lambda54_ (i=, node=, array=, self=0x55e3da4a24a0) at ../../src/Views/TimelineView.vala:124 #14 0x55e3d8bf55f6 in lambda54__json_array_foreach (array=, index_=, element_node=, self=0x55e3da4a24a0) at ../../src/Views/TimelineView.vala:120 #15 0x7f3b489d5096 in json_array_foreach_element () at /usr/lib/x86_64-linux-gnu/libjson-glib-1.0.so.0 #16 0x55e3d8bf59fa in __lambda53_ (mess=0x55e3dc047d90, sess=, self=0x55e3da4a24a0) at ../../src/Views/TimelineView.vala:120 #17 0x55e3d8bf59fa in ___lambda53__soup_session_callback (session=, msg=0x55e3dc047d90, self=0x55e3da4a24a0) at ../../src/Views/TimelineView.vala:118 #18 0x55e3d8bdd994 in __lambda116_ (mess=0x55e3dc047d90, sess=0x55e3da17b100, _data7_=0x55e3db7ca6d0) at ../../src/Network.vala:71 #19 0x55e3d8bdd994 in ___lambda116__soup_session_callback (session=0x55e3da17b100, msg=0x55e3dc047d90, self=0x55e3db7ca6d0) at ../../src/Network.vala:47 #20 0x7f3b4898ecde in () at /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 #21 0x7f3b4898f6ca in () at /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 #22 0x7f3b4898f756 in () at /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 #23 0x7f3b48d93ae8 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x7f3b48d93ed8 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x7f3b48d93f6c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #26 0x7f3b48f5a13d in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #27 0x55e3d8bd6639 in tootle_application_main (args=, args_length1=) at ../../src/Application.vala:56 #28 0x7f3b487a0b17 in __libc_start_main (main= 0x55e3d8bd5c60 , argc=1, argv=0x7ffe420964b8, init=, fini=, rtld_fini=, stack_end=0x7ffe420964a8) at ../csu/libc-start.c:310 #29 0x55e3d8bd5c9a in _start () at ../../src/Application.vala:43 [Switching to thread 2 (Thread 0x7f3b315bf700 (LWP 569))] #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory. (gdb) bt #0 0x7f3b48870a79 in syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7f3b48dda75a in g_cond_wait_until () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f3b48d66061 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f3b48dbcc12 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f3b48dbc135 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f3b474f7f2a in start_thread (arg=0x7f3b315bf700) at pthread_create.c:463 #6 0x7f3b48875edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) thread 3 [Switching to thread 3 (Thread 0x7f3b41bf3700 (LWP 30717))] #0 0x7f3b4886b739 in __GI___poll (fds=0x55e3d9fced10, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) bt #0 0x7f3b4886b739 in __GI___poll (fds=0x55e3d9fced10, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f3b48d93e46 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f3b48d93f6c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/li
Bug#914552: black: FTBFS Attempt to download test dependencies during build
Source: black
Version: 18.9b0-1-5
Severity: serious
Tags: patch
Dear Maintainer,
I tried to build the package locally in pbuilder,
but it fails to build from source with the following error message:
running test
Searching for toml>=0.9.4
Note: Bypassing https://pypi.org/simple/toml/ (disallowed host; see
http://bit.ly/2hrImnY for details).
Couldn't find index page for 'toml' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Note: Bypassing https://pypi.org/simple/ (disallowed host; see
http://bit.ly/2hrImnY for details).
No local packages or working download links found for toml>=0.9.4
error: Could not find suitable distribution for
Requirement.parse('toml>=0.9.4')
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1:
python3.7 setup.py test
It fails since it attempts to download additional dependencies from the
Internet.
I originally saw this when it failed to build when it was synced to
Ubuntu [1][2],
but was also able to reproduce it on Sid.
With the attached patch, gradually adding additional build dependencies,
it eventually built successfully.
[1]
https://launchpad.net/ubuntu/+source/black/18.9b0-1-5/+build/15638431
[2]
https://launchpadlibrarian.net/39789/buildlog_ubuntu-disco-amd64.black_18.9b0-1-5_BUILDING.txt.gz
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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
--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index 4bca183..bcd8447 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,8 @@ Maintainer: Neil Williams
Build-Depends: debhelper (>= 11), dh-python,
python3, python3-recommonmark, python3-setuptools,
python3-sphinx, python3-docutils,
- libjs-underscore, libjs-jquery
+ libjs-underscore, libjs-jquery,
+ python3-appdirs, python3-attr, python3-click, python3-toml
Standards-Version: 4.2.1
Homepage: https://github.com/ambv/black
X-Python3-Version: >= 3.6
Bug#914553: sysstat: CVE-2018-19517: out of bound read in sadf which leads to crash
Source: sysstat Version: 12.0.1-1 Severity: important Tags: security upstream Forwarded: https://github.com/sysstat/sysstat/issues/199 Hi, The following vulnerability was published for sysstat, similar to CVE-2018-19416. CVE-2018-19517[0]: | An issue was discovered in sysstat 12.1.1. The remap_struct function in | sa_common.c has an out-of-bounds read during a memset call, as | demonstrated by sadf. The poc to verify a fix (base64 encoded here): ltV1ITAwMDBIAQAAMDAwMAEBMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBQAAADAwMDkA AAACAAAkEDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDABMDAwMAIBAAgwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAEBABAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMAAwMDAwMDAwMDAwMDAwMDAwMDAwMDAGiwEBACgA AAAF/wAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAAwMDAwMDAw MDAwMDAwMDAwADAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA= This is similar to #914384 but fo the issue triggered during the memset call. 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-2018-19517 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19517 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#904309: RFP: tilda -- [SHORT DESCRIPTION]
I can confirm this issue (Segfault when trying to start under Wayland) is valid in Debian Testing. The issue is known upstream (https://github.com/lanoxx/tilda/issues/314) andthere's a workaround in commit daa64f5. I tried cherry-picking this commit and installing the rebuilt Debian package, and found that tilda starts up normally again. Best regards, P.
Bug#914554: clxclient FTBFS: freetype-config not found
Source: clxclient Version: 3.9.0-4 Severity: serious Tags: ftbfs patch upstream clxclient fails to build from source in unstable, because freetype-config got removed. You're supposed to use pkg-config instead. The attached patch fixes the build. Helmut --- clxclient-3.9.0.orig/Makefile +++ clxclient-3.9.0/Makefile @@ -31,8 +31,9 @@ VERSION = $(MAJVERS).$(MINVERS) -CPPFLAGS += -Wall -I. -I/usr/X11R6/include `freetype-config --cflags` -fpic -DVERSION=\"$(VERSION)\" -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -O2 -LDFLAGS += -L/usr/X11R6/$(LIBDIR) -Wl,--as-needed `freetype-config --libs` +PKG_CONFIG ?= pkg-config +CPPFLAGS += -Wall -I. -I/usr/X11R6/include `$(PKG_CONFIG) freetype2 --cflags` -fpic -DVERSION=\"$(VERSION)\" -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -O2 +LDFLAGS += -L/usr/X11R6/$(LIBDIR) -Wl,--as-needed `$(PKG_CONFIG) freetype2 --libs` LDLIBS +=
Bug#914554: clxclient FTBFS: freetype-config not found
On Sat, Nov 24, 2018 at 09:43:31PM +0100, Helmut Grohne wrote: > Source: clxclient > Version: 3.9.0-4 > Severity: serious > Tags: ftbfs patch upstream > > clxclient fails to build from source in unstable, because > freetype-config got removed. You're supposed to use pkg-config instead. > The attached patch fixes the build. That's despite the package not build-dependending on freetype nor any binary having a dependency on it. That's wrong on several levels, so please investigate why is it so, I'd expect both a build-dep and a runtime dependency. -- 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#914555: ITP: node-lunr -- simple full-text search
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: node-lunr Version : 2.3.5 Upstream Author : Oliver Nightingale * URL : https://lunrjs.com/ * License : Expat Programming Lang: JavaScript Description : simple full-text search Lunr.js is a small, full-text search library for use in the browser. It indexes JSON documents and provides a simple search interface for retrieving documents that best match text queries. Async is a utility module which provides straight-forward, powerful functions for working with asynchronous Javascript. . This package provides Lunr for use directly in web browsers. This package is needed by recent releases of mkdocs (see bug#907256). The package will be maintained in the JavaScript team. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlv5xF0ACgkQLHwxRsGg ASE5kA/+MMuMsObJdO6CctkzN3qh4tpQYWAk4Z3tRGfoiC6rNHIsZI9fxHEncTcf n+r7CchTiG9XiZvUftG+TCZ/9Sy34oQ+x1RbfZbO9dU5bX1tandNXvwtyJ2IN27V RQi91gN22gvZ0qbeozYDHcLJoe2EoYfVlGe6bkE3mqgHZjW/iwztoRP2OPgLHXnl C8MYAhhHi0zRVdSAMcTmY28TPRyb/nHBFup7J47bpd8F6V/p2Py7KgOcFHPbmZvN 5hRo0kX8uebpgRLp9gHrXR7aQzKKIu8es9OVv6SX2h5D78cnSJoznw4NXB0DRJ5A CdtimHlpxheTJzIsMUAxyn5qZyacEsjFAjNMiOdfp4wm7JkRk8VyXFACF8zHheke 8XztQ87GIPoXup8Ifj+rhEZVUZVelVDyztdyfgEfRiAcGQlU0gHbXKOT1C7VqyQy GEnqa7g61mZFrAwdrp+BJX/nlJxI50iFK+hBwjK9XDTvuNuXRoDYtoHtcMxgm41E BR5UdKnOfFqP70R97zZ397V10UF8KU65fpXxDpUXsqWAPhIOAnjcH7JaQu/v3f4d p81K+XHO0l+OS+VFCqTZ8zyGlOmmQ5lHsSPUjj3oVToXG1/VbG9Xm64wbTfTOW8q qvuSbDxN1TtEODdBiyNWCGiTAaO79vRFRXvT6+DUx+gRhOMW7xc= =f0Xz -END PGP SIGNATURE-
Bug#914556: linux: FTBFS on arm64: changed ABI
Source: linux Version: 4.9.135-1 Severity: serious Justification: FTBFS Control: affects -1 release.debian.org For tracking the issue: 4.9.135-1 FTBFS on arm64 due to changed ABI: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=arm64&ver=4.9.135-1&stamp=1543036173&raw=0 Relevant part: hnae_ae_register module: drivers/net/ethernet/hisilicon/hns/hnae, version: 0xdf635812 -> 0xbdde09c7, export: EXPORT_SYMBOL hnae_ae_unregister module: drivers/net/ethernet/hisilicon/hns/hnae, version: 0xe679c9fd -> 0x1c9eb41e, export: EXPORT_SYMBOL hnae_get_handle module: drivers/net/ethernet/hisilicon/hns/hnae, version: 0xafb4a8fd -> 0x29ae7935, export: EXPORT_SYMBOL hnae_put_handle module: drivers/net/ethernet/hisilicon/hns/hnae, version: 0x899f69bb -> 0x43a26da5, export: EXPORT_SYMBOL hnae_reinit_handle module: drivers/net/ethernet/hisilicon/hns/hnae, version: 0x767c1c31 -> 0xbc41182f, export: EXPORT_SYMBOL Regards, Salvatore
Bug#870836: imake generated makefile use deprecated -D_BSD_SOURCE and -D_SVID_SOURCE
Hilariously, I just ran into this today when building a program I wrote in 1987. Thanks huge to Teemu for working out the patch; I have verified that it works for me. It would be great if this could be packaged.
Bug#914557: thunderbird: Version 1:60.3.0-1+b1 is not installable (breaks lightning and various calendar)
Package: thunderbird Version: 1:60.3.0-1+b1 Severity: important LANG=C apt-get -s install thunderbird NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done Recommended packages: lightning The following packages will be REMOVED: calendar-exchange-provider calendar-google-provider lightning The following packages will be upgraded: thunderbird 1 upgraded, 0 newly installed, 3 to remove and 5 not upgraded. Remv calendar-exchange-provider [5.0.0~alpha1-1] Remv calendar-google-provider [1:60.3.0-1] Remv lightning [1:60.3.0-1] Inst thunderbird [1:60.3.0-1] (1:60.3.0-1+b1 Debian:unstable [amd64]) Conf thunderbird (1:60.3.0-1+b1 Debian:unstable [amd64]) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.83 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunderbird depends on: ii debianutils 4.8.6 ii fontconfig2.13.1-2 ii libatk1.0-0 2.30.0-1 ii libc6 2.28-0experimental1 ii libcairo-gobject2 1.16.0-1 ii libcairo2 1.16.0-1 ii libdbus-1-3 1.13.6-1 ii libdbus-glib-1-2 0.110-3 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-8 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-10 ii libgdk-pixbuf2.0-02.38.0+dfsg-6 ii libglib2.0-0 2.58.1-6 ii libgtk-3-03.24.1-2 ii libgtk2.0-0 2.24.32-3 ii libhunspell-1.6-0 1.6.2-2 ii libicu60 60.2-6 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.39-1 ii libpango-1.0-01.42.4-4 ii libpangocairo-1.0-0 1.42.4-4 ii libpangoft2-1.0-0 1.42.4-4 ii libsqlite3-0 3.25.3-2 ii libstartup-notification0 0.12-5 ii libstdc++68.2.0-10 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-1 ii libxcb1 1.13.1-1 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc23.2-1 ii x11-utils 7.7+4 ii zlib1g1:1.2.11.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1 ii hunspell-fr-classical [hunspell-dictionary] 1:6.3-1 ii lightning1:60.3.0-1 Versions of packages thunderbird suggests: ii apparmor 2.13.1-3+b1 ii fonts-lyx 2.3.1-2-2 ii libgssapi-krb5-2 1.16.1-1 -- no debconf information
Bug#914558: petsc: hardcodes path to sh depending on build host
Package: petsc Version: 3.9.4+dfsg1-2 Dear maintainer, Recently your package was rebuild as part of the hdf5 transition. During the rebuild, the buildds accidentally had a merged usr setup [1]. Although this setup has been reverted, it exposed the fact that your package embeds the path to sh from the build host, as the autopkgtest of your started failing [2] with the error copied below. There was a large thread on debian-devel@l.d.o about merged usr setup due to the buildd issue. I think your build should not rely on the location of sh in the $PATH of the build host. I have requested binNMUs of your package on #debian-release. Paul [1] https://wiki.debian.org/UsrMerge [2] https://ci.debian.net/packages/p/petsc/unstable/amd64/ [3] https://lists.debian.org/msgid-search/20181120211617.gxnuwxpx2hy44...@angband.pl https://ci.debian.net/data/autopkgtest/testing/amd64/p/petsc/1370827/log.gz autopkgtest [07:28:26]: test test-petsc: [--- Running test examples to verify correct installation Using PETSC_DIR=/usr/lib/petsc make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:158: clean-legacy] Error 127 (ignored) make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:159: clean-legacy] Error 127 (ignored) run SNES testex19 make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:402: ex19.PETSc] Error 127 (ignored) make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:403: ex19.PETSc] Error 127 (ignored) make: /usr/bin/sh: Command not found make: [makefile:266: testex19] Error 127 (ignored) test HYPRE make: /usr/bin/sh: Command not found make: [makefile:287: runex19_hypre] Error 127 (ignored) test MUMPS make: /usr/bin/sh: Command not found make: [makefile:297: runex19_fieldsplit_mumps] Error 127 (ignored) run testex5f make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:453: ex5f.PETSc] Error 127 (ignored) make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:454: ex5f.PETSc] Error 127 (ignored) make: /usr/bin/sh: Command not found make: *** [makefile:250: testex5f] Error 127 make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:158: clean-legacy] Error 127 (ignored) make: /usr/bin/sh: Command not found make: [/usr/lib/petsc/lib/petsc/conf/rules:159: clean-legacy] Error 127 (ignored) Completed test examples autopkgtest [07:28:26]: test test-petsc: ---] signature.asc Description: OpenPGP digital signature
