Bug#926432: apache2: Internal error: error fetching from cache 'dbm:/var/cache/apache2/gnutls_cache'
Hello, Unfortunately, not. apache2 2.4.39-1 is installed, but I can see these errors in apache2/error.log Best regards, Damir -Original Message- From: Xavier Sent: Friday, April 5, 2019 11:40 AM To: Damir R. Islamov Cc: 926...@bugs.debian.org; 926...@bugs.debian.org Subject: Re: Bug#926432: apache2: Internal error: error fetching from cache 'dbm:/var/cache/apache2/gnutls_cache' Le 03/04/2019 à 14:40, Damir R. Islamov a écrit : > Package: apache2 > Version: 2.4.38-2 > Severity: normal > > Dear Maintainer, > > After update to aapche 2.4.38-1 /var/log/apache2/error.log has a lot of > errors like > > [gnutls:warn] [pid 6466:tid 140230002730752] (20014)Internal error (specific > information not available): error fetching from cache > 'dbm:/var/cache/apache2/gnutls_cache' > > One string per virtual host, every 10 minutes. Hello, could you try with apache-2.4.39 (https://people.debian.org/~yadd/apache/) ? It seems that this has been fixed. Cheers, Xavier
Bug#926623: ITP: ruby-parallel-tests -- Run Test::Unit / RSpec / Cucumber / Spinach in parallel
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: ruby-parallel-tests Version : 2.28.0 Upstream Author : Michael Grosser * URL : https://github.com/grosser/parallel_tests * License : MIT Programming Lang: Ruby Description : Run Test::Unit / RSpec / Cucumber / Spinach in parallel Speedup Test::Unit + RSpec + Cucumber + Spinach by running parallel on multiple CPU cores. ParallelTests splits tests into even groups (by number of lines or runtime) and runs each group in a single process with its own database.
Bug#925411: kernel-package: Not suitable for release
Hi Ben, On Sun, Mar 24, 2019 at 11:23:58PM +, Ben Hutchings wrote: > Control: severity -1 serious > > On Sun, 2019-03-24 at 16:19 -0600, Nicholas D Steeves wrote: > > Control: severity -1 important > > Justification: essential package that works flawlessly for me > > This was agreed with the maintainer, so you should not override it. > > The discussion is here: > https://lore.kernel.org/lkml/1551888035-13329-1-git-send-email-yamada.masah...@socionext.com/ > but unfortunately Manoj's message didn't get archived there for some > reason. > Maybe I'm missing something, but I couldn't find sufficient justification there... That said, I did more tests, because an RC bug that cuts such a useful package from a release really ought to have justification. I can now confirm that at least one dkms module (tp-smapi-dkms) doesn't build with make-kpkg-generated kernel packages on buster. Maybe all dkms modules are affected? Maybe Manoj' message said something to that affect, and how make-kpkg produces packages that are defective in this way...and maybe other ways? > [...] > > The new style kernel packaging is hard to learn how to use, and builds > > take much longer for some reason (generation of more packages?). > [...] > > It sounds like you're looking at the linux source package. I would > certainly not suggest using that for local custom packages; it's meant > for distributions. > > The simple alternative is already included in the kernel tree itself: > > make bindeb-pkg > Ah, yes, thank you! :-) Regarding documentation, should Debian-specific bits go on our wiki or be forwarded upstream? eg: the top line of BuildADebianKernelPackage says "this is an obsolete now guide", but then at the bottom it says "make -j`nproc` bindeb-pkg". I specifically missed that because first line conveys the message "stop reading this doc now, it's an obsolete waste of time". > It does generate some extra packages (linux-headers and linux-libc-dev) > but that doesn't take very long. The generated packages don't support > /etc/kernel-img.conf but they do support hooks in /etc/kernel. > Should users who track a 4.19.x-based branch use buster's linux-libc-dev headers, or install the ones that correspond to their custom kernel? > > 13.018+nmu1 on buster works like it always has for me--flawlessly. I > > built upstream vanilla 4.19.31 two days ago. > > Bug #890817 also looks like it may be a big problem for current kernel > versions, but apparently you have avoided it. > For once, yes :-) Generally I'm unlucky and hit all the bugs haha. Thanks again for taking the time to reply, I appreciate it! Also, thank you for your hard work, and for all time spent on the BTS. Cheers, Nicholas signature.asc Description: PGP signature
Bug#926618: RFP: webext-plasma-integration -- provides integration of web browsers with the Plasma desktop
Hi Scarlett, On Sun, Apr 07, 2019 at 06:59:10PM -0400, John Scott wrote: > Package: wnpp > Severity: wishlist > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name: webext-plasma-integration > Version : 1.4 > Upstream Author : Kai Uwe Broulik > * URL : https://community.kde.org/Plasma/Browser_Integration > * License : GPL 3 > Programming Lang: HTML + JavaScript > Description : provides integration of web browsers with the Plasma > desktop > > Plasma Browser Integration is an extension for common browsers > to closer fit into the Plasma shell. This includes: > * Media Controls > * Send links via KDE Connect > * Show downloads in and control them from Plasma’s notification area > * Find browser tabs in the Run Command (Alt-Space) window > > I think it would be handy to have this extension packaged > for a couple of reasons. > > * dependency management > plasma-integration is useful if and only if the extension > is actually used, so installing the Web Extension package > would let one mark the former as automatically installed > and forget about it. > > * Suggests: or Enhances: for easier discovery > I was delighted to have found the extension after several > weeks of using KDE Connect, and hope that no one misses > out on it for not being aware. > > Thank you, IIRC you were working on this or something similar? Cheers, Nicholas signature.asc Description: PGP signature
Bug#926622: unblock: zulucrypt/5.4.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package zulucrypt
This debian release fixes the bug #922038. This bug affect the working of
zulucrypt-cli and zulumount-cli. Because of ordering the linker flags
the linker doesn't consider the functions used in zuluplay-static when
determining that libgcrypt is not used and thus need not be linked
against.
This upload implements the patch to solve this.
(include/attach the debdiff against the package in testing)
unblock zulucrypt/5.4.0-3
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C), LANGUAGE=pt_BR.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru zulucrypt-5.4.0/debian/changelog zulucrypt-5.4.0/debian/changelog
--- zulucrypt-5.4.0/debian/changelog2018-01-28 15:32:27.0 -0200
+++ zulucrypt-5.4.0/debian/changelog2019-02-18 21:11:00.0 -0300
@@ -1,3 +1,20 @@
+zulucrypt (5.4.0-3) unstable; urgency=medium
+
+ * New debian release.
+ * Created the directory debian/upstream.
+ * debian/control:
+ - Bumped Standards-Version to 4.3.0.
+ - Updated the Maintainer e-mail.
+ - Updated the Vcs-Git field.
+ - Updated the Vcs-Browser field.
+ * debian/patches:
+ - Created the patch linker-flags-ordering.patch.(Closes: #922038)
+Thanks Ahzod, Luca and Peter Ziegler.
+ * debian/upstream:
+ - Created the metadata file.
+
+ -- Marcio de Souza Oliveira Tue, 19 Feb 2019
00:11:00 +
+
zulucrypt (5.4.0-2) unstable; urgency=medium
* Upload to unstable.
diff -Nru zulucrypt-5.4.0/debian/control zulucrypt-5.4.0/debian/control
--- zulucrypt-5.4.0/debian/control 2018-01-28 15:32:27.0 -0200
+++ zulucrypt-5.4.0/debian/control 2019-02-18 21:11:00.0 -0300
@@ -1,7 +1,7 @@
Source: zulucrypt
Section: utils
Priority: optional
-Maintainer: Marcio de Souza Oliveira
+Maintainer: Marcio de Souza Oliveira
Build-Depends: debhelper (>= 10),
libcryptsetup-dev,
libpwquality-dev,
@@ -18,10 +18,10 @@
chrpath,
cmake,
bzip2
-Standards-Version: 4.1.3
+Standards-Version: 4.3.0
Homepage: http://mhogomchungu.github.io/zuluCrypt
-Vcs-Git: https://github.com/marciosouza20/zulucrypt.git
-Vcs-Browser: https://github.com/marciosouza20/zulucrypt.git
+Vcs-Git: https://salsa.debian.org/debian/zulucrypt.git
+Vcs-Browser: https://salsa.debian.org/debian/zulucrypt
Package: zulucrypt-cli
Architecture: any
diff -Nru zulucrypt-5.4.0/debian/patches/fix_spelling
zulucrypt-5.4.0/debian/patches/fix_spelling
--- zulucrypt-5.4.0/debian/patches/fix_spelling 2017-04-13 12:48:14.0
-0300
+++ zulucrypt-5.4.0/debian/patches/fix_spelling 2019-02-18 21:11:00.0
-0300
@@ -2,11 +2,11 @@
Author: Marcio de Souza Oliveira
Last-Update: 2017-04-13
-Index: zulucrypt-5.1.0/zuluCrypt-cli/bin/main.c
+Index: zulucrypt-5.4.0/zuluCrypt-cli/bin/main.c
===
zulucrypt-5.1.0.orig/zuluCrypt-cli/bin/main.c
-+++ zulucrypt-5.1.0/zuluCrypt-cli/bin/main.c
-@@ -626,7 +626,7 @@ int main( int argc,char * argv[] )
+--- zulucrypt-5.4.0.orig/zuluCrypt-cli/bin/main.c
zulucrypt-5.4.0/zuluCrypt-cli/bin/main.c
+@@ -648,7 +648,7 @@ int main( int argc,char * argv[] )
switch( zuluCryptGetDeviceFileProperties(
deviceuid ) ){
case 0 : break ;
@@ -15,10 +15,10 @@
case 2 : return zuluExit( 112,stl,stx,env,gettext(
"ERROR: Given path is a directory" ) ) ;
case 3 : return zuluExit( 113,stl,stx,env,gettext(
"ERROR: A file can have only one hard link" ) ) ;
case 4 : return zuluExit( 113,stl,stx,env,gettext(
"ERROR: Insufficient privilges to access the device" ) ) ;
-Index: zulucrypt-5.1.0/zuluMount-cli/main.c
+Index: zulucrypt-5.4.0/zuluMount-cli/main.c
===
zulucrypt-5.1.0.orig/zuluMount-cli/main.c
-+++ zulucrypt-5.1.0/zuluMount-cli/main.c
+--- zulucrypt-5.4.0.orig/zuluMount-cli/main.c
zulucrypt-5.4.0/zuluMount-cli/main.c
@@ -463,7 +463,7 @@ Possible reasons for getting the error a
close( fd ) ;
}
@@ -28,11 +28,11 @@
case 2 : printf( gettext( "ERROR: Given path is a directory\n"
) ) ;return 221 ;
case 3 : printf( gettext( "ERROR: A file can have only one hard
link\n" ) ) ; return 222 ;
case 4
Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt
On Mon, 8 Apr 2019 at 02:07, wrote: > > Would you be able to check if this also affects fwupd? The fwupdate binary > was also merged into that project a while back and I would suspect it's > affecting both. > I've had a report that Fedora's version of the fwupdmgr .efi helper is broken, but looking at the binary [0], it appears to be a different problem. PE header starts at 0x40 'PE' 0040 50 45 00 00 64 aa 02 00 00 00 00 00 00 00 00 00 0050 01 00 00 00 a0 00 06 02 0b 02 02 14 00 a0 00 00 0060 00 1c 00 00 00 00 00 00 00 10 00 00 00 10 00 00 0070 00 00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 The section alignment and file alignment are at offsets 0x78 and 0x7c, respectively, so 0x1000 and 0x200 which looks fine. 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090 00 cc 00 00 00 10 00 00 00 00 00 00 0a 00 00 00 Total file size at 0x90, which is 0xcc00 00f0 00 00 00 00 00 00 00 00 2e 74 65 78 74 00 00 00 |.text...| 0100 00 a0 00 00 00 10 00 00 00 a0 00 00 00 10 00 00 || Size and offset of .text section at 0x100 and 0x104: 0xa000 bytes @ 0x1000 0120 2e 64 61 74 61 00 00 00 00 1c 00 00 00 b0 00 00 |.data...| Size and offset of .data section at 0x128 and 0x12c: 0x1c00 bytes @ 0xb000, which brings the total file size to 0xcc00 just like in the main header. [0] http://people.linaro.org/~ard.biesheuvel/fwupdaa64.efi-f29 > -Original Message- > From: Ard Biesheuvel > Sent: Sunday, April 7, 2019 10:46 PM > To: Debian Bug Tracking System > Subject: Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt > > > [EXTERNAL EMAIL] > > Package: fwupdate > Version: 12-4 > Severity: important > > Dear Maintainer, > > Version 12-4 of fwupdate is broken for arm64. The included binary > fwupaa64.efi is corrupt, resulting in EFI_LOAD_ERROR to be returned by the > firmware when trying to invoke it. > > The binary layout looks like this: > > Detected 'AArch64' type PE/COFF image consisting of 2 sections Section > alignment: 0x1000 File alignment: 0x200 Image size: 0xd890 Section '.text' @ > 0x1000 File offset: 0x1000 Virtual size: 0xac20 Raw size: 0xac20 Section > '.data' @ 0xbc20 File offset: 0xbc20 Virtual size: 0x1d70 Raw size: 0x1d70 > > Note that file offset + size of section #2 exceeds the total image size. But > the file offset of that section is not even a multiple of the file alignment, > so the whole image seems pretty broken. > > > > -- System Information: > Debian Release: 9.8 > APT prefers stable > APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') > Architecture: arm64 (aarch64) > > Kernel: Linux 5.1.0-rc2+ (SMP w/24 CPU cores; PREEMPT) > 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 fwupdate depends on: > ii e2fsprogs1.43.4-2 > ii efibootmgr 14-2 > ii libc62.28-8 > ii libefiboot1 37-2 > ii libefivar1 37-2 > ii libfwup1 12-4 > ii libpopt0 1.16-10+b2 > > Versions of packages fwupdate recommends: > ii fwupdate-arm64-signed [fwupdate-signed] 12+4 > > fwupdate suggests no packages. > > -- no debconf information >
Bug#926621: ITP: ruby-strptime -- fast strptime/strftime engine
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: ruby-strptime Version : 0.2.3 Upstream Author : NARUSE, Yui * URL : https://github.com/nurse/strptime * License : BSD-2-Clause Programming Lang: C, Ruby Description : fast strptime/strftime engine fluentd depends on it
Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt
Would you be able to check if this also affects fwupd? The fwupdate binary was also merged into that project a while back and I would suspect it's affecting both. -Original Message- From: Ard Biesheuvel Sent: Sunday, April 7, 2019 10:46 PM To: Debian Bug Tracking System Subject: Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt [EXTERNAL EMAIL] Package: fwupdate Version: 12-4 Severity: important Dear Maintainer, Version 12-4 of fwupdate is broken for arm64. The included binary fwupaa64.efi is corrupt, resulting in EFI_LOAD_ERROR to be returned by the firmware when trying to invoke it. The binary layout looks like this: Detected 'AArch64' type PE/COFF image consisting of 2 sections Section alignment: 0x1000 File alignment: 0x200 Image size: 0xd890 Section '.text' @ 0x1000 File offset: 0x1000 Virtual size: 0xac20 Raw size: 0xac20 Section '.data' @ 0xbc20 File offset: 0xbc20 Virtual size: 0x1d70 Raw size: 0x1d70 Note that file offset + size of section #2 exceeds the total image size. But the file offset of that section is not even a multiple of the file alignment, so the whole image seems pretty broken. -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.1.0-rc2+ (SMP w/24 CPU cores; PREEMPT) 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 fwupdate depends on: ii e2fsprogs1.43.4-2 ii efibootmgr 14-2 ii libc62.28-8 ii libefiboot1 37-2 ii libefivar1 37-2 ii libfwup1 12-4 ii libpopt0 1.16-10+b2 Versions of packages fwupdate recommends: ii fwupdate-arm64-signed [fwupdate-signed] 12+4 fwupdate suggests no packages. -- no debconf information
Bug#925785: neovim: ftbfs with GCC-9
Control: tag -1 + upstream fixed-upstream
On Wed, Mar 27, 2019 at 07:47:15PM +, Matthias Klose wrote:
> From test_mksession.vim:
> Found errors in Test_mksession_arglist():
> Caught exception in Test_mksession_arglist(): Vim(set):E539: Illegal
> character : shortmess=aoO @
> /<>/src/nvim/testdir/Xtest_mks.out, line 8
> Found errors in Test_mksession_winheight():
> Caught exception in Test_mksession_winheight(): Vim(set):E539: Illegal
> character : shortmess=aoO @
> /<>/src/nvim/testdir/Xtest_mks.out, line 8
This ended up being due to the new compound literal lifetime changes --
https://gcc.gnu.org/gcc-9/porting_to.html#complit.
The code in question is something close to:
unsigned char *varp;
unsigned char *p;
if (varp == _shm) {
p = (unsigned char *)((unsigned char[]){ 'a', 'b', 'c' });
}
...
// iterate over p
It would have been helpful in diagnosing this if gcc had warned about
using a pointer to an object outside of its scope.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
signature.asc
Description: PGP signature
Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused
On Sun, 07 Apr 2019 at 20:56:41 +0200, gregor herrmann wrote: > Alright, after purging libssl1.0.2 (and the outdated packages which > depended on it *cough*) I get the hang as well: > […] > Thanks for the push in the right direction! You're welcome :-) Does clearing the SSL_MODE_AUTO_RETRY context flag (i.e., reverting the default from OpenSSL <1.1.1) solves this for you too? If so, what do you think about my proposed paths forwards from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914034#71 If there is consensus that libssl's SSL_CTRL_CLEAR_MODE and/or SSL_CTX_clear_mode should be exposed to Net::SSLeay I'd be happy to propose a patch there. That leaves the question about which defaults context flags should IO::Socket::SSL (or LWP) have, though. -- Guilhem. signature.asc Description: PGP signature
Bug#926603: Debian fails to start after installation into Virtualbox
Control: tags -1 moreinfo Am 07.04.19 um 18:51 schrieb Andy Ruddock: > Package: systemd > Severity: critical > > I'm running Windows 10 (Home edition - up to date) on the desktop, with > Virtualbox (v6.0.4). > I've used both the netinst CD & the testing DVD (downloaded today - > 07/Apr/2019) to install Buster. > After installation the system fails to start with many errors. > The first is : > > systemd[1]: user.slice: Failed to set inovcation ID for unit: File > exists > [FAILED]: Failed to start User and Session Slice. > > other services then fail to start : > > [FAILED] Failed to start Slices. > [FAILED] Failed to listen on udev Kernel Socket. > [FAILED] Failed to start Remote File Systems. > [FAILED] Failed to listen on Syslog Socket. > > and many more, followed by > > systemd[1]: Timed out waiting for device /dev/disk/by-uuid/2cb > > finally > > [FAILED] Failed to start Network. > > At which point there is no more, the system just halts. > > Starting with "quiet" removed from linux invocation in grub, I see > > systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX > +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS > +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 > default-hierarchy=hybrid) > systemd[1]: Detected virtualization oracle. > systemd[1]: Detected architecture x86-64. > > Welcome to Debian GNU/Linux buser/sid! Please follow the instructions at https://freedesktop.org/wiki/Software/systemd/Debugging/ and get us a verbose debug log from the complete boot. Please also attach the output of "reportbug --template systemd" on the affected system. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#926620: debsums: [INTL:pt] Update on Portuguese translation of manpage
Package: debsumsr Version: 2.2.3 3ags: l10n, patch- Severity: wishlist Updated Portuguese translation for debsums's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro debsums_2.2.3_pt.po.gz Description: application/gzip
Bug#926306: RFS: socklog/2.1.0-9
On Sat, Apr 06, 2019 at 07:13:56PM +, Dmitry Bogatov wrote: > > [2019-04-04 13:30] Mathieu Mirmont > > > * I know, it is pain, but there should be init.d script. You may want to > > > take a look at bcron=0.11-8. > > > > Sure, no worries. How about systemd service files? It makes little sense > > to run socklog along with systemd I think, but for the principle it may > > be required to profile service files. What do you think? > > Up to you. Presence of systemd unit files is not mandated by Policy, > unlike init.d scripts. Done, the init scripts call daemon(1) and runsv(1) and they work pretty nicely. > > > I believe there should be separate sysuser for socklog-* services. > > > Ideally, separate sysuser for /every/ from socklog-* service, but I do > > > not know, whehter it is possible. > > > > Yeah good point. I tend to think that a single user for all socklog-* > > services would be enough, but if you prefer I can add one user per > > service. > > Yes, I'd prefer as much separation, as possible. Done, one user per service. > > Thanks for the review! > > My pleasure. By the way, you seems to forgot to add changelog entry > about new maintainer. Something in lines: > > * Set myself as maintainer (Closes: #) I had this line but somehow I messed up and accidentally squashed two commits so the line disappeared (I use gbp dch to generate the changelog). I've put it back. There is one more issue that I noticed this weekend: the orig.tar.gz file that is registered in debian archives is not the same as the upstream tarball. It is in fact a tarball of the upstream tarball (!). I don't know why it's done this way, and it pretty much breaks breaks source format 3.0 (quilt) because I can't get dpkg-source to unpack the tarball before applying the patches. Do you know how to deal with that? -- Mathieu Mirmont signature.asc Description: PGP signature
Bug#926619: deborphan: [INTL:pt] Update on Portuguese translation of manpage
Package: deborphan Version: 1.7.31 3ags: l10n, patch- Severity: wishlist Updated Portuguese translation for deborphan's manpage Translator: Américo Monteiro Feel free to use it. For translation updates please contact 'Last Translator' -- Melhores cumprimentos/Best regards, Américo Monteiro deborphan_1.7.31_pt.po.gz Description: application/gzip
Bug#926618: RFP: webext-plasma-integration -- provides integration of web browsers with the Plasma desktop
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: webext-plasma-integration Version : 1.4 Upstream Author : Kai Uwe Broulik * URL : https://community.kde.org/Plasma/Browser_Integration * License : GPL 3 Programming Lang: HTML + JavaScript Description : provides integration of web browsers with the Plasma desktop Plasma Browser Integration is an extension for common browsers to closer fit into the Plasma shell. This includes: * Media Controls * Send links via KDE Connect * Show downloads in and control them from Plasma’s notification area * Find browser tabs in the Run Command (Alt-Space) window I think it would be handy to have this extension packaged for a couple of reasons. * dependency management plasma-integration is useful if and only if the extension is actually used, so installing the Web Extension package would let one mark the former as automatically installed and forget about it. * Suggests: or Enhances: for easier discovery I was delighted to have found the extension after several weeks of using KDE Connect, and hope that no one misses out on it for not being aware. Thank you, -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEAXEkn09uX7g8Tv8W3qerYfa4vJcFAlyqgLkACgkQ3qerYfa4 vJdc2wgAo1yPuGzVMMgMF4oeA21e2QG6c3+WJbZOzg3bjrZYOt2O5nWLSfCdmO4u rkNbo2Ay6TS4QQUAFhLXkkX8v8nQQBxo+MyBT7djPp8CNFf/zosc4kIPm2sHN8jf k09gTlvhI1bv+RiN+OgR/JzwCrIyHMjlVyy04F/ioXKBszMWlzj1c6eU3bTMv2gh SaLOdsPaVMJlPiIZbi+DVww/m93uXjNDOCBqElrYsmrsYXHk0AfBvM3vj+2X0vWp T9GcrmPudG8WNHfiYU1pIzJjMPSbcqVOVv0tnxACp0ijbQgvYO5o83L5OaQ2jRuO hhlMFEnWHkBMgQgg13WPHU0hSaEEbQ== =3uw6 -END PGP SIGNATURE-
Bug#926617: plasma-pa: Speakers test doesn't work if libcanberra-pulse is not installed
Package: plasma-pa Version: 4:5.14.5-1 Severity: normal The speakers test functionality in the settings of the plasmoid didn't work for me. When I tried to use it, I saw the following in the console: ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM 2 ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM 2 ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM 2 After studying the code, I noticed that test sounds are being played with libcanberra, and the device ID is backend-specific there. It seems that the numeric IDs are used by Pulseaudio backend, not ALSA. So, I installed the Pulseaudio backend: $ sudo apt install libcanberra-pulse This fixed the bug for me. So, please add libcanberra-pulse to Recommends of plasma-pa. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-pa depends on: ii libc62.28-8 ii libcanberra0 0.30-7 ii libkf5coreaddons55.54.0-1 ii libkf5globalaccel-bin5.54.0-1 ii libkf5globalaccel5 5.54.0-1 ii libkf5i18n5 5.54.0-1 ii libkf5quickaddons5 5.54.0-1 ii libpulse-mainloop-glib0 12.2-4 ii libpulse012.2-4 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5dbus5 5.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5qml5 5.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5widgets5 5.11.3+dfsg1-1 ii libstdc++6 8.3.0-5 ii plasma-framework 5.54.0-1 ii pulseaudio 12.2-4 ii qml-module-org-kde-draganddrop 5.54.0-1 ii qml-module-org-kde-kquickcontrolsaddons 5.54.0-1 ii qml-module-qtquick-controls 5.11.3-2 ii qml-module-qtquick-layouts 5.11.3-4 ii qml-module-qtquick2 5.11.3-4 plasma-pa recommends no packages. plasma-pa suggests no packages. -- no debconf information
Bug#926616: CVE-2018-3750: Prototype Pollution
Package: node-deep-extend Version: 0.4.1-1 Severity: important Dear Maintainer, As per the ubuntu bug report: from https://snyk.io/vuln/npm:deep-extend:20180409 : deep-extend "all the listed modules can be tricked into modifying the prototype of "Object" when the attacker control part of the structure passed to these function." This is verifiably true on at least buster, given the PoC listed in the above URL, but since it's the same deep-extend in sid, it's probably the same there. The following commit apparently fixes this: (though I haven't verified that) https://github.com/unclechu/node-deep-extend/commit/433ee51ed606f4e1867ece57b6ff5a47bebb492f -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages node-deep-extend depends on: ii nodejs 10.15.2~dfsg-1 node-deep-extend recommends no packages. node-deep-extend suggests no packages. -- debconf-show failed
Bug#925185: unblock pre-approval: sysstat/12.0.3-1 (actually 12.0.3-2)
Control: tags -1 -moreinfo Control: retitle -1 unblock sysstat/12.0.3-2 Hi, >> [...] > Please go ahead with 12.0.3-1 for buster and remove the moreinfo tag > when it is ready for unblocks. > Thanks. I uploaded 12.0.3-2 to unstable yesterday. Could you please unblock it? Comparing to 12.0.3-1, it only introduces a new changelog entry, and a fix for the typo you've found: -- sysstat-12.0.3/debian/changelog 2019-03-17 23:09:46.0 +0100 +++ sysstat-12.0.3/debian/changelog 2019-04-06 09:18:26.0 +0200 @@ -1,3 +1,9 @@ +sysstat (12.0.3-2) unstable; urgency=medium + + * Upload to unstable. + + -- Robert Luberda Sat, 06 Apr 2019 09:18:26 +0200 + sysstat (12.0.3-1) experimental; urgency=medium * New upstream stable version: @@ -11,7 +17,7 @@ marker into statistics file on systems on which systemd is not used. Thanks to Georgios Zarkadas for noticing this (closes: #924864). * debian/rules: replace deprecated dh_systemd_start by dh_installsystemd, -as suggested by lintian; the former command wass ignored by debhelper v11, +as suggested by lintian; the former command was ignored by debhelper v11, what in turn resulted in the `--no-start' option being ignored, and the restart markers were incorrectly added during package upgrades. Regards, robert
Bug#926408: Scrolling makes kdiff3 crash
Control: tags 926408 + upstream patch Control: tags 926408 - moreinfo unreproducible Dear Maintainer, Hello Gudjon, I forgot to mention that this little "save" button should be on the developers information tab of DrKonqi. Then you should not need to do something in gdb manually. However, I overlooked initially the subject of your submitting email completely - so I was now able to reproduce. In KDiff3App::scrollDiffTextWindow is m_pDiffVScrollBar unconditionally accessed when it currently contains a null pointer. Attached patch simply avoids that and does not crash anymore. Could not find an upstream issue about this. Kind regards, Bernhard Thread 1 (Thread 0x7f50273cd800 (LWP 18204)): [KCrash Handler] #6 QAbstractSlider::value (this=this@entry=0x0) at widgets/qabstractslider.cpp:526 #7 0x5649e94cba8a in KDiff3App::scrollDiffTextWindow (this=0x5649e9fe1920, deltaX=0, deltaY=-810) at ./src/pdiff.cpp:490 #8 0x7f502c001588 in QWidget::event (this=0x5649e9fe1920, event=0x7ffe9592cdc0) at kernel/qwidget.cpp:8925 #9 0x7f502bfc34b1 in QApplicationPrivate::notify_helper (this=this@entry=0x5649e9b0e040, receiver=receiver@entry=0x5649e9fe1920, e=e@entry=0x7ffe9592cdc0) at kernel/qapplication.cpp:3726 #10 0x7f502bfcc69f in QApplication::notify (this=, receiver=0x5649e9daf590, e=0x7ffe9592d2d0) at kernel/qapplication.cpp:3294 #11 0x7f502b6485a9 in QCoreApplication::notifyInternal2 (receiver=0x5649e9daf590, event=0x7ffe9592d2d0) at ../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307 #12 0x7f502c001588 in QWidget::event (this=this@entry=0x5649e9d0ada0, event=event@entry=0x7ffe9592d2d0) at kernel/qwidget.cpp:8925 #13 0x7f502c0a4d1e in QFrame::event (this=0x5649e9d0ada0, e=0x7ffe9592d2d0) at widgets/qframe.cpp:550 #14 0x7f502c2161bb in QAbstractItemView::viewportEvent (this=this@entry=0x5649e9d0ada0, event=event@entry=0x7ffe9592d2d0) at itemviews/qabstractitemview.cpp:1750 #15 0x7f502c27e40b in QTreeView::viewportEvent (this=0x5649e9d0ada0, event=0x7ffe9592d2d0) at itemviews/qtreeview.cpp:1326 #16 0x7f502b6482bb in QCoreApplicationPrivate::sendThroughObjectEventFilters (event=, receiver=) at kernel/qcoreapplication.cpp:1173 #17 QCoreApplicationPrivate::sendThroughObjectEventFilters (receiver=receiver@entry=0x5649e9bdc320, event=event@entry=0x7ffe9592d2d0) at kernel/qcoreapplication.cpp:1162 #18 0x7f502bfc34a1 in QApplicationPrivate::notify_helper (this=this@entry=0x5649e9b0e040, receiver=receiver@entry=0x5649e9bdc320, e=e@entry=0x7ffe9592d2d0) at kernel/qapplication.cpp:3722 #19 0x7f502bfcc69f in QApplication::notify (this=, receiver=0x5649e9bdc320, e=0x7ffe9592d450) at kernel/qapplication.cpp:3294 #20 0x7f502b6485a9 in QCoreApplication::notifyInternal2 (receiver=0x5649e9bdc320, event=0x7ffe9592d450) at ../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307 #21 0x7f502c01d56c in QWidgetWindow::handleWheelEvent (this=this@entry=0x5649e9b53200, event=event@entry=0x7ffe9592d7a0) at kernel/qwidgetwindow.cpp:844 #22 0x7f502c01ebf3 in QWidgetWindow::event (event=0x7ffe9592d7a0, this=0x5649e9b53200) at kernel/qwidgetwindow.cpp:308 #23 QWidgetWindow::event (this=0x5649e9b53200, event=0x7ffe9592d7a0) at kernel/qwidgetwindow.cpp:224 #24 0x7f502bfc34b1 in QApplicationPrivate::notify_helper (this=this@entry=0x5649e9b0e040, receiver=receiver@entry=0x5649e9b53200, e=e@entry=0x7ffe9592d7a0) at kernel/qapplication.cpp:3726 #25 0x7f502bfca950 in QApplication::notify (this=0x7ffe9592dad0, receiver=0x5649e9b53200, e=0x7ffe9592d7a0) at kernel/qapplication.cpp:3485 #26 0x7f502b6485a9 in QCoreApplication::notifyInternal2 (receiver=receiver@entry=0x5649e9b53200, event=event@entry=0x7ffe9592d7a0) at ../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307 #27 0x7f502b9f031c in QCoreApplication::sendSpontaneousEvent (event=0x7ffe9592d7a0, receiver=0x5649e9b53200) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:237 #28 QGuiApplicationPrivate::processWheelEvent (e=0x7f5020007500) at kernel/qguiapplication.cpp:2160 #29 0x7f502b9f5e15 in QGuiApplicationPrivate::processWindowSystemEvent (e=e@entry=0x7f5020007500) at kernel/qguiapplication.cpp:1820 #30 0x7f502b9d006b in QWindowSystemInterface::sendWindowSystemEvents (flags=...) at kernel/qwindowsysteminterface.cpp:1032 #31 0x7f50270303eb in QPAEventDispatcherGlib::processEvents (this=0x5649e9b51e40, flags=...) at qeventdispatcher_glib.cpp:70 #32 0x7f502b64727b in QEventLoop::exec (this=this@entry=0x7ffe9592d980, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:140 #33 0x7f502b64f262 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:120 #34 0x5649e94a5932 in main (argc=, argv=) at ./src/main.cpp:177 [Inferior 1 (process 18204) detached]
Bug#926615: bug#314: Acknowledgement (gpsd: ..2'nd roll over bug: gpsd "clock is 56 years wrong", like "1963-07-18T08:57:40.584Z")
..upstream bug reports: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926615 https://savannah.nongnu.org/bugs/index.php?56094 ..our bug report: https://bugs.devuan.org//cgi/bugreport.cgi?bug=314 -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case.
Bug#926615: gpsd: ..2'nd roll over bug: gpsd "clock is 56 years wrong", like "1963-07-18T08:57:40.584Z"
Package: gpsd Version: 3.16-4 Severity: important ..upstream bug. Hi, ..reportbug reports our (Devuan) BTS is down, bug report on gpsd: Content-Type : text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Arnt To: Devuan Bug Tracking System Subject: gpsd: ..2'nd roll over bug: gpsd clock is 56 years wrong, "1963-07-18T08:57:40.584Z" Message-ID: <155465156363.24771.3526445890355259661.reportbug@sda3> X-Mailer: reportbug 7.1.6+devuan2.1 Date: Sun, 07 Apr 2019 17:39:23 +0200 X-Debbugs-Cc: a...@iaksess.no Package: gpsd Version: 3.16-4 Severity: important ..upstream bug. Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? ..according to http://catb.org/gpsd/NMEA.html#_dates_and_times : GPS date and time are subject to a rollover problem in the 10-bit week number counter, which will re-zero every 1024 weeks (roughly every 19.6 years). The last rollover (and the first since GPS went live in 1980) was in Aug-1999; the next will fall in Apr-2019. ..checks out rather well: arnt@sda3:~$ date --date='1024 weeks ago' Sun Aug 22 18:23:04 CEST 1999 arnt@sda3:~$ date --date='2048 weeks ago' Sun Jan 6 17:23:36 CET 1980 arnt@sda3:~$ date --date='TZ=UTC 2048 weeks ago' date: invalid date ‘TZ=UTC 2048 weeks ago’ arnt@sda3:~$ date --date='TZ="UTC" 2048 weeks ago' Sun Jan 6 19:25:50 CET 1980 arnt@sda3:~$ http://www.leapsecond.com/java/gpsclock.htm http://www.leapsecond.com/java/cal.htm ..fix suggestions: hard code third 10bit era and/or move to the new 13bit "CNAV" data format pointed to above. ..this patch hard codes third 10bit era as suggested in gpsd-3.1x's timebase.c: arnt@nb6:~$ diff -u timebase.h-3.16 timebase.h-new --- timebase.h-3.16 2016-01-08 20:30:27.0 +0100 +++ timebase.h-new 2019-04-07 20:11:52.903644739 +0200 @@ -1,9 +1,9 @@ /* * Constants used for GPS time detection and rollover correction. * - * Correct for week beginning 2016-01-07T00:00:00 + * Correct for week beginning 2019-04-07T02:00:00 UTC */ #define BUILD_CENTURY 2000 -#define BUILD_WEEK 854# Assumes 10-bit week counter -#define BUILD_LEAPSECONDS 17 -#define BUILD_ROLLOVERS1 # Assumes 10-bit week counter +#define BUILD_WEEK 1 # Assumes 10-bit week counter +#define BUILD_LEAPSECONDS 19 +#define BUILD_ROLLOVERS2 # Assumes 10-bit week counter ..and ditto for gpsd-3.17: arnt@nb6:~$ diff -u timebase.h-3.17 timebase.h-new --- timebase.h-3.17 2017-09-07 13:53:40.0 +0200 +++ timebase.h-new 2019-04-07 20:11:52.903644739 +0200 @@ -1,9 +1,9 @@ /* * Constants used for GPS time detection and rollover correction. * - * Correct for week beginning 2017-09-07T00:00:00 + * Correct for week beginning 2019-04-07T02:00:00 UTC */ #define BUILD_CENTURY 2000 -#define BUILD_WEEK 941 # Assumes 10-bit week counter +#define BUILD_WEEK 1 # Assumes 10-bit week counter #define BUILD_LEAPSECONDS 19 -#define BUILD_ROLLOVERS1 # Assumes 10-bit week counter +#define BUILD_ROLLOVERS2 # Assumes 10-bit week counter ..this patch hard codes third 10bit era as suggested in gpsd-3.11's timebase.c: arnt@sda3:~$ diff -u timebase.h* --- timebase.h-3.11 2019-04-07 19:19:42.442197516 +0200 +++ timebase.h-ny 2019-04-07 19:18:28.572535352 +0200 @@ -1,8 +1,8 @@ /* * Constants used for GPS time detection and rollover correction. * - * Correct for week beginning 2014-08-21T00:00:00 + * Correct for week beginning 2019-04-07T00:00:00 */ -#define CENTURY_BASE 201400 -#define LEAPSECOND_NOW 16 -#define GPS_WEEK_NOW 1806 +#define CENTURY_BASE 201900 +#define LEAPSECOND_NOW 19 +#define GPS_WEEK_NOW 2049 ..current timebase.h in gpsd-3.11 source: arnt@sda3:~$ cat timebase.h /* * Constants used for GPS time detection and rollover correction. * * Correct for week beginning 2014-08-21T00:00:00 */ #define CENTURY_BASE201400 #define LEAPSECOND_NOW 16 #define GPS_WEEK_NOW1806 arnt@sda3:~$ * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux 2.0 (ascii) Release:2.0 Codename: ascii Architecture: armv6l Kernel: Linux 4.19.32+ Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gpsd depends on: ii adduser 3.115 ii init-system-helpers 1.48+devuan2.0 ii libbluetooth35.43-2+deb9u1 ii libc62.24-11+deb9u4 ii libdbus-1-3 1.10.22-1+devuan2 ii libgps22
Bug#925909: [Help] Re: pbgenomicconsensus: autopkgtest regression
On Sun, Apr 07, 2019 at 02:08:54PM +0200, Liubov Chuprikova wrote: > I have just added python-pytest and one more missing library. Now the tests > should pass. Finally it passes now. Thanks a lot, Andreas. -- http://fam-tille.de
Bug#921176: redis-server service is failing to start in buster lxc container
On Sun, Apr 07, 2019 at 08:37:53PM +0200, Pierre-Elliott Bécue wrote: > Le dimanche 24 février 2019 à 15:01:14+0100, intrigeri a écrit : > > Control: reassign -1 lxc > > Control: severity -1 important > > > > Hi, > > > > Pirate Praveen: > > > In dmesg inside container (same error on the host as well), so it seems > > > apparmor is blocking it. > > > > > [14760.307180] audit: type=1400 audit(1549992481.311:156): > > > apparmor="DENIED" operation="mount" info="failed flags match" error=-13 > > > profile="lxc-container-default-cgns" name="/" pid=20531 > > > comm="(s-server)" flags="rw, rslave" > > > > The lxc-container-default-cgns profile is shipped by the lxc > > package ⇒ reassigning. > > > > This looks very much like LXC bug #916639 so please retry with: > > lxc 1:3.1.0+really3.0.3-3 or newer? > > > > If that's not sufficient, you might need to set these options for > > your container: > > > >lxc.apparmor.profile = generated > >lxc.apparmor.allow_nesting = 1 > > > > (On sid, these settings are in /etc/lxc/default.conf already but I'm > > not familiar with LXC and I don't know if they'll apply to > > pre-existing containers.) > > > > Thanks in advance! > > > > Also, I'm setting severity to non-RC as it would be unfortunate to > > block the migration to testing of… the very version that likely fixes > > this bug. Once it's clarified that this is #916639, I'll fix > > the metadata. > > > > Cheers, > > Dear Praveen, > > Did you give a test at the latest LXC3 releases? > > I wonder if I can close this bug report now. FWIW I just tested in a clean container and redis-server starts just fine. signature.asc Description: PGP signature
Bug#926613: openssh-server: Locked out of server after upgrading to buster.
Package: openssh-server Severity: serious Justification: Policy 8.2 Dear Maintainer, Due to a change in how some options are handled in sshd_config, upgrading to buster can result in the user getting locked out of their system if the config is not updated. Probably the most likely cause (and what occurred to me) is if the PubkeyAcceptedKeyTypes includes ssh-rsa and the admin logs in with an RSA key. After upgrading, the user will no longer be able to connect to the server. The solution for this case is to replace ssh-rsa with rsa-sha2-256,rsa-sha2-512. At the very least this needs to be mentioned in the upgrade instructions in the release notes for buster. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-47-generic (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8), LANGUAGE=en_GB:en (charmap=locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.6 ii libaudit1 1:2.8.4-2 ii libc6 2.28-8 ii libcom-err21.44.5-1 ii libgssapi-krb5-2 1.17-2 ii libkrb5-3 1.17-2 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libssl1.1 1.1.1b-1 ii libsystemd0241-1 pn libwrap0 ii lsb-base 10.2019031300 ii openssh-client 1:7.9p1-9 pn openssh-sftp-server pn procps pn ucf ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd 241-1 pn ncurses-term ii xauth 1:1.0.10-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw
Bug#916145: closure-compiler: Not working with recent JS code
Am 07.04.19 um 20:36 schrieb Adrian Bunk: > On Sun, Apr 07, 2019 at 11:12:30AM -0700, tony mancill wrote: >> ... >> Somewhat related, given that closure-compiler upstream releases about >> once a month on average, perhaps it is a candidate for doing Something >> Different. > > That's pretty normal for a package, and we aren't even close to the > point where this would matter: > > It is by design that stretch ships 2016 versions of packages and > buster ships 2018 versions of packages. > > But stretch and buster shipping a 2013 version of a package with more > recent versions means that even the version in stretch is 3 years > older than it could be. What tony wanted to imply is that closure-compiler requires more maintenance effort than other packages and releases more frequently which means more changes, more often, more new build-dependencies and more work. The day is only 24 hours long for all of us. The maintainer who introduced this package left the team shortly afterwards and tony just spent some of his time to keep this package in Debian (a real team effort) because it seems useful for other packages. Those who contribute nothing to the packaging work, which also means packaging new build-dependencies and making sure that r-deps continue to work, have absolutely no right to complain about how up-to-date a package is. >> Maybe a closure-compiler-installer package or something like that? >> ... > > The main user of the version currently in buster/unstable are reverse > dependencies inside Debian. And some are already blocked by the outdated > version. This is the only reason why this package is still in Debian and apparently closure-compiler seems to work for those packages, otherwise the maintainers would have noticed it, I guess? So it is still useful for its main purpose, being a build-dependency for other packages, although heavily outdated. The only positive way forward is to update this package and its reverse-dependencies. The less positive way is to remove the package from Debian. Just to be clear, personally I don't mind but the timing is bad. Maintainers of reverse-dependencies should have had a chance to contribute a fix or ensure that their packages work without closure-compiler but it looks to me it never happened. So as long as those r-deps are useful and work correctly, bug #916145 is not RC. > closure-compiler-installer would force such packages out of main. We know that. At least it would give users "something", that's the quick and dirty approach. IMO this would be the perfect fit for our "bikeshed" or the currently discussed Debian User Repository idea. However it isn't implemented yet. signature.asc Description: OpenPGP digital signature
Bug#926595: cache policy
Dear maintainers, Below is the output you required (in French). I hope I am not just making you lose time because of a bad config Regards, python3-numpy: Installé : 1:1.16.2-1 Candidat : 1:1.16.2-1 Table de version : *** 1:1.16.2-1 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status 1:1.12.1-3 500 500 http://ftp.fr.debian.org/debian stable/main amd64 Packages python3-scipy: Installé : 1.1.0-4 Candidat : 1.1.0-4 Table de version : *** 1.1.0-4 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status 0.18.1-2 500 500 http://ftp.fr.debian.org/debian stable/main amd64 Packages libblas3: Installé : 3.8.0-2 Candidat : 3.8.0-2 Table de version : *** 3.8.0-2 500 500 http://ftp.fr.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status 3.7.0-2 500 500 http://ftp.fr.debian.org/debian stable/main amd64 Packages
Bug#926612: missing hp-laserjet_200_colormfp_m276-ps.ppd
Package: hpijs-ppds Version: 3.16.11+repack0-3 Hi, I have a HP LaserJet 200 colorMFP M276n. The PPD for this printer is in the hplip source package: $ pwd /home/rjk/junk/hplip-3.16.11+repack0 $ find . -name *m276* ./prnt/ps/hp-laserjet_200_colormfp_m276-ps.ppd.gz However it is not in the binary package: $ dpkg --contents hpijs-ppds_3.16.11+repack0-3_all.deb |grep m267 $ Is there any reason for this? Please could it be added? ttfn/rjk
Bug#900912: Enabling jaw (Java-atk-wrapper) by default ? (Bug#900912)
Vincent Privat, le dim. 07 avril 2019 21:55:33 +0200, a ecrit: > Disabling it only through accessibility.properties means we have no control > over it from JOSM. So when the next bug appears, we'll have to tell all of our > impacted Ubuntu users to modify the file. We are here only talking about Buster, not Ubuntu. > It's cumbersome for us, and for them. > I would prefer a runtime flag we can set in josm launcher. I don't want to > experience major issues like [1]https://josm.openstreetmap.de/ticket/12022 > and > [2]https://josm.openstreetmap.de/ticket/1 again. AFAIK, these have been fixed, so won't appear again. Exposing jaw largely *before* deciding to enable it for Buster is precisely what could be a better option. Limited-scope testing wouldn't expose the bugs seen in JOSM. Samuel
Bug#919929: python-scipy's autopkgtests break again
Control: reopen -1 I'm seeing this failure again: https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-scipy/2213599/log.gz Helmut
Bug#926611: unblock: schema2ldif/1.3-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package schema2ldif + [ Ondřej Nový ] + * d/copyright: ++ Change Format URL to correct one Formalistic auto-commit that already was in git log for next upload. + [ Mike Gabriel ] + * debian/control: ++ Update Homepage: URL to one that resolves and exists. In fact, the homepage URL used so far is not available anymore. Replaced by an existing one. ++ Bump Standards-Version: to 4.3.0. No changes needed. Formalistic change. ++ Update Maintainer: field. Use tracker.debian.org team mail address. + (Closes: ##925526). -> RC bug fix. Previous mailing list address is not available anymore. unblock schema2ldif/1.3-3 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru schema2ldif-1.3/debian/changelog schema2ldif-1.3/debian/changelog --- schema2ldif-1.3/debian/changelog2018-06-11 15:03:44.0 +0200 +++ schema2ldif-1.3/debian/changelog2019-04-07 21:25:06.0 +0200 @@ -1,3 +1,18 @@ +schema2ldif (1.3-3) unstable; urgency=medium + + [ Ondřej Nový ] + * d/copyright: ++ Change Format URL to correct one + + [ Mike Gabriel ] + * debian/control: ++ Update Homepage: URL to one that resolves and exists. ++ Bump Standards-Version: to 4.3.0. No changes needed. ++ Update Maintainer: field. Use tracker.debian.org team mail address. + (Closes: ##925526). + + -- Mike Gabriel Sun, 07 Apr 2019 21:25:06 +0200 + schema2ldif (1.3-2) unstable; urgency=medium * debian/control: diff -Nru schema2ldif-1.3/debian/control schema2ldif-1.3/debian/control --- schema2ldif-1.3/debian/control 2018-06-11 15:03:44.0 +0200 +++ schema2ldif-1.3/debian/control 2019-04-07 21:23:53.0 +0200 @@ -1,14 +1,14 @@ Source: schema2ldif Section: text Priority: optional -Maintainer: FusionDirectory Maintenance Team +Maintainer: FusionDirectory Packagers Uploaders: Benoit Mortier , Mike Gabriel , Build-Depends: debhelper (>= 11~), -Standards-Version: 4.1.4 -Homepage: https://forge.fusiondirectory.org/projects/schema2ldif/ +Standards-Version: 4.3.0 +Homepage: https://www.fusiondirectory.org/projects/schema2ldif-project-and-components/ Vcs-Browser: https://salsa.debian.org/debian/schema2ldif Vcs-Git: https://salsa.debian.org/debian/schema2ldif.git diff -Nru schema2ldif-1.3/debian/copyright schema2ldif-1.3/debian/copyright --- schema2ldif-1.3/debian/copyright2018-06-11 15:03:44.0 +0200 +++ schema2ldif-1.3/debian/copyright2019-04-07 21:20:14.0 +0200 @@ -1,4 +1,4 @@ -Format: https://www.debian.org/doc/copyright-format/1.0 +Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: FusionDirectory Upstream-Contact: Contact Source: https://repos.fusiondirectory.org/sources/schema2ldif/
Bug#147164: ping and new proposal
Remove the outdated /doc/docpolicy. Even the "current draft of the new policy" is outdated and deprecated. Instead of a whole policy manual which is outdated for a long time my proposal is to just list a few things to consider on /doc. Currently we have these items on /doc about the policy: Manual licenses comply with DFSG. Directory structure: filesystem, WWW, FTP. We use Docbook XML for our documents. Use of DebianDoc SGML is being phased out. Every document has one maintainer. "Every document has one maintainer." seems to be not true since I found this in debian/control: Maintainer: Debian Documentation Project So just remove this item. My proposal to list these items on /doc: Manual licenses comply with DFSG We use Docbook XML for our documents The sources should be at https://salsa.debian.org/ddp-team www.debian.org/doc/ will be the official URL Please ask on debian-doc if you like to write a new document Any objections on removing /doc/docpolicy? -- regards Thomas
Bug#926610: unblock: ceph/12.2.11+dfsg1-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi release team, please unblock package ceph. I've NMUed it to add a missing systemd @.service file, which basically renedered the package unusuable (unless you'd be doing crazy stuff which is far away from the documented process of setting up a ceph cluster). Find the short diff below. unblock ceph/12.2.11+dfsg1-2.1 Thanks, Bernd bzed@think ~debian/BSP/ceph (git)-[luminous/unstable] % git diff-tree -p debian/12.2.11+dfsg1-2..debian/12.2.11+dfsg1-2.1 diff --git a/debian/changelog b/debian/changelog index 92d40bfbe4..44d4e3a672 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +ceph (12.2.11+dfsg1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * [3194010] Install ceph-volume@.service into ceph-osd. +(Closes: #924061) + + -- Bernd Zeimetz Fri, 05 Apr 2019 15:12:52 +0200 + ceph (12.2.11+dfsg1-2) unstable; urgency=medium * [27a321] Fix builds on 32bit architectures diff --git a/debian/rules b/debian/rules index d167e96e96..ae1c2270e1 100755 --- a/debian/rules +++ b/debian/rules @@ -123,8 +123,10 @@ override_dh_installinit: install -d -m0755 debian/ceph-osd/lib/systemd/system install -m0644 systemd/ceph-osd@.service debian/ceph-osd/lib/systemd/system install -m0644 systemd/ceph-disk@.service debian/ceph-osd/lib/systemd/system + install -m0644 systemd/ceph-volume@.service debian/ceph-osd/lib/systemd/system sed -i s./etc/sysconfig/./etc/default/.g debian/ceph-osd/lib/systemd/system/ceph-osd@.service sed -i s./etc/sysconfig/./etc/default/.g debian/ceph-osd/lib/systemd/system/ceph-disk@.service + sed -i s./etc/sysconfig/./etc/default/.g debian/ceph-osd/lib/systemd/system/ceph-volume@.service install -m0644 systemd/ceph-osd.target debian/ceph-osd/lib/systemd/system # systemd:ceph-mds install -d -m0755 debian/ceph-mds/lib/systemd/system bzed@think ~debian/BSP/ceph (git)-[luminous/unstable] % -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#926609: unblock: apache2/2.4.38-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package apache2, it fixes various security issues (no
other changes).
Debdiff is attached
unblock apache2/2.4.38-3
diff -Nru apache2-2.4.38/debian/changelog apache2-2.4.38/debian/changelog
--- apache2-2.4.38/debian/changelog 2019-01-31 21:54:05.0 +0100
+++ apache2-2.4.38/debian/changelog 2019-04-07 20:15:40.0 +0200
@@ -1,3 +1,40 @@
+apache2 (2.4.38-3) unstable; urgency=high
+
+ [ Marc Deslauriers ]
+ * SECURITY UPDATE: read-after-free on a string compare in mod_http2
+- debian/patches/CVE-2019-0196.patch: disentangelment of stream and
+ request method in modules/http2/h2_request.c.
+- CVE-2019-0196
+ * SECURITY UPDATE: privilege escalation from modules' scripts
+- debian/patches/CVE-2019-0211.patch: bind the bucket number of each
+ child to its slot number in include/scoreboard.h,
+ server/mpm/event/event.c, server/mpm/prefork/prefork.c,
+ server/mpm/worker/worker.c.
+- CVE-2019-0211
+ * SECURITY UPDATE: mod_ssl access control bypass
+- debian/patches/CVE-2019-0215.patch: restore SSL verify state after
+ PHA failure in TLSv1.3 in modules/ssl/ssl_engine_kernel.c.
+- CVE-2019-0215
+ * SECURITY UPDATE: mod_auth_digest access control bypass
+- debian/patches/CVE-2019-0217.patch: fix a race condition in
+ modules/aaa/mod_auth_digest.c.
+- CVE-2019-0217
+ * SECURITY UPDATE: URL normalization inconsistincy
+- debian/patches/CVE-2019-0220-1.patch: merge consecutive slashes in
+ the path in include/http_core.h, include/httpd.h, server/core.c,
+ server/request.c, server/util.c.
+- debian/patches/CVE-2019-0220-2.patch: fix r->parsed_uri.path safety
+ in server/request.c, server/util.c.
+- debian/patches/CVE-2019-0220-3.patch: maintainer mode fix in
+ server/util.c.
+- CVE-2019-0220
+
+ [ Stefan Fritsch ]
+ * Pull security fixes from 2.4.39 via Ubuntu
+ * CVE-2019-0197: mod_http2: Fix possible crash on late upgrade
+
+ -- Stefan Fritsch Sun, 07 Apr 2019 20:15:40 +0200
+
apache2 (2.4.38-2) unstable; urgency=medium
* Disable "reset" test in allowmethods.t (Closes: #921024)
diff -Nru apache2-2.4.38/debian/patches/CVE-2019-0196.patch
apache2-2.4.38/debian/patches/CVE-2019-0196.patch
--- apache2-2.4.38/debian/patches/CVE-2019-0196.patch 1970-01-01
01:00:00.0 +0100
+++ apache2-2.4.38/debian/patches/CVE-2019-0196.patch 2019-04-07
19:37:55.0 +0200
@@ -0,0 +1,27 @@
+From 8de3c6f2a0df79d1476c89ec480a96f9282cea28 Mon Sep 17 00:00:00 2001
+From: Stefan Eissing
+Date: Tue, 5 Feb 2019 11:52:28 +
+Subject: [PATCH] Merge of r1852986 from trunk:
+
+mod_http2: disentangelment of stream and request method.
+
+
+
+git-svn-id:
https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1852989
13f79535-47bb-0310-9956-ffa450edef68
+---
+ modules/http2/h2_request.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/modules/http2/h2_request.c b/modules/http2/h2_request.c
+index 8899c4feb75..5ee88e9679f 100644
+--- a/modules/http2/h2_request.c
b/modules/http2/h2_request.c
+@@ -266,7 +266,7 @@ request_rec *h2_request_create_rec(const h2_request *req,
conn_rec *c)
+
+ /* Time to populate r with the data we have. */
+ r->request_time = req->request_time;
+-r->method = req->method;
++r->method = apr_pstrdup(r->pool, req->method);
+ /* Provide quick information about the request method as soon as known */
+ r->method_number = ap_method_number_of(r->method);
+ if (r->method_number == M_GET && r->method[0] == 'H') {
diff -Nru apache2-2.4.38/debian/patches/CVE-2019-0197.patch
apache2-2.4.38/debian/patches/CVE-2019-0197.patch
--- apache2-2.4.38/debian/patches/CVE-2019-0197.patch 1970-01-01
01:00:00.0 +0100
+++ apache2-2.4.38/debian/patches/CVE-2019-0197.patch 2019-04-07
19:49:17.0 +0200
@@ -0,0 +1,93 @@
+# https://svn.apache.org/r1855406
+--- apache2.orig/modules/http2/h2_conn.c
apache2/modules/http2/h2_conn.c
+@@ -305,6 +305,10 @@ conn_rec *h2_slave_create(conn_rec *mast
+ c->notes = apr_table_make(pool, 5);
+ c->input_filters = NULL;
+ c->output_filters = NULL;
++c->keepalives = 0;
++#if AP_MODULE_MAGIC_AT_LEAST(20180903, 1)
++c->filter_conn_ctx= NULL;
++#endif
+ c->bucket_alloc = apr_bucket_alloc_create(pool);
+ c->data_in_input_filters = 0;
+ c->data_in_output_filters = 0;
+@@ -332,16 +336,15 @@ conn_rec *h2_slave_create(conn_rec *mast
+ ap_set_module_config(c->conn_config, mpm, cfg);
+ }
+
+-ap_log_cerror(APLOG_MARK, APLOG_TRACE2, 0, c,
+- "h2_stream(%ld-%d): created slave", master->id, slave_id);
++ap_log_cerror(APLOG_MARK, APLOG_TRACE3, 0, c,
++ "h2_slave(%s): created", c->log_id);
+ return c;
+ }
+
+ void
Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused
On Sun, 07 Apr 2019 18:39:44 +0200, Guilhem Moulin wrote:
> > I can't reproduce this problem:
> Interesting, are you talking TLS 1.3?
Good question :)
> $ dpkg-query -l "libssl*" "libnet-ssleay-perl" "liblwp-protocol-https-perl"
> "libio-socket-ssl-perl"
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==---=
> ii libio-socket-ssl-perl 2.060-3 all Perl module
> implementing object oriented interface to SSL sockets
> ii liblwp-protocol-https-perl 6.07-2 all HTTPS driver for
> LWP::UserAgent
> ii libnet-ssleay-perl 1.85-2+b1amd64Perl module for
> Secure Sockets Layer (SSL)
> ii libssl-dev:amd64 1.1.1b-1 amd64Secure Sockets Layer
> toolkit - development files
> un libssl-doc (no description
> available)
> un libssl0.9.8 (no description
> available)
> un libssl1.0-dev(no description
> available)
> ii libssl1.1:amd641.1.1b-1 amd64Secure Sockets Layer
> toolkit - shared libraries
% dpkg -l "libssl*" "libnet-ssleay-perl" "liblwp-protocol-https-perl"
"libio-socket-ssl-perl"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==-===--=
ii libio-socket-ssl-perl 2.060-3 all Perl module
implementing object oriented interface to SSL sockets
ii liblwp-protocol-https-perl 6.07-2 all HTTPS driver for
LWP::UserAgent
ii libnet-ssleay-perl 1.85-2+b1 amd64Perl module for
Secure Sockets Layer (SSL)
un libssl0.9.8 (no description
available)
un libssl1.0.0 (no description
available)
ii libssl1.0.2:amd64 1.0.2r-1~deb9u1 amd64Secure Sockets
Layer toolkit - shared libraries
ii libssl1.1:amd641.1.1b-1amd64Secure Sockets
Layer toolkit - shared libraries
ii libssl1.1:i386 1.1.1b-1i386 Secure Sockets
Layer toolkit - shared libraries
Hm I note that I still have libssl1.0.2 installed additionally.
Alright, after purging libssl1.0.2 (and the outdated packages which
depended on it *cough*) I get the hang as well:
% time perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
[long time nothing]
perl -MLWP::UserAgent -e 0.18s user 0.02s system 0% cpu 3:06.66 total
Thanks for the push in the right direction!
> > % time perl -MLWP::UserAgent -e
> > 'LWP::UserAgent->new->post("https://twitter.com;, { data => "foo" }) or die'
> > perl -MLWP::UserAgent -e 0.13s user 0.02s system 36% cpu 0.415 total
>
> twitter.com doesn't support TLS 1.3 though, right?
Good catch, I just wanted to try a random website which is IPv4-only.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Furry Lewis: Billy lyons & stack o' lee
signature.asc
Description: Digital Signature
Bug#926607: tracetuner FTCBFS: upstream Makefiles hard code build architecture compiler
Source: tracetuner Version: 3.0.6~beta+dfsg-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap tracetuner fails to cross build from source, because it seeds the LINK.c variable from the build architecture compiler in two occasions. Defaulting them to $(CXX) fixes the cross build failure and should be acceptable upstream. Please consider applying the attached patch. Helmut --- tracetuner-3.0.6~beta+dfsg.orig/src/mkchk/Makefile +++ tracetuner-3.0.6~beta+dfsg/src/mkchk/Makefile @@ -37,7 +37,7 @@ CFLAGS += -I$(INCTOOLSDIR)/io_lib CFLAGS += -I$(INCTOOLSDIR)/io_lib/utils $(EXTRACFLAGS) -LINK.c = g++ +LINK.c = $(CXX) $(RELDIR)/checkqv: $(CHECKQVOBJS) $(TTLIB) @mkdir -p $(RELDIR) --- tracetuner-3.0.6~beta+dfsg.orig/src/mklut/Makefile +++ tracetuner-3.0.6~beta+dfsg/src/mklut/Makefile @@ -57,7 +57,7 @@ mkdir -p $(OBJDIR) $(COMPILE.c) $< -o $@ -LINK.c = g++ +LINK.c = $(CXX) $(RELDIR)/lut: $(LUTOBJS) $(TTLIB) @mkdir -p $(RELDIR)
Bug#926606: hawknl FTCBFS: does not pass cross tools to make
Source: hawknl Version: 1.6.8+dfsg2-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap hawknl fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - makes hawknl cross buildable. Please consider applying the attached patch. Helmut diff -u hawknl-1.6.8+dfsg2/debian/changelog hawknl-1.6.8+dfsg2/debian/changelog --- hawknl-1.6.8+dfsg2/debian/changelog +++ hawknl-1.6.8+dfsg2/debian/changelog @@ -1,3 +1,10 @@ +hawknl (1.6.8+dfsg2-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Sun, 07 Apr 2019 20:38:09 +0200 + hawknl (1.6.8+dfsg2-1) unstable; urgency=low [ Barry deFreese ] diff -u hawknl-1.6.8+dfsg2/debian/rules hawknl-1.6.8+dfsg2/debian/rules --- hawknl-1.6.8+dfsg2/debian/rules +++ hawknl-1.6.8+dfsg2/debian/rules @@ -31,7 +31,7 @@ build-stamp: dh_testdir - $(MAKE) -C src -f makefile.linux + dh_auto_build --sourcedirectory=src --buildsystem=makefile -- -f makefile.linux touch build-stamp diff -u hawknl-1.6.8+dfsg2/debian/control hawknl-1.6.8+dfsg2/debian/control --- hawknl-1.6.8+dfsg2/debian/control +++ hawknl-1.6.8+dfsg2/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian Games Team Uploaders: Barry deFreese -Build-Depends: debhelper (>= 5.0.0), quilt +Build-Depends: debhelper (>= 7), quilt Standards-Version: 3.8.3 Homepage: http://hawksoft.com/hawknl/ Vcs-Git: git://git.debian.org/pkg-games/hawknl.git
Bug#926608: duktape FTCBFS: does not pass cross tools to make
Source: duktape Version: 2.3.0-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap duktape fails to cross build from source, because it does not pass cross tools to make. The easiest way of fixing that - using dh_auto_build - makes duktape cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru duktape-2.3.0/debian/changelog duktape-2.3.0/debian/changelog --- duktape-2.3.0/debian/changelog 2018-08-14 22:12:45.0 +0200 +++ duktape-2.3.0/debian/changelog 2019-04-07 20:14:24.0 +0200 @@ -1,3 +1,10 @@ +duktape (2.3.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Sun, 07 Apr 2019 20:14:24 +0200 + duktape (2.3.0-1) unstable; urgency=medium * New upstream release diff --minimal -Nru duktape-2.3.0/debian/rules duktape-2.3.0/debian/rules --- duktape-2.3.0/debian/rules 2017-11-24 18:23:21.0 +0100 +++ duktape-2.3.0/debian/rules 2019-04-07 20:14:24.0 +0200 @@ -10,8 +10,8 @@ override_dh_auto_build: mkdir -p tmp-build/lib tmp-build/include - make -f Makefile.sharedlibrary install - make -f Makefile.cmdline + dh_auto_build --buildsystem=makefile -- -f Makefile.sharedlibrary install + dh_auto_build --buildsystem=makefile -- -f Makefile.cmdline cat debian/duktape.pc.in|sed "s/#TRIPLE#/$(DEB_HOST_MULTIARCH)/g" > debian/duktape.pc dh_auto_build
Bug#926605: webissues FTCBFS: uses the build architecture qmake
Source: webissues Version: 1.1.5-3 Tags: patch User: helm...@debian.org Usertags: rebootstrap webissues fails to cross build from source, because it uses the build architecture qmake. The attached patch passes a suitable qmake via -qmake to ./configure and makes webissues cross buildable. Plase consider applying it. Helmut diff --minimal -Nru webissues-1.1.5/debian/changelog webissues-1.1.5/debian/changelog --- webissues-1.1.5/debian/changelog2018-03-15 15:39:26.0 +0100 +++ webissues-1.1.5/debian/changelog2019-04-07 20:42:30.0 +0200 @@ -1,3 +1,10 @@ +webissues (1.1.5-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Pass a triplet-prefixed qmake to configure. (Closes: #-1) + + -- Helmut Grohne Sun, 07 Apr 2019 20:42:30 +0200 + webissues (1.1.5-3) unstable; urgency=medium * Set a save URL in the homepage field. diff --minimal -Nru webissues-1.1.5/debian/rules webissues-1.1.5/debian/rules --- webissues-1.1.5/debian/rules2018-03-15 15:39:26.0 +0100 +++ webissues-1.1.5/debian/rules2019-04-07 20:42:30.0 +0200 @@ -1,13 +1,20 @@ #!/usr/bin/make -f +include /usr/share/dpkg/architecture.mk export DEB_BUILD_MAINT_OPTIONS = hardening=+all export QT_SELECT=qt5 +ifeq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) +QMAKE = qmake +else +QMAKE = $(DEB_HOST_GNU_TYPE)-qmake +endif %: dh $@ override_dh_auto_configure: ./configure \ + -qmake `which $(QMAKE)` \ -system-sqlite \ -prefix /usr \ -destdir $(CURDIR)/debian/tmp/ \
Bug#925167: kmod: add softdep dwc3 to have GBit network on Odroid
Control: reassign -1 src:linux Control: retitle -1 add a modules softdep to dwc3 to fix it on odroid On Mar 22, Jochen Sprickerhof wrote: > Not apart from that I was not aware of that option :). I've send a patch > upstream: > > https://marc.info/?l=linux-usb=155321315512949=2 > > and will close this if it's accepted. I am reassigning the bug to the kernel since this is where it should be handled anyway. -- ciao, Marco signature.asc Description: PGP signature
Bug#921176: redis-server service is failing to start in buster lxc container
Le dimanche 24 février 2019 à 15:01:14+0100, intrigeri a écrit : > Control: reassign -1 lxc > Control: severity -1 important > > Hi, > > Pirate Praveen: > > In dmesg inside container (same error on the host as well), so it seems > > apparmor is blocking it. > > > [14760.307180] audit: type=1400 audit(1549992481.311:156): > > apparmor="DENIED" operation="mount" info="failed flags match" error=-13 > > profile="lxc-container-default-cgns" name="/" pid=20531 > > comm="(s-server)" flags="rw, rslave" > > The lxc-container-default-cgns profile is shipped by the lxc > package ⇒ reassigning. > > This looks very much like LXC bug #916639 so please retry with: > lxc 1:3.1.0+really3.0.3-3 or newer? > > If that's not sufficient, you might need to set these options for > your container: > >lxc.apparmor.profile = generated >lxc.apparmor.allow_nesting = 1 > > (On sid, these settings are in /etc/lxc/default.conf already but I'm > not familiar with LXC and I don't know if they'll apply to > pre-existing containers.) > > Thanks in advance! > > Also, I'm setting severity to non-RC as it would be unfortunate to > block the migration to testing of… the very version that likely fixes > this bug. Once it's clarified that this is #916639, I'll fix > the metadata. > > Cheers, Dear Praveen, Did you give a test at the latest LXC3 releases? I wonder if I can close this bug report now. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#926062: qbitorrent crashes, blames QNetworkAccessM
This seems the same bug as https://github.com/qbittorrent/qBittorrent/issues/9667 A possible workaround is in PR: https://github.com/qbittorrent/qBittorrent/pull/10445 Or you can just disable the download of tracker favicons from the advanced settings. Out of curiosity: How many trackers do you have? (number is shown in the sidepanel) On Sat, Apr 6, 2019 at 2:12 AM Tobias Frost wrote: > Control: serverity -1 important > Control: tags -1 unreproducible moreinfo > > Hi shirish, > > I tried to reproduce your SEGV, but here qbittorrent seems to work > fine. Do you have additional informations about how to trigger the > SEGV, like what you are doing to trigger it or like? > > Cheers from the Salzburg BSP, > tobi > >
Bug#916145: closure-compiler: Not working with recent JS code
On Sun, Apr 07, 2019 at 11:12:30AM -0700, tony mancill wrote: >... > Somewhat related, given that closure-compiler upstream releases about > once a month on average, perhaps it is a candidate for doing Something > Different. That's pretty normal for a package, and we aren't even close to the point where this would matter: It is by design that stretch ships 2016 versions of packages and buster ships 2018 versions of packages. But stretch and buster shipping a 2013 version of a package with more recent versions means that even the version in stretch is 3 years older than it could be. > Maybe a closure-compiler-installer package or something like that? >... The main user of the version currently in buster/unstable are reverse dependencies inside Debian. And some are already blocked by the outdated version. closure-compiler-installer would force such packages out of main. > Cheers, > tony > (wearing a Java Team hat...) cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#925899: lxc: Unprivileged containers fail to start after recent updates
Le dimanche 31 mars 2019 à 14:55:52+0200, intrigeri a écrit : > Hi, > > Regis Smith: > >> > lxc-start: test: lsm/apparmor.c: apparmor_prepare: 974 Cannot use > > generated profile: apparmor_parser not available > > I've reproduced this problem and I could fix it with: > > lxc.apparmor.profile = unconfined > > Regis, can you please confirm this fix works for you as well? > > Pierre-Elliott Bécue: > > Cc-ing intrigeri: I'm reconsidering the /etc/lxc/default.conf setting > > regarding apparmor.profile. Putting generated breaks many unpriv > > containers as they have no apparmor.profile set in their configuration. > > Considering kernel.unprivileged_userns_clone is disabled by default > on Debian, IMO we should: > > - Optimize for the Debian defaults, i.e. privileged containers: > - Keep the settings we added recently in /etc/lxc/default.conf > - Replace "Suggests: apparmor" with "Depends: apparmor", because > the default config will create containers that fail to start > if the apparmor package is not installed. > > - Document how to use unprivileged containers on Debian. It's not as >if they were previously working fine by default and AppArmor broke >them — regardless of AppArmor, on current sid with the default >kernel settings and lxc.apparmor.profile = unconfined, trying to >start an unprivileged container fails in a very much user >unfriendly way: > > conf.c: chown_mapped_root: 3250 lxc-usernsexec failed: Permission denied > - Failed to open tt > >That's a first usability stumbling block. The new >lxc.apparmor.profile default setting merely adds a second one. > >So I think README.Debian should document the need for >kernel.unprivileged_userns_clone=1 and for >lxc.apparmor.profile = unconfined > > - Take care of the Stretch→Buster upgrade path for unprivileged >containers, by mentioning in NEWS.Debian that previously working >unprivileged containers now need lxc.apparmor.profile = unconfined. > > Thoughts? See the two latest commits for lxc: https://salsa.debian.org/lxc-team/lxc/commits/master Tell me what you think about them, and if needed don't hesitate to submit a MR! :) -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#916145: closure-compiler: Not working with recent JS code
On Sun, Apr 07, 2019 at 11:16:53AM +0300, Adrian Bunk wrote: > On Sat, Apr 06, 2019 at 06:13:05PM +0200, Chris Hofstaedtler wrote: > > * Roland Gruber [190406 16:07]: > > > the current version is so old that it got incompatible with recent JS > > > code. > > > E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors. > > > > > > Please either update the tool or remove it from the archive. This is now > > > 5 years in unmaintained state. > > > > I've checked all r-deps of closure-compiler in Debian, and they all > > build -- datatables-extensions shows some errors in a prebuilt file, > > but it has done so for a long time, so probably not super relevant. > > > > While I agree that having a 5 year old JS compiler in Debian is not > > Now over 6 years. > > > a great situation, its also not threatening to the packages in > > Debian using it, so I'd suggest keeping it for now. > > Packages that would require a non-prehistoric version of > closure-compiler are already blocked from entering Debian, > see #843951 and #727529 (since 2013!) as examples. > > Any actual user installing closure-compiler will have a WTF experience > when discovering that the new Debian release ships a version that was > already outdated when the dinosaurs roamed the earth. > > > Adrian: you raised the severity, care to lower it until buster is > > out (or say some words on why)? > > IMHO the release team adding a buster-ignore tag would be the best way > forward here - this would still show up as RC bug for bullseye. +1 for not orphaning r-build-deps at this point in the release cycle but forcing the issue at the onset of the bullseye release cycle. I'm not a user of closure-compiler but have tried to help keep the package in Debian because it appears to be useful to others. I agree that at a certain point, an old package is probably more harmful than a missing package. Packaging the transitive build-deps for closure-compiler is a non-trivial effort and one that people might easily overlook when they ask for the latest version. Since there are plenty of users who want a newer version, it shouldn't be that hard to get some help with those build-deps, right? Somewhat related, given that closure-compiler upstream releases about once a month on average, perhaps it is a candidate for doing Something Different. Maybe a closure-compiler-installer package or something like that? (Maybe backports would work, but we would have to manage the transitive dependencies as well.) Cheers, tony (wearing a Java Team hat...) signature.asc Description: PGP signature
Bug#913823: apache2: dav.load does not check for an already loaded dav_module
On Friday, 1 February 2019 03:49:22 CEST Nye Liu wrote:
> Package: apache2
> Version: 2.4.38-1
> Followup-For: Bug #913823
>
> Workaround in /etc/apache2/mods-available/dav.load:
>
>
> LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so
>
>
> Alternately just make dav_fs not depend on dav, it will autoload it.
This does not make sense. There is no functionality in mod_dav_fs that would
autoload mod_dav. The "# Depends: dav" in dav_fs.load is a hint to a2enmod to
enable dav.load, too. But this is visible by a symlink in mods-enabled. There
must be another LoadModule somewhere else in your configuration.
You should probably do
grep -R dav_module /etc/apache2/{*.conf,*-enabled}
to find it.
Bug#926212: gnome-shell crashed (segfault)
Hello Guenter Grodotzki, (I guess you wanted me to receive your last message, so you should use "reply all", or it gets just attached to your bug report.) I have left a note in this upstream report [1], lets see if they agree. Kind regards, Bernhard [1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/822#note_484642 PS.: My untested change in message 10 might not crash, but lead to an infinitive loop, as app->running_state might not change anymore...
Bug#869318: libimage-sane-perl FTBFS randomly: build hangs during tests
retitle 869318 libimage-sane-perl: FTBFS randomly: build hangs during tests tags 869318 - unreproducible thanks Greetings. I can reproduce the random nature of this bug on START1-S instances from Scaleway (amd64). The failure rate is around 25% here. I've put a bunch of build logs here: https://people.debian.org/~sanvila/build-logs/libimage-sane-perl/ (Note: Those logs use eatmydata, but I've also checked that it fails in a normal way, i.e. without eatmydata). If you need a test machine to reproduce the randomness, please contact me privately and I will gladly provide ssh access. I'm retitling the bug because it is not really architecture specific. My theory is that it's a race condition which happens easily on machines with 2 CPUs (and maybe also slower than average). Note: I know START1-S instances are discontinued but in either case the bug is in the package, not in the instances. I will try to check on the new DEV1-S instances (those also have 2 CPUs and 2 GB of RAM). Thanks.
Bug#925455: alsa volume never saved/restored
* gregor herrmann [2019-04-07 18:16 +0200]: > On Sun, 07 Apr 2019 18:05:06 +0200, Elimar Riesebieter wrote: > > > > There is a commit in the packaging repo which claims to fix this bug: > > > https://salsa.debian.org/alsa-team/alsa-utils/commit/af161676131e94bbaed72f37d0c5d4c6685a119e > > Jordi is MIA at the moment. Tried to reach him since a few days. I > > can't upload the fix myself, though... > > I pinged him on a different channel, but if he doesn't have time I'm > happy to offer a sponsored upload to fix this bug. Would be nice. Yes, please :-) -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche signature.asc Description: PGP signature
Bug#920665: xwayland: Crash with external display, notifications, and screen idle [upstream patch attached]
Hi, On Thu, Apr 04, 2019 at 04:30:31PM +0300, csaavedra...@gmail.com wrote: > I see that this landed in unstable (in the next upstream release) but > testing is still affected, as it's frozen. I installed testing in a new > machine and I have hit this crasher again. I think this should be > considered serious enough to be fixed in testing/upcoming stable. Yeah, as testing is currently frozen an unblock request is required to unblock xorg-server/2:1.20.4-1 and thus allow it to migrate to testing. I've filed such a request at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926540 Thanks, Andreas
Bug#926603: Debian fails to start after installation into Virtualbox
Package: systemd Severity: critical I'm running Windows 10 (Home edition - up to date) on the desktop, with Virtualbox (v6.0.4). I've used both the netinst CD & the testing DVD (downloaded today - 07/Apr/2019) to install Buster. After installation the system fails to start with many errors. The first is : systemd[1]: user.slice: Failed to set inovcation ID for unit: File exists [FAILED]: Failed to start User and Session Slice. other services then fail to start : [FAILED] Failed to start Slices. [FAILED] Failed to listen on udev Kernel Socket. [FAILED] Failed to start Remote File Systems. [FAILED] Failed to listen on Syslog Socket. and many more, followed by systemd[1]: Timed out waiting for device /dev/disk/by-uuid/2cb finally [FAILED] Failed to start Network. At which point there is no more, the system just halts. Starting with "quiet" removed from linux invocation in grub, I see systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) systemd[1]: Detected virtualization oracle. systemd[1]: Detected architecture x86-64. Welcome to Debian GNU/Linux buser/sid! -- Andy Ruddock andy.rudd...@rainydayz.org (OpenPGP Key ID 0xB0324245) signature.asc Description: OpenPGP digital signature
Bug#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)
intrigeri: > Would you be interested in testing whether > https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/84 > fixes this problem for you? FWIW the patch proposed upstream applies nicely on top of our debian/unstable branch: https://salsa.debian.org/gnome-team/gnome-settings-daemon/merge_requests/3 I probably won't have time to test this myself in the next few days. Hoping this WIP MR might save someone else a tiny bit of time :) Cheers, -- intrigeri
Bug#926602: jinja2: CVE-2019-10906
Source: jinja2 Version: 2.10-1 Severity: grave Tags: patch security upstream Hi, The following vulnerability was published for jinja2. CVE-2019-10906[0]: | In Pallets Jinja before 2.10.1, str.format_map allows a sandbox | escape. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-10906 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10906 [1] https://palletsprojects.com/blog/jinja-2-10-1-released/ [2] https://github.com/pallets/jinja/commit/a2a6c930bcca591a25d2b316fcfd2d6793897b26 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#649492: libimdi0: Typo in package description
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 reassign 649492 libimdi0 thanks Hi, libimdi0 is not part of argyll. CU Jörg - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlyqLiUACgkQCfifPIyh 0l2qDw/7BzFmR4mIC/yDjREqlZ5nu78G/2b+GH/p2NjC548TvzI2MbXS4oSjI33n BX7DTtPVVOOXfjYhhmBAjkvzRqzdi8wR50HDkVzOO1Dp6jXk2pYeQYiwYfLJUHot Q0ZoldC6oyX9i+rsFh8LArwNNboGVt+mAoUmlMCw8kWOcVUlsnhfV8DGGu76iPgJ x32Z1INB9XAdP3rNefjdBV0pnE0lwqRG4XetzVfpt2OJ2bxNNg2zFlmTDkd9nx4/ xb0RPhech7+E9oqe8oAXTP8OwiY0CiBuEa39yhjgMMBWoLXDcSGBwowgt51rkUyC Tf1BCLCt7KCFHanMDGlyiXanVx713rz1QSdD8mm5lYmfL9LcJXOhDF+Crv0YCTOE 1Ta6j/4XeVyIfAbftDlVYVaLeRGCb4rhwK9GVa8VD1dd1daE+uqVr64mt6aldHPh C7jzjs9I2N06qPmUSXT5VjP0I3LXsXcGD1FuEbOnHSJudorx2063N98qIVqs1r+D DdQzPo3yM1qe7I3+9Nz1jMD/Mcy2YNnsy9q1hh+G8jxZpH/6TtyhDYx9Tpl1Zx+e eXZZVQNTY+7YInXJGJFoygs4llXZX4I217haX7d+c5DOqpKhRxdzriqE0wJBB5AF 0HYuz1qGUgbzPHR2tZ8ZIhBPbHAMxukHZRDEs7KhiGsEXH6SZxs= =Qy78 -END PGP SIGNATURE-
Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused
On Sun, 07 Apr 2019 at 18:12:45 +0200, gregor herrmann wrote:
> On Sun, 18 Nov 2018 19:41:05 +0200, Niko Tyni wrote:
>
>> Reiterating a bit: the underlying issue with TLSv1.3 seems to be related
>> to handling of 'non-application_data_records'.
>>
>> The client tries to POST but gets an 'SSL wants a read first' error,
>> then waits until timeout for the socket to become writable.
>>
>> A simple way to reproduce it here is
>>
>> perl -MLWP::UserAgent -e 'LWP::UserAgent->new->post("https://facebook.com;,
>> { data => "foo" }) or die'
>>
>> which deadlocks for me.
>
> I can't reproduce this problem:
Interesting, are you talking TLS 1.3?
$ dpkg-query -l "libssl*" "libnet-ssleay-perl" "liblwp-protocol-https-perl"
"libio-socket-ssl-perl"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---=
ii libio-socket-ssl-perl 2.060-3 all Perl module
implementing object oriented interface to SSL sockets
ii liblwp-protocol-https-perl 6.07-2 all HTTPS driver for
LWP::UserAgent
ii libnet-ssleay-perl 1.85-2+b1amd64Perl module for Secure
Sockets Layer (SSL)
ii libssl-dev:amd64 1.1.1b-1 amd64Secure Sockets Layer
toolkit - development files
un libssl-doc (no description
available)
un libssl0.9.8 (no description
available)
un libssl1.0-dev(no description
available)
ii libssl1.1:amd641.1.1b-1 amd64Secure Sockets Layer
toolkit - shared libraries
$ openssl req -x509 -newkey rsa:4096 -keyout /tmp/key.pem -out /tmp/cert.pem
-subj /CN=example.net -nodes
$ openssl s_server -accept 127.0.0.1:4433 -key /tmp/key.pem -cert /tmp/cert.pem
-tls1_3
[…]
Then on a separate terminal, with SSL_MODE_AUTO_RETRY set (the default),
it blocks on read(2):
$ strace -eselect,read,write perl -MLWP::UserAgent -e
'LWP::UserAgent->new(ssl_opts =>
{verify_hostname => 0, SSL_ca_file =>
"/tmp/cert.pem"})->post("https://127.0.0.1:4433;, { data => "foo" })'
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], left
{tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 250) = 250
read(3, "…", 5) = 5
read(3, "…", 250) = 250
read(3,
With SSL_MODE_AUTO_RETRY cleared, the handshake terminates and it waits
for the reply from the server:
$ strace -eselect,read,write perl -MLWP::UserAgent -e
'LWP::UserAgent->new(ssl_opts =>
{verify_hostname => 0, SSL_ca_file =>
"/tmp/cert.pem"})->post("https://127.0.0.1:4433;, { data => "foo" })'
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3], left
{tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 250) = 250
write(3, "…", 216) = 216
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left
{tv_sec=179, tv_usec=99})
read(3, "…", 5) = 5
read(3, "…", 250) = 250
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}
(and the connection closes gracefuly when I write “HTTP/1.1
200\r\nContent-Length: 0\r\n\r\n” from the server)
> % time perl -MLWP::UserAgent -e
> 'LWP::UserAgent->new->post("https://twitter.com;, { data => "foo" }) or die'
> perl -MLWP::UserAgent -e 0.13s user 0.02s system 36% cpu 0.415 total
twitter.com doesn't support TLS 1.3 though, right?
$ openssl s_client -4 -connect twitter.com:443 -servername twitter.com -tls1_3
CONNECTED(0003)
139682444989504:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:../ssl/record/rec_layer_s3.c:1536:SSL alert number 40
--
Guilhem.
signature.asc
Description: PGP signature
Bug#926601: VarDirInode-n reports link count mismatches
Package: aide
Version: 0.16.1-1
Severity: normal
Hi,
this might be a bug or a user error. aide --update reports:
---
Removed and changed entries:
---
d ...n .. : /run
---
Detailed information about changes:
---
Directory: /run
Linkcount: 19 | 18
while I think that I have explicitly excluded the link count:
@@ifndef RUN
@@define RUN run
@@ifndef RUNLOCK
@@define RUNLOCK run/lock
/@@{ROOTPREFIX}@@{RUN}/acpid\.(socket|pid)$ VarFile
!/@@{ROOTPREFIX}@@{RUN}/aide$
Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10
Andrei POPESCU wrote: >> In issues.dbk: >> >> >> Migrating from legacy network interface names >> >> If your system was upgraded from an earlier release, and still uses >> the old-style network interface names that were deprecated with >> stretch (such as eth0 or wlan), > > s/eth0/eth/ ? (since you used the non-numbered names also in upgrading.dbk) Here I'm just giving a familiar example to identify the scheme from. (Oh, you're right, I'm inconsistent.) >> you should be aware that udev >> in buster no longer supports the mechanism of defining their names via >> /etc/udev/rules.d/70-persistent-net.rules. To >> avoid the danger of your machine losing networking after the upgrade >> to buster, it is recommended that you migrate in advance to the new >> naming scheme (usually meaning names like enp0s1 or >> wlp2s5, which incorporate PCI bus- and >> slot-numbers). Take care to update any interface names hard-coded in >> configuration for firewalls, > role="package">ifupdown. >> and so on. >> >> >> The alternative is to switch to a supported mechanism for enforcing >> the old naming scheme, such as the net.ifname=0 >> kernel commandline option or a systemd .link >> file. > > Point to systemd.link(5)? Oh yes, I forgot to come back to this. It's not completely clear what the approved method of doing manpage links is, but one option is to point at https://manpages.debian.org/stretch/udev/systemd.link.5.html;>systemd.link(5). or maybe just https://manpages.debian.org/systemd.link;>systemd.link(5). >> >> >> To find the new-style names that will be used, first find the >> current names of the relevant interfaces: >> >> > $ echo /sys/class/net/[ew]* >> >> >> For each one, check whether it is used in configuration files: >> >> >> $ sudo rgrep -w eth0 /etc >> >> >> And what name udev would prefer >> to >> use for it: >> >> >> $ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null >> >> >> (One of these may be a fallback MAC-based name, sometimes needed >> for USB network hardware.) >> >> >> [Possibly add extra details there for other special cases] (In particular there are onboard cards and PCI hotplug cards, but the upstream docs explain these better than I could.) >> >> >> To switch over, disable 70-persistent-net.rules >> either by renaming it or by commenting out individual lines. >> On virtual machines you will need to remove the files >> /etc/systemd/network/99-default.link and >> (if using virtio network devices) >> /etc/systemd/network/50-virtio-kernel-names.link. >> Then rebuild the initrd: >> >> >> $ sudo update-initramfs -u >> >> >> and reboot. Your system should now have new-style network interface >> names. Adjust any remaining configuration files, and test your system. >> > > https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names > suggests this might not be sufficient to activate the predictable naming > on stretch, is this tested? It was enough for me, but there are also at least two other ways of complicating matters: * a net.ifnames=0 option in your grub config * masking /dev/null symlinks in /etc/systemd/network/ Setting up one of those then forgetting about it might cause problems. >> [possibly a paragraph about safe upgrades over SSH] > > I believe your text above provides sufficient information to enable a > remote sysadmin to deal with this without further help. Given unlimited space and copious reliable sources we could also produce a decision tree for which configuration files to modify before or after the reboot, and whether to do test-runs with one-off kernel options and dead-man's-handle cronjobs, and so on, but a small and inaccurate version would probably do more harm than good. > >> >> See the >> > url="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/;>upstream >> documentation and the udev >> README.Debian for further information. >> >> >> >> And/or maybe a pointer to some useful page in the Debian Wiki, but I >> suspect we'd need to write one first. >> >> Then in upgrading.dbk >> >> >> Verify network interface name support >> >> Systems upgraded from older releases that still use network interfaces >> with names like eth or wlan are >> at risk of losing networking once they switch to buster; see >> for migration instructions. >> >> Oh, you're right; there's no reason for that to say "eth" that wouldn't also apply in the previous one. This should either say "like eth0 or wlan0" or "with names starting with eth- or wlan-". -- JBR with qualifications in linguistics, experience as a Debian sysadmin,
Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused
On Sun, 18 Nov 2018 19:41:05 +0200, Niko Tyni wrote:
> Reiterating a bit: the underlying issue with TLSv1.3 seems to be related
> to handling of 'non-application_data_records'.
>
> The client tries to POST but gets an 'SSL wants a read first' error,
> then waits until timeout for the socket to become writable.
>
> A simple way to reproduce it here is
>
> perl -MLWP::UserAgent -e 'LWP::UserAgent->new->post("https://facebook.com;,
> { data => "foo" }) or die'
>
> which deadlocks for me.
I can't reproduce this problem:
% time perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com;, { data => "foo" }) or die'
perl -MLWP::UserAgent -e 0.15s user 0.01s system 40% cpu 0.397 total
Has there something changed in LWP::Protocol::https Net::HTTPS
IO::Socket::SSL Net::SSLeay or something else, or is this some local
environment thing?
Also no issue with IPv4-only hosts:
% time perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://twitter.com;, { data => "foo" }) or die'
perl -MLWP::UserAgent -e 0.13s user 0.02s system 36% cpu 0.415 total
Cheers,
gregor, confused, as Guilhem (in message #71) could still reproduce
it at 7 Apr 2019
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Furry Lewis: Billy lyons & stack o' lee
signature.asc
Description: Digital Signature
signature.asc
Description: Digital Signature
Bug#925455: alsa volume never saved/restored
On Sun, 07 Apr 2019 18:05:06 +0200, Elimar Riesebieter wrote: > > There is a commit in the packaging repo which claims to fix this bug: > > https://salsa.debian.org/alsa-team/alsa-utils/commit/af161676131e94bbaed72f37d0c5d4c6685a119e > Jordi is MIA at the moment. Tried to reach him since a few days. I > can't upload the fix myself, though... I pinged him on a different channel, but if he doesn't have time I'm happy to offer a sponsored upload to fix this bug. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Furry Lewis: Billy lyons & stack o' lee signature.asc Description: Digital Signature
Bug#925455: alsa volume never saved/restored
* gregor herrmann [2019-04-07 17:46 +0200]: > Control: tag -1 + patch pending > > On Mon, 25 Mar 2019 12:05:36 +0100, Laurent Bigonville wrote: > > > The more obvious solution would of course be to remove the condition in the > > .service file > > There is a commit in the packaging repo which claims to fix this bug: > https://salsa.debian.org/alsa-team/alsa-utils/commit/af161676131e94bbaed72f37d0c5d4c6685a119e Jordi is MIA at the moment. Tried to reach him since a few days. I can't upload the fix myself, though... Elimar -- We all know Linux is great... it does infinite loops in 5 seconds. -Linus Torvalds signature.asc Description: PGP signature
Bug#926600: eom: missing depends for gir1.2-eom-1.0
Package: eom Version: 1.20.2-2 Severity: normal Dear Maintainer, * What led up to the situation? start eom * What was the outcome of this action? an error: loading Eom typelib: Typelib file for namespace 'Eom', version '1.0' not found * What outcome did you expect instead? no error * error disappear by installing gir1.2-eom-1.0 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.144-3-2019-03-05 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages eom depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii eom-common 1.20.2-2 ii libatk1.0-0 2.30.0-2 ii libc62.28-8 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libdbus-1-3 1.12.12-1 ii libdbus-glib-1-2 0.110-4 ii libexempi8 2.5.0-2 ii libexif120.6.21-5.1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgirepository-1.0-11.58.3-2 ii libgl1 1.1.0-1 ii libgl1-mesa-glx 18.3.4-2 ii libglib2.0-0 2.58.3-1 ii libgtk-3-0 3.24.5-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii libmate-desktop-2-17 1.20.4-2 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpeas-1.0-01.22.0-4 ii librsvg2-2 2.44.10-1 ii librsvg2-common 2.44.10-1 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.7-1 ii libxml2 2.9.4+dfsg1-7+b3 ii mate-desktop-common 1.20.4-2 ii shared-mime-info 1.10-1 ii zlib1g 1:1.2.11.dfsg-1 eom recommends no packages. eom suggests no packages. -- debconf-show failed
Bug#926305: nis startup scripts are completely broken
Hello everyone, Greetings from the Gothenburg BSP. If someone is interested in modernizing the nis package it seems like ArchLinux has native systemd units for nis and related services so I'd suggest importing those: https://aur.archlinux.org/packages/nis-utils/ https://www.archlinux.org/packages/core/x86_64/rpcbind/ See also https://wiki.archlinux.org/index.php/NIS Regards, Andreas Henriksson
Bug#925455: alsa volume never saved/restored
Control: tag -1 + patch pending On Mon, 25 Mar 2019 12:05:36 +0100, Laurent Bigonville wrote: > The more obvious solution would of course be to remove the condition in the > .service file There is a commit in the packaging repo which claims to fix this bug: https://salsa.debian.org/alsa-team/alsa-utils/commit/af161676131e94bbaed72f37d0c5d4c6685a119e Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Furry Lewis: Billy lyons & stack o' lee signature.asc Description: Digital Signature
Bug#914034: bug in Net::SSLeay?
Control: usertag -1 bsp-2019-04-se-gothenburg
Hi there,
strace(1) shows a select(2) syscall indicating that the socket is ready for
both read and write, but is later blocking on a read(2) without any
write(2) taking place.
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3],
left {tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 156) = 156
read(3,
Net::SSLeay warns:
If you need to select(2) on the socket, go right ahead, but be warned that
OpenSSL does some internal buffering so SSL_read does not always return
data even if the socket selected for reading (just keep on selecting and
trying to read). "Net::SSLeay" is no different from the C language OpenSSL
in this respect.
And indeed LWP::Protocol::http's use of select(2) on SSL sockets *does*
assume that read/write readiness won't block. (If Net::SSLeay::read()
returns -1, then the loop will retry later with SSL_ERROR_WANT_READ/WRITE.)
However since OpenSSL 1.1.1 the SSL_MODE_AUTO_RETRY flag is on by
default, which breaks that assumption: ssl_read(3) might block, even
when select(2) claimed the socket had data to be read.
SSL_MODE_AUTO_RETRY
During normal operations, non-application data records might need to be
sent or received that the application is not aware of. If a
non-application data record was processed, SSL_read_ex(3) and SSL_read(3)
can return with a failure and indicate the need to retry with
SSL_ERROR_WANT_READ. If such a non-application data record was processed,
the flag SSL_MODE_AUTO_RETRY causes it to try to process the next record
instead of returning.
[…]
In a blocking environment, applications are not always prepared to deal
with the functions returning intermediate reports such as retry requests,
and setting the SSL_MODE_AUTO_RETRY flag will cause the functions to only
return after successfully processing an application data record or a
failure.
[…]
All modes are off by default except for SSL_MODE_AUTO_RETRY which is on by
default since 1.1.1.
— https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_mode.html
See also https://github.com/openssl/openssl/issues/6234 .
I see several paths forward here:
- Refactor LWP::Protocol::http's select loop to solve the assumption
that's now broken with OpenSSL ≥1.1.1; or
- Unset SSL_MODE_AUTO_RETRY in IO::Socket::SSL; or
- Make context flags configurable in IO::Socket::SSL, and unset
SSL_MODE_AUTO_RETRY from LWP.
IMHO the first option is not ideal so late in the release cycle. The
second option is the easiest to implement, and should™ be regression-free,
but might confuse people who became used to OpenSSL ≥1.1.1's new context
default flags.
SSL_CTX_clear_mode(3) and SSL_CTRL_CLEAR_MODE macros are unfortunately
not exposed to Net::SSLeay 1.85-2. The proper fix would be to expose
these and release a new version of Net::SSLeay, of course, but for tests
the macros can be taken from /usr/include/openssl/ssl.h:
# define SSL_CTRL_CLEAR_MODE 78
[…]
# define SSL_CTX_clear_mode(ctx,op) \
SSL_CTX_ctrl((ctx),SSL_CTRL_CLEAR_MODE,(op),NULL)
and used as is in IO::Socket::SSL.pm. With the following patch I'm
again able to POST to HTTPS servers using TLS 1.3.
--8<--->8--
--- a/IO/Socket/SSL.pm
+++ b/IO/Socket/SSL.pm
@@ -2433,6 +2433,7 @@
# cannot guarantee, that the location of the buffer stays constant
Net::SSLeay::CTX_set_mode( $ctx,
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER|SSL_MODE_ENABLE_PARTIAL_WRITE);
+ Net::SSLeay::CTX_ctrl($ctx, 78, Net::SSLeay::MODE_AUTO_RETRY(), undef);
if ( my $proto_list = $arg_hash->{SSL_npn_protocols} ) {
return IO::Socket::SSL->_internal_error("NPN not supported in
Net::SSLeay",9)
--8<--->8--
(Again, I'm not proposing to patch IO::Socket::SSL as above :-) With
MODE_AUTO_RETRY set — the default for OpenSSL ≥1.1.1 — one gets:
$ strace -e trace=read,write,select perl -MLWP::UserAgent -e
'LWP::UserAgent->new(ssl_opts =>
{SSL_version => "TLSv1_3"})->post("https://facebook.com;, { data =>
"plonc" })';
[…]
select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3],
left {tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 156) = 156
read(3,
And now with the MODE_AUTO_RETRY flag unset:
$ select(8, [3], [3], NULL, {tv_sec=180, tv_usec=0}) = 2 (in [3], out [3],
left {tv_sec=179, tv_usec=98})
read(3, "…", 5) = 5
read(3, "…", 156) = 156
write(3, "…", 217) = 217
select(8, [3], NULL, NULL, {tv_sec=180, tv_usec=0}) = 1 (in [3], left
{tv_sec=179, tv_usec=870931})
read(3, "…", 5) = 5
read(3, "…", 361) = 361
Cheers,
--
Guilhem.
signature.asc
Description: PGP signature
Bug#916332: local tiled installation
I had the same or a similar error to what you see. The issue was for me (and I think is likely the same for you) that I had an older local tiled installation, built from source. This installed a version of `libtiled.so` which get's looked up by the newer tiled, but doesn't work with it, so you should cleanly uninstall the source-built tiled, completely (`make uninstall` in you old source dir). You can find the offending lib, by doing `ldd /usr/bin/tiled`. In short, this is not a bug in the packaged tiled.
Bug#926598: xmlstarlet fo --omit-decl exits with non-zero code
Package: xmlstarlet Version: 1.6.1-2 Steps to reproduce: $ echo '' | xmlstarlet fo --omit-decl; echo $? Expected result: 0 Actual result: 5 What's really weird is that the returned error code is always identical to the number of bytes written to the output. This bug seems to only occur if --omit-decl is used.
Bug#924365: www.debian.org: FTBFS in buster: turkish vs. tr_TR locale
Hello Ömer To avoid such errors you need to make the english folder first, I think make -j1 -C english STRICT_ERROR_CHECKS=1 USE_SAMPLE_FILES=1 and then make -j1 -C turkish STRICT_ERROR_CHECKS=1 USE_SAMPLE_FILES=1 I cannot reproduce the error in Stretch, the error happens only in Buster. Kind regards, El 7/4/19 a las 6:26, Omer Ozarslan escribió: > Hello Laura, > > I'm not sure if I missed some steps, but I couldn't reproduce this > issue. Yet, I hit another one: > > [snipped] > > root@a179023d59e0:/webwml# make -j1 -C turkish STRICT_ERROR_CHECKS=1 > USE_SAMPLE_FILES=1 > make: Entering directory '/webwml/turkish' > make -C po install > make[1]: Entering directory '/webwml/turkish/po' > make[1]: Leaving directory '/webwml/turkish/po' > make -C CD > make[1]: Entering directory '/webwml/turkish/CD' > make -C http-ftp > make[2]: Entering directory '/webwml/turkish/CD/http-ftp' > make[2]: *** No rule to make target > '../../../english/CD/http-ftp/cdimage_mirrors.list', needed by > 'index.tr.html'. Stop. > make[2]: Leaving directory '/webwml/turkish/CD/http-ftp' > make[1]: *** [../../Makefile.common:79: http-ftp] Error 2 > make[1]: Leaving directory '/webwml/turkish/CD' > make: *** [../Makefile.common:79: CD] Error 2 > make: Leaving directory '/webwml/turkish' > > Here is the verbose part I snipped for convenience: > > root@a179023d59e0:/# cd webwml > root@a179023d59e0:/webwml# cat /var/log/apt/history.log | grep Commandline > Commandline: apt-get install -y build-essential vim gettext make perl > wml git wget libxml-rss-perl > root@a179023d59e0:/webwml# git reset --hard > HEAD is now at c28ce7bbd78 (fr) DSA 4223-4225, initial translation > root@a179023d59e0:/webwml# make -j1 -C turkish STRICT_ERROR_CHECKS=1 > USE_SAMPLE_FILES=1 > make: Entering directory '/webwml/turkish' > make -C po install > make[1]: Entering directory '/webwml/turkish/po' > msgmerge -q templates.tr.po ../../english/po/templates.pot | \ > msgfmt --statistics -o templates.mo - > 91 translated messages, 16 fuzzy translations, 12 untranslated messages. > 'templates.mo' -> '../../locale/tr/LC_MESSAGES/templates.mo' > msgmerge -q bugs.tr.po ../../english/po/bugs.pot | \ > msgfmt --statistics -o bugs.mo - > 34 translated messages. > 'bugs.mo' -> '../../locale/tr/LC_MESSAGES/bugs.mo' > msgmerge -q blends.tr.po ../../english/po/blends.pot | \ > msgfmt --statistics -o blends.mo - > 0 translated messages, 18 untranslated messages. > 'blends.mo' -> '../../locale/tr/LC_MESSAGES/blends.mo' > msgmerge -q cdimage.tr.po ../../english/po/cdimage.pot | \ > msgfmt --statistics -o cdimage.mo - > 26 translated messages. > 'cdimage.mo' -> '../../locale/tr/LC_MESSAGES/cdimage.mo' > msgmerge -q consultants.tr.po ../../english/po/consultants.pot | \ > msgfmt --statistics -o consultants.mo - > 15 translated messages. > 'consultants.mo' -> '../../locale/tr/LC_MESSAGES/consultants.mo' > msgmerge -q countries.tr.po ../../english/po/countries.pot | \ > msgfmt --statistics -o countries.mo - > 104 translated messages. > 'countries.mo' -> '../../locale/tr/LC_MESSAGES/countries.mo' > msgmerge -q date.tr.po ../../english/po/date.pot | \ > msgfmt --statistics -o date.mo - > 38 translated messages. > 'date.mo' -> '../../locale/tr/LC_MESSAGES/date.mo' > msgmerge -q distrib.tr.po ../../english/po/distrib.pot | \ > msgfmt --statistics -o distrib.mo - > 46 translated messages. > 'distrib.mo' -> '../../locale/tr/LC_MESSAGES/distrib.mo' > msgmerge -q doc.tr.po ../../english/po/doc.pot | \ > msgfmt --statistics -o doc.mo - > 16 translated messages, 2 fuzzy translations, 14 untranslated messages. > 'doc.mo' -> '../../locale/tr/LC_MESSAGES/doc.mo' > msgmerge -q l10n.tr.po ../../english/po/l10n.pot | \ > msgfmt --statistics -o l10n.mo - > 21 translated messages. > 'l10n.mo' -> '../../locale/tr/LC_MESSAGES/l10n.mo' > msgmerge -q langs.tr.po ../../english/po/langs.pot | \ > msgfmt --statistics -o langs.mo - > 86 translated messages. > 'langs.mo' -> '../../locale/tr/LC_MESSAGES/langs.mo' > msgmerge -q legal.tr.po ../../english/po/legal.pot | \ > msgfmt --statistics -o legal.mo - > 25 translated messages. > 'legal.mo' -> '../../locale/tr/LC_MESSAGES/legal.mo' > msgmerge -q mailinglists.tr.po ../../english/po/mailinglists.pot | \ > msgfmt --statistics -o mailinglists.mo - > 20 translated messages. > 'mailinglists.mo' -> '../../locale/tr/LC_MESSAGES/mailinglists.mo' > msgmerge -q newsevents.tr.po ../../english/po/newsevents.pot | \ > msgfmt --statistics -o newsevents.mo - > 24 translated messages, 7 fuzzy translations, 37 untranslated messages. > 'newsevents.mo' -> '../../locale/tr/LC_MESSAGES/newsevents.mo' > msgmerge -q organization.tr.po ../../english/po/organization.pot | \ > msgfmt --statistics -o organization.mo - > 49 translated messages, 17 fuzzy translations, 22 untranslated messages. >
Bug#887101: (no subject)
It is planned to ship the IPython LTS branch (5.x) for buster, maintaining single-source python2 and python3 compatibility. IPython and related tools 6.x and later drop python2 support. We'll aim to update and python3 versions and retain the existing python2 versions of interactive tools only (ipython, ipykernel and dependencies) in bullseye.
Bug#926576: ghostscript: printer stopped working: ghostscript fails with ""Unable to determine number of pages"
I have released cups-filters 1.22.5 upstream now with the fix. Till
Bug#926597: unblock: golang-github-puerkitobio-purell/1.1.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Greetings from the Gothenburg BSP.
Please unblock package golang-github-puerkitobio-purell
unblock golang-github-puerkitobio-purell/1.1.0-2
Fixes FTBFS (testsuite failure)
(Sorry, this also included some minor trivial changes that where
already sitting in the salsa git repo for this package.)
Regards,
Andreas Henriksson
diff --git a/debian/changelog b/debian/changelog
index a85603e..e233aac 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+golang-github-puerkitobio-purell (1.1.0-2) unstable; urgency=medium
+
+ * Team upload with greetings from Gothenburg BSP.
+
+ [ Alexandre Viau ]
+ * Point Vcs-* urls to salsa.debian.org.
+
+ [ Andreas Henriksson ]
+ * Add debian/patches/pr-29.patch (Closes: #926380)
+
+ -- Andreas Henriksson Sun, 07 Apr 2019 17:00:51 +0200
+
golang-github-puerkitobio-purell (1.1.0-1) unstable; urgency=medium
* New upstream release
diff --git a/debian/control b/debian/control
index a6a5a13..ce8e849 100644
--- a/debian/control
+++ b/debian/control
@@ -1,6 +1,6 @@
Source: golang-github-puerkitobio-purell
Section: devel
-Priority: extra
+Priority: optional
Maintainer: Debian Go Packaging Team
Uploaders: Anthony Fok
Build-Depends: debhelper (>= 9),
@@ -9,10 +9,10 @@ Build-Depends: debhelper (>= 9),
golang-github-opennota-urlesc-dev (>=
0.0~git20150208.0.5fa9ff0-3),
golang-golang-x-net-dev,
golang-golang-x-text-dev
-Standards-Version: 3.9.8
+Standards-Version: 4.0.0
Homepage: https://github.com/PuerkitoBio/purell
-Vcs-Browser:
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-puerkitobio-purell.git
-Vcs-Git:
https://anonscm.debian.org/git/pkg-go/packages/golang-github-puerkitobio-purell.git
+Vcs-Browser:
https://salsa.debian.org/go-team/packages/golang-github-puerkitobio-purell
+Vcs-Git:
https://salsa.debian.org/go-team/packages/golang-github-puerkitobio-purell.git
XS-Go-Import-Path: github.com/PuerkitoBio/purell
Package: golang-github-puerkitobio-purell-dev
diff --git a/debian/copyright b/debian/copyright
index 707eab8..afd538d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Purell
Source: https://github.com/PuerkitoBio/purell
diff --git a/debian/gitlab-ci.yml b/debian/gitlab-ci.yml
new file mode 100644
index 000..5c8c31b
--- /dev/null
+++ b/debian/gitlab-ci.yml
@@ -0,0 +1,28 @@
+
+# auto-generated, DO NOT MODIFY.
+# The authoritative copy of this file lives at:
+# https://salsa.debian.org/go-team/ci/blob/master/cmd/ci/gitlabciyml.go
+
+# TODO: publish under debian-go-team/ci
+image: stapelberg/ci2
+
+test_the_archive:
+ artifacts:
+paths:
+- before-applying-commit.json
+- after-applying-commit.json
+ script:
+# Create an overlay to discard writes to /srv/gopath/src after the build:
+- "rm -rf /cache/overlay/{upper,work}"
+- "mkdir -p /cache/overlay/{upper,work}"
+- "mount -t overlay overlay -o
lowerdir=/srv/gopath/src,upperdir=/cache/overlay/upper,workdir=/cache/overlay/work
/srv/gopath/src"
+- "export GOPATH=/srv/gopath"
+- "export GOCACHE=/cache/go"
+# Build the world as-is:
+- "ci-build -exemptions=/var/lib/ci-build/exemptions.json >
before-applying-commit.json"
+# Copy this package into the overlay:
+- "GBP_CONF_FILES=:debian/gbp.conf gbp buildpackage --git-no-pristine-tar
--git-ignore-branch --git-ignore-new --git-export-dir=/tmp/export
--git-no-overlay --git-tarball-dir=/nonexistant --git-cleaner=/bin/true
--git-builder='dpkg-buildpackage -S -d --no-sign'"
+- "pgt-gopath -dsc /tmp/export/*.dsc"
+# Rebuild the world:
+- "ci-build -exemptions=/var/lib/ci-build/exemptions.json >
after-applying-commit.json"
+- "ci-diff before-applying-commit.json after-applying-commit.json"
diff --git a/debian/patches/pr-29.patch b/debian/patches/pr-29.patch
new file mode 100644
index 000..c5f889e
--- /dev/null
+++ b/debian/patches/pr-29.patch
@@ -0,0 +1,76 @@
+From b5f01560a83bfe6f1551df3579f2149ae7f3f54c Mon Sep 17 00:00:00 2001
+From: Martin Angers
+Date: Sat, 16 Feb 2019 16:08:08 -0500
+Subject: [PATCH] fix failing go1.12 test due to control chars causing
+ url.Parse to fail
+
+---
+ purell_test.go | 41 -
+ 1 file changed, 24 insertions(+), 17 deletions(-)
+
+diff --git a/purell_test.go b/purell_test.go
+index 8eb5191..efde722 100644
+--- a/purell_test.go
b/purell_test.go
+@@ -4,6 +4,7 @@ import (
+ "fmt"
+ "net/url"
+ "testing"
++ "unicode"
+ )
+
+ type testCase struct {
+@@ -746,30 +747,36 @@ func TestDecodeUnnecessaryEscapesAll(t *testing.T) {
+ for i := 0; i < 256; i++ {
+ url += fmt.Sprintf("%%%02x", i)
+ }
Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10
On Du, 07 apr 19, 15:32:32, Justin B Rye wrote: > Okay, here's a significantly trimmed-down version that we might be > able to use if it's bulked out with good external references. > > In issues.dbk: > > > Migrating from legacy network interface names > > If your system was upgraded from an earlier release, and still uses > the old-style network interface names that were deprecated with > stretch (such as eth0 or wlan), s/eth0/eth/ ? (since you used the non-numbered names also in upgrading.dbk) > you should be aware that udev > in buster no longer supports the mechanism of defining their names via > /etc/udev/rules.d/70-persistent-net.rules. To > avoid the danger of your machine losing networking after the upgrade > to buster, it is recommended that you migrate in advance to the new > naming scheme (usually meaning names like enp0s1 or > wlp2s5, which incorporate PCI bus- and > slot-numbers). Take care to update any interface names hard-coded in > configuration for firewalls, role="package">ifupdown. > and so on. > > > The alternative is to switch to a supported mechanism for enforcing > the old naming scheme, such as the net.ifname=0 > kernel commandline option or a systemd .link > file. Point to systemd.link(5)? > > > To find the new-style names that will be used, first find the > current names of the relevant interfaces: > > $ echo /sys/class/net/[ew]* > > > For each one, check whether it is used in configuration files: > > > $ sudo rgrep -w eth0 /etc > > > And what name udev would prefer > to > use for it: > > > $ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null > > > (One of these may be a fallback MAC-based name, sometimes needed > for USB network hardware.) > > > [Possibly add extra details there for other special cases] > > > To switch over, disable 70-persistent-net.rules > either by renaming it or by commenting out individual lines. > On virtual machines you will need to remove the files > /etc/systemd/network/99-default.link and > (if using virtio network devices) > /etc/systemd/network/50-virtio-kernel-names.link. > Then rebuild the initrd: > > > $ sudo update-initramfs -u > > > and reboot. Your system should now have new-style network interface > names. Adjust any remaining configuration files, and test your system. > https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names suggests this might not be sufficient to activate the predictable naming on stretch, is this tested? > [possibly a paragraph about safe upgrades over SSH] I believe your text above provides sufficient information to enable a remote sysadmin to deal with this without further help. > > See the > url="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/;>upstream > documentation and the udev > README.Debian for further information. > > > > And/or maybe a pointer to some useful page in the Debian Wiki, but I > suspect we'd need to write one first. > > Then in upgrading.dbk > > > Verify network interface name support > > Systems upgraded from older releases that still use network interfaces > with names like eth or wlan are > at risk of losing networking once they switch to buster; see > for migration instructions. > > > > -- > JBR with qualifications in linguistics, experience as a Debian > sysadmin, and probably no clue about this particular package > Otherwise (FWIW) this looks good for me. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#863468: (no subject)
I can confirm this bug is still present in 0.8.10, but I don't have a clear sense of how to fix it; awaiting an upstream fix.
Bug#926576: ghostscript: printer stopped working: ghostscript fails with ""Unable to determine number of pages"
Thanks for reporting this. I have fixed the problem now by changing the Ghostscript call to count pages in a PDF file. See https://github.com/OpenPrinting/cups-filters/commit/297cc2d I found this solution with the help of a bug report to Arch Linux: https://bugs.archlinux.org/task/62251 There they have found the alternative method and also talked with the Ghostscript developers on IRC to confirm the need of the change. The old call used the undocumented internal "pdfdict" of Ghostscript which from Ghostscript 9.27 on is not accessible any more for security reasons. Now I use the call suggested in the Arch Linux bug report using "runpdfbegin". Till
Bug#926342: libprotobuf17: I was forced to download libprotobuf17 on this site: https://packages.debian.org/buster/amd64/libprotobuf17/download
On Fri, Apr 5, 2019 at 8:18 PM wrote: > C]I have just a file which name is apt-listbugs in /etc/apt/preferences.d : > > /etc/apt/preferences.d# ls -ail > total 12 > 1044672 drwxr-xr-x 2 root root 4096 mars 6 2018 . > 1044507 drwxr-xr-x 8 root root 4096 avril 5 08:44 .. > 1045052 -rw-r--r-- 1 root root 631 févr. 26 08:22 apt-listbugs > > > less apt-listbugs > Result : [...] > Explanation: Pinned by apt-listbugs at 2018-10-27 19:50:22 +0200 > Explanation: #910964: libprotobuf17 needs Breaks: libprotobuf10 > Package: libprotobuf17 > Pin: version * > Pin-Priority: -3 This is the culprit. Somehow auto-generated I suppose. Please delete this segment and you will be able to install / update libprotobuf17 again. Cheers, Laszlo/GCS
Bug#926596: fwupdate: arm64 version of PE/COFF efi binary is corrupt
Package: fwupdate Version: 12-4 Severity: important Dear Maintainer, Version 12-4 of fwupdate is broken for arm64. The included binary fwupaa64.efi is corrupt, resulting in EFI_LOAD_ERROR to be returned by the firmware when trying to invoke it. The binary layout looks like this: Detected 'AArch64' type PE/COFF image consisting of 2 sections Section alignment: 0x1000 File alignment: 0x200 Image size: 0xd890 Section '.text' @ 0x1000 File offset: 0x1000 Virtual size: 0xac20 Raw size: 0xac20 Section '.data' @ 0xbc20 File offset: 0xbc20 Virtual size: 0x1d70 Raw size: 0x1d70 Note that file offset + size of section #2 exceeds the total image size. But the file offset of that section is not even a multiple of the file alignment, so the whole image seems pretty broken. -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.1.0-rc2+ (SMP w/24 CPU cores; PREEMPT) 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 fwupdate depends on: ii e2fsprogs1.43.4-2 ii efibootmgr 14-2 ii libc62.28-8 ii libefiboot1 37-2 ii libefivar1 37-2 ii libfwup1 12-4 ii libpopt0 1.16-10+b2 Versions of packages fwupdate recommends: ii fwupdate-arm64-signed [fwupdate-signed] 12+4 fwupdate suggests no packages. -- no debconf information
Bug#923930: testsuite comes with built-in time-bomb
Control: forwarded -1 https://github.com/heimdal/heimdal/issues/533 Greetings from the Gothenburg BSP. To summarize the above issue: - certs used in test-suite expired - upstream regenerated certs with 500 years expiration time set - this solves the issue on machines with 64bit time_t but 32bit machines still fails the test-suite. - A suggestion was made to generate certs that expire "Tue, 19 Jan 2038 03:14:06 GMT" instead. On the debian side of things: including the upstream diff is annoying because debian/patches/ (quilt 3.0) doesn't support git binary diffs. The lazy solution here is to argue that we don't want time-bombs and just disable the test-suite. The better solution involves generating the certificates so that they align with what 32bit machines can handle, uuencoding the result and setting up debian/rules handling to "manually patch" the build. Regards, Andreas Henriksson
Bug#926577: eeschema: assert failed with more than one instance of hierarchical sheet
Hi, On Sun, Apr 07, 2019 at 11:45:50AM +0200, Cobra wrote: > When I try to create more than one instance of a hierarchical sheet, > an assert fails. After hitting "continue", the same error appears again > and again. I gave up after 10 repetitions and hit stop to kill kicad, > losing any unsaved content. > This happens when creating a new hierarchical sheet and linking it to an > existing one by entering the same file name but also when duplicating an > existing sheet. > It seems like this bug has been fixed upstream in 5.1.0, see > https://bugs.launchpad.net/kicad/+bug/1798930 > https://bugs.launchpad.net/kicad/+bug/1800796 the KiCad version 5.1.0 is currently only available in unstable. I've asked the release team for an unblock of that version so it could migrate to testing then. Please see #926004. As this is a big change to the previous version in testing I can't overview if this unblock will happen even I don't expect any big or small issues on this update. https://bugs.debian.org/926004 Given your report is created against the version of KiCad in stretch-backports there not much I can do right now. First version 5.1.0 need to be in testing before I can work on a new updated version for stretch-backports. As upstream has started again talking about the next update of KiCad to 5.1.1 I'm not much motivated currently to work in between times an a backport version of KiCad for stretch which wouldn't made into backports. But maybe I change my mind on this. :) Regards Carsten
Bug#926380: golang-github-puerkitobio-purell: FTBFS (failing tests)
Hi, On Sun, Apr 7, 2019 at 10:09 PM Andreas Henriksson wrote: > > Greetings from the Gothenburg BSP. > > This is the output I get when reproducing this issue: > > ---8<->8- > > --- FAIL: TestEncodeNecessaryEscapesAll (0.00s) > purell_test.go:761: Got error parse http://host/ > > > � net/url: invalid control character in URL > FAIL > exit status 1 > FAIL_/tmp/golang-github-puerkitobio-purell-1.1.00.003s > > ---8<->8- > > > net/url Parse now explicitly check that you don't pass in > "invalid" (non-encoded) urls and rejects them: > https://sources.debian.org/src/golang-1.11/1.11.6-1/src/net/url/url.go/?hl=498#L498 > > The NormalizeUrlString helper function starts out by passing the url > string to url.Parse: > https://sources.debian.org/src/golang-github-puerkitobio-purell/1.1.0-1/purell.go/#L153 > > The TestDecodeUnnecessaryEscapesAll function creates an url with control > characters and passes it to NormalizeURLString to try to get it > normalized/escaped. > > I'd say the design of the NormalizeUrlString function is broken and thus > it's not obvious to me how to fix it. I'd say that if you have a > non-normalized string you want encoded, you should pass it in as > something that doesn't need to be parsed. ie. use NormalizeUrl helper > function, which takes an Url type. > > Removing the NormalizeUrlString function however would be an API/ABI > break as it's publicly exported (and used by Hugo and Kubernetes)... > > Maybe open-coding some homebrew url parsing to fall back on could be > done to keep the function around. Sounds bad to think you know > better than net/url how to parse an url though. > > I'm attaching a patch which "fixes" this issue, but really it's most likely > a stupid and wrong things to do to solve this. It's just designed to > make the testsuite pass. As mentioned, I think the NormalizeURLString > function is incorrectly designed and there's no way to fix it (so should > be deprecated in favour of NormalizeURL). > Thus intentionally *not* tagging patch, as this is rather a "proof of > concept". > > Regards, > Andreas Henriksson Thanks for your great work! However it's already fixed by upstream, https://github.com/PuerkitoBio/purell/pull/29 If someone is going to upload the new version, please take upstream patch instead :/ -- Shengjing Zhu
Bug#882179: (no subject)
Unable to reproduce this. The output of `jupyter kernelspec list` provided shows that there is a custom install of ipykernel (python2) in /usr/local/share/jupyter/kernels/python2 shadowing python-ipykernel - maybe installed with `sudo pip install`? Try removing that version and see if the packaged kernel (/usr/share/jupyter/kernels/python2/kernel.json) works as expected.
Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10
Karl O. Pinc wrote: >> Whether I'm accessing it physically or via ssh, can't I use something >> like: >> udevadm test /sys/class/net/$ETHX 2>/dev/null | grep NET >> or >> udevadm test-builtin net_id /sys/class/net/$ETHX 2>/dev/null >> ...? That worked for me even on Jessie machine. > > I don't know. I just tried both the above on a > jessie box running on a VM and it did not show me > an ID_NET_NAME_PATH, which I presume is what > shows me the new-style interface name? (By "$ETHX" I mean "eth0 or whatever you've currently got"...) Is the VM one that supports the ports-and-slots scheme? Some apparently don't. I don't know exactly what happens instead, but udevadm seems the most reliable way of narrowing that down. > I don't have a stretch box with old-style names to test on. If I boot a physical stretch box with the net.ifnames=0 option, it comes up with an eth0 but udevadm says ID_NET_PATH=enp1s0. I know udevadm worked for me on physical machines running jessie, since that's how I predicted their names for my own upgrades. But if it *is* the officially approved way of predicting predictable names, I wish the upstream docs would say so. Okay, here's a significantly trimmed-down version that we might be able to use if it's bulked out with good external references. In issues.dbk: Migrating from legacy network interface names If your system was upgraded from an earlier release, and still uses the old-style network interface names that were deprecated with stretch (such as eth0 or wlan), you should be aware that udev in buster no longer supports the mechanism of defining their names via /etc/udev/rules.d/70-persistent-net.rules. To avoid the danger of your machine losing networking after the upgrade to buster, it is recommended that you migrate in advance to the new naming scheme (usually meaning names like enp0s1 or wlp2s5, which incorporate PCI bus- and slot-numbers). Take care to update any interface names hard-coded in configuration for firewalls, ifupdown. and so on. The alternative is to switch to a supported mechanism for enforcing the old naming scheme, such as the net.ifname=0 kernel commandline option or a systemd .link file. To find the new-style names that will be used, first find the current names of the relevant interfaces: For each one, check whether it is used in configuration files: $ sudo rgrep -w eth0 /etc And what name udev would prefer to use for it: $ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null (One of these may be a fallback MAC-based name, sometimes needed for USB network hardware.) [Possibly add extra details there for other special cases] To switch over, disable 70-persistent-net.rules either by renaming it or by commenting out individual lines. On virtual machines you will need to remove the files /etc/systemd/network/99-default.link and (if using virtio network devices) /etc/systemd/network/50-virtio-kernel-names.link. Then rebuild the initrd: $ sudo update-initramfs -u and reboot. Your system should now have new-style network interface names. Adjust any remaining configuration files, and test your system. [possibly a paragraph about safe upgrades over SSH] See the https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/;>upstream documentation and the udev README.Debian for further information. And/or maybe a pointer to some useful page in the Debian Wiki, but I suspect we'd need to write one first. Then in upgrading.dbk Verify network interface name support Systems upgraded from older releases that still use network interfaces with names like eth or wlan are at risk of losing networking once they switch to buster; see for migration instructions. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#926576: ghostscript: printer stopped working: ghostscript fails with ""Unable to determine number of pages"
c Il giorno dom 7 apr 2019 alle ore 11:56 Till Kamppeter < till.kamppe...@gmail.com> ha scritto: > Does > > gs -o - -dNODISPLAY > > using Ghostscript 9.27, with being a PDF file which you do > not succeed to print due to this problem, give you a list of "Page XX" > lines for each page in the PDF file (plus some other irrelevant lines)? > I guess no. It's not file related. I get the same error with any file, even printing from the browser. > > Can you post the output of the command here? > leo@asbesto:~/Scaricati$ gs -o - -dNODISPLAY file_162654.pdf GPL Ghostscript 9.27 (2019-04-04) Copyright (C) 2018 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Processing pages 1 through 1. Page 1 Loading NimbusSans-Regular font from /usr/share/ghostscript/9.27/Resource/Font/NimbusSans-Regular... 4349448 2837965 3337976 1998733 4 done. Loading NimbusSans-Bold font from /usr/share/ghostscript/9.27/Resource/Font/NimbusSans-Bold... 4436528 3058081 3956024 2549354 4 done. Leonardo
Bug#926595: python3 can't import scipy.misc
Control: tags -1 + unreproducible moreinfo Hi Laurent, Perhaps you could include the output of $ apt-cache policy python3-numpy python3-scipy libblas3 for this report. > APT policy: (500, 'unstable'), (500, 'stable') this is not a promising sign btw. 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#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)
Hi Josh, Josh Triplett: > Recently, disabling the setting "Suspend when laptop lid is closed" > seems to have started preventing *any* action on lid close, including > locking the screen; Would you be interested in testing whether https://gitlab.gnome.org/GNOME/gnome-settings-daemon/merge_requests/84 fixes this problem for you? Cheers, -- intrigeri
Bug#913110: (no subject)
The report above appears to reference .local/jupyter/kernels/python3/kernel.json , which would be a user-local kernel file not installed by the package. If the kernel file is wrong, I don't think this is a bug in jupyter-notebook. If the system-installed kernel file /usr/share/jupyter/kernels/python3/kernel.json refers to python[2], that would be a bug in python3-ipykernel
Bug#926595: python3 can't import scipy.misc
Package: python3 Version: 3.7.3-1 Severity: important Tags: upstream Dear Maintainer, When trying to import scipy.misc in python3 [numpy scipy are both installed and were fonctionning correctly some weeks ago] I got the error below which accordingly to the debian user mailing list seems to be a bug. I insist that python3-numpy is installed. Best regards, :> from scipy.misc import * --- ModuleNotFoundError Traceback (most recent call last) ModuleNotFoundError: No module named 'numpy.core._multiarray_umath' --- ImportError Traceback (most recent call last) in () 4 from numpy import * 5 from numpy.random import * > 6 from scipy.misc import * 7 from scipy.stats import * /usr/lib/python3/dist-packages/scipy/misc/__init__.py in () 66 from numpy import who as _who, source as _source, info as _info 67 import numpy as np ---> 68 from scipy.interpolate._pade import pade as _pade 69 from scipy.special import (comb as _comb, logsumexp as _lsm, 70 factorial as _fact, factorial2 as _fact2, factorialk as _factk) /usr/lib/python3/dist-packages/scipy/interpolate/__init__.py in () 173 from __future__ import division, print_function, absolute_import 174 --> 175 from .interpolate import * 176 from .fitpack import * 177 /usr/lib/python3/dist-packages/scipy/interpolate/interpolate.py in () 18dot, ravel, poly1d, asarray, intp) 19 ---> 20 import scipy.linalg 21 import scipy.special as spec 22 from scipy.special import comb /usr/lib/python3/dist-packages/scipy/linalg/__init__.py in () 188 from .linalg_version import linalg_version as __version__ 189 --> 190 from .misc import * 191 from .basic import * 192 from .decomp import * /usr/lib/python3/dist-packages/scipy/linalg/misc.py in () 3 import numpy as np 4 from numpy.linalg import LinAlgError > 5 from .blas import get_blas_funcs 6 from .lapack import get_lapack_funcs 7 /usr/lib/python3/dist-packages/scipy/linalg/blas.py in () 212 import numpy as _np 213 --> 214 from scipy.linalg import _fblas 215 try: 216 from scipy.linalg import _cblas ImportError: numpy.core.multiarray failed to import -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3 depends on: ii libpython3-stdlib 3.7.3-1 ii python3-minimal3.7.3-1 ii python3.7 3.7.3-2 python3 recommends no packages. Versions of packages python3 suggests: pn python3-doc ii python3-tk3.7.3-1 pn python3-venv -- no debconf information
Bug#374039: #374039 shutdown -h -H: warn that then cannot poweroff perhaps
> Halt action is to halt or drop into boot monitor on systems that > support it." is not enough to convey, that in many cases it brings > machine into state, when it is still on, display still showing > letters, but no interation (except physical poweroff) is possible. That is what halt means - to stop running the system without powering off. > "Maybe -H is actually produces useful behaviour in some cases (no > idea), but please add into manpage warning like "Do not use -H option, > unless you really know what are you doing." Halting is often used to run through the shutdown process and leave output on the screen for debugging purposes. Or when you want the OS to stop, but leave the power on. There is no negative side-effect to using the -H option, no loss of data. There isn't any reason to print an extra warning. Which brings me back to the original bug report which read: "Well, I tried "-h -H", and guess what, it put my IBM Thinkpad in a unrebootable state... no button would respond, no way to poweroff either. I had to remove the AC cord, and remove the battery, to finally poweroff. So perhaps add a warning to the man page." The user could, in that case, just press and hold the power button for five seconds to power off the machine. There is no need to remove the AC power or take out the battery. Holding the power button works on all workstations and laptops made in the past 20 years. It's common practise for any time a machine hangs, has a kernel panic or stops responding to keyboard input.
Bug#926380: golang-github-puerkitobio-purell: FTBFS (failing tests)
Greetings from the Gothenburg BSP.
This is the output I get when reproducing this issue:
---8<->8-
--- FAIL: TestEncodeNecessaryEscapesAll (0.00s)
purell_test.go:761: Got error parse http://host/
� net/url: invalid control character in URL
FAIL
exit status 1
FAIL_/tmp/golang-github-puerkitobio-purell-1.1.00.003s
---8<->8-
net/url Parse now explicitly check that you don't pass in
"invalid" (non-encoded) urls and rejects them:
https://sources.debian.org/src/golang-1.11/1.11.6-1/src/net/url/url.go/?hl=498#L498
The NormalizeUrlString helper function starts out by passing the url
string to url.Parse:
https://sources.debian.org/src/golang-github-puerkitobio-purell/1.1.0-1/purell.go/#L153
The TestDecodeUnnecessaryEscapesAll function creates an url with control
characters and passes it to NormalizeURLString to try to get it
normalized/escaped.
I'd say the design of the NormalizeUrlString function is broken and thus
it's not obvious to me how to fix it. I'd say that if you have a
non-normalized string you want encoded, you should pass it in as
something that doesn't need to be parsed. ie. use NormalizeUrl helper
function, which takes an Url type.
Removing the NormalizeUrlString function however would be an API/ABI
break as it's publicly exported (and used by Hugo and Kubernetes)...
Maybe open-coding some homebrew url parsing to fall back on could be
done to keep the function around. Sounds bad to think you know
better than net/url how to parse an url though.
I'm attaching a patch which "fixes" this issue, but really it's most likely
a stupid and wrong things to do to solve this. It's just designed to
make the testsuite pass. As mentioned, I think the NormalizeURLString
function is incorrectly designed and there's no way to fix it (so should
be deprecated in favour of NormalizeURL).
Thus intentionally *not* tagging patch, as this is rather a "proof of
concept".
Regards,
Andreas Henriksson
diff -uriNp golang-github-puerkitobio-purell-1.1.0/purell.go golang-github-puerkitobio-purell-1.1.0-fixed/purell.go
--- golang-github-puerkitobio-purell-1.1.0/purell.go 2016-11-15 03:49:42.0 +0100
+++ golang-github-puerkitobio-purell-1.1.0-fixed/purell.go 2019-04-07 16:00:06.039745498 +0200
@@ -12,6 +12,7 @@ import (
"sort"
"strconv"
"strings"
+ "errors"
"github.com/PuerkitoBio/urlesc"
"golang.org/x/net/idna"
@@ -147,10 +148,43 @@ func MustNormalizeURLString(u string, f
return result
}
+func myURLParse(u string) (*url.URL, error) {
+ // first try to parse the url as normal and return it if successful
+ parsed, err := url.Parse(u)
+ if err == nil {
+ return parsed, nil
+ }
+
+ // path possibly contains control characters, which url.Parse
+ // doesn't allow. Try to parse url without path and then add it.
+
+ // find third / and assume that's where path starts.
+ parts := strings.SplitN(u, "/", 4)
+
+ var noPathURL string
+ if len(parts) != 4 {
+ return nil, errors.New("Failed to find start of path in url")
+ }
+ noPathURL = strings.Join(parts[:3], "/")
+
+ parsed, err = url.Parse(noPathURL)
+ if err != nil {
+ return nil, err
+ }
+
+ pathquery := strings.SplitN(parts[3], "#", 2)
+ parsed.Path = pathquery[0]
+ if len(pathquery) > 1 {
+ parsed.Fragment = pathquery[1]
+ }
+
+ return parsed, nil
+}
+
// NormalizeURLString returns the normalized string, or an error if it can't be parsed into an URL object.
// It takes an URL string as input, as well as the normalization flags.
func NormalizeURLString(u string, f NormalizationFlags) (string, error) {
- parsed, err := url.Parse(u)
+ parsed, err := myURLParse(u)
if err != nil {
return "", err
}
Bug#924840: highwayhash: FTBFS - symbol missing
I do see this bug in both sid and mostly-buster (I haven't tried
creating a new buster chroot). If only some people see this bug, but
who sees it is reproducible, that could be a sign of another problem
such as the package doing build-time hardware detection.
(https://sources.debian.org/src/highwayhash/0%7Egit20190222.276dd7b-1/README.md/#L24
says it provides both build-time-CPU-detection and
run-time-CPU-detection variants.)
It appears to be the same bug as #923255 (which is "arch-specific"
because the expected symbol list was updated for amd64), implying that
if it is caused by a change in other packages, it appeared between
2018-11-26 (gcc 8.2.0-10, glibc 2.27-8, binutils 2.31.1-8) and
2019-02-24 (gcc 8.2.0-21, glibc 2.28-7, binutils 2.21.1-14).
It is one of 4 symbol mismatch bugs (in different packages) found in
this archive rebuild run:
#924840 / #923255 highwayhash
(gdb) demangle
_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
0~20180209-g14dedec
void std::vector
>::_M_realloc_insertconst&>(__gnu_cxx::__normal_iteratorint, std::allocator > >, unsigned int const&)@Base
0~20180209-g14dedec
#924849 gatb-core
(gdb) demangle
_ZZN4gatb4core8debruijn4impl5bglueILm96EEEvPNS0_5tools7storage4impl7StorageENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiibENKUlRKNS0_4bank8SequenceEE_clESI_@Base
gatb::core::debruijn::impl::bglue<96ul>(gatb::core::tools::storage::impl::Storage*,
std::__cxx11::basic_string,
std::allocator >, int, int, int,
bool)::{lambda(gatb::core::bank::Sequence
const&)#1}::operator()(gatb::core::bank::Sequence const&) const@Base
#924841 lib3mf
(gdb) demangle
_ZNSt8_Rb_treeIjSt4pairIKjSt10shared_ptrIN3NMR14CModelResourceEEESt10_Select1stIS6_ESt4lessIjESaIS6_EE5eraseERS1_@Base
1.8.0+ds
std::_Rb_treestd::shared_ptr >,
std::_Select1ststd::shared_ptr > >, std::less,
std::allocatorstd::shared_ptr > > >::erase(unsigned int
const&)@Base 1.8.0+ds
#924819 libstatgen
(c++)"void std::vector
>::emplace_back(float&&)@Base" 1.0.14
The other 3 were fixed by updating the expected symbols list, and this
one probably could be as well, but that only fixes the FTBFS itself and
not any potential underlying issue.
As highwayhash has no rdeps in sid (it was packaged as a dependency of
tensorflow, which is only in experimental), doing nothing and allowing
it to be removed from buster may also be an option.
Bug#926575: Debidiff as a suggestion
On Sun, 2019-04-07 at 11:52 +0200, Christian Ehrhardt wrote: > This debdiff was test built against gpsd in experimental and works > fine with it. I expect I'll just make a new upstream release after buster. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#926594: unblock: jupyter-notebook/5.7.8-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package jupyter-notebook, 5.7.4-2.1 -> 5.7.8-1 (pending
approval before the latter version is uploaded to unstable).
There are two new CVEs since 5.7.4:
* CVE-2019-9644 (#924515)
* CVE-2019-10255 (#925939)
The diff between 5.7.4 and 5.7.8 upstream consists mostly of fixes for
these issues. There are also a couple of small non-security related bug
fixes. In principle two of these fixes are not needed (one concerning
MIME types relevant only on Windows, one concerning compatibility with a
newer major version of tornado, which is not yet in debian), but it
seems preferable to use the upstream changes unmodified rather than
selectively remove a small fraction of them.
unblock jupyter-notebook/5.7.8-1
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-3-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru jupyter-notebook-5.7.4/debian/changelog
jupyter-notebook-5.7.8/debian/changelog
--- jupyter-notebook-5.7.4/debian/changelog 2019-03-30 14:52:25.0
+
+++ jupyter-notebook-5.7.8/debian/changelog 2019-04-07 11:46:04.0
+
@@ -1,3 +1,11 @@
+jupyter-notebook (5.7.8-1) unstable; urgency=medium
+
+ * New upstream release 5.7.8
+ * Fixes CVE-2019-9644 (Closes: #924515)
+ * Fixes CVE-CVE-2019-10255 (Closes: #925939)
+
+ -- Gordon Ball Sun, 07 Apr 2019 11:46:04 +
+
jupyter-notebook (5.7.4-2.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru jupyter-notebook-5.7.4/docs/source/changelog.rst
jupyter-notebook-5.7.8/docs/source/changelog.rst
--- jupyter-notebook-5.7.4/docs/source/changelog.rst2018-12-17
10:01:51.0 +
+++ jupyter-notebook-5.7.8/docs/source/changelog.rst2019-04-01
10:22:11.0 +
@@ -21,6 +21,44 @@
Use ``pip install pip --upgrade`` to upgrade pip. Check pip version with
``pip --version``.
+.. _release-5.7.8:
+
+5.7.8
+-
+
+- Fix regression in restarting kernels in 5.7.5.
+ The restart handler would return before restart was completed.
+- Further improve compatibility with tornado 6 with improved
+ checks for when websockets are closed.
+- Fix regression in 5.7.6 on Windows where .js files could have the wrong
mime-type.
+- Fix Open Redirect vulnerability (CVE-2019-10255)
+ where certain malicious URLs could redirect from the Jupyter login page
+ to a malicious site after a successful login.
+ 5.7.7 contained only a partial fix for this issue.
+
+.. _release-5.7.6:
+
+5.7.6
+-
+
+5.7.6 contains a security fix for a cross-site inclusion (XSSI) vulnerability
(CVE-2019–9644),
+where files at a known URL could be included in a page from an unauthorized
website if the user is logged into a Jupyter server.
+The fix involves setting the ``X-Content-Type-Options: nosniff``
+header, and applying CSRF checks previously on all non-GET
+API requests to GET requests to API endpoints and the /files/ endpoint.
+
+The attacking page is able to access some contents of files when using
Internet Explorer through script errors,
+but this has not been demonstrated with other browsers.
+
+.. _release-5.7.5:
+
+5.7.5
+-
+
+- Fix compatibility with tornado 6 (:ghpull:`4392`, :ghpull:`4449`).
+- Fix opening integer filedescriptor during startup on Python 2
(:ghpull:`4349`)
+- Fix compatibility with asynchronous `KernelManager.restart_kernel` methods
(:ghpull:`4412`)
+
.. _release-5.7.4:
5.7.4
diff -Nru jupyter-notebook-5.7.4/notebook/auth/login.py
jupyter-notebook-5.7.8/notebook/auth/login.py
--- jupyter-notebook-5.7.4/notebook/auth/login.py 2018-12-17
10:01:51.0 +
+++ jupyter-notebook-5.7.8/notebook/auth/login.py 2019-04-01
10:22:11.0 +
@@ -7,9 +7,9 @@
import os
try:
-from urllib.parse import urlparse # Py 3
+from urllib.parse import urlparse, urlunparse # Py 3
except ImportError:
-from urlparse import urlparse # Py 2
+from urlparse import urlparse, urlunparse # Py 2
import uuid
from tornado.escape import url_escape
@@ -39,15 +39,23 @@
"""
if default is None:
default = self.base_url
-if not url.startswith(self.base_url):
+# protect chrome users from mishandling unescaped backslashes.
+# \ is not valid in urls, but some browsers treat it as /
+# instead of %5C, causing `\\` to behave as `//`
+url = url.replace("\\", "%5C")
+parsed = urlparse(url)
+path_only = urlunparse(parsed._replace(netloc='', scheme=''))
+if url != path_only or not (parsed.path +
'/').startswith(self.base_url):
Bug#926475: Uploads
Hi Bruno, On Sat, Apr 06, 2019 at 04:56:29AM +0200, Bruno Kleinert wrote: > Hi Stefan, > > that's great! I offer reviews and will sponsor uploads :) cool, thanks for the offer :). Preliminary package available: dget http://potyra.de/dlt-viewer/dlt-viewer_2.18.0+dfsg-1.dsc Please give it a thourough review. It's been some time since I last created a package... Cheers, Stefan. signature.asc Description: PGP signature
Bug#926418: [Pkg-libvirt-maintainers] Bug#926418: libvirt: CVE-2019-3886: virsh domhostname command discloses guest hostname in readonly mode
Hi Guido, On Fri, Apr 05, 2019 at 09:54:30PM +0200, Salvatore Bonaccorso wrote: > Hi Guido, > > On Fri, Apr 05, 2019 at 07:10:25PM +0200, Guido Günther wrote: > > Hi, > > On Thu, Apr 04, 2019 at 10:30:14PM +0200, Salvatore Bonaccorso wrote: > > > Source: libvirt > > > Version: 5.0.0-1 > > > Severity: important > > > Tags: security upstream > > > Forwarded: > > > https://www.redhat.com/archives/libvir-list/2019-April/msg00339.html > > > > > > Hi, > > > > > > The following vulnerability was published for libvirt. > > > > > > CVE-2019-3886[0]: > > > | An incorrect permissions check was discovered in libvirt 4.8.0 and > > > | above. The readonly permission was allowed to invoke APIs depending on > > > | the guest agent, which could lead to potentially disclosing unintended > > > | information or denial of service by causing libvirt to block. > > > > > > I'm filling it here as well for ruther investigation. Is this only > > > affecting versions >= 4.8.0? > > > > I'd assume this to affect older version as well (looking at the > > fix). I'll prepare an upload once upstream has this in git. > > Thanks. Yes I'm confused that it's claimed to be 4.8.0 onwards, but > the submitted fix would in theory apply. And https://bugzilla.novell.com/show_bug.cgi?id=1131595#c3 confirms somehow that >= 4.8.0 only looks strange. So let's assume it's affecting as well the older version were the commit applies. Regards, Salvatore
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
On Sun, 7 Apr 2019, Ivo De Decker wrote:
> Also, I'm not sure adding an init script now is an approriate change
> for the freeze.
It is, it only touches systems on which it previously did not work.
> Some other changes suggested in this bug (like changes in systemd)
> certainly are not.
This was discussed for later. Emmanuel agreed that, if those changes
were not implemented for buster, the suggested patch to restore user
creation with adduser (trivial, fits into less than an ANSI screen
page, easy to audit) can go into this for buster.
> This bug should not be used as an argument to force these kind of
> changes for buster.
Indeed, and that was never my intention.
I would like to respectfully ask that this *not* be buster-ignored,
and to review the attached patch, which has been tested to indeed
unbreak sysvinit (and fixed some bugs detected during that).
Thanks in advance,
//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 Steegdiff -Nru tomcat9-9.0.16/debian/README.Debian
tomcat9-9.0.16/debian/README.Debian
--- tomcat9-9.0.16/debian/README.Debian 2019-02-05 10:11:13.0 +0100
+++ tomcat9-9.0.16/debian/README.Debian 2019-04-01 16:26:55.0 +0200
@@ -54,6 +54,13 @@
systemctl daemon-reload
systemctl restart tomcat9
+⚠ This is supported only when Tomcat is started with the systemd unit.
+
+Using Tomcat with other init systems is supported, however that will
+negate the security hardening detailed above, make Tomcat not have
+its own temporary directory, not drop privileges/capabilities after
+start, and not be restarted on crashing. Use at your own risk.
+
* To run more than one Tomcat instance on your server, install the package
tomcat9-user and run the tomcat9-instance-create utility.
You should remove the tomcat9 package if you don't want Tomcat to
diff -Nru tomcat9-9.0.16/debian/changelog tomcat9-9.0.16/debian/changelog
--- tomcat9-9.0.16/debian/changelog 2019-02-26 09:31:13.0 +0100
+++ tomcat9-9.0.16/debian/changelog 2019-04-02 22:54:17.0 +0200
@@ -1,3 +1,21 @@
+tomcat9 (9.0.16-4) unstable; urgency=medium
+
+ * Team upload.
+ * debian/logging.properties: Add commented-out non-systemd configuration
+ * Make tomcat9 installable without systemd:
+- Readd logic to create the system user via adduser
+- Add sysvinit script, for init independence (Closes: #925473)
+ * debian/README.Debian: Document non-systemd risks
+ * debian/libexec/tomcat-locate-java.sh: Remove shebang and make
+not executable as this is only ever sourced (makes no sense otherwise)
+ * Make the systemd startup script honour the (renamed) $SECURITY_MANAGER
+ * Remove -XX:+UseG1GC from standard JAVA_OPTS; the JRE chooses
+a suitable GC automatically anyway (Closes: #925928)
+ * Correct the ownership and permissions on the log directory:
+group adm and setgid (Closes: #925929)
+
+ -- Thorsten Glaser Tue, 02 Apr 2019 22:54:17 +0200
+
tomcat9 (9.0.16-3) unstable; urgency=medium
* Removed read/write access to /var/lib/solr (Closes: #923299)
diff -Nru tomcat9-9.0.16/debian/control tomcat9-9.0.16/debian/control
--- tomcat9-9.0.16/debian/control 2019-02-05 10:53:30.0 +0100
+++ tomcat9-9.0.16/debian/control 2019-04-01 16:26:55.0 +0200
@@ -47,7 +47,7 @@
Architecture: all
Depends:
lsb-base (>= 3.0-6),
- systemd (>= 215),
+ systemd (>= 215) | adduser,
tomcat9-common (>= ${source:Version}),
ucf,
${misc:Depends}
diff -Nru tomcat9-9.0.16/debian/copyright tomcat9-9.0.16/debian/copyright
--- tomcat9-9.0.16/debian/copyright 2019-02-05 10:11:13.0 +0100
+++ tomcat9-9.0.16/debian/copyright 2019-04-01 16:26:55.0 +0200
@@ -49,6 +49,7 @@
2013-2014, Gianfranco Costamagna
2013-2018, Emmanuel Bourg
2001-2017, Markus Koschany
+ 2015–2019, mirabilos
License: Apache-2.0
License: Apache-2.0
diff -Nru tomcat9-9.0.16/debian/default.template
tomcat9-9.0.16/debian/default.template
--- tomcat9-9.0.16/debian/default.template 2019-02-05 10:11:13.0
+0100
+++ tomcat9-9.0.16/debian/default.template 2019-04-01 17:15:52.0
+0200
@@ -3,9 +3,10 @@
# OpenJDK and the Oracle JDK are tried.
#JAVA_HOME=/usr/lib/jvm/java-8-openjdk
-# You may pass JVM startup parameters to Java here. If unset, the default
-# options will be: -Djava.awt.headless=true -XX:+UseG1GC
-JAVA_OPTS="-Djava.awt.headless=true -XX:+UseG1GC"
+# You may pass JVM startup parameters to Java here. If you run Tomcat with
+# Java 8 instead of 9 or newer, add "-XX:+UseG1GC" to select a suitable GC.
+# If unset, the default options will be: -Djava.awt.headless=true
+JAVA_OPTS="-Djava.awt.headless=true"
# To enable remote debugging uncomment the
Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)
Control: tags -1 buster-ignore Hi, On Wed, Apr 03, 2019 at 02:33:47PM +0200, Thorsten Glaser wrote: > On Wed, 3 Apr 2019, Emmanuel Bourg wrote: > > > > I really insist on being able to install tomcat9 without having to > > > install a whole other init system, even if it is not used. > > > > See this as a compromise? > > I don’t know… the missing initscript is an RC bug, so the compromise > would start _after_ it’s added… I'm tagging this bug buster-ignore, because we're not going to delay buster for it. Also, I'm not sure adding an init script now is an approriate change for the freeze. Some other changes suggested in this bug (like changes in systemd) certainly are not. This bug should not be used as an argument to force these kind of changes for buster. Thanks, Ivo
Bug#923986: ruby-pygments.rb: FTBFS randomly (failing tests)
Santiago Vila wrote: > I tried to build this package in buster but it failed: Hm, I've just built this package 20 times in sid and the tests pass every time. > My recommendation is that the failing tests are simply disabled for buster. If it's a specific test, then I recommend just disabling that one or (better) explicitly marking it as XFAIL. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#916145: closure-compiler: Not working with recent JS code
Control: severity -1 important Hi, On Sun, Apr 07, 2019 at 11:16:53AM +0300, Adrian Bunk wrote: > > Adrian: you raised the severity, care to lower it until buster is > > out (or say some words on why)? > > IMHO the release team adding a buster-ignore tag would be the best way > forward here - this would still show up as RC bug for bullseye. No. Downgrading is the way forward. If you want to update the package for bullseye, filing an RC bug is not the way to do it. Joining the team and preparing a new package (after the freeze) is. Thanks, Ivo
Bug#905446: haskell-hackage-mirror: FTBFS: Module `Control.Monad.Trans.Resource' does not export `monadThrow'
This package is deprecated. https://github.com/fpco/hackage-mirror Regards
Bug#917203: FTBFS on at least two architectures: test failure in the enigma algorithm
tags 917203 + pending
thanks
I've uploaded libmcrypt 2.5.8-3.4 to DELAYED/5:
libmcrypt (2.5.8-3.4) unstable; urgency=medium
* Non-maintainer upload.
* Fix FTBFS on at least two architectures due to test failures in the
"enigma". Thanks to Göran Weinholt (weinholt) for the patch.
(Closes: #917203)
* Update Vcs-{Git,Browser} to point to salsa.debian.org.
The full debdiff is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diffstat for libmcrypt_2.5.8-3.3 libmcrypt_2.5.8-3.4
libmcrypt-2.5.8/debian/changelog | 10 ++
libmcrypt-2.5.8/debian/control |4 ++--
modules/algorithms/enigma.h | 10 +-
3 files changed, 17 insertions(+), 7 deletions(-)
diff -u libmcrypt-2.5.8/debian/changelog libmcrypt-2.5.8/debian/changelog
--- libmcrypt-2.5.8/debian/changelog
+++ libmcrypt-2.5.8/debian/changelog
@@ -1,3 +1,13 @@
+libmcrypt (2.5.8-3.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS on at least two architectures due to test failures in the
+"enigma". Thanks to Göran Weinholt (weinholt) for the patch.
+(Closes: #917203)
+ * Update Vcs-{Git,Browser} to point to salsa.debian.org.
+
+ -- Chris Lamb Sun, 07 Apr 2019 14:38:10 +0200
+
libmcrypt (2.5.8-3.3) unstable; urgency=low
* Non-maintainer upload.
diff -u libmcrypt-2.5.8/debian/control libmcrypt-2.5.8/debian/control
--- libmcrypt-2.5.8/debian/control
+++ libmcrypt-2.5.8/debian/control
@@ -3,8 +3,8 @@
Priority: optional
Maintainer: RISKO Gergely
Build-Depends: debhelper (>= 7.0.50), dh-autoreconf, libltdl-dev
-Vcs-Browser: http://git.debian.org/?p=collab-maint/libmcrypt.git;a=summary
-Vcs-Git: git://git.debian.org/collab-maint/libmcrypt.git
+Vcs-Browser: http://salsa.debian.org/debian/libmcrypt
+Vcs-Git: http://salsa.debian.org/debian/libmcrypt.git
Homepage: http://mcrypt.sourceforge.net/
Standards-Version: 3.8.1
--- libmcrypt-2.5.8.orig/modules/algorithms/enigma.h
+++ libmcrypt-2.5.8/modules/algorithms/enigma.h
@@ -3,11 +3,11 @@
#define MASK 0377
typedef struct crypt_key {
- char t1[ROTORSZ];
- char t2[ROTORSZ];
- char t3[ROTORSZ];
- char deck[ROTORSZ];
- char cbuf[13];
+ signed char t1[ROTORSZ];
+ signed char t2[ROTORSZ];
+ signed char t3[ROTORSZ];
+ signed char deck[ROTORSZ];
+ signed char cbuf[13];
int n1, n2, nr1, nr2;
} CRYPT_KEY;
Bug#900912: Enabling jaw (Java-atk-wrapper) by default ? (Bug#900912)
If enabled by default, please offer a reliable way for applications to disable it. We don't need it for JOSM, and we have been so impacted with jaw's problems in the past years that we will never want it enabled by default for us. Le dim. 7 avr. 2019 à 12:08, Samuel Thibault a écrit : > Hello, > > Matthias Klose, le sam. 06 avril 2019 15:46:21 +0200, a ecrit: > > On 06.04.19 15:13, Paul Gevers wrote: > > > We're late already, I would want this rather sooner than latter > > > in buster, such that there is some real live testing before we release. > > > Sure, there are chances for bugs, but if that's the case, let's find > > > them and fix them. > > > > I disagree. I'll do the next upload with Samuel's proposed patches, not > > enabling that by default, together with the planned security update. > Then > > people can start testing if the wrapper works. > > Well, I'm afraid that what will happen is that the people who will > test will simply find out that it just works for them (just like it > does already for them with openjdk-8) ; will we then conclude near the > release that it should be enabled by default for Buster, and then be hit > by the much wider exposition to jaw? > > If on the contrary we enable it by default during the freeze, we will > have *way* more testing coverage, and thus be much more confident with > keeping it enabled by default in Buster if we don't see bug reports. > > > Enabling features during the freeze which were broken most of the time > > during the development cycle sounds risky. > > Just ftr: what was broken was the load of jaw in openjdk-11, jaw itself > seems to work in openjdk-8 for people needing it. > > Samuel >
Bug#926479: Interesting ..
Hi, that is very interesting, thanks for pulling me in. Since the same tests ran in Ubuntu for quite a while I checked it, but it looks good across the board [1] and since you posted an amd64 fail I checked that for Xenial [2] and Bionic [3] which both look non flaky to me on our infrastructure at least. However that was just a statement for the overall status. They seem to be flaky for you, so let us take a look why. To reproduce I did: $ autopkgtest-build-lxd images:debian/sid/amd64 $ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --test-name=daemon --no-built-binarie s --apt-upgrade --shell-fail strongswan_5.7.2-1.dsc -- lxd images:debian/sid/amd64 That really gave me in Debian the failing services ?! why would that be different? The command above gives you a login into the just failed test environment and there really is no pid for the daemon. This also does not resolve over time. The reason is that normally a started service would look like: ● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf Loaded: loaded (/lib/systemd/system/strongswan.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-04-07 12:05:59 UTC; 2min 20s ago Main PID: 14806 (starter) Tasks: 18 (limit: 547) Memory: 4.9M CGroup: /system.slice/strongswan.service ├─14806 /usr/lib/ipsec/starter --daemon charon --nofork └─14845 /usr/lib/ipsec/charon Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading aa certificates from '/etc/ Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading ocsp signer certificates fr Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading attribute certificates from Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading crls from '/etc/ipsec.d/crl Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[CFG] loading secrets from '/etc/ipsec.se Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[LIB] loaded plugins: charon aes rc2 sha2 Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[LIB] dropped capabilities, running as ui Apr 07 12:05:59 disco-checklvm-pass charon[14845]: 00[JOB] spawning 16 worker threads Apr 07 12:05:59 disco-checklvm-pass ipsec[14806]: charon (14845) started after 40 ms Apr 07 12:05:59 disco-checklvm-pass ipsec_starter[14806]: charon (14845) started after 40 ms But on the Debian test it is like: systemctl status strongswan .service ● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf Loaded: loaded (/lib/systemd/system/strongswan.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sun 2019-04-07 12:00:56 UTC; 8min ago Main PID: 1120 (code=exited, status=0/SUCCESS) Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: 00[CFG] expanding file expression '/var/li b/strongswan/ipsec.secrets.inc' failed Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: 00[LIB] failed to load 2 critical plugin f eatures Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: 00[DMN] initialization failed - aborting c haron Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: charon has quit: initialization failed Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: charon refused to be started Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec_starter[1120]: charon has quit: initialization fa iled Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec[1120]: ipsec starter stopped Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec_starter[1120]: charon refused to be started Apr 07 12:00:56 autopkgtest-lxd-gstxpo ipsec_starter[1120]: ipsec starter stopped Apr 07 12:00:56 autopkgtest-lxd-gstxpo systemd[1]: strongswan.service: Succeeded. The other tests work in the container environment, but the daemon itself needs a VM to load modules and fails in containers. The reason it is flaky might be that it runs on VMs sometimes and on Containers in the other cases. The fix for that would be simple, how about: diff --git a/debian/tests/control b/debian/tests/control index eb9e20463c..b6afafd29d 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,3 +1,7 @@ -Tests: daemon admin-strongswan-charon admin-strongswan-starter plugins +Tests: admin-strongswan-charon admin-strongswan-starter plugins Depends: strongswan, libstrongswan-standard-plugins, libstrongswan-extra-plugins, libcharon-e xtra-plugins, strongswan-pki, strongswan-scepclient Restrictions: needs-root isolation-container allow-stderr + +Tests: daemon +Depends: strongswan-starter +Restrictions: needs-root isolation-machine allow-stderr I have no Debian VM that supports autopkgtest, maybe you could upload that to experimental or the QA team could otherwise help to verify the suggestion. Or - if you want - you can take the change as is, as it should be really safe. [1]: http://autopkgtest.ubuntu.com/packages/strongswan [2]: http://autopkgtest.ubuntu.com/packages/strongswan/xenial/amd64 [3]: http://autopkgtest.ubuntu.com/packages/strongswan/bionic/amd64 -- Christian Ehrhardt Software
Bug#926592: Buffer overflow in readlink running under fakechroot
Package: fakechroot Version: 2.19-3 In an up-to-date installation of stretch, I do this: fakechroot readlink /etc/ssl/certs/* and get this: *** Error in readlink: free(): invalid next size (fast): 0xee312140 *** Note that this is *not* in a faked chroot. Looking at the source code: readlink allocates a small buffer for the linked filename, and relies on the readlink() call returning a truncated value if the buffer overflows. But the replacement readlink() in libfakechroot calls the original function with a huge buffer, and if a faked chroot is not in effect then it just copies the whole result to the caller. The file names in /etc/ssl/certs are long enough for this to cause an overflow. I haven't investigated to see how much damage this could cause if (e.g.) a specially-crafted malicious file name were used.
