Bug#920373: default soundfonts
Am Donnerstag, den 08.08.2019, 10:56 +0200 schrieb Fabian Greffrath: > from what I can see, only these two soundfont package are still > missing > from our transition to provide sf[23]-soundfont-gm, right? I have filed a bug against fluid-soundfont-gm and issued a pull request for opl3-soundfont, respectively. So, chances are high we can finish this transition in the short term. - Fabian signature.asc Description: This is a digitally signed message part
Bug#931325: manpages-dev: io_cancel can fail with EINTR
Hello Marc, On 7/1/19 10:34 PM, Marc Lehmann wrote: Package: manpages-dev Version: 4.16-2 Severity: minor Dear Maintainer, I found that, at least with debians 4.19 kernel, io_cancel can fail with EINTR on signal delivery, which should be documented as per similar calls. Can you provide some more info on the circumstances where you observed this behavior please. Thanks, MIchael
Bug#935142: FTBFS arch all
close 935142 thanks I could trace it down to sqlite3 3.29.0-2 (downgrading to 3.29.0-1 makes it build again). will check further and then report to sqlite3 i guess.. sorry for the noise :/ Regards, Daniel
Bug#850009: I've the same error mentionned...
Cadschool Sàrl wrote... > I've he same error that mentionned in this bugs reports: >//etc/cron.daily/logrotate: error: error creating output file >/var/log/mail.warn.1.gz: Le fichier existe (...) This smells like a duplicate of #734688 (scroll down to the end). > My server config (KVM Debian Jessie): The listed upstream patch fixed the issue and is part of Debian 9 (stretch) and later. You could try to backport it on your own. Christoph (not the logrotate maintainer, but I fixed the above issue in Debian) signature.asc Description: PGP signature
Bug#935144: smb2www: [INTL:fr] French debconf templates translation
Package: smb2www Version: N/A Severity: wishlist Tags: patch l10n Dear Maintainer, Please find attached the French debconf templates translation, proofread by the debian-l10n-french mailing list contributors. Kind regards Grégoire # Translation of smb2www debconf templates to French # Copyright (C) 2007 Christian Perrier # This file is distributed under the same license as the smb2www package. # # Christian Perrier , 2005-2007. msgid "" msgstr "" "Project-Id-Version: \n" "Report-Msgid-Bugs-To: smb2...@packages.debian.org\n" "POT-Creation-Date: 2019-08-04 13:21+0200\n" "PO-Revision-Date: 2019-08-13 10:13+0800\n" "Last-Translator: Christian Perrier \n" "Language-Team: French \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.11.4\n" #. Type: note #. Description #: ../templates:2001 msgid "smb2www disabled by default" msgstr "smb2www désactivé par défaut" #. Type: note #. Description #: ../templates:2001 msgid "" "If enabled, smb2www will, by default, allow anyone to browse the local SMB " "network." msgstr "" "S'il est activé, smb2www permettra, par défaut, à quiconque de parcourir le " "réseau SMB local." #. Type: note #. Description #: ../templates:2001 msgid "" "As this may have security consequences, it is disabled by default and you " "should modify the web server configuration to enable smb2www securely. " "Please read /usr/share/doc/smb2www/index.html for more information (more " "particularly FAQ 4) about such configuration for Apache." msgstr "" "Comme cela peut avoir des implications néfastes sur la sécurité, il est " "désactivé par défaut et vous devez modifier la configuration du serveur web " "pour l'activer de manière sécurisée. Veuillez lire /usr/share/doc/smb2www/" "index.html pour plus d'informations sur la méthode à employer avec Apache " "(particulièrement la section 4 de la FAQ)." #. Type: boolean #. Description #: ../templates:3001 msgid "Do you want to enable smb2www?" msgstr "Faut-il activer smb2www ?" #. Type: string #. Description #: ../templates:4001 msgid "Master browser server:" msgstr "Maître explorateur :" #. Type: string #. Description #: ../templates:4001 msgid "" "Please enter the name of the server which will be used by smb2www as a " "master browser." msgstr "" "Veuillez indiquer le nom du serveur qui sera utilisé comme maître " "explorateur par smb2www." #. Type: select #. Choices #: ../templates:5001 msgid "English" msgstr "anglais" #. Type: select #. Choices #: ../templates:5001 msgid "Czech" msgstr "tchèque" #. Type: select #. Choices #: ../templates:5001 msgid "Dutch" msgstr "néerlandais" #. Type: select #. Choices #: ../templates:5001 msgid "German" msgstr "allemand" #. Type: select #. Choices #: ../templates:5001 msgid "Finnish" msgstr "finnois" #. Type: select #. Choices #: ../templates:5001 msgid "French" msgstr "français" #. Type: select #. Choices #: ../templates:5001 msgid "Polish" msgstr "polonais" #. Type: select #. Choices #: ../templates:5001 msgid "Spanish" msgstr "espagnol" #. Type: select #. Choices #: ../templates:5001 msgid "Swedish" msgstr "suédois" #. Type: select #. Choices #: ../templates:5001 msgid "Vietnamese" msgstr "vietnamien" #. Type: select #. Default #. You must NOT translate this string, but you can change its value. #. The comment between brackets is used to distinguish this msgid #. from the one in the Choices list; you do not have to worry about #. them, and have to simply choose a msgstr among the English values #. listed in the Choices field above, e.g. msgstr "Dutch" #: ../templates:5002 msgid "English[ default language ]" msgstr "French" #. Type: select #. Description #: ../templates:5003 msgid "Language for smb2www pages:" msgstr "Langue des pages de smb2www :" #. Type: select #. Description #: ../templates:5003 msgid "Smb2www can generate its HTML pages in several languages." msgstr "Smb2www peut créer ses pages HTML en plusieurs langues." #. Type: select #. Description #: ../templates:5003 msgid "Please choose the language you want to use on generated pages." msgstr "Veuillez choisir la langue à utiliser sur les pages créées."
Bug#934978: mini-buildd: Does not function behind a NAT router
On Mon, Aug 19, 2019 at 12:25 PM Stephan Sürken wrote: > I am not quite getting it ;), I guess I need more information here. > > What's the 'Hostname' entry of the 'Daemon' instance? localhost > Do you have remotes configured (not needed if you are building on that > host only)? No, no remotes configured. Also, on further investigation, it appears that "a23-195-69-106.deploy.static.akamaitechnologies.com" is actually the FQDN of the host my ISP's broken DNS redirects me to for nonexistent host names :( , rather than the external IP address of the NAT router. -- Daniel Schepler
Bug#935143: nmu: apache-opennlp_1.9.1-1 jamm_0.3.3-1 jarchivelib_1.0.0-1 vectorgraphics2d_0.13-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, I want to request binNMU on amd64 for recently accepted new arch:all packages, as they are not migrated to testing due to missing builds on buildd. nmu apache-opennlp_1.9.1-1 . amd64 . unstable . -m "Rebuild on buildd" nmu jamm_0.3.3-1 . all . amd64 . -m "Rebuild on buildd" nmu jarchivelib_1.0.0-1 . amd64 . unstable . -m "Rebuild on buildd" nmu vectorgraphics2d_0.13-1 . amd64 . unstable . -m "Rebuild on buildd" Thanks, Andrius
Bug#935142: FTBFS arch all
Package: firefox Version: 68.0.1-1 Severity: serious Hi, starting with 68.0.1-1, firefox stopped to build on arch all as can be seen on the buildd logs. It would be nice to get that fixed to get translations back. Regards, Daniel
Bug#934600: gffread in cufflinks seems to be the same codebase but older
Hi Alexandre, it looks as if the gffread code in cufflinks would be the same code base but the code in gffread source seems to be more recent. What do you think? Kind regards Andreas. - Forwarded message from Debian testing autoremoval watch - Date: Tue, 20 Aug 2019 04:39:04 + From: Debian testing autoremoval watch To: cuffli...@packages.debian.org Subject: cufflinks is marked for autoremoval from testing cufflinks 2.2.1+dfsg.1-3 is marked for autoremoval from testing on 2019-09-10 It is affected by these RC bugs: 934600: cufflinks,gffread: both ship /usr/bin/gffread ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging - End forwarded message - -- http://fam-tille.de
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Control: tags -1 + moreinfo On Tue, 2019-08-20 at 00:33 +0100, Samuel Henrique wrote: > Thanks for your help Paul :) > > I'm attaching a debdiff for 1.3.2-1+deb10u1, release team please > advise whether that's acceptable or not (please read discussion on > the bugreport), It certainly can't be 1.3.2-1+deb10u1, as that version number is higher than the package in unstable. Either one would need to go with 1.3.1- 2+deb10u1 with just the bug fix applied, or 1.3.2-1~deb10u1 with a "backports-style" changelog containing both 1.3.2-1 and then the stable update. In either case we would need a debdiff that reflects the chosen approach. One thing that will need to be fixed in unstable first either way: Not built on buildd: arch all binaries uploaded by samueloph As per the d-d-a announcement, that will need a new source upload to unstable to resolve, as arch:all can't be usefully binNMUed. Regards, Adam
Bug#934634: allow choosing other riot-web instances
On Tue, 13 Aug 2019 11:41:32 +0530, Pirate Praveen said: > On 2019, ഓഗസ്റ്റ് 12 11:08:49 PM IST, Andrej Shadura > wrote: >> Hi, >> >> On Mon, 12 Aug 2019 at 19:30, Pirate Praveen >> >> wrote: >>> I'd like to use chat.poddery.com instead of riot.im in revolt. I >> think >>> this can be configured with debconf question with default value >>> being riot.im/app. >> >> I’d say rather with a ~/.config setting or a command line argument. >> Debconf is a bad choice IMHO since it’s system-wide. > That would be fine too. You can change the location of the Riot instance that it uses by going to Revolt's preferences (either in the Application menu, and select Preferences, or right-click on the systray icon and select Preferences, or hit Ctrl-E). -- Hubert Chathi -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
Bug#916167: libpodofo: CVE-2018-15889
Control: retitle -1 libpodofo: CVE-2018-5783 Control: forcemerge 916142 -1 This has been confirmed now to be a duplicate of CVE-2018-5783. Regards, Salvatore
Bug#935141: wxmaxima: assertion failure with multiple monitors
Package: wxmaxima Version: 19.01.2-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm having this issue both with 19.01.2-1 and 19.07.0-1. Backtraces and screenshots are from the latter. On my Plasma system, Maxima keeps giving an assertion failure dialog when clicking just about any item from a dropdown menu. Sometimes the dialogs have very small dimensions and need to be expanded, but it seems to otherwise work fine. Clicking 'Stop' in the dialog gets the backtrace I've included. - -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wxmaxima depends on: ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libstdc++68.3.0-6 ii libwxbase3.0-0v5 3.0.4+dfsg-8 ii libwxgtk3.0-0v5 3.0.4+dfsg-8 ii maxima5.42.1-1 Versions of packages wxmaxima recommends: ii maxima-doc 5.42.1-1 Versions of packages wxmaxima suggests: ii fonts-jsmath 0.090709+0-3 ii ibus-gtk31.5.19-4 ii texlive-latex-extra 2018.20190227-2 - -- no debconf information *** /home/john/wxmaxima-bt.txt Program received signal SIGTRAP, Trace/breakpoint trap. raise (sig=sig@entry=5) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 raise (sig=sig@entry=5) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7705942a in wxTrap () at ../src/common/appbase.cpp:1074 #2 0x7758ee2d in wxGUIAppTraits::ShowAssertDialog (this=, msg=...) at ../src/gtk/utilsgtk.cpp:345 #3 0x7705cab2 in ShowAssertDialog (file=..., line=, func=..., cond=..., msgUser=..., traits=0x55bb34f0) at ../include/wx/buffer.h:44 #4 0x7705e9b0 in wxAppConsoleBase::OnAssertFailure (this=this@entry=0x55b425d0, file=, line=119, func=, cond=, msg=) at ../include/wx/string.h:3488 #5 0x7755e3b0 in wxApp::OnAssertFailure (this=0x55b425d0, file=, line=, func=, cond=, msg=) at ../src/gtk/app.cpp:540 #6 0x7705ec68 in wxDefaultAssertHandler (file=..., line=119, func=..., cond=..., msg=...) at ../include/wx/string.h:4179 #7 0x7705e041 in wxOnAssert (file=file@entry=0x777e34b0 "../src/common/dpycmn.cpp", line=line@entry=119, func=func@entry=0x777e3540 "wxDisplay", cond=cond@entry=0x777e34c9 "n < GetCount()", msg=msg@entry=0x777e33c8 L"An invalid index was passed to wxDisplay") at ../include/wx/string.h:3488 #8 0x7767712e in wxDisplay::wxDisplay (this=0x7fffcb30, n=4294967295) at ../include/wx/display_impl.h:82 #9 0x77667021 in wxStandardDialogLayoutAdapter::DoMustScroll (dialog=0x56671720, windowSize=..., displaySize=...) at ../src/common/dlgcmn.cpp:907 #10 0x776670e8 in wxStandardDialogLayoutAdapter::MustScroll (displaySize=..., windowSize=..., dialog=, this=) at ../src/common/dlgcmn.cpp:897 #11 wxStandardDialogLayoutAdapter::CanDoLayoutAdaptation (this=, dialog=) at ../src/common/dlgcmn.cpp:654 #12 0x775dea66 in wxDialog::Show (this=0x56671720, show=) at ../src/gtk/dialog.cpp:69 #13 0x775debce in wxDialog::ShowModal (this=0x56671720) at ../src/gtk/dialog.cpp:164 #14 0x55808fb2 in wxMaxima::CalculusMenu (this=0x55becbb0, event=...) at ./src/wxMaxima.cpp:6329 #15 0x771bf7ae in wxEvtHandler::ProcessEventIfMatchesId (event=..., handler=, entry=...) at ../include/wx/app.h:439 #16 wxEvtHandler::ProcessEventIfMatchesId (entry=..., handler=, event=...) at ../src/common/event.cpp:1365 #17 0x771bf8b3 in wxEventHashTable::HandleEvent (this=, event=..., self=self@entry=0x55becbb0) at ../src/common/event.cpp:996 #18 0x771bfbec in wxEvtHandler::TryHereOnly (this=0x55becbb0, event=...) at ../src/common/event.cpp:1587 #19 0x771bfa73 in wxEvtHandler::DoTryChain (this=, event=...) at ../src/common/event.cpp:1552 #20 0x771bfd11 in wxEvtHandler::ProcessEvent (this=0x55bed190, event=...) at ../src/common/event.cpp:1493 #21 0x7773f3cb in wxWindowBase::TryAfter (this=0x55f69800, event=...) at ../include/wx/window.h:846 #22 0x771bfab7 in wxEvtHandler::SafelyProcessEvent (this=, event=...) at ../src/common/event.cpp:1611 #23 0x777408ec in wxWindowBase::HandleWindowEvent (this=this@entry=0x55f69800, event=...) at ../include/wx/window.h:846 #24 0x776f69f5 in wxMenuBase::SendEvent (this=this@entry=0x55fbee00, itemid=itemid@entry=8574, checked=) at ../src/common/menucmn.cpp:666 #25 0x775f5abb in menuitem_activate (item=0x55ff0850) at ../
Bug#935139: libguichan_allegro-0.8.1.so: needs to link with -lguichan -lalleg
Package: libguichan-allegro-0.8.1-1v5 Version: 0.8.2-18+b1 Severity: minor File: /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 User: debian...@lists.debian.org Usertags: undefined-symbol adequate libguichan_allegro-0.8.1.so needs to link with -lguichan -lalleg, see the output of adequate, symtree and objdump below. I detected this on amd64 but the Debian build log scanner also detected dpkg-buildpackage complaining about it on most architectures, see the w3m/getbuildlog output below. I filed this bug at severity minor since I'm not sure if there are any programs using the guichan-allegro lib and if they already use the guichan/alleg symbols and link with the -lguichan -lalleg flags or not. This bug report brought to you by adequate: https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/ $ lib=/usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 $ link=/usr/lib/x86_64-linux-gnu/libguichan-0.8.1.so.1.1.0 $ pkg="$(dpkg-query --search "$lib" | sed s/:.*//)" $ src="$(grep-aptavail --no-field-names --show-field Source:Package --field Package --exact-match --pattern "$pkg" | sed 's/ .*//')" $ first="$(printf '%s' "$src" | head --bytes 1)" $ adequate "$pkg" libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZTIN3gcn4FontE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZNK3gcn4Font16getStringIndexAtERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZTIN3gcn8GraphicsE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZTIN3gcn8GraphicsE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZN3gcn8Graphics18getCurrentClipAreaEv libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZN3gcn8Graphics9drawImageEPKNS_5ImageEii libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZN3gcn8Graphics7setFontEPNS_4FontE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZN3gcn8Graphics8drawTextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiNS0_9AlignmentE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZTIN3gcn5ImageE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZTIN3gcn5ImageE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => mouse_y libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => key libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => mouse_x libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZTVN3gcn8GraphicsE libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _rgb_r_shift_32 libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => key_shifts libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _rgb_b_shift_32 libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => mouse_b libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => mouse_z libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _rgb_g_shift_32 libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => drawing_mode libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZN3gcn8Graphics11popClipAreaEv libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => text_length libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => text_height libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => poll_mouse libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0 => _ZN3gcn9ExceptionC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_S8_j libguichan-allegro-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-l
Bug#935140: libguichan_opengl-0.8.1.so: needs to link with -lGL
Package: libguichan-opengl-0.8.1-1v5 Version: 0.8.2-18+b1 Severity: minor File: /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 User: debian...@lists.debian.org Usertags: undefined-symbol adequate libguichan_opengl-0.8.1.so needs to link with -lGL, see the output of adequate, symtree and objdump below. I detected this on amd64 but the Debian build log scanner also detected dpkg-buildpackage complaining about it on most architectures, see the w3m/getbuildlog output below. I filed this bug at severity minor since I'm not sure if there are any programs using the guichan_opengl lib and if they already use the libGL symbols and link with the -lGL flag or not. This bug report brought to you by adequate: https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/ $ lib=/usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 $ link=/usr/lib/x86_64-linux-gnu/libGL.so.1.7.0 $ pkg="$(dpkg-query --search "$lib" | sed s/:.*//)" $ src="$(grep-aptavail --no-field-names --show-field Source:Package --field Package --exact-match --pattern "$pkg" | sed 's/ .*//')" $ first="$(printf '%s' "$src" | head --bytes 1)" $ adequate "$pkg" libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glPopAttrib libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glPointSize libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glBegin libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glDisable libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glTexImage2D libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glTexCoord2f libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glGetError libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glVertex3i libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glBlendFunc libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glScissor libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glEnable libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glVertex2f libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glBindTexture libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glVertex2i libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glLoadIdentity libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glEnd libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glDeleteTextures libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glTexParameteri libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glTexEnvf libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glMatrixMode libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glGenTextures libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glPushAttrib libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glColor4ub libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glPushMatrix libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glLineWidth libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glPopMatrix libguichan-opengl-0.8.1-1v5:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libguichan_opengl-0.8.1.so.1.1.0 => glOrtho $ man adequate | grep -A4 undefined-symbol undefined-symbol The symbol has not been found in the libraries linked with the binary. Either the binary either needs to be linked with an additional shared library, or the dependency on the shared library package that provides this symbol is too weak. References: Debian Policy §3.5, §8.6, §10.2. $ lddtree "$lib" libguichan_opengl-
Bug#935138: lintian: version-substvar-for-external-package only matches :Version and not :Upstream-Version
Package: lintian Version: 2.18.0 Severity: normal Control: affects -1 src:wireguard While resolving #930432 in the wireguard package, I noticed that the code for lintian tag version-substvar-for-external-package appears to only trigger if the dependency is on source:Version or binary:Version but not on *:Upstream-Version. While i'm legitimately overriding this tag in wireguard anyway, it would probably make sense to test for :Upstream-Version too, for the cases where it is actually catching a legitimate packaging mistake. Thanks for your work on Lintian! --dkg -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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) Versions of packages lintian depends on: ii binutils 2.32.51.20190727-1 ii bzip21.0.6-9.2 ii diffstat 1.62-1+b1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.37-5 ii gettext 0.19.8.1-9 ii gpg 2.2.17-3 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b1 ii libarchive-zip-perl 1.64-1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.44-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl0.41-1+b1 pn libdigest-sha-perl ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.74-1 ii libipc-run-perl 20180523.0-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b4 ii libmoo-perl 2.003004-2 ii libpath-tiny-perl0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.004004-1 ii liburi-perl 1.76-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.79+repack-2 ii man-db 2.8.6.1-1 ii patchutils 0.3.4-2+b1 ii perl 5.28.1-6 ii t1utils 1.41-3 ii xz-utils 5.2.4-1 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 ii libtext-template-perl 1.55-1 -- no debconf information
Bug#932086:
Also related: # CONFIG_SURFACE_3_BUTTON is not set # CONFIG_INTEL_BXTWC_PMIC_TMU is not set
Bug#932775: [Pkg-net-snmp-devel] Bug#932775: snmpd: Systemd service file also does not respect /etc/default/snmpd
On Tue, 20 Aug. 2019, 6:54 am Cool Fire, wrote: > It seems the systemd service file (/lib/systemd/system/snmpd.service) > also ignores the /etc/default/snmpd file. That's correct and how systemd files work. You copy it to /etc/systemd and make your changes. It's actually an bhg to use the default files for systemd setup. - Craig
Bug#892264: Hy 0.17.0
On Sat, 17 Aug 2019 at 04:04, Tristan Seligmann wrote: > Go for it! Maintainer should probably be DPMT anyway. To be fair, it is, but you're a human listed for the package so I figured I'd reach out to avoid stepping on your toes. Thanks! :) Will be uploading soon, and once/if ACCEPTed will finally get Hy 0.17.0 uploaded and get these bugs closed and behind us! :D ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Thanks for your help Paul :) I'm attaching a debdiff for 1.3.2-1+deb10u1, release team please advise whether that's acceptable or not (please read discussion on the bugreport), Regards, -- Samuel Henrique ruby-airbrussh_1.3.2-1+deb10u1.debdiff Description: Binary data
Bug#926798: RFP: elpa-magit-forge -- Work with Git forges from the comfort of Magit
Hi! Antoine Beaupré writes: > > Stay tuned. ;-) > > I'm still tuned! Have you worked on this more? Did you managed to make > it work with magit at all? :) > I've worked on packaging most of its dependencies but got stuck on something, back a month ago or something like that. Then hadn't much time to figure out what was wrong there. :-/ Anyway, I'll ping on IRC to see if we can find a solution easily together. Cheers. mfv
Bug#919694: elogind triggers ACPI suspend on laptop lid close, contrary to prior acpi-support configuration
Dixi quod… >I just ran into this myself. Why is this still unfixed? >Freezing the laptop(’s playing music) just because I close it >is utterly inacceptable as a default setting. My laptop also doesn’t lock the screen any more when I close it. This used to work at least while X11 is running (it started xlock -mode blank), now it works neither when logged in on the text (framebugger) console nor under X11. bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#935137:
I forgot to add the patch to d/series, you'll find the updated debdiff attached. -- Samuel Henrique acme-tiny_4.0.4-1+deb10u1.debdiff Description: Binary data
Bug#874857: [dssi] Future Qt4 removal from Buster - patch available
Control: tags -1 + patch A patch to disable the generation of the Qt4 example plugins is at https://salsa.debian.org/multimedia-team/dssi/merge_requests/1 plus some general packaging updates at https://salsa.debian.org/multimedia-team/dssi/merge_requests/2 (I will merge and upload in a few days if there are no further comments) regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#931768: Sample patch
That would be
--- /tmp/old2019-08-19 22:54:56.281542733 +
+++ /etc/apparmor.d/usr.sbin.libvirtd 2019-08-19 22:53:48.402550623 +
@@ -85,6 +85,7 @@
/usr/{lib,lib64}/xen-common/bin/xen-toolstack PUx,
/usr/{lib,lib64}/xen/bin/* Ux,
/usr/lib/xen-*/bin/libxl-save-helper PUx,
+ /usr/lib/xen-*/bin/pygrub PUx,
# Required by nwfilter_ebiptables_driver.c:ebiptablesWriteToTempFile() to
# read and run an ebtables script.
-towo
signature.asc
Description: This is a digitally signed message part
Bug#935137: buster-pu: package acme-tiny/4.0.4-1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu The acme v2 protocol is gonna stop accepting plain GET requests as of November 1st, this will make buster's acme-tiny stop working. I applied an upstream patch to fix it, it's just a switch to use signed requests, support was already in there. More detailed information: https://github.com/diafygi/acme-tiny/issues/226 https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380 This update needs to be part of the first point release, I will upload as soon as I receive confirmation from the release team. Thanks, -- Samuel Henrique acme-tiny_4.0.4-1+deb10u1.debdiff Description: Binary data
Bug#933822: virtualenvwrapper depends on cruft package python-stevedore
Control: tags + pending Fix applied, changelog finalised, and it appears an upload is pending. https://salsa.debian.org/debian/virtualenvwrapper/blob/a4fb07eb2768d9b25f96946c4bb0ac74f4b7690d/debian/changelog signature.asc Description: PGP signature
Bug#935136: gitg: noisy assertion to stderr: "g_date_time_difference: assertion 'begin != NULL' failed"
Package: gitg Version: 3.30.1-1 Severity: normal try this (without any gitg instance already running): $ git clone https://github.com/libreswan/libreswan $ cd libreswan $ gitg The result is a bunch of lines like the following to stderr: (gitg:27936): GLib-CRITICAL **: 18:50:32.798: g_date_time_difference: assertion 'begin != NULL' failed (gitg:27944): GLib-CRITICAL **: 18:50:36.949: g_date_time_difference: assertion 'end != NULL' failed If there's a failing assertion based on data from a typical, reasonably-formed public git repo, that suggests a worrisome problem with the gitg code, which we want to be able to handle arbitrary repositories. thanks for maintaining gitg in debian! --dkg -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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) Versions of packages gitg depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii gir1.2-peas-1.0 1.22.0-4 ii git 1:2.23.0~rc1-1 ii gsettings-desktop-schemas 3.28.1-1 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libgee-0.8-2 0.20.2-1 ii libgirepository-1.0-1 1.58.3-2 ii libgit2-glib-1.0-00.27.7-1 ii libglib2.0-0 2.60.6-2 ii libgtk-3-03.24.10-1 ii libgtksourceview-3.0-13.24.9-2 ii libgtkspell3-3-0 3.0.9-3 ii libpango-1.0-01.42.4-7 ii libpeas-1.0-0 1.22.0-4 ii libsecret-1-0 0.18.7-1 ii libsoup2.4-1 2.64.2-2 ii libxml2 2.9.4+dfsg1-7+b3 gitg recommends no packages. gitg suggests no packages. -- no debconf information
Bug#932015: wireguard-dkms: Wireguard dkms module build fails with gcc-8 on arm for 4.19.0-5-armmp-lpae kernel
Control: tags 932015 + moreinfo Hi Martin-- On Sun 2019-07-14 02:26:05 +0200, Martin Hoefling wrote: > Package: wireguard-dkms > Version: 0.0.20190702-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > Dear Maintainer, > >* What led up to the situation? > >Upgrading to buster and to kernel 4.19.0-5-armmp-lpae this is a package name, and not a package version. Martin, can you tell me what version of linux-headers-* you have installed on the failing system? If it's version 4.9.168-1+deb9u5 then it's possible that what you're running into is https://bugs.debian.org/935134, which is worked around in wireguard 0.0.20190702-2 (see https://bugs.debian.org/934763). Please let me know when you've tried that version. if it works for you, we can close this bug as a duplicate of #935134. If it doesn't work for you, then i'll need to dig into it further. Thanks for reporting problems to debian! --dkg signature.asc Description: PGP signature
Bug#935133: [Pkg-openssl-devel] Bug#935133: slow TLS handshake renders browsers and email client unusable
On 8/19/19 3:19 PM, Kurt Roeckx wrote:
On Mon, Aug 19, 2019 at 02:57:14PM -0700, nbi wrote:
Package: libssl1.0.0,libssl1.0.2,libssl1.1,openssl
Version:
libssl1.0.0 1.0.2l-1~bpo8+1
libssl1.0.2 1.0.2q-2
libssl1.1 1.1.1c-1
openssl 1.1.1c-1
After booting a distribution (sparkylinux.org) based on "testing" everything
appears to be working correctly. Browsers and email clients access their destinations
without
perceptible delay regardless of whether the connection is secure or not.
However after some extended web usage (I often see this problem after about an
hour of web surfing)
browsers get stuck on TLS connections. This problem has existed since the
beginning of June, i.e. Buster and testing since Buster. It does not happen
with Debian Stretch.
I first saw this with Firefox Quantum and assumed it was a Firefox specific
problem however none of the purported solutions solved this problem. I then
realized that it
also happens with Chrome. Worse yet, even the Thunderbird email client is
affected. The messages for each:
Firefox: performing TLS handshake
Chrome: establishing secure connection
Thunderbird: cannot establish secure connection
Basically the browsers get stuck on the TLS handshake. This seemingly gets
worse as time goes on. After boot up these messages fly by so quickly they're
barely perceptible.
Eventually the handshakes take seconds. At some point the bowsers become
unusable as the handshake seems to time out.
I repeated the testing with the very latest versions of both Firefox and Chrome on both
sparkylinux ("testing") and Debian Stretch. This problem does not happen on
Stretch.
The evidence suggests it's distribution version specific. The above ssl library
components changed from Stretch to Buster. Since the browsers utilize these
components for
TLS handshakes it stands to reason this is either a regression or new bug in
these ssl components.
Neither Firefox nor Chrome makes use of openssl. Firefox makes use
of NSS (libnss3). Chrome makes use of boringssl, but neither
Chrome nor boringssl is part of Debian. Chromium has an embeded
copy of boringssl.
I don't understand how all these apps can experience the same problem
without using a shared component for the TLS handshakes. That would just
be too coincidental, no?
boringssl is a fork of Openssl. So is it possible that some of the
problems that existed in Openssl were carried forward to boringssl
without correction?
What they all do have in common is that they now support TLS 1.3,
but I currently don't see how that should have any effect. Is the
whole PC slower, or the browsers, or just the connection? And a
reboot solves the problem?
As I reported just the TLS handshake. Other parts of the connection
sequence take on the order of milliseconds as usual. PC and other apps
are fine. Yes, reboot solves the problem although only temporarily. Also
as mentioned this doesn't happen with Stretch. Maybe the regression or
new bug were introduced with newer versions of libboringssl and libnss3 ?
Did you try to look at network traffic with something like
wireshark?
And what am I looking for? You're suggesting that I'm the first person
to report this problem? I've already spent far too much time on this
issue and now you're asking me an end user to spend even more time on
this issue? I don't mind helping, but it needs to be within reason. In
this case having specific things to look for would be most helpful.
Kurt
Bug#931645: (no subject)
I think this bug should be raised to "serious" level, as there is no longer a python-pil package < 6.1 available in bullseye/sid.
Bug#935135: ssh-add: loads key with wrong key comment, impairing key management
Package: openssh-client Version: 1:8.0p1-4 Severity: normal │ 1|tglase@tglase-nb:~ $ cat .ssh/id_pvt.pub │ ssh-rsa AAA…riqh id_...@tglase-nb.lan.tarent.de │ tglase@tglase-nb:~ $ ssh-add .ssh/id_pvt │ Enter passphrase for .ssh/id_pvt: │ Identity added: .ssh/id_pvt (tgl...@tglase-nb.lan.tarent.de) ^^ │ tglase@tglase-nb:~ $ ssh-add -l │ 3072 SHA256:5P4HaUvrwJVP/5u1NpDEckku9RNwy9weOs+NPhgSdXI /home/tglase/.ssh/id_rsa (RSA) │ 2048 SHA256:f9MzCY/Cq7WxR83Uzj8uk3uSCBOXef18hn9XIHwLHhE tgl...@tglase-nb.lan.tarent.de (RSA) ^^ In both cases, there must be “id_pvt” instead, so I know which key is which. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libc6 2.28-10 ii libedit2 3.1-20190324-1 ii libgssapi-krb5-2 1.17-6 ii libselinux1 2.9-2+b2 ii libssl1.1 1.1.1c-1 ii passwd1:4.7-2 ii zlib1g1:1.2.11.dfsg-1+b1 Versions of packages openssh-client recommends: ii xauth 1:1.0.10-1 Versions of packages openssh-client suggests: pn keychain ii kwalletcli [ssh-askpass] 3.02-1 pn libpam-ssh pn monkeysphere -- no debconf information
Bug#935133: [Pkg-openssl-devel] Bug#935133: slow TLS handshake renders browsers and email client unusable
On Mon, Aug 19, 2019 at 02:57:14PM -0700, nbi wrote:
> Package: libssl1.0.0,libssl1.0.2,libssl1.1,openssl
> Version:
> libssl1.0.0 1.0.2l-1~bpo8+1
> libssl1.0.2 1.0.2q-2
> libssl1.1 1.1.1c-1
> openssl 1.1.1c-1
>
> After booting a distribution (sparkylinux.org) based on "testing" everything
> appears to be working correctly. Browsers and email clients access their
> destinations without
> perceptible delay regardless of whether the connection is secure or not.
> However after some extended web usage (I often see this problem after about
> an hour of web surfing)
> browsers get stuck on TLS connections. This problem has existed since the
> beginning of June, i.e. Buster and testing since Buster. It does not happen
> with Debian Stretch.
>
> I first saw this with Firefox Quantum and assumed it was a Firefox specific
> problem however none of the purported solutions solved this problem. I then
> realized that it
> also happens with Chrome. Worse yet, even the Thunderbird email client is
> affected. The messages for each:
>
> Firefox: performing TLS handshake
> Chrome: establishing secure connection
> Thunderbird: cannot establish secure connection
>
> Basically the browsers get stuck on the TLS handshake. This seemingly gets
> worse as time goes on. After boot up these messages fly by so quickly they're
> barely perceptible.
> Eventually the handshakes take seconds. At some point the bowsers become
> unusable as the handshake seems to time out.
>
> I repeated the testing with the very latest versions of both Firefox and
> Chrome on both sparkylinux ("testing") and Debian Stretch. This problem does
> not happen on Stretch.
> The evidence suggests it's distribution version specific. The above ssl
> library components changed from Stretch to Buster. Since the browsers utilize
> these components for
> TLS handshakes it stands to reason this is either a regression or new bug in
> these ssl components.
Neither Firefox nor Chrome makes use of openssl. Firefox makes use
of NSS (libnss3). Chrome makes use of boringssl, but neither
Chrome nor boringssl is part of Debian. Chromium has an embeded
copy of boringssl.
What they all do have in common is that they now support TLS 1.3,
but I currently don't see how that should have any effect. Is the
whole PC slower, or the browsers, or just the connection? And a
reboot solves the problem?
Did you try to look at network traffic with something like
wireshark?
Kurt
Bug#935047: pulseaudio: regularly stops producing sound over USB interface
Thanks for your feedback! I attached the log and the output of pactl list. Time table: 23:50:06 start 23:50:53 attached interface 23:51:28 (I guess) pactl-list.working 23:59:42 (or a bit later) sound died 00:00:59 pactl-list.broken 00:10:11 disconnect interface 00:10:49 reattached interface 00:15:06 (this is precise) sound died again Module #0 Name: module-device-restore Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "Automatically restore the volume/mute state of devices" module.version = "12.2" Module #1 Name: module-stream-restore Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "Automatically restore the volume/mute/device state of streams" module.version = "12.2" Module #2 Name: module-card-restore Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "Automatically restore profile of cards" module.version = "12.2" Module #3 Name: module-augment-properties Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "Augment the property sets of streams with additional static information" module.version = "12.2" Module #4 Name: module-switch-on-port-available Argument: Usage counter: n/a Properties: module.author = "David Henningsson" module.description = "Switches ports and profiles when devices are plugged/unplugged" module.version = "12.2" Module #5 Name: module-udev-detect Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "Detect available audio hardware and load matching drivers" module.version = "12.2" Module #6 Name: module-alsa-card Argument: device_id="0" name="pci-_00_1b.0" card_name="alsa_card.pci-_00_1b.0" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1" Usage counter: 0 Properties: module.author = "Lennart Poettering" module.description = "ALSA Card" module.version = "12.2" Module #7 Name: module-bluetooth-policy Argument: Usage counter: n/a Properties: module.author = "Frédéric Dalleau, Pali Rohár" module.description = "Policy module to make using bluetooth devices out-of-the-box easier" module.version = "12.2" Module #8 Name: module-bluetooth-discover Argument: Usage counter: n/a Properties: module.author = "João Paulo Rechi Vita" module.description = "Detect available Bluetooth daemon and load the corresponding discovery module" module.version = "12.2" Module #9 Name: module-bluez5-discover Argument: Usage counter: n/a Properties: module.author = "João Paulo Rechi Vita" module.description = "Detect available BlueZ 5 Bluetooth audio devices and load BlueZ 5 Bluetooth audio drivers" module.version = "12.2" Module #10 Name: module-native-protocol-unix Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "Native protocol (UNIX sockets)" module.version = "12.2" Module #11 Name: module-default-device-restore Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "Automatically restore the default sink and source" module.version = "12.2" Module #12 Name: module-rescue-streams Argument: Usage counter: n/a Properties: module.author = "Lennart Poettering" module.description = "When a sink/source is removed, try to move its streams to the default sink/source" module.version = "12.2" Module #13 Name: module-always-sink Argument: Usage counter: n/a Properties: module.author = "Colin Guthrie" module.description = "Always keeps at least one sink loaded even if it's a null one" module.version = "12.2" Module #14 Name: module-intended-roles Argument: Usage counter: n/a Properties: module.aut
Bug#934763: Debian 4.9.0.9-amd64 :: DMKS failed
On Mon 2019-08-19 14:06:37 +0200, Markus Grundmann wrote: > This is a new debian VM running on BHYVE. After the installation and > upgrading operating system the following DKMS fails. This is https://bugs.debian.org/934763, which i'll work around shortly with the attached patch to the wireguard packaging in 0.0.20190702-2. Thanks to Jason for supplying the attached patch to update the compatibility checks. Note that if you apply the attached patch to wireguard and build against 4.9.168-1+deb9u5, but then try to load the module on a system running 4.9.168-1+deb9u4, the module will fail to load with unrecognized symbols, due to the weird state of the backported siphash (but no hsiphash). --dkg From: "Jason A. Donenfeld" Date: Thu, 15 Aug 2019 06:37:10 + Subject: compat: fix on debian 4.9.168 in sloppy manner Ben backported siphash but forgot to backport hsiphash, which goes into the same .h and .o files, making a proper compat layer for it kind of cumbersome and annoying. Since he plans to backport hsiphash for 4.9.169, this commit is a stop-gap solution for the Debian package. --- src/compat/compat.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/compat/compat.h b/src/compat/compat.h index 239fa58..7fc3145 100644 --- a/src/compat/compat.h +++ b/src/compat/compat.h @@ -844,6 +844,12 @@ static inline void skb_mark_not_on_list(struct sk_buff *skb) #define cpu_have_named_feature(name) (elf_hwcap & (HWCAP_ ## name)) #endif +#if LINUX_VERSION_CODE == KERNEL_VERSION(4, 9, 168) +#define hsiphash_2u32 siphash_2u32 +#define hsiphash_3u32 siphash_3u32 +#define hsiphash_key_t siphash_key_t +#endif + /* https://github.com/ClangBuiltLinux/linux/issues/7 */ #if defined( __clang__) && (!defined(CONFIG_CLANG_VERSION) || CONFIG_CLANG_VERSION < 8) #include signature.asc Description: PGP signature
Bug#935115: bash: [regression] passing variable assignments to functions broken in POSIX mode, violating POSIX
Hi Chet, >There is a problem with bash-5.0 when the variable is declared local in >the interposed function, and I need to fix that, but that's not a posix ah, okay, I didn’t test what removing the “local” would do. Debian is a special beast: it requires of a /bin/sh to behave like a POSIX shell *plus* “local” and a couple other things (echo -n, test -a/-o, kill -signal and trap with numbers) that are reasonable. Currently, bash, dash and mksh fulfil these requirements, as ksh93 is missing “local”; posh is too outdated wrt mksh development and thus too buggy, and I don’t know how well yash or *shudder* zsh would do as /bin/sh. >issue because posix doesn't have anything to say about local variables. It does not, agreed, but you probably realise that’s besides the point here ;-) >So thanks for the report, and I'll look at the local variable issue. Thanks! bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Bug#934763: wireguard-dkms: kernel module fails to build with latest Stretch linux kernel sources
Control: tags 934763 + confirmed
Control: clone 934763 -1
Control: reassign -1 linux-headers-4.9.0-9-common 4.9.168-1+deb9u5
Control: tags -1 + patch
Control: affects -1 + wireguard-dkms
On Wed 2019-08-14 17:50:08 +0300, Thomas Kapoulas wrote:
> Hello, wireguard-dkms failed to build its module on a Debian Stretch
> system with the latest kernel (4.9.0-9-amd64). Although it works with
> the previous one (4.9.0-8-amd64).
This failure to wireguard appears to be due to the backport of "siphash:
add cryptographically secure PRF" in 4.9.168, without its follow-on
upstream patch 1ae2324f732c9c4e2fa4ebd885fa1001b70d52e1 (attached).
The cloned bug report should keep track of the kernel part of the
problem for now, while i temporarily work around the problem in the
wireguard packaging with a version-check compatibiity workaround nudge
from upstream.
--dkg
From 1ae2324f732c9c4e2fa4ebd885fa1001b70d52e1 Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld"
Date: Sun, 8 Jan 2017 13:54:01 +0100
Subject: siphash: implement HalfSipHash1-3 for hash tables
HalfSipHash, or hsiphash, is a shortened version of SipHash, which
generates 32-bit outputs using a weaker 64-bit key. It has *much* lower
security margins, and shouldn't be used for anything too sensitive, but
it could be used as a hashtable key function replacement, if the output
is never exposed, and if the security requirement is not too high.
The goal is to make this something that performance-critical jhash users
would be willing to use.
On 64-bit machines, HalfSipHash1-3 is slower than SipHash1-3, so we alias
SipHash1-3 to HalfSipHash1-3 on those systems.
64-bit x86_64:
[0.509409] test_siphash: SipHash2-4 cycles: 4049181
[0.510650] test_siphash: SipHash1-3 cycles: 2512884
[0.512205] test_siphash: HalfSipHash1-3 cycles: 3429920
[0.512904] test_siphash:JenkinsHash cycles: 978267
So, we map hsiphash() -> SipHash1-3
32-bit x86:
[0.509868] test_siphash: SipHash2-4 cycles: 14812892
[0.513601] test_siphash: SipHash1-3 cycles: 9510710
[0.515263] test_siphash: HalfSipHash1-3 cycles: 3856157
[0.515952] test_siphash:JenkinsHash cycles: 1148567
So, we map hsiphash() -> HalfSipHash1-3
hsiphash() is roughly 3 times slower than jhash(), but comes with a
considerable security improvement.
Signed-off-by: Jason A. Donenfeld
Reviewed-by: Jean-Philippe Aumasson
Signed-off-by: David S. Miller
---
Documentation/siphash.txt | 75 +++
include/linux/siphash.h | 57 +++-
lib/siphash.c | 321 +-
lib/test_siphash.c| 98 +-
4 files changed, 546 insertions(+), 5 deletions(-)
diff --git a/Documentation/siphash.txt b/Documentation/siphash.txt
index e8e6ddbbaab4..908d348ff777 100644
--- a/Documentation/siphash.txt
+++ b/Documentation/siphash.txt
@@ -98,3 +98,78 @@ u64 h = siphash(&combined, offsetofend(typeof(combined), dport), &secret);
Read the SipHash paper if you're interested in learning more:
https://131002.net/siphash/siphash.pdf
+
+
+~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
+
+HalfSipHash - SipHash's insecure younger cousin
+---
+Written by Jason A. Donenfeld
+
+On the off-chance that SipHash is not fast enough for your needs, you might be
+able to justify using HalfSipHash, a terrifying but potentially useful
+possibility. HalfSipHash cuts SipHash's rounds down from "2-4" to "1-3" and,
+even scarier, uses an easily brute-forcable 64-bit key (with a 32-bit output)
+instead of SipHash's 128-bit key. However, this may appeal to some
+high-performance `jhash` users.
+
+Danger!
+
+Do not ever use HalfSipHash except for as a hashtable key function, and only
+then when you can be absolutely certain that the outputs will never be
+transmitted out of the kernel. This is only remotely useful over `jhash` as a
+means of mitigating hashtable flooding denial of service attacks.
+
+1. Generating a key
+
+Keys should always be generated from a cryptographically secure source of
+random numbers, either using get_random_bytes or get_random_once:
+
+hsiphash_key_t key;
+get_random_bytes(&key, sizeof(key));
+
+If you're not deriving your key from here, you're doing it wrong.
+
+2. Using the functions
+
+There are two variants of the function, one that takes a list of integers, and
+one that takes a buffer:
+
+u32 hsiphash(const void *data, size_t len, const hsiphash_key_t *key);
+
+And:
+
+u32 hsiphash_1u32(u32, const hsiphash_key_t *key);
+u32 hsiphash_2u32(u32, u32, const hsiphash_key_t *key);
+u32 hsiphash_3u32(u32, u32, u32, const hsiphash_key_t *key);
+u32 hsiphash_4u32(u32, u32, u32, u32, const hsiphash_key_t *key);
+
+If you pass the generic hsiphash function something of a constant length, it
+will constant fold at compile-time and automatically choose one of the
+optimized functions.
+
+3. Hashtable key function usage:
+
+struct some_hashtable {
+ DEC
Bug#926798: RFP: elpa-magit-forge -- Work with Git forges from the comfort of Magit
On 2019-04-10 22:34:40, Matteo F. Vescovi wrote: > Hi! > > Il mer 10 apr 2019, 16:54 Antoine Beaupre ha scritto: > >> Package: wnpp >> Severity: wishlist >> >> * Package name: elpa-magit-forge >> Version : 0.1.0 >> Upstream Author : Jonas Bernoulli >> * URL : https://github.com/magit/forge >> * License : GPL-3 >> Programming Lang: Elisp >> Description : Work with Git forges from the comfort of Magit >> > > This is really nice. > I'll try to give a look at it and hopefully package it. > > Stay tuned. ;-) I'm still tuned! Have you worked on this more? Did you managed to make it work with magit at all? :) a. -- Le féminisme n'a jamais tué personne Le machisme tue tous les jours. - Benoîte Groulx
Bug#935133: slow TLS handshake renders browsers and email client unusable
Package: libssl1.0.0,libssl1.0.2,libssl1.1,openssl
Version:
libssl1.0.0 1.0.2l-1~bpo8+1
libssl1.0.2 1.0.2q-2
libssl1.1 1.1.1c-1
openssl 1.1.1c-1
After booting a distribution (sparkylinux.org) based on "testing" everything
appears to be working correctly. Browsers and email clients access their destinations
without
perceptible delay regardless of whether the connection is secure or not.
However after some extended web usage (I often see this problem after about an
hour of web surfing)
browsers get stuck on TLS connections. This problem has existed since the
beginning of June, i.e. Buster and testing since Buster. It does not happen
with Debian Stretch.
I first saw this with Firefox Quantum and assumed it was a Firefox specific
problem however none of the purported solutions solved this problem. I then
realized that it
also happens with Chrome. Worse yet, even the Thunderbird email client is
affected. The messages for each:
Firefox: performing TLS handshake
Chrome: establishing secure connection
Thunderbird: cannot establish secure connection
Basically the browsers get stuck on the TLS handshake. This seemingly gets
worse as time goes on. After boot up these messages fly by so quickly they're
barely perceptible.
Eventually the handshakes take seconds. At some point the bowsers become
unusable as the handshake seems to time out.
I repeated the testing with the very latest versions of both Firefox and Chrome on both
sparkylinux ("testing") and Debian Stretch. This problem does not happen on
Stretch.
The evidence suggests it's distribution version specific. The above ssl library
components changed from Stretch to Buster. Since the browsers utilize these
components for
TLS handshakes it stands to reason this is either a regression or new bug in
these ssl components.
Bug#934881: ccls: Crashes when used with Emacs
> 1. compile ccls from upstream git repo, if it works, then there's > something wrong in packaging script. Cloned https://github.com/MaskRay/ccls/commit/03263c85217dd0cfddff73b966cd2d5cd8245d9d Did sudo apt install clang cmake libclang-dev llvm-dev rapidjson-dev cmake -H. -BRelease cmake --build Release sudo cp Release/ccls /usr/local/bin/ That binary works now. pgpdHjDBhCHoJ.pgp Description: Digitale Signatur von OpenPGP
Bug#928050: wireguard: Remove debhelper-compat-12 dependency. Replace with debian/compat level=5
Control: tags 928050 + wontfix On Fri 2019-04-26 13:40:52 -0700, Anthony Metzidis wrote: >* Upon attempting a build on raspbian-stretch, the build failed due to > missing debhelper-compat=12 . debhelper-compat=12 is not available on > raspbian >* As a workaround, I removed the debhelper-compat=12 dependency, and set > debian/compat level=5 >* Without the change, naturally build failed. >* With this change the build completed, and the binary package installed > properly Why compat level 5 instead of, say, 10? And why is a rebuild necessary at all? For debian stretch users, the already-distributed binary packages in debian unstable should be sufficient. For debian stretch users who want to rebuild for some reason, debhelper 12 is already in stretch-backports, so even there a change in the source isn't needed. If raspbian needs to patch, that's fine with me, but i think the report should be specific to that distro, and not to debian. debhelper 12 is significantly better than debhelper 5, and i'd rather use the more modern tooling. So i'm closing this bug in the debian BTS, but if there's something i've misunderstood, please feel free to re-open it and explain what i'm missing. Thanks for reporting issues in wireguard! All the best, --dkg signature.asc Description: PGP signature
Bug#935132: traceroute.1: Fix lines with a misused two-fonts macro
Package: traceroute Version: 1:2.1.0-2+b1 Severity: minor Tags: patch Dear Maintainer, 1) correct the misuse of a two-fonts macro 2) correct some arguments to a such macro. --- traceroute.db.1 2019-08-19 19:07:42.0 + +++ traceroute.db.1.new 2019-08-19 19:26:05.0 + @@ -27,13 +27,13 @@ traceroute \- print the route packets tr .ti +8 .BR host " [" "packet_len" "]" .br -.BR traceroute6 +.B traceroute6 .RI " [" options ] .br -.BR tcptraceroute +.B tcptraceroute .RI " [" options ] .br -.BR lft +.B lft .RI " [" options ] .ad .SH DESCRIPTION @@ -122,7 +122,7 @@ and source/destination port, in order to by firewalls just as a start of allowed type of a network session). .SH OPTIONS .TP -.BI \--help +.B \-\-help Print help info and exit. .TP .BR \-4 ", " \-6 @@ -173,14 +173,14 @@ Specifies with what TTL to start. Defaul Tells traceroute to add an IP source routing option to the outgoing packet that tells the network to route the packet through the specified -.IR gateway +.I gateway (most routers have disabled source routing for security reasons). In general, several -.IR gateway\fR's +.IR gateway 's is allowed (comma separated). For IPv6, the form of -.IR num\fB,\fIaddr\fB,\fIaddr... +.IB num , addr , addr... is allowed, where -.IR num +.I num is a route header type (default is type 2). Note the type 0 route header is now deprecated (rfc5095). .TP @@ -204,7 +204,7 @@ considerably. The default value is 16. Note that some routers and hosts can use ICMP rate throttling. In such a situation specifying too large number can lead to loss of some responses. .TP -.BI \-n +.B \-n Do not try to map IP addresses to host names when displaying them. .TP .BI \-p " port" ", --port=" port @@ -236,13 +236,13 @@ Determines how long to wait for a respon .br There are three (in general) float values separated by a comma (or a slash). -.IR Max +.I Max specifies the maximum time (in seconds, default 5.0) to wait, in any case. .br .br Traditional traceroute implementation always waited whole -.IR max +.I max seconds for any probe. But if we already have some replies from the .B same hop, or even from some @@ -253,15 +253,15 @@ to determine the actual reasonable amoun .br The optional -.IR here +.I here (default 3.0) specifies a factor to multiply the round trip time of an already received response from the .B same hop. The resulting value is used as a timeout for the probe, instead of (but no more than) -.IR max\fR. +.IR max . The optional -.IR near +.I near (default 10.0) specifies a similar factor for a response from some .B next hop. @@ -275,24 +275,24 @@ hop (of the probe which will be printed If nothing found, then look for some .B next hop. If nothing found, use -.IR max\fR. +.IR max . If -.IR here +.I here and/or -.IR near +.I near have zero values, the corresponding computation is skipped. .br -.IR Here +.I Here and -.IR near +.I near are always set to zero if only -.IR max +.I max is specified (for compatibility with previous versions). .TP .BI \-q " nqueries" ", --queries=" nqueries Sets the number of probe packets per hop. The default is 3. .TP -.BI \-r +.B \-r Bypass the normal routing tables and send directly to a host on an attached network. If the host is not on a directly-attached network, an error is returned. This option can be used to ping a @@ -370,7 +370,7 @@ To print information about available opt Use UDP to particular destination port for tracerouting (instead of increasing the port per each probe). Default port is 53 (dns). .TP -.BI \-UL +.B \-UL Use UDPLITE for tracerouting (default port is 53). .TP .B \-D, \-\-dccp @@ -380,7 +380,7 @@ Use DCCP Requests for probes. Use raw packet of specified protocol for tracerouting. Default protocol is 253 (rfc3692). .TP -.BI \--mtu +.B \-\-mtu Discover MTU along the path being traced. Implies .BR \-F\ \-N\ 1 . New @@ -406,7 +406,7 @@ See .B \-F option for more info. .TP -.BI \--back +.B \-\-back Print the number of backward hops when it seems different with the forward direction. This number is guessed in assumption that remote hops send reply packets with initial ttl set to either 64, or 128 or 255 (which seems @@ -437,7 +437,7 @@ This method may be allowed for unprivile since the kernel 3.0 (IPv4, for IPv6 since 3.11), which supports new .I dgram icmp (or -.IR \fR"\fIping\fR") +.RI ping """)" sockets. To allow such sockets, sysadmin should provide .I net/ipv4/ping_group_range sysctl range to match any group of the user. @@ -555,7 +555,7 @@ Options: .TP .B service\fR=\fInum Set DCCP service code to -.IR num +.I num (default is 1885957735). .SS raw \ \ \ \ \-P proto Send raw packet of protocol -- System Information: Debian Release: bullseye/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.37-6 (SMP w/2 CPU
Bug#934712: node-mysql: CVE-2019-14939 - Issue closed uptream without changes
Control: tags -1 - fixed-upstream Control: tags -1 + moreinfo Hi all, remote issue[1] was closed without any change in a "locked and limited to collaborators conversation" Title changed from "LOAD DATA LOCAL INFILE option shouldn't be open by default." to "Question" Mitre issue isn't updated
Bug#935031: Same here
Instead of the tabs that were left open before reboot action, I have only one window, with nothing in it, not even a shell. Until I do C-S-t which results in replacing the blank window, with a shell. C.
Bug#932775: snmpd: Systemd service file also does not respect /etc/default/snmpd
Package: snmpd Version: 5.7.3+dfsg-5 Followup-For: Bug #932775 It seems the systemd service file (/lib/systemd/system/snmpd.service) also ignores the /etc/default/snmpd file. It does not even appear to attempt to read any configuration for there but rather has the defaults hardcoded into the service file's ExecStart parameter. -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND 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 snmpd depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libmariadb31:10.3.15-1 ii libsnmp-base 5.7.3+dfsg-5 ii libsnmp30 5.7.3+dfsg-5 ii libssl1.1 1.1.1c-1 ii lsb-base 10.2019051400 ii zlib1g 1:1.2.11.dfsg-1 snmpd recommends no packages. Versions of packages snmpd suggests: ii snmptrapd 5.7.3+dfsg-5 -- Configuration Files: /etc/default/snmpd changed: export MIBS= SNMPDRUN=yes SNMPDOPTS='-LS0-5d -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux -p /var/run/snmpd.pid' TRAPDRUN=no TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid' SNMPDCOMPAT=yes -- debconf information: snmpd/upgradefrom521:
Bug#935128: aspell: potentially unbounded buffer over-read in GNU Aspell 0.60.*
On Mon, 19 Aug 2019, Salvatore Bonaccorso wrote: See https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html Also see http://aspell.net/buffer-overread-ucs.txt for a slightly improved version of the announcement that I edited for clarity.
Bug#934168: linux-image-4.19.0-5-amd64: iptables-restore may result in NULL pointer dereference at nf_tables_newrule on startup
Hi Elias,
On Thu, Aug 08, 2019 at 12:47:12AM +0200, Elias Werberich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi Salvatore,
>
> using the current 5.2.6-1 Debian Kernel fixes this bug.
> I have checked the differences between v4.19 and v5.2 in the upstream kernel
> repository and found the following commit:
>
> Commit 9b1ef3a0e906bb4a37a71ee39c8528270b490243 from Linux Kernel Upstream:
> > From 9b1ef3a0e906bb4a37a71ee39c8528270b490243 Mon Sep 17 00:00:00 2001
> > From: Taehee Yoo
> > Date: Tue, 19 Mar 2019 13:22:41 +0900
> > Subject: [PATCH] netfilter: nf_tables: add missing ->release_ops() in error
> > path of newrule()
> >
> > ->release_ops() callback releases resources and this is used in error path.
> > If nf_tables_newrule() fails after ->select_ops(), it should release
> > resources. but it can not call ->destroy() because that should be called
> > after ->init().
> > At this point, ->release_ops() should be used for releasing resources.
> >
> > Test commands:
> >modprobe -rv xt_tcpudp
> >iptables-nft -I INPUT -m tcp <-- error command
> >lsmod
> >
> > Result:
> >Module Size Used by
> >xt_tcpudp 20480 2 <-- it should be 0
> >
> > Fixes: b8e204006340 ("netfilter: nft_compat: use .release_ops and remove
> > list of extension")
> > Signed-off-by: Taehee Yoo
> > Signed-off-by: Pablo Neira Ayuso
> > ---
> > net/netfilter/nf_tables_api.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> > index 2cfb173cd0b2..4e57d90f8884 100644
> > --- a/net/netfilter/nf_tables_api.c
> > +++ b/net/netfilter/nf_tables_api.c
> > @@ -2693,8 +2693,11 @@ static int nf_tables_newrule(struct net *net, struct
> > sock *nlsk,
> > nf_tables_rule_release(&ctx, rule);
> > err1:
> > for (i = 0; i < n; i++) {
> > - if (info[i].ops != NULL)
> > + if (info[i].ops) {
> > module_put(info[i].ops->type->owner);
> > + if (info[i].ops->type->release_ops)
> > + info[i].ops->type->release_ops(info[i].ops);
> > + }
> > }
> > kvfree(info);
> > return err;
> > --
> > 2.22.0
>
> AFAIK, this is not backported to Debian Linux Kernel for Buster.
> It would be great if anyone can check if this is the correct commit.
This looks right, and the commit will actually be included when we
rebase to 4.19.67 for buster.
If it is possible for you, please try to do the simple patching (cf.
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2)
and confirm it fixes the issue indedd that would be great. Otherwise I
will try to have a look tomorrow.
Regards,
Salvatore
Bug#781913:
Le lun. 19 août 2019 à 14:27, Andreas Hasenack a écrit : > > FWIW, in Ubuntu we completely dropped python2, I think Debian will > want both for a while? On the other hand, I hear that samba 4.11 will > also completely drop python2. The plan is to build both for 4.10, and drop python2 with (or before) 4.11. I don't want to break depending packages. Regards -- Mathieu Parent
Bug#935115: bash: [regression] passing variable assignments to functions broken in POSIX mode, violating POSIX
On 8/19/19 11:47 AM, Thorsten Glaser wrote:
> Package: bash
> Version: 5.0-4
> Severity: critical
> Justification: breaks unrelated software
>
> The expected output is:
>
> dbc_mysql_createdb: _dbc_nodb(1)= # initially not set / empty
> dbc_mysql_exec_command: _dbc_nodb=yes # MUST be visible inside the function
> inner: 0 or 1 # MAY be exported, does not need to
> dbc_mysql_createdb: _dbc_nodb(2)=[yes]# MAY be visible afterwards,
> optional
> after: 0 or 1 # if visible afterwards MAY be exported
> dbc_mysql_createdb:0
>
> POSIX reference:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
> specifically:
>
> * If the command name is a function that is not a standard utility
>implemented as a function, variable assignments shall affect the
>current execution environment during the execution of the function.
>It is unspecified:
>+ Whether or not the variable assignments persist after the
> completion of the function
>+ Whether or not the variables gain the export attribute during the
> execution of the function
>+ Whether or not export attributes gained as a result of the variable
> assignments persist after the completion of the function (if
> variable assignments persist after the completion of the function)
This behavior hasn't changed substantially since bash-4.4: it still
implements the previous version of the Posix standard, which says that
assignment statements preceding functions are supposed to be treated like
special builtins.
$ cat x15b
# test whether or not temporary environment assignments are exported
# in posix mode
#set -o posix
showfoo()
{
printf %s "foo=${foo-}"
echo -n ' environment foo='
printenv foo || echo
}
unset foo
showfoo
foo=foo showfoo
showfoo
$ ./bash -o posix ./x15b
foo= environment foo=
foo=foo environment foo=foo
foo=foo environment foo=foo
$ ../bash-5.0-patched/bash -o posix ./x15b
foo= environment foo=
foo=foo environment foo=foo
foo=foo environment foo=foo
$ ../bash-4.4-patched/bash -o posix ./x15b
foo= environment foo=
foo=foo environment foo=foo
foo=foo environment foo=foo
(The first test uses the current development version.)
I don't see substantial differences when I interpose another function in
between and call showfoo from that function with a preceding assignment
statement.
There is a problem with bash-5.0 when the variable is declared local in
the interposed function, and I need to fix that, but that's not a posix
issue because posix doesn't have anything to say about local variables.
So thanks for the report, and I'll look at the local variable issue.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bug#935072: [lintian] Asymmetrical tag names
retitle 935072 Asymmetrical changelog file tag names thanks Felix Lechner wrote: > In my view, it is unnecessary to issue two different tags. I would > like to use a shorter tag name for both, and show the expected path, > plus perhaps an annotation like > > debian-changelog-file-missing /usr/share/doc/pkg/changelog.gz Good idea. Don't forget to record them in data/override/renamed-tags of course. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#873520: Check for bad distribution in d/changelog only when changes file is signed
Felix Lechner wrote: > > Did we get that logic right? Should Lintian perhaps complain instead > > when analysing a changes file---which is clearly intended for > > upload---versus a dsc file that can hold sources at any stage? > > Forgive me. Our original idea works great. There is no way > dpkg-buildpackage can do its job, and keep the source and the > installation packages (the name binary is a misnomer) together, > without producing a *.changes file even though it is unsigned. Lintian > also could not analyze both in context without a changes file, even > though it is unsigned and not intended for upload. Thanks for soliciting my advice. However, I'm afraid I'm a little lost in the details here and I probably won't be able to carve out the time to absorb it all very soon, so I would just go ahead and merge if you are confident enough so we keep up development momentum. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#781913: [Pkg-samba-maint] Bug#781913: please build bindings for Python3 and let samba-common-bin use them
Le dim. 18 août 2019 à 14:15, Laurent Bigonville a écrit : > > Package: src:samba > Followup-For: Bug #781913 > > Hi, > > samba 4.10 is apparently supporting python3 > > Are there any plans to upload that soon? Yes. Work has already started. I plan to finish this during August. > Not that ubuntu already did the work apparently I know. Regards -- Mathieu Paren
Bug#935070: [lintian] Tags are too similar
Hi Felix, > During the conversion of the test suite to source format 3.0, some > packages emitted both tags > > latest-debian-changelog-entry-without-new-version > latest-debian-changelog-entry-reuses-existing-version > > According to the tag descriptions, the second tag strips the epoch, if > present, before comparing the current version with the prior one. That > seems to be a fine point. I propose to delete the first tag and keep > the second. Works for me. I just checked that they don't have different severities which could have been a justification for different tags (they don't). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#935070: [lintian] Tags are too similar
Hi Felix, > During the conversion of the test suite to source format 3.0, some > packages emitted both tags > > latest-debian-changelog-entry-without-new-version > latest-debian-changelog-entry-reuses-existing-version > > According to the tag descriptions, the second tag strips the epoch, if > present, before comparing the current version with the prior one. That > seems to be a fine point. I propose to delete the first tag and keep > the second. Works for me. I just checked that they don't have different severities which could have been a justification for different tags (they don't). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#935131: RM: xpyb -- RoQA; orphaned; RC-buggy; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal No upstream releases since the last packaged one in 2012. python3-xcffib description says "This package is intended to be a (mostly) drop-in replacement for xpyb. xpyb has an inactive upstream, several memory leaks, is python2 only and doesn't have pypy support." Reverse deps checked with dak rm -Rnb python-xpyb -- WBR, wRAR signature.asc Description: PGP signature
Bug#935129: RM: python-uniconvertor -- RoQA; orphaned; RC-buggy; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal Looks like it doesn't work at all in the current state. Reverse deps checked with dak rm -Rn python-uniconvertor -- WBR, wRAR signature.asc Description: PGP signature
Bug#935130: RM: pyvtk -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal The latest upstream code at https://github.com/pearu/pyvtk seems to support Python 3, but the Debian package contains code from 2007. Reverse deps checked with dak rm -Rnb python-pyvtk -- WBR, wRAR signature.asc Description: PGP signature
Bug#694077: Package review
I'm afraid it's failing to build from source: x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtScript -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o qlcfixturedefcache.o qlcfixturedefcache.cpp qlcfixturedef.cpp: In member function ‘QLCPhysical QLCFixtureDef::physical() const’: qlcfixturedef.cpp:342:12: error: implicitly-declared ‘QLCPhysical::QLCPhysical(const QLCPhysical&)’ is deprecated [-Werror=deprecated-copy] 342 | return m_physical; |^~ In file included from qlcfixturedef.h:28, from qlcfixturemode.h:29, from qlcfixturedef.cpp:28: qlcphysical.h:78:18: note: because ‘QLCPhysical’ has user-provided ‘QLCPhysical& QLCPhysical::operator=(const QLCPhysical&)’ 78 | QLCPhysical& operator=(const QLCPhysical& physical); | ^~~~ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1206: qlcfixturedef.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/<>/engine/src' make[2]: *** [Makefile:90: sub-src-make_first-ordered] Error 2 make[2]: Leaving directory '/<>/engine' make[1]: *** [Makefile:96: sub-engine-make_first-ordered] Error 2 make[1]: Leaving directory '/<>' dh_auto_build: make -j2 returned exit code 2 make: *** [debian/rules:14: build] Error 255 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Build finished at 2019-08-19T19:38:24Z Could it be the switch to gcc-9?
Bug#935075: Incorrect city code for Lima, Perú. Missing weather information.
Control: fixed -1 3.32.0-1 On Mon, 19 Aug 2019 at 01:25:52 -0500, Diego Escalante Urrelo wrote: > Some time in 2015 Lima changed its airport code, libgweather upstream > corrected that here: > > https://gitlab.gnome.org/GNOME/libgweather/commit/6a79e8871e3e74ef276f24158735172ff6af1819 This is fixed in the newer upstream version in experimental. I'll apply the change to unstable now. Sorry, I don't think this qualifies as 'important' severity, so the stable release managers are unlikely to be receptive to requests for a stable update for this change - we can't fix every lower-severity bug in stable without overwhelming the stable release team. However, the use-after-free fixes in 3.28.3-1 might be sufficiently important to justify a stable update, at which point we might as well include this fix too. Please could you try rebuilding 3.28.3-1 plus this change (or 3.28.3-2 when I've uploaded that) on a buster system, and check whether that version works correctly without regressions? > HOWEVER, there's a catch: gnome-weather crashes if it tries to start > with unknown locations configured in: > dconf read /org/gnome/Weather/Application/locations You reported a separate bug for this (#935090) which is now fixed. Thanks, smcv
Bug#935128: aspell: potentially unbounded buffer over-read in GNU Aspell 0.60.*
Source: aspell Version: 0.60.7~20110707-6 Severity: important Tags: security upstream Hi [X-Debbugs-CC'ed Kevin Atkinson ] See https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html Within Debian the "pumpa" will need an update. Others might be required as well. Kevin Atkinson might be up for help if needed. Regards, Salvatore
Bug#694077: Package review
On 19/08/13 11:06, Jérôme Lebleu wrote: > Hi Lisandro, > > Thanks a lot for your review and all your advice! It gives me more > motivation to follow through this package. Great! I've looked into the changes and really liked what I saw :-) > On Sat, 3 Aug 2019 23:27:28 -0300 Lisandro Damián Nicanor Pérez Meyer > wrote: > > = debian/changelog > > > > As it's the first upload the only line really needed is: > > > > * Initial release (Closes: #694077) > > It's done. > > > = debian/patches > > > > Why are you disabling patches? The patch description is not clear > > about it. I had to read debian/rules to know why :-) > > > > Try this: > > > > override_dh_auto_test-arch: > > xvfb-run -a -s "-screen 0 1024x768x24 +extension RANDR > > +extension RENDER +extension GLX +extension EGL" \ > > dh_auto_test --max-parallel=1 -- > > QT_PLUGIN_PATH=$(CURDIR)/plugins QML2_IMPORT_PATH=$(CURDIR)/qml > > > > The Qt5 version seems to use QML so the above should work. This comes > > from qt3d's debian/rules. > > > > After that override the -indep target: > > > > override_dh_auto_test-indep: > > > > > > And leave no commands in it. This is because this package does not > > seems to have testes for arch:all binary packages (I might be wrong > > though). > > I have try to understand all of this first, so I went step by step and I > succeed to pass the tests with only: > > override_dh_auto_test-arch: > xvfb-run -a dh_auto_test > > More work was needed, I let you review it at > https://salsa.debian.org/jlebleu-guest/qlcplus/commit/54a466af5361321638350cbf8ee2ba2a2893c30d. Looks good, I'll be compiling it hopeully today. > > = debian/copyright > > > > Massimo Callegari's copyright should go at least up to 2018: > > > >2012-2018 Massimo Callegari > > > > You are missing many copyright entries and licenses. Please start with: > > > > grep -iRn copyright * > > > > in the project's root directory. You will find many people nott yest listed. > > Indeed!... I have tried to add all missing entries. > > I also try to fix all other warnings reported by lintian. There are > still some Info however: > > * I: qlcplus: hardening-no-fortify-functions > usr/lib/x86_64-linux-gnu/qt5/plugins/qlcplus/libmidiplugin.so > >I would say that it is a false-positive since it is the only one but > I don't know enough to be sure. What do you think? We can start by leaving it as it is. > * I: qlcplus: desktop-entry-lacks-keywords-entry > usr/share/applications/qlcplus-fixtureeditor.desktop >I: qlcplus: desktop-entry-lacks-keywords-entry > usr/share/applications/qlcplus.desktop > >I will see to purpose a patch upstream first. Great. Also not strictly necessary for a fir upload. > Finally, I have - at least - ask to be the owner of this bug as Wouter > was okay with that. > > > Feel free to ping me for sponsorship!!! > > Thanks for your proposal, I am really interested in! In fact, I first > ask a friend of mine, with whom I try to maintain another package, but > he seems quite busy with many other projects. Moreover, having the > sponsor of someone else can only be enriching. Great!
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
FWIW both packages are pristinely clean at CRAN with current versions: https://cran.r-project.org/web/checks/check_results_DoseFinding.html https://cloud.r-project.org/web/checks/check_results_multcomp.html These problems still seem self-imposed to me. We (maybe randomly ?) appear to be checking (maybe out-of-sync ?) permutations that upstream (ie CRAN) does not see. The whole issue is odd _because CRAN already does all the checking_ and we do not fundamentally alter packages, or R. So I still think that we could potentially save ourselves a lot of grief if we aligned more with what CRAN already does. But I said that before, and nobody seems to agree so Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#934978: mini-buildd: Does not function behind a NAT router
Hi Daniel, On Sat, 2019-08-17 at 08:53 -0700, Daniel Schepler wrote: > Package: mini-buildd > Version: 1.1.18 > Severity: wishlist > > I think I've gotten my local mini-buildd instance mostly set up. But > now, when I try to upload to it to do a test build, I get a failure > along the lines of: > > Host: a23-195-69-106.deploy.static.akamaitechnologies.com > Build request failed: 100 (upload-failed): Failed to update status > for > remote via URL ' > http://a23-195-69-106.deploy.static.akamaitechnologies.com:8066/mini_buildd/api?command=status&output=python' > : > > > I've verified by direct search through config.sqlite that no > instances > of that external host name are left in the configuration; yet it > still > seems to be getting that from somewhere as the address to connect > builders to. My intent is to use it only locally, and not to expose > it to the internet. I am not quite getting it ;), I guess I need more information here. What's the 'Hostname' entry of the 'Daemon' instance? Do you have remotes configured (not needed if you are building on that host only)? Thx! S
Bug#933872: grisbi: rounds JPY to EUR exchange fees value incorrectly when saving gsb file to disk
Hi Ludovic, I downloaded, installed and tested the amd64 package you generated. And from my quick testing, that fixed the issue I reported. Thank you all of you. Br, Le 18/08/2019 à 16:42, Ludovic Rousseau a écrit : Le 06/08/2019 à 18:03, Ludovic Rousseau a écrit : Hello I also opened the bug upstream. I may need the help of the upstream author. Feel free to add any more information in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933872 Upstream proposed a fix in http://www.grisbi.org/bugsreports/view.php?id=1961#c5138 I generated a new Debian package with the fix. You can get the amd64 package at http://ludovic.rousseau.free.fr/softwares/grisbi/ Please tell me if the proposed fix works for you or not. Thanks
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
Hi Andreas, On 19-08-2019 21:16, Andreas Tille wrote: > So the bug was first filed against r-cran-multcomp, The bug was filed against *both* packages, as I always do when it isn't totally clear from the failure to which package it belongs. > reassigned to > r-cran-dosefinding by edd, who refuses to look into these kind of issues. > where the test is OK in sid but the issue is blocking > the migration. I admit I neither have any idea how to fix this. When the test is successful in sid, it suggests that there is a combination of packages that need to migrate together to bullseye to be successful. If we want to help r-cran-multcomp migrate, it would be helpful to know the combination that is needed. Then we can figure out which package needs to grow which kind of dependency. > If its rather a matter of the bug severity downgrading it manually could > enable the migration. I have no idea whether this is the right course > of action but otherwise it looks like a deadlock for me. The migration is *not* blocked by this bug report, so severity doesn't help. The migration is blocked because the autopkgtest of r-cran-dosefinding in bullseye fails when run with the binary packages from multcomp together with a whole set of other packages deemed necessary (by britney based on package relations) from unstable. And that is the subject of this report (albeit missing the "in bullseye" part). As said, I am hoping that without doing anything, things will be all right in a couple of days. If not, r-base migration will simplify finding the issue a lot. Paul signature.asc Description: OpenPGP digital signature
Bug#935126: systemd-networkd fails with "Could not bring up interface: Invalid argument"
Am 19.08.19 um 21:04 schrieb Daniel Kahn Gillmor: > Package: systemd > Version: 241-6 > Severity: normal > Tags: upstream patch > Control: forwarded -1 https://github.com/systemd/systemd/issues/12784 > > from the journal: > > -- Reboot -- > Aug 19 10:55:17 tyr systemd[1]: Starting Network Service... > Aug 19 10:55:19 tyr systemd-networkd[230]: Enumeration completed > Aug 19 10:55:19 tyr systemd[1]: Started Network Service. > Aug 19 10:55:19 tyr systemd-networkd[230]: eth0: Could not bring up > interface: Invalid argument > Aug 19 14:48:35 tyr systemd-networkd[230]: eth0: Gained carrier > Aug 19 14:48:37 tyr systemd-networkd[230]: eth0: Gained IPv6LL > Aug 19 14:48:38 tyr systemd-networkd[230]: eth0: DHCPv4 address 10.70.11.3/23 > via 10.70.10.1 > Aug 19 14:48:49 tyr systemd-networkd[230]: eth0: Configured > > note that the "Gained carrier" happend after i manually did "ip l set eth0 > up". > > The upstream bug report suggests that the attached two patches should resolve > the issue, but i haven't tested them. > Should be fixed in 241-7. Please see the relevant changelog entry. https://salsa.debian.org/systemd-team/systemd/commit/cce6b9e2c23c315659147cb28ad1a8947995a997 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
Control: tags -1 help Hi Paul, On Mon, Aug 19, 2019 at 08:54:03PM +0200, Paul Gevers wrote: > Hi Andreas, > > On Mon, 19 Aug 2019 11:57:05 +0200 Andreas Tille > wrote: > > I wonder whether we can close this bug since the test is passing > > in unstable (with r-cran-multcomp 1.4-10-2). > > No, because currently it is blocking the migration of r-cran-multcomp. > Apparently r-cran-multcomp isn't making sure that the right stuff is > pulled into testing when it is testing r-cran-dosefinding. I am hoping > that r-cran migrates soon with lots of r stuff, maybe after that it is > "fixed". There is still a breaks missing somewhere I guess, but I don't > know where. So the bug was first filed against r-cran-multcomp, reassigned to r-cran-dosefinding where the test is OK in sid but the issue is blocking the migration. I admit I neither have any idea how to fix this. If its rather a matter of the bug severity downgrading it manually could enable the migration. I have no idea whether this is the right course of action but otherwise it looks like a deadlock for me. Kind regards Andreas. -- http://fam-tille.de
Bug#934779: libreoffice: Not read the "About LibreOffice" window contents
tag 934779 + fixed-upstream thanks On Fri, Aug 16, 2019 at 02:17:20PM +0300, Сергей Фёдоров wrote: > It is recognized in version 6.3.0.2 rc, but now Version: 6.3.0.4 and that > do something about it? Huh, what? This was reported in 6.3.0 rc2 (= 6.3.0.2), and it isn't fixed in 6.3.0 (= 6.3.0 rc4 == 6.3.0.4). The bug clearly shows that upstream was looking at it - give them time. Not every bug needs immediate attention, there's priorities. Anyways: In fact, it is now fixed in git and wil be included in 6.3.1 rc2. Regards, Rene
Bug#935126: systemd-networkd fails with "Could not bring up interface: Invalid argument"
Package: systemd
Version: 241-6
Severity: normal
Tags: upstream patch
Control: forwarded -1 https://github.com/systemd/systemd/issues/12784
from the journal:
-- Reboot --
Aug 19 10:55:17 tyr systemd[1]: Starting Network Service...
Aug 19 10:55:19 tyr systemd-networkd[230]: Enumeration completed
Aug 19 10:55:19 tyr systemd[1]: Started Network Service.
Aug 19 10:55:19 tyr systemd-networkd[230]: eth0: Could not bring up interface:
Invalid argument
Aug 19 14:48:35 tyr systemd-networkd[230]: eth0: Gained carrier
Aug 19 14:48:37 tyr systemd-networkd[230]: eth0: Gained IPv6LL
Aug 19 14:48:38 tyr systemd-networkd[230]: eth0: DHCPv4 address 10.70.11.3/23
via 10.70.10.1
Aug 19 14:48:49 tyr systemd-networkd[230]: eth0: Configured
note that the "Gained carrier" happend after i manually did "ip l set eth0 up".
The upstream bug report suggests that the attached two patches should resolve
the issue, but i haven't tested them.
--dkg
-- Package-specific info:
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 5.2.0-2-powerpc-smp (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)
Versions of packages systemd depends on:
ii adduser 3.118
ii libacl1 2.2.53-4
ii libapparmor1 2.13.3-4
ii libaudit11:2.8.5-2
ii libblkid12.34-0.1
ii libc62.28-10
ii libcap2 1:2.25-2
ii libcryptsetup12 2:2.2.0-1
ii libgcrypt20 1.8.4-5
ii libgnutls30 3.6.9-4
ii libgpg-error01.36-7
ii libidn11 1.33-2.2
ii libip4tc21.8.3-2
ii libkmod2 26-1
ii liblz4-1 1.8.3-1
ii liblzma5 5.2.4-1
ii libmount12.34-0.1
ii libpam0g 1.3.1-5
ii libpcre2-8-0 10.32-5
ii libseccomp2 2.4.1-2
ii libselinux1 2.9-2+b2
ii libsystemd0 241-6
ii mount2.34-0.1
ii util-linux 2.34-0.1
Versions of packages systemd recommends:
ii dbus1.13.8-1
ii libpam-systemd 241-6
Versions of packages systemd suggests:
ii policykit-10.105-26
pn systemd-container
Versions of packages systemd is related to:
pn dracut
ii initramfs-tools 0.134
ii udev 241-6
-- Configuration Files:
/etc/systemd/timesyncd.conf changed [not included]
-- no debconf information
>From 4eb086a38712ea98faf41e075b84555b11b54362 Mon Sep 17 00:00:00 2001
From: Susant Sahani
Date: Thu, 9 May 2019 07:35:35 +0530
Subject: [PATCH] networkd: fix link_up() (#12505)
Fillup IFLA_INET6_ADDR_GEN_MODE while we do link_up.
Fixes the following error:
```
dummy-test: Could not bring up interface: Invalid argument
```
After reading the kernel code when we do a link up
```
net/core/rtnetlink.c
IFLA_AF_SPEC
af_ops->set_link_af(dev, af);
inet6_set_link_af
if (tb[IFLA_INET6_ADDR_GEN_MODE])
Here it looks for IFLA_INET6_ADDR_GEN_MODE
```
Since link up we didn't filling up that it's failing.
Closes #12504.
---
src/network/networkd-link.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 3c8b5c5cb4..4db9f3f980 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -2031,6 +2031,8 @@ static int link_up(Link *link) {
}
if (link_ipv6_enabled(link)) {
+uint8_t ipv6ll_mode;
+
r = sd_netlink_message_open_container(req, IFLA_AF_SPEC);
if (r < 0)
return log_link_error_errno(link, r, "Could not open
IFLA_AF_SPEC container: %m");
@@ -2046,6 +2048,19 @@ static int link_up(Link *link) {
return log_link_error_errno(link, r, "Could
not append IFLA_INET6_TOKEN: %m");
}
+if (!link_ipv6ll_enabled(link))
+ipv6ll_mode = IN6_ADDR_GEN_MODE_NONE;
+else if (sysctl_read_ip_property(AF_INET6, link->ifname,
"stable_secret", NULL) < 0)
+/* The file may not exist. And event if it exists,
when stable_secret is unset,
+ * reading the file fails with EIO. */
+ipv6ll_mode = IN6_ADDR_GEN_MODE_EUI64;
+else
+ipv6ll_mode = IN6_ADDR_GEN_MODE_STABLE_PRIVACY;
+
+r = sd_netlink_message_append_u8(req,
IFLA_INET6_ADDR_GEN_MODE, ipv6ll_mode);
+if (r < 0)
+return log_link_error_errno(link, r, "Could not append
IFLA_INET6_ADDR_GEN_MODE: %m");
+
r = sd_netlink_message_close_container(req);
if (r < 0)
return log_link_error_errno(link, r, "Could not close
AF_INET6 container: %m");
--
2.23.0.rc1
>From 9f6e82e6eb3b6e73d66d00d
Bug#935127: bash: please make the build reproducible
Source: bash Version: 5.0-4 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, A patch is attached that makes the Bash interpreter build reproducibily for me in unstable. This is because in various places it encoded the absolute build path via the inclusion of output from CFLAGS or even quite-literally as "BUILD_DIR". I did have another patch that modified the source files "properly" themselves but I was not only having problems with autoreconf-ing the package (it worked, but the command was returning a non-zero exit code regardless which I papered over with a "|| true"...?), additionally one of the Makefiles could not have it's BUILD_DIR patched to point to some deterministic location as it would cause the package to FTBFS. Thus, we would have required some post-processing anyway. (Another alternative to this could be to simply not ship that particular file as it is likely not going to work on end-user machines anyway). [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/rules 2019-08-19 11:39:35.821792908 -0700 --- b/debian/rules 2019-08-19 11:56:21.330814485 -0700 @@ -263,6 +263,14 @@ $(d_bins)/usr/share/doc/$(p)/examples/loadables ln -sf bash $(d_bins)/usr/share/doc/$(p_bins) + sed -i \ + -e 's@-ffile-prefix-map=[^ ]*[ ]*@@g' \ + -e 's@-fdebug-prefix-map=[^ ]*[ ]*@@g' \ + -e 's@^BUILD_DIR =.*@BUILD_DIR = /path/to/build-dir@' \ + $(d)/usr/bin/bashbug \ + $(d_bins)/usr/lib/bash/Makefile.inc \ + $(d_bins)/usr/share/doc/$(p)/examples/loadables/Makefile + # cat debian/README stamps/stamp-patch > debian/README.Debian cat debian/README > debian/README.Debian
Bug#924514: Closing since solved in unstable
Hi Andreas, On Mon, 19 Aug 2019 11:57:05 +0200 Andreas Tille wrote: > I wonder whether we can close this bug since the test is passing > in unstable (with r-cran-multcomp 1.4-10-2). No, because currently it is blocking the migration of r-cran-multcomp. Apparently r-cran-multcomp isn't making sure that the right stuff is pulled into testing when it is testing r-cran-dosefinding. I am hoping that r-cran migrates soon with lots of r stuff, maybe after that it is "fixed". There is still a breaks missing somewhere I guess, but I don't know where. Paul signature.asc Description: OpenPGP digital signature
Bug#935125: RM: pyexcelerator -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal Last release in 2009. Reverse deps checked with dak rm -Rnb python-excelerator -- WBR, wRAR signature.asc Description: PGP signature
Bug#934465: xtrlock FTCBFS: uses the build architecture compiler
Hi Helmut, > xtrlock fails to cross build from source, because debian/rules uses the > build architecture compiler as a make default. This is a result of > improperly applying #902648 Whoops; sorry about that. I will try to be more attentive in future. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#935122: RM: optcomplete -- RoQA; orphaned; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal Upstream Python 3 bugreport: https://bitbucket.org/blais/optcomplete/issues/2/python3-compatibility Reverse deps checked with dak rm -Rnb python-optcomplete -- WBR, wRAR signature.asc Description: PGP signature
Bug#935124: RM: pyao -- RoQA; orphaned; ancient; dead upstream; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal There is some Py3 fork at https://github.com/tynn/PyAO Reverse deps checked with dak rm -Rn pyao -- WBR, wRAR signature.asc Description: PGP signature
Bug#935123: RM: m2ext -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal Last upstream commit in 2012. Reverse deps checked with dak rm -Rnb python-m2ext -- WBR, wRAR signature.asc Description: PGP signature
Bug#934905: libaqbanking35: libaqbanking not ready for PSD2, will not work after 14 September 2019
Hi Christian, I understand your bug report and confirm it to be an issue. Unfortunately I don't have much capacity at the moment to work on an updated package in a timely manner. But I do appreciate and support any volunteer's help. Best regards, Micha
Bug#935121: RM: maptransfer -- RoQA; Unmaintained; Affected by Qt4/Python2 Removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-CC: 933...@bugs.debian.org Dear FTP Masters, Package maptransfer saw no upstream activity since 2010 and it is stuck on python2 and qt4, which are to be removed in the bullseye cycle. There are also no package maintainer activity since 2015. Previous proposal of package removal ( https://bugs.debian.org/933033 ) received no reply. As a result, I'm requesting to have maptransfer removed from Sid. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#935120: RM: jabber.py -- RoQA; orphaned; ancient; no Python 3 support and no reverse deps
Package: ftp.debian.org Severity: normal User: debian-pyt...@lists.debian.org Usertag: py2removal Last release in 2003. Reverse deps checked with dak rm -Rnb python-jabber -- WBR, wRAR signature.asc Description: PGP signature
Bug#935090: gnome-weather crashes if invalid locations are configured in dconf
Control: severity -1 important
Control: tags -1 + patch fixed-upstream pending
On Mon, 19 Aug 2019 at 07:00:12 -0500, Diego Escalante Urrelo wrote:
> When an invalid value is stored in:
> /org/gnome/Weather/Application/locations
>
> gnome-weather will crash and never start.
Reproducer (this is somewhat destructive because it replaces configuration):
$ dconf write /org/gnome/Weather/Application/locations "[<(uint32 2, <('Bees',
'BEES', false, [(0.0, 0.0)], [(0.0, 0.0)])>)>]"
$ gnome-weather
I've confirmed that the patches you proposed fix this.
This will need to be fixed in unstable before the stable release managers
will consider a fixed version for buster, so I'm uploading 3.26.0-6 with
this fixed. (It will also need to be fixed in experimental by landing
v3.32.2.)
Thanks,
smcv
Bug#935119: RM: lfhex -- ROM; Unmaintained; Dead Upstream; Affected by Qt4 Removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-CC: tklau...@distanz.ch Dear FTP Masters, As requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875018#15 , the package maintainer of lfhex has agreed to have it removed from Sid. This package has no recent activity and is affected by the Qt4 removal in Bullseye cycle. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#935015: datalad: please drop python-datalad (python 2 removal effort)
Package: datalad
Followup-For: Bug #935015
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch
Sorry, I overlooked that there was still an undeclared build-dependency on
python/python-setuptools which I happened to have present in my test build
environment. The attached patch or something like it is also needed in
order for datalad to build without python2.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru datalad-0.11.6/debian/patches/python3.patch
datalad-0.11.6/debian/patches/python3.patch
--- datalad-0.11.6/debian/patches/python3.patch 2019-08-16 21:28:05.0
-0700
+++ datalad-0.11.6/debian/patches/python3.patch 2019-08-19 10:49:52.0
-0700
@@ -40,3 +40,38 @@
where='local'
)
ds.unlock("fromproc.txt")
+Index: datalad-0.11.6/Makefile
+===
+--- datalad-0.11.6.orig/Makefile
datalad-0.11.6/Makefile
+@@ -1,8 +1,8 @@
+ # simple makefile to simplify repetetive build env management tasks under
posix
+ # Ideas borrowed from scikit-learn's and PyMVPA Makefiles -- thanks!
+
+-PYTHON ?= python
+-NOSETESTS ?= nosetests
++PYTHON ?= python3
++NOSETESTS ?= nosetests3
+
+ MODULE ?= datalad
+
+@@ -16,7 +16,7 @@
+
+ bin:
+ mkdir -p $@
+- PYTHONPATH=bin:$(PYTHONPATH) python setup.py develop --install-dir $@
++ PYTHONPATH=bin:$(PYTHONPATH) $(PYTHON) setup.py develop --install-dir $@
+
+ test-code: bin
+ PATH=bin:$(PATH) PYTHONPATH=bin:$(PYTHONPATH) $(NOSETESTS) -s -v
$(MODULE)
+@@ -45,8 +45,8 @@
+ release-pypi: update-changelog
+ # better safe than sorry
+ test ! -e dist
+- python setup.py sdist
+- python setup.py bdist_wheel --universal
++ $(PYTHON) setup.py sdist
++ $(PYTHON) setup.py bdist_wheel --universal
+ twine upload dist/*
+
+ render-casts: docs/source/usecases/simple_provenance_tracking.rst.in
Bug#935118: rkhunter doesn't reports ALL suspicious (large) shared memory segments BUT just the biggest one
Package: rkhunter
Version: 1.4.6-7
Severity: important
Dear Maintainer,
* What led up to the situation?
rkhunter seem to only report the biggest shared memory segment, but not all (?)
* What exactly did you do (or not do) that was effective (or
ineffective)?
1) Start for example "terminology":
# ps ax| grep terminology
566 ?S 0:00 /bin/sh -c /usr/bin/terminology
567 ?Sl 0:49 /usr/bin/terminology
580 ?S 0:00 /bin/sh -c /usr/bin/terminology
581 ?Sl 0:22 /usr/bin/terminology
2676 ?S 0:00 /bin/sh -c /usr/bin/terminology
2678 ?S 0:00 /bin/sh -c /usr/bin/terminology
2679 ?Sl 2:44 /usr/bin/terminology
2682 ?Sl 0:00 /usr/bin/terminology
25244 ?S 0:00 /bin/sh -c /usr/bin/terminology
25245 ?Sl 0:06 /usr/bin/terminology
26838 ?S 0:00 /bin/sh -c /usr/bin/terminology
26839 ?Sl 2:03 /usr/bin/terminology
27741 pts/5S+ 0:00 grep terminology
... and run "rkrhunter --check":
# less /var/log/rkhunter.log:
[19:09:52] Checking for suspicious (large) shared memory segments [ Warning ]
[19:09:52] Warning: The following suspicious (large) shared memory segments
have been found:
[19:09:52] Process: /usr/bin/terminologyPID: 26839Owner: ci
Size: 1.5MB (configured size allowed: 1.0MB)
2) Then start "firefox" ("terminology"(s) are still open):
# ps ax| grep firefox
27738 pts/5S+ 0:00 grep firefox
30775 ?S 0:00 /bin/sh -c /usr/lib/firefox/firefox
30776 ?Sl 0:05 /usr/lib/firefox/firefox
30837 ?Sl 0:01 /usr/lib/firefox/firefox -contentproc -childID 1
-isForBrowser -prefsLen 1 -prefMapSize 209913 -parentBuildID 20190601044405
-greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja
-appdir /usr/lib/firefox/browser 30776 true tab
30912 ?Sl 0:04 /usr/lib/firefox/firefox -contentproc -childID 2
-isForBrowser -prefsLen 5797 -prefMapSize 209913 -parentBuildID 20190601044405
-greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja
-appdir /usr/lib/firefox/browser 30776 true tab
31018 ?Sl 0:00 /usr/lib/firefox/firefox -contentproc -childID 3
-isForBrowser -prefsLen 7308 -prefMapSize 209913 -parentBuildID 20190601044405
-greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja
-appdir /usr/lib/firefox/browser 30776 true tab
... and run again "rkhunter --check":
# less /var/log/rkhunter.log
[19:24:01] Warning: The following suspicious (large) shared memory segments
have been found:
[19:24:01] Process: /usr/lib/firefox/firefoxPID: 30776Owner:
ciSize: 1.9MB (configured size allowed: 1.0MB)
[19:24:01] Process: /usr/lib/firefox/firefoxPID: 30776Owner:
ciSize: 1.9MB (configured size allowed: 1.0MB)
3) Then close "firefox" ("terminology"(s) are still open)
# ps ax| grep terminology
566 ?S 0:00 /bin/sh -c /usr/bin/terminology
567 ?Sl 0:50 /usr/bin/terminology
580 ?S 0:00 /bin/sh -c /usr/bin/terminology
581 ?Sl 0:22 /usr/bin/terminology
2676 ?S 0:00 /bin/sh -c /usr/bin/terminology
2678 ?S 0:00 /bin/sh -c /usr/bin/terminology
2679 ?Sl 2:58 /usr/bin/terminology
2682 ?Sl 0:00 /usr/bin/terminology
25244 ?S 0:00 /bin/sh -c /usr/bin/terminology
25245 ?Sl 0:10 /usr/bin/terminology
26838 ?S 0:00 /bin/sh -c /usr/bin/terminology
26839 ?Sl 2:10 /usr/bin/terminology
31804 pts/5S+ 0:00 grep terminology
# ps ax| grep firefox
1116 pts/5S+ 0:00 grep firefox
...and run again "rkhunter --check":
[19:30:45] Warning: The following suspicious (large) shared memory segments
have been found:
[19:30:45] Process: /usr/bin/terminologyPID: 26839Owner: ci
Size: 1.5MB (configured size allowed: 1.0MB)
* What was the outcome of this action?
The warning on supicious (large) shared memory segments seems to be only valid
for the LARGEST one
* What outcome did you expect instead?
ALL large shared memory segments reported
Thanks in advance!
--xiscu
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-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)
Versions of packages rkhunter depends on:
ii binutils 2.32.51.20190727-1
ii debconf [debconf-2.0] 1.5.73
ii file 1:5.37-5
ii lsof 4.91+dfsg-1+b1
ii net-tools 1.60+git20180626.aebd88e-1
ii perl 5.28.1-6
ii ucf3.0038+nmu1
Versions of packag
Bug#935015: datalad: please drop python-datalad (python 2 removal effort)
Package: datalad
Version: 0.11.6-1
Followup-For: Bug #935015
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch
Hello,
Attached is a patch that drops python2 from datalad. A small patch to
upstream is needed to switch the python interpreter used for dispatching
scripts from /usr/bin/python to /usr/bin/python3. If you think this is
risky because it breaks compatibility with existing third-party scripts, the
alternative solution is to add a build-depends on python, but I wouldn't
recommend that as a solution to support for the next release.
Also, just as a comment, the heudiconv package build-depends on and
recommends python-datalad, however heudiconv is RC-buggy and not included in
testing so I don't think this should block removal of the python2 bindings.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru datalad-0.11.6/debian/control datalad-0.11.6/debian/control
--- datalad-0.11.6/debian/control 2019-07-29 09:07:25.0 -0700
+++ datalad-0.11.6/debian/control 2019-08-16 21:28:05.0 -0700
@@ -11,39 +11,6 @@
git-annex (>= 6.20180913~) | git-annex-standalone (>= 6.20180913~),
help2man,
patool,
- python-all,
- python-appdirs,
- python-argcomplete,
- python-boto,
- python-dateutil,
- python-exif,
- python-fasteners,
- python-iso8601,
- python-jsmin,
- python-git (>= 2.1.6~),
- python-github,
- python-html5lib,
- python-httpretty,
- python-humanize,
- python-keyrings.alt | python-keyring (<=8),
- python-keyring,
- python-secretstorage | python-keyring (<<9.2),
- python-nose (>= 1.3.7-2) | python-libxmp,
- python-lzma,
- python-mock,
- python-msgpack,
- python-mutagen,
- python-nose,
- python-pil,
- python-pyperclip,
- python-requests,
- python-setuptools,
- python-simplejson,
- python-six (>= 1.8.0~),
- python-tqdm,
- python-whoosh,
- python-vcr,
- python-wrapt,
python3-all,
python3-appdirs,
python3-argcomplete,
@@ -89,7 +56,7 @@
python3-datalad (= ${binary:Version}),
python3-argcomplete,
${misc:Depends},
- ${python:Depends}
+ ${python3:Depends}
Suggests:
datalad-containers,
datalad-crawler,
@@ -113,69 +80,6 @@
This package provides the command line tools. Install without
Recommends if you need only core functionality.
-Package: python-datalad
-Architecture: all
-Section: python
-Provides: ${python:Provides}
-Depends:
- git-annex (>= 6.20180913~) | git-annex-standalone (>= 6.20180913~),
- patool,
- python-appdirs,
- python-fasteners,
- python-git (>= 2.1.6~),
- python-humanize,
- python-iso8601,
- python-keyrings.alt | python-keyring (<=8),
- python-secretstorage,
- python-keyring,
- python-mock,
- python-msgpack,
- python-pil,
- python-requests,
- python-simplejson,
- python-six (>= 1.8.0~),
- python-tqdm,
- python-wrapt,
- ${misc:Depends},
- ${python:Depends}
-Recommends:
- python-exif,
- python-github,
- python-jsmin,
- python-html5lib,
- python-httpretty,
- python-libxmp,
- python-lzma,
- python-mutagen,
- python-nose,
- python-pyperclip,
- python-requests-ftp,
- python-vcr,
- python-whoosh,
-Suggests:
- python-duecredit,
- python-bs4,
- python-numpy,
-Description: data files management and distribution platform
- DataLad is a data management and distribution platform providing
- access to a wide range of data resources already available online.
- Using git-annex as its backend for data logistics it provides following
- facilities built-in or available through additional extensions
- .
- - command line and Python interfaces for manipulation of collections of
-datasets (install, uninstall, update, publish, save, etc.) and
- separate files/directories (add, get)
- - extract, aggregate, and search through various sources of metadata
-(xmp, EXIF, etc; install datalad-neuroimaging for DICOM, BIDS, NIfTI
-support)
- - crawl web sites to automatically prepare and update git-annex
-repositories with content from online websites, S3, etc (install
-datalad-crawler)
- .
- This package installs the module for Python 2, and Recommends install
- all dependencies necessary for searching and managing datasets, publishing,
- and testing. If you need base functionality, install without Recommends.
-
Package: python3-datalad
Architecture: all
Section: python
diff -Nru datalad-0.11.6/debian/patches/python3.patch
datalad-0.11.6/debian/patches/python3.patch
--- datalad-0.11.6/debian/patches/python3.patch 1969-12-31 16:00:00.0
-0800
+++ datalad-0.11.6/debian/patches/python3.patch 2019-08-16 21:28:05.0
-0700
@@ -0,0 +1,42 @@
+Description: use python3 interpreter, not python
+ datalad will automatically try to run .py scripts it's been given under
+ 'python' but that is python2 and no longer guaranteed to be available by
+ defau
Bug#934979: debian 10 main after turning on computer resuming from hibernation displays
Hello, maybe the following report is related: https://bugs.debian.org/928736 Kind regards, Bernhard
Bug#934483: virtualbox-guest-dkms: Doesn't build with latest kernel in unstable 5.2.0-2-686-pae
On Sun, 11 Aug 2019, Christian Marillat wrote: > But bevare fixind the include file path (drm/ttm/ttm_page_alloc.h) doesn't > work at all the virtualbox doesn't start. I fixed the path, the build went through. I rebooted my VM and it worked. What exactly was the failure that you had? Did you have some error message in the kernel logs? However on the gdm3 login screen, after I have input my login/password, the picture stays fixed and I have to resize the window or force a VT switch to get it working again... In the kernel log I see this: > [drm] Error -12 pinnning new fb, out of video mem? And as you mentionned in your other mail, if I increase the allocated memory for video to 32 Mb (I had 16), this problem goes away. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#935117: samba: Missing upgrade notes in NEWS.Debian
Package: samba Version: 2:4.9.5+dfsg-5 Severity: normal Dear Maintainer, * What led up to the situation? During an upgrade from Debian Stretch to Buster the apt-listchanges package shows noteworthy changes and usually warnings about modified configuration settings from the /usr/share/doc/samba/NEWS.Debian.gz file. * What happened? During the upgrade from Stretch to Buster only a note on changed systemd services is shown. So I expected the existing configuration to continue working, however, that was not the case. After some troubleshooting I found out that winbind was now required as mentioned in the upgrading section of the release notes for Samba 4.8. * What outcome did you expect instead? My expectation would be that the NEWS file includes the upgrading section contained in the upstream release notes (for 4.6, 4.7 and 4.8). Or at least there should be a pointer to the release notes. Note: The NEWS.Debian.gz files is unchanged from 4.9.5+dfsg-5 in the 4.9.11+dfsg-1 version of the samba package. Best regards, Michael Eischer -- Package-specific info: * /etc/samba/smb.conf present, but not attached * /var/lib/samba/dhcp.conf present, but not attached -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (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 samba depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libbsd0 0.9.1-2 ii libc6 2.28-10 ii libldb1 2:1.5.1+really1.4.6-3 ii libpam-modules1.3.1-5 ii libpam-runtime1.3.1-5 ii libpopt0 1.16-12 ii libpython2.7 2.7.16-2 ii libtalloc22.1.14-2 ii libtdb1 1.3.16-2+b1 ii libtevent00.9.37-1 ii lsb-base 10.2019051400 ii procps2:3.3.15-2 ii python2.7.16-1 ii python-dnspython 1.16.0-1 ii python-samba 2:4.9.5+dfsg-5 ii python2.7 2.7.16-2 ii samba-common 2:4.9.5+dfsg-5 ii samba-common-bin 2:4.9.5+dfsg-5 ii samba-libs2:4.9.5+dfsg-5 ii tdb-tools 1.3.16-2+b1 Versions of packages samba recommends: ii attr1:2.4.48-4 ii logrotate 3.14.0-4 ii samba-dsdb-modules 2:4.9.5+dfsg-5 ii samba-vfs-modules 2:4.9.5+dfsg-5 Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb pn ldb-tools pn ntp | chrony pn smbldap-tools pn ufw ii winbind2:4.9.5+dfsg-5 -- no debconf information
Bug#923481: alpine: replies lose In-Reply-To and References headers
On Tue, 13 Aug 2019, Unit 193 wrote: > Ah right. Though while looking through several of my recent sent items, it > seems it preserved those fields as expected. I am using alpine 2.21. Please try this, from the original submission: If I take a message, reply to it, then go to the Subject line, press ^K to remove the existing (possibly damaged) text and type new text (possibly to change the subthread subject), the eMail When just replying to a message without changing Subject, alpine indeed keeps the headers just fine. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#935116: qwt: Switch to git in salsa.debian.org
On Mon, 19 Aug 2019 at 13:18, Lisandro Damián Nicanor Pérez Meyer wrote: > > Source: qwt > Version: 6.1.4-1 > Severity: wishlist > > Hi Gudjon! would it be ok for you if we switch qwt to git within > salsa.debian.org? > I can import it from SVN too. And if you like we can put it within the > qt-kde-iteam's umbrella, extras subproject. In fact alioth is gone and I do not have access to the SVN repo. Do you have it at hand?
Bug#934483: virtualbox-guest-dkms: Doesn't build with latest kernel in unstable 5.2.0-2-686-pae
On 19 août 2019 17:18, Raphael Hertzog wrote: > Hi, > > On Thu, 15 Aug 2019, Darsey Litzenberger wrote: >> I haven't gotten around to testing, but it looks like maybe all that needs >> to be done is to disable building some of these modules after a certain >> kernel version. > > At least I can confirm that if you disable "vboxvideo" from the > dkms configuration (in dkms.conf and Makefile in the > /usr/src/virtualbox-guest-6.0.10/ directory), then the DKMS build > works. Works for me too. But memory assigned to video in virtualbox need to be increased, 10MB isn't enough. Christian
Bug#935116: qwt: Switch to git in salsa.debian.org
Source: qwt Version: 6.1.4-1 Severity: wishlist Hi Gudjon! would it be ok for you if we switch qwt to git within salsa.debian.org? I can import it from SVN too. And if you like we can put it within the qt-kde-iteam's umbrella, extras subproject. Cheers, Lisandro. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#935095: nmu: znc-backlog
Control: close -1 On Mon, Aug 19, 2019 at 02:36:42PM +0200, Mattia Rizzolo wrote: > please bin-nmu znc-backlog against the new znc, so that then znc can > finally migrate. > > We are discussing in #917222 on how to improve the situation, but in the > meantime it would be better to not to block znc… > > wb nmu znc-backlog_0.20180824-1 . ANY . -m "Rebuild against the last znc" Actually, nvm. We unblocked our situation sooner than I expected, so I'll now upload a src:znc building znc-backlog, and there won't be any other issue like this one. -- 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#914865: anything new?
Hello,
this problem seems to be in apt, not in unattended-uprades.
I have configured apt to use /tmp as base for packages:
Dir::Cache::archives "/tmp/archives";
Apt::Update::Pre-Invoke {"mkdir -m 700 -p /tmp/archives/partial";};
unfortunately, the pre-invoke command only seems to be called when package
list is updated (as its name says), not when packages are fetched to be
installed.
hacking unattended-uprades to call update would apparently fix this
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Emacs is a complicated operating system without good text editor.
Bug#932614: basemap: pyproj upstream going to drop Python 2 support
On Mon, Aug 19, 2019 at 11:47 AM Sebastiaan Couwenberg wrote: > > On 8/19/19 5:27 PM, Sandro Tosi wrote: > > So, what do you want me to do? drop the python 2 package for basemap? > > Yes. > > > i cant do that, it has reverse dependencies (just like pyproj) > > basemap is the only remaining rdep for python-pyproj, as it also for > python-shp & python-netcdf4. > > pyspread is the only remaining rdep for python-mpltoolkits.basemap. > > You should file a bugreport for pyspread and have it block this one. I will review the rdeps of basemap and file reports; that wont make the rdeps migrate automagically... > Aren't you also coordinating the python2 removal for your packages? I am. > > Are you saying that you're willing to break pyproj reverse > > dependencies without giving them a chance to clear their rdeps first? > > Everyone except you has already taken the chance they were given and > stopped depending on python-pyproj. there are packages that are easier to migrate than others, leaf pkgs for examples; not every pkg is a leaf tho > > not really a nice idea > > Not coordinating numpy updates with its reverse dependencies is not nice > either, but that never stopped you. ok, so is this something you're doing on purpose then? good to know. -- 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#935115: bash: [regression] passing variable assignments to functions broken in POSIX mode, violating POSIX
Package: bash
Version: 5.0-4
Severity: critical
Justification: breaks unrelated software
Found this gem in #934027:
tglase@tglase:~ $ cat testscript
dbc_mysql_createdb(){
local ret l_dbname _dbc_nodb
echo "dbc_mysql_createdb: _dbc_nodb(1)=$_dbc_nodb"
_dbc_nodb="yes" dbc_mysql_exec_command "CREATE DATABASE
\`$dbc_dbname\`${extrasql:-}"
ret=$?
echo "dbc_mysql_createdb: _dbc_nodb(2)=$_dbc_nodb" # POSIX:
unspecified
/usr/bin/env | fgrep -c _dbc_nodb | sed 's/^/after: /' # POSIX:
unspecified
echo dbc_mysql_createdb:$ret
}
dbc_mysql_exec_command(){
local statement l_sqlfile l_retval
statement="$@"
l_retval=0
echo "dbc_mysql_exec_command: _dbc_nodb=$_dbc_nodb" # POSIX:
required
/usr/bin/env | fgrep -c _dbc_nodb | sed 's/^/inner: /' # POSIX:
unspecified
return $l_retval
}
dbc_mysql_createdb
tglase@tglase:~ $ dash testscript
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 0
dbc_mysql_createdb: _dbc_nodb(2)=yes
after: 0
dbc_mysql_createdb:0
tglase@tglase:~ $ ksh -c 'alias local=typeset; . ./testscript'
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 0
dbc_mysql_createdb: _dbc_nodb(2)=yes
after: 0
dbc_mysql_createdb:0
tglase@tglase:~ $ lksh -o posix testscript # native mksh +o posix is identical
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=yes
after: 1
dbc_mysql_createdb:0
tglase@tglase:~ $ posh testscript
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=
after: 0
dbc_mysql_createdb:0
tglase@tglase:~ $ yash testscript
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=
after: 0
dbc_mysql_createdb:0
tglase@tglase:~ $ zsh -c 'emulate sh; . ./testscript'
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=yes
after: 1
dbc_mysql_createdb:0
tglase@tglase:~ $ bash --version 2>&1 | head -1
GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnux32)
tglase@tglase:~ $ bash testscript
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=
after: 0
dbc_mysql_createdb:0
tglase@tglase:~ $ bash --posix testscript
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=
after: 1
dbc_mysql_createdb:0
tglase@tglase:~ $ schroot -prc stretch
(stretch-i386)tglase@tglase:~ $ bash --version 2>&1 | head -1
GNU bash, version 4.4.12(1)-release (i686-pc-linux-gnu)
(stretch-i386)tglase@tglase:~ $ bash testscript
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=
after: 0
dbc_mysql_createdb:0
(stretch-i386)tglase@tglase:~ $ bash --posix testscript
dbc_mysql_createdb: _dbc_nodb(1)=
dbc_mysql_exec_command: _dbc_nodb=yes
inner: 1
dbc_mysql_createdb: _dbc_nodb(2)=yes
after: 1
dbc_mysql_createdb:0
The expected output is:
dbc_mysql_createdb: _dbc_nodb(1)= # initially not set / empty
dbc_mysql_exec_command: _dbc_nodb=yes # MUST be visible inside the function
inner: 0 or 1 # MAY be exported, does not need to
dbc_mysql_createdb: _dbc_nodb(2)=[yes] # MAY be visible afterwards, optional
after: 0 or 1 # if visible afterwards MAY be exported
dbc_mysql_createdb:0
POSIX reference:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
specifically:
* If the command name is a function that is not a standard utility
implemented as a function, variable assignments shall affect the
current execution environment during the execution of the function.
It is unspecified:
+ Whether or not the variable assignments persist after the
completion of the function
+ Whether or not the variables gain the export attribute during the
execution of the function
+ Whether or not export attributes gained as a result of the variable
assignments persist after the completion of the function (if
variable assignments persist after the completion of the function)
Tested shells:
┌──┬┬──┬┬──┐
│ shell \ what │ inside visible │ exported │ afterwards visible │ exported │
├──┼┼──┼┼──┤
│ bash4│ ✔ as required │ ✓ (good) │ ✗ no, permitted│ –│
│ bash4 posix │ ✔ as required │ ✓ (good) │ ✓ yes, permitted │ ✓ (ok) │
│ bash5│ ✔ as required │ ✓ (good) │ ✗ no, permitted│ –│
│ bash5 posix │ ✘ !!FAIL!! ⚠ │ ✓ (huh?) │ ✗ empty│ ✓ (huh?) │
│ dash │ ✔ as required │ ✗ (ok) │ ✗ no, permitted│ –│
│ ksh93│ ✔ as required │ ✗ (ok) │ ✗ no, permit
Bug#932614: basemap: pyproj upstream going to drop Python 2 support
On 8/19/19 5:27 PM, Sandro Tosi wrote: > So, what do you want me to do? drop the python 2 package for basemap? Yes. > i cant do that, it has reverse dependencies (just like pyproj) basemap is the only remaining rdep for python-pyproj, as it also for python-shp & python-netcdf4. pyspread is the only remaining rdep for python-mpltoolkits.basemap. You should file a bugreport for pyspread and have it block this one. Aren't you also coordinating the python2 removal for your packages? > Are you saying that you're willing to break pyproj reverse > dependencies without giving them a chance to clear their rdeps first? Everyone except you has already taken the chance they were given and stopped depending on python-pyproj. > not really a nice idea Not coordinating numpy updates with its reverse dependencies is not nice either, but that never stopped you. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#930451: fabric: please consider uploading the latest version
On Wed, 12 Jun 2019 22:44:28 +0100 Luca Boccassi < bl...@debian.org > wrote: > Source: fabric > Version: 1.14.0-1 > Severity: wishlist > Blocks: 930413 > > Dear Maintainer, > > Please consider uploading the latest version of fabric, 2.4.0: > > https://github.com/fabric/fabric/releases/tag/2.4.0 > > Among other things, it's a requirement for azure-cli which I'd like to > upload in the next few weeks. > > I'd be happy to help and do the work myself if you are short on time. > > Thank you for your work on this package! Dear Maintainer, Since I am currently blocked by this, unless there are objections I'll start working on an NMU shortly. I'll post the debdiff here before any upload, and use a long DELAYED queue if the nmu is to go ahead. Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#925700:
I think this can be worked around by adding -Werror=stringop-truncation to CXXFLAGS -- Michael R. Crusoe
Bug#935114: lsof: Some processes with modified name become invisible
Package: lsof Version: 4.91+dfsg-1 Severity: normal Dear Maintainer, By modifying the process name (e.g. by assigning to `$0` in perl as per below), lsof sometimes fails to see the process even when their PID is specified directly with `-p`. Compare a working case: $ perl -E '$0 = "changed"; print "My PID is $$\n"; ' My PID is 4200 $ lsof -p 4200 COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME changed 4200 leo cwdDIR 254,320480 3293185 /home/leo changed 4200 leo rtdDIR 254,0 4096 2 / ... With a non-working one: $ perl -E '$0 = "with-hyphen (and paren)"; print "My PID is $$\n"; ' My PID is 4748 $ lsof -p 4748 $ lsof -p 4748 -V lsof: process ID not located: 4748 So far I don't have a conclusive pattern to which modifications are OK and which cause it to fail. All of these work fine: $0 = "a really long name goes here with some stuff" $0 = "with(paren)" $0 = "with (paren) and spaces" $0 = "with-(paren)" $0 = "(a b)" $0 = "(a b c d e f g)" This does not $0 = "(a b c d e f g h)" It seems somehow to be related to what's inside the parentheses in the process name, but I don't know if it's length, or word count, or what set of characters are present. But then $0 = "(and paren)" on its own *does* work, when it didn't work with the original example when it suffixed longer text. Hopefully, these test cases will help mean something to the lsof developers who might be able to narrow down what is going on. -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lsof depends on: ii libc62.28-10 ii libselinux1 2.8-1+b1 lsof recommends no packages. Versions of packages lsof suggests: ii perl 5.28.1-6 -- no debconf information -- Paul "LeoNerd" Evans leon...@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Bug#935113: ITA: vtun -- virtual tunnel over TCP/IP networks
Package: wnpp Severity: normal I intend to adopt the vtun package. The package description is: VTun is the easiest way to create virtual tunnels over TCP/IP networks with traffic shaping and compression. . It supports IP, PPP, SLIP, Ethernet and other tunnel types. . VTun is easily and highly configurable, it can be used for various network tasks. . VTun requires the universal TUN/TAP kernel module which can be found at http://vtun.sourceforge.net/tun/index.html or in the 2.4 and newer Linux kernels. . Note: This program includes an "encryption" feature intended to protect the tunneled data as it travels across the network. However, the protocol it uses is known to be very insecure, and you should not rely on it to deter anyone but a casual eavesdropper. See the included README.Encryption file for more information.
