Bug#919551: O: gemmlowp -- small self-contained low-precision GEMM library
Package: wnpp Severity: normal I intend to orphan the gemmlowp package. This package is a dependency of TensorFlow
Bug#919550: O: farmhash -- FarmHash, a family of hash functions
Package: wnpp Severity: normal I intend to orphan the farmhash package. This package is a dependency of TensorFlow.
Bug#919553: O: nsync -- C library that exports various synchronization primitives
Package: wnpp Severity: normal I intend to orphan the nsync package. This package is a tensorflow dependency
Bug#919552: O: highwayhash -- Fast strong hash functions: SipHash/HighwayHash
Package: wnpp Severity: normal I intend to orphan the highwayhash package. this package is a dependency of tensorflow
Bug#919549: ITP: kylin-nm -- Gui Applet tool for display and edit network simply
Package: wnpp Severity: wishlist Owner: handsome_feng * Package name: kylin-nm Version : 1.0.0 Upstream Author : shine * URL : http://github.com/ukui/kylin-nm * License : GPL-3+ Programming Lang: C++ Description : Gui Applet tool for display and edit network simply Kylin-nm is a Applet tool for managing network settings simply. It has beautiful UI and very comfortable to use. This package will be maintained by Kylin Team.
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Hi Samuel,
First, I have to say that I switched keycodes 66 and 118 by editing
/usr/share/X11/xkb/keycodes/evdev and switched the Orca modifier to
Insert, which gives me an environment I can work with again, although
it's a nasty workaround.
So just beware that 66 (CAPS) and 118 (INS) have been switched, nothing
else.
Samuel Thibault wrote:
> Could you post the output of
>
> xkbcomp $DISPLAY -
Is attached.
Best regards
Robert
xkb_keymap {
xkb_keycodes "(unnamed)" {
minimum = 8;
maximum = 255;
= 9;
= 10;
= 11;
= 12;
= 13;
= 14;
= 15;
= 16;
= 17;
= 18;
= 19;
= 20;
= 21;
= 22;
= 23;
= 24;
= 25;
= 26;
= 27;
= 28;
= 29;
= 30;
= 31;
= 32;
= 33;
= 34;
= 35;
= 36;
= 37;
= 38;
= 39;
= 40;
= 41;
= 42;
= 43;
= 44;
= 45;
= 46;
= 47;
= 48;
= 49;
= 50;
= 51;
= 52;
= 53;
= 54;
= 55;
= 56;
= 57;
= 58;
= 59;
= 60;
= 61;
= 62;
= 63;
= 64;
= 65;
= 66;
= 67;
= 68;
= 69;
= 70;
= 71;
= 72;
= 73;
= 74;
= 75;
= 76;
= 77;
= 78;
= 79;
= 80;
= 81;
= 82;
= 83;
= 84;
= 85;
= 86;
= 87;
= 88;
= 89;
= 90;
= 91;
= 92;
= 94;
= 95;
= 96;
= 97;
= 98;
= 99;
= 100;
= 101;
= 102;
= 103;
= 104;
= 105;
= 106;
= 107;
= 108;
= 109;
= 110;
= 111;
= 112;
= 113;
= 114;
= 115;
= 116;
= 117;
= 118;
= 119;
= 120;
= 121;
= 122;
= 123;
= 124;
= 125;
= 126;
= 127;
= 128;
= 129;
= 130;
= 131;
= 132;
= 133;
= 134;
= 135;
= 136;
= 137;
= 138;
= 139;
= 140;
= 141;
= 142;
= 143;
= 144;
= 145;
= 146;
= 147;
= 148;
= 149;
= 150;
= 151;
= 152;
= 153;
= 154;
= 155;
= 156;
= 157;
= 158;
= 159;
= 160;
= 161;
= 162;
= 163;
= 164;
= 165;
= 166;
= 167;
= 168;
= 169;
= 170;
= 171;
= 172;
= 173;
= 174;
= 175;
= 176;
= 177;
= 178;
= 179;
= 180;
= 181;
= 182;
= 183;
= 184;
= 185;
= 186;
= 187;
= 188;
= 189;
= 190;
= 191;
= 192;
= 193;
= 194;
= 195;
= 196;
= 197;
= 198;
= 199;
= 200;
= 201;
= 202;
= 203;
= 204;
= 205;
= 206;
= 207;
= 208;
= 209;
= 210;
= 211;
= 212;
= 213;
= 214;
= 215;
= 216;
= 217;
= 218;
= 219;
= 220;
= 221;
= 222;
= 223;
= 224;
= 225;
= 226;
= 227;
= 228;
= 229;
= 230;
= 231;
= 232;
= 233;
= 234;
= 235;
= 236;
= 237;
= 238;
= 239;
= 240;
= 241;
= 242;
= 243;
= 244;
= 245;
= 246;
= 247;
= 248;
= 249;
= 250;
= 251;
= 252;
= 253;
indicator 1 = "Caps Lock";
indicator 2 = "Num Lock";
indicator 3 = "Scroll Lock";
indicator 4 = "Compose";
indicator 5 = "Kana";
indicator 6 = "Sleep";
indicator 7 = "Suspend";
indicator 8 = "Mute";
indicator 9 = "Misc";
indicator 10 = "Mail";
indicator 11 = "Charging";
indicator 12 = "Shift Lock";
indicator 13 = "Group 2";
indicator 14 = "Mouse Keys";
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
alias = ;
};
xkb_types "(unnamed)" {
virtual_modifiers
NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper,Kana_Lock;
type "ONE_LEVEL" {
modifiers= none;
level_name[Level1]= "Any";
};
type "TWO_LEVEL" {
modifiers= Shift;
map[Shift]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Shift";
};
type "ALPHABETIC" {
modifiers= Shift+Lock;
map[Shift]= Level2;
map[Lock]= Level2;
level_name[Level1]= "Base";
level_name[Level2]= "Caps";
};
type "KEYPAD" {
modifiers= Shift+NumLock;
map[Shift]= Level2;
map[NumLock]= Level2;
Bug#919417: orca: Orca reads character by character when holding navigation keys pressed
Hi Samuel, Samuel Thibault wrote: > Control: tags -1 + moreinfo > Do you mean: on your system the synthesis keeps saying the whole > character, and all characters, while you would rather that the synthesis > stops as soon as moving to another character, to the point that > characters are never spoken entirely, but just a glimpse? Yes, exactly. > If so, it happens that on my system I am getting that latter behavior, > with speech dispatcher 0.8, espeak-ng, and orca 3.31.4, so it seems > something is different with your system... > > Which desktop are you using? Which application are you trying with? It's Gnome 3 and gnome-terminal, all from Buster. Orca is frmo experimental (3.31.4-1). Just tried with gedit, which is affected as well. To reproduce: 1. Open gedit with a file that has some lines, maybe 10+. 2. Move the cursor to the beginning of the document. 3. Keep Arrow Down pressed for 3 seconds. 4. Orca will read line by line, although the cursor reached the last line long ago. Best regards Robert signature.asc Description: PGP signature
Bug#919256: dnssec-trigger: Failed to upgrade: installed dnssec-trigger package post-installation script subprocess returned error exit status 1
On Wed, 2019-01-16 at 08:55 +0100, Axel Beckert wrote: > > > # summary of how this script can be called: > #* `configure' > [...] > case "$1" in > configure) > # configure the control channel if run for the first time > if [ -z "$2" ]; then > dnssec-trigger-control-setup > fi > ;; > > So as I read it, dnssec-trigger-control-setup is only called if there > was no previously configured version installed and is hence never > called when upgrading the package and hence never removes, the too > small old keys on upgrade. > I'm tired enough I wanted to double check the logic of a solution before trying to implement it. the check to remove too small keys should probably be moved out of dnssec-trigger-control-setup and into the postinst script. Then the "if [ -z "$2" ]" conditional in the post should be replaced with checking for the existence of the keys instead of the package version number to decide if the control-setup script is called. Something like configure) debian_remove_small_keys $SERVER debian_remove_small_keys $CONTROL if [ \! -e /etc/dnssec-trigger/dnssec_trigger_control.key ]; then dnssec-trigger-control-setup fi How's that sound to you? Diane
Bug#919402: devscripts: [salsa] documentation mentions both SALSA_TOKEN and SALSA_PRIVATE_TOKEN
Le 16/01/2019 à 21:58, Daniel Kahn Gillmor a écrit : > On Tue 2019-01-15 18:54:19 +0100, Xavier wrote: >> this feature allows one to use another file that contains one of this >> fields. This permits compatibility with dpt(1) tool (from >> pkg-perl-tools) which uses a ~/.dpt.conf that contains >> >> DPT_SALSA_PRIVATE_TOKEN= >> >> So this is not a bug ;-). Maybe documentation isn't clear on this. > > definitely not clear! i was setting this up and trying to understand > what i should choose here -- if i used _PRIVATE_, will it be treated > differently than if i did not? why should i choose one or the other? > > an update to the documentation that makes it clearer what's happening > would be great. > > thanks for helping to maintain devscripts! > >--dkg Is this better? diff --git a/scripts/salsa.pl b/scripts/salsa.pl index 6cc9a234..e1084b20 100755 --- a/scripts/salsa.pl +++ b/scripts/salsa.pl @@ -43,11 +43,17 @@ or SALSA_TOKEN_FILE=~/.dpt.conf -If you choose to link another file, it must contain a line with something like: +If you choose to link another file using SALSA_TOKEN_FILE, it must contain a +line with something like: SALSA_PRIVATE_TOKEN= SALSA_TOKEN= +This allows for example to use dpt(1) configuration file (~/.dpt.conf) which +contains: + + DPT_SALSA_PRIVATE_TOKEN=abcdefghi + =head1 COMMANDS =head2 Managing users and groups
Bug#919507: Packaging policy to flag unattended-upgrades reboot
Hi Karl, Thank you for bringing this up. On Thu, Jan 17, 2019 at 7:10 AM Karl O. Pinc wrote: > > Hello, > > Do you have any suggestions for updating the > Debian Policy docs so that packagers know what > must be done to inform when an update requires > a reboot? > > I filed the following bugs against debian-policy > and systemd: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919507 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919509 > thinking that packages are supposed to provide > breadcrumbs so that unattended-upgrades knows when > a package upgrade requires a reboot. > > I've been invited to submit a patch to Debian policy. > > But looking at the packaging of packages I _thought_ > flagged reboots I don't see anything. > > I know the kernel flags a reboot, but see that > unattended-upgrades is dropping a config into > /etc/kernel/postinst.d/. > > I thought libc6 flagged a reboot, but can't find > anything. > > I've got an email from a box that flagged a > reboot on upgrade of tomcat8, but can't find > anything in the packaging. Why I got an email is > now a mystery. > > I would think that having the unattended-upgrade > package have to keep track of which packages > require reboot would not scale I agree. I was surprised too, when I found the scripts for the kernel in unattended-upgrades. Please note that in Ubuntu update-notifier-common also ships a similar hook: /etc/kernel/postinst.d/update-notifier -> /usr/share/update-notifier/notify-reboot-required I agree that packages should ask for reboot themselves, but I'm OK with keeping the current logic in u-u for the kernels. Regarding the policy change I'd also mention /var/run/reboot-required.pkgs , like this: Maintainer scripts can signal that a reboot is required to fully apply the changes to the system by touching /var/run/reboot-required and adding the package name to /var/run/reboot-required.pkgs. Maintainer scripts should not add the package name to /var/run/reboot-required.pkgs if it is already present there. Thanks, Balint > > Thanks. > > Regards, > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > > P.S. Somebody on #debian-mentors was able to do a > search today for all the packages which, I think, > contained mention of "reboot-required". I don't > know what they did or how they did it. > There was a list of maybe 15 or 20 packages, > but the remark was that some of these are > tool-related. (?) I forget the details. > -- Balint Reczey Ubuntu & Debian Developer
Bug#919548: pdftk-java: please, update the new version 3.0.3
Package: pdftk-java
Version: 3.0.2-1
Severity: normal
Tags: upstream
Hi.
I have discovered a bug with pdftk versions 3.0.2 and earlier and I reported
the bug upstream [0] and a fix was committed [1].
A new upstream version was tagged yesterday [2].
[0]: https://gitlab.com/pdftk-java/pdftk/issues/13
[1]:
https://gitlab.com/pdftk-java/pdftk/commit/e61c4744dba7bf553954f8b8afb1feba5e54422b
[2]: https://gitlab.com/pdftk-java/pdftk/tags/v3.0.3
It would be really, really nice to have a robust version of pdftk released
with buster.
Thanks in advance,
Rogério Brito.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages pdftk-java depends on:
ii default-jre-headless [java8-runtime-headless] 2:1.11-71
ii libbcprov-java1.60-1
ii libcommons-lang3-java 3.8-2
ii openjdk-11-jre-headless [java8-runtime-headless] 11.0.1+13-3
pdftk-java recommends no packages.
Versions of packages pdftk-java suggests:
ii poppler-utils [xpdf-utils] 0.71.0-2
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#919547: projectile: Homepage URL is obsolete
Control: tags -1 + patch On 17-Jan-2019, Ben Finney wrote: > Please set the “Homepage” field to the current project URL, > https://www.projectile.mx/>. I have created a merge request addressing this bug, now available at https://salsa.debian.org/emacsen-team/projectile/merge_requests/2>. -- \ “Our urge to trust our senses overpowers what our measuring | `\ devices tell us about the actual nature of reality.” —Ann | _o__) Druyan, _Cosmos_, 2014 | Ben Finney
Bug#919183: julia: baseline violation on armhf
control: severity -1 important This is not baseline violation. julia -C "armv7-a;armv7-a,neon;armv7-a,neon,vfp4" compiles 3 branches of code, and the optimal branch will be selected during runtime. The SIGILL raised during build on the buildd stems from LLVM's incorrect CPU detection. Here is a proof with QEMU emulated ARM Cortex-a7: (sid_armhf-dchroot)lumin@abel:~$ julia Invalid ARM instruction at 0xad4253d0: 0xf2800050 signal (4): Illegal instruction in expression starting at no file:0 __init__ at ./sysinfo.jl:92 jl_apply_generic at /usr/bin/../lib/arm-linux-gnueabihf/libjulia.so.1 (unknown line) unknown function (ip: 0xb6d7e006) unknown function (ip: 0xb6d6e43a) julia_init__threading at /usr/bin/../lib/arm-linux-gnueabihf/libjulia.so.1 (unknown line) unknown function (ip: 0x44df2c) __libc_start_main at /lib/arm-linux-gnueabihf/libc.so.6 (unknown line) unknown function (ip: 0x44dfc4) Allocations: 3006 (Pool: 3002; Big: 4); GC: 0 Illegal instruction (sid_armhf-dchroot)lumin@abel:~$ qemu-arm -cpu cortex-a7 julia Error while loading julia: Permission denied (sid_armhf-dchroot)lumin@abel:~$ qemu-arm -cpu cortex-a7 /usr/bin/julia _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_)| _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.0.3 _/ |\__'_|_|_|\__'_| | Debian ⛬ julia/1.0.3+dfsg-1 |__/ | julia>
Bug#919547: projectile: Homepage URL is obsolete
Source: projectile Version: 2.0.0-1 Severity: minor The current value of the “Homepage” field leads to a page that informs the reader that the project has moved to a different URL. Please set the “Homepage” field to the current project URL, https://www.projectile.mx/>. -- \ “The process by which banks create money is so simple that the | `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It | _o__) Came, Where It Went_, 1975 | Ben Finney
Bug#919500: golang-github-grpc-ecosystem-grpc-gateway: build dependency on golang-google-genproto-dev must be bumped to (>= 0.0~git20190111.db91494)
Dear Go team, I pushed a fix on Salsa, can you please review and upload these changes? Thanks! Regards, Arnaud
Bug#919546: xinput-calibrator FTCBFS: configures for the wrong architecture
Source: xinput-calibrator Version: 0.7.5+git20140201-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap xinput-calibrator fails to cross build from source, because it configures for the build architecture. It actually configures twice. Once via autogen.sh (for the wrong architecture) and once via dh_auto_configure. It also runs autoreconf twice. Once via dh_autoreconf and once via autogen.sh. So it seems that autogen.sh is rather counterproductive. The only thing it changes is passing --enable-maintainer-mode to ./configure, but we can tell dh_auto_configure to do that. Once dropping the autogen.sh call, xinput-calibrator cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru xinput-calibrator-0.7.5+git20140201/debian/changelog xinput-calibrator-0.7.5+git20140201/debian/changelog --- xinput-calibrator-0.7.5+git20140201/debian/changelog2014-02-09 12:36:38.0 +0100 +++ xinput-calibrator-0.7.5+git20140201/debian/changelog2019-01-17 05:48:50.0 +0100 @@ -1,3 +1,10 @@ +xinput-calibrator (0.7.5+git20140201-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: ./configure once only via dh_auto_configure. (Closes: #-1) + + -- Helmut Grohne Thu, 17 Jan 2019 05:48:50 +0100 + xinput-calibrator (0.7.5+git20140201-1) unstable; urgency=low * Initial release. (Closes: #592073) diff --minimal -Nru xinput-calibrator-0.7.5+git20140201/debian/rules xinput-calibrator-0.7.5+git20140201/debian/rules --- xinput-calibrator-0.7.5+git20140201/debian/rules2014-02-09 12:28:25.0 +0100 +++ xinput-calibrator-0.7.5+git20140201/debian/rules2019-01-17 05:48:44.0 +0100 @@ -5,5 +5,4 @@ dh $@ --with autoreconf override_dh_auto_configure: - ./autogen.sh - dh_auto_configure + dh_auto_configure -- --enable-maintainer-mode
Bug#919545: ITP: c-graph -- interactive visualization tool for the convolution theorem
Package: wnpp Owner: Paul Hardy Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: c-graph Version: 2.0.1 Upstream Author: Adrienne Gaye Thompson URL: https://www.gnu.org/software/c-graph/ License: GPL-3+, GFDL-1.3+ Programming Language: Fortran 95 Description: interactive visualization tool for the convolution theorem GNU C-Graph is a novel tool for visualizing the mathematical operation of convolution. "C-Graph" is an abbreviation for "Convolution Graph". A game changer, C-Graph -- the de facto tool for visualizing the convolution theorem in universities worldwide -- is invaluable for lecture demonstrations and lab work in the teaching of signals and systems, as well as other courses featuring convolution. GNU C-Graph is widely used across industries that utilize signal processing techniques for design, test, and development: telecommunications, instrumentation and control, manufacturing, automotive, aviation and aerospace, medical devices, and others. This nifty package seamlessly generates publication quality graphics for papers, lecture demonstrations, and other professional presentations. . GNU C-Graph is interactive, prompting the user to enter character or numerical values from the keyboard - dispensing with the learning curve for writing code. A Texinfo manual provides sample sessions and an overview of the convolution theorem. C-Graph computes the linear convolution of two signals in the time domain then compares their circular convolution by demonstrating the convolution theorem. Each signal is modeled by a register of discrete values simulating samples of a signal, and the discrete Fourier transform (DFT) computed by means of the fast Fourier transform (FFT). . Select, Transform, Visualize : GNU C-Graph makes visualizing convolution easy Uploading this package will close the associated RFP bug #694088 filed in 2012. -- Paul Hardy
Bug#908524: closed by Jeremy Bicha (Bug#908524: fixed in pipewire 0.2.5-1)
Control: reopen 908524 Control: reopen 919544 Control: block 908524 by 919544 Control: summary 908524 Section corrected in package metadata. This bug is not fixed until package override is changed (bug#919544). On 2018-09-11, Ben Finney wrote: > Since the package is already in Debian with a different section, you > will also need to submit a request to override the existing section > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#override-file>. > > Then mark that new bug report as blocked by this one, to show the > dependency between them. -- \“Good morning, Pooh Bear”, said Eeyore gloomily. “If it is a | `\ good morning”, he said. “Which I doubt”, said he. —A. A. Milne, | _o__)_Winnie-the-Pooh_ | Ben Finney
Bug#820069: dhcpcd5: configures interface without being asked to
severity 820069 important
tags 820069 security
I was hit by this bug last night. After plugging a new Internet provider
into my local network, my Debian router automatically added an IP address
and default route to the new device. This resulted in my entire home's
Internet access being disrupted as the router tried to route traffic via
the new device. What's worse is that when the default route is removed
it's automatically added back.
dhcpcd is STILL bringing up this interface even after disabling the DHCP
server on the AT device. The IP address that dhcpcd added is not visible
in ifconfig. It only shows up when you run 'ip addr list'.
This is very serious security bug. This bug could easily be exploited by
an attacker to force routing of traffic via the attacker's device.
Relevant logs/config files:
Jan 17 03:56:32 raspberrypi dhcpcd[16922]: eth0: Router Advertisement from
fe80:[removed]
Jan 17 03:56:32 raspberrypi dhcpcd[16922]: eth0: adding address [removed
ipv6 address]
Jan 17 03:56:32 raspberrypi dhcpcd[16922]: eth0: soliciting a DHCPv6 lease
Jan 17 03:56:35 raspberrypi dhcpcd[16922]: eth0: leased 192.168.1.67 for
86400 seconds
Jan 17 03:56:35 raspberrypi dhcpcd[16922]: eth0: adding route to
192.168.1.0/24
Jan 17 03:56:35 raspberrypi dhcpcd[16922]: eth0: adding default route via
192.168.1.254
/etc/network/interfaces.d/eth0
==
auto eth0
iface eth0 inet static
address [removed]
netmask 255.255.255.0
auto eth0:0
allow-hotplug eth0:0
iface eth0:0 inet static
address 192.168.1.1
netmask 255.255.255.0
/etc/dhcpcd.conf
===
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
subnet [removed] netmask 255.255.255.0 {
range [removed] [removed];
option broadcast-address [removed];
option routers [removed];
default-lease-time 600;
max-lease-time 7200;
option domain-name "local-network";
option domain-name-servers 8.8.8.8, 8.8.4.4;
}
interface eth0
static ip_address [removed]
static domain_name_servers=8.8.8.8 8.8.4.4
Bug#908524: pipewire: Move to “Section: net”
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: severity -2 normal Control: retitle -2 override: pipewire:net/optional Howdy FTPmasters, At the package maintainer's request, please move the ‘pipewire’ binary package to “Section: net” to match its latest metadata. On 04-Jan-2019, Jeremy Bicha wrote: > Ben or Laurent, do one of you want to submit the follow-up bug report > to fully change the section? Okay. This message should create that bug report, I believe. -- \ “I went camping and borrowed a circus tent by mistake. I didn't | `\ notice until I got it set up. People complained because they | _o__) couldn't see the lake.” —Steven Wright | Ben Finney
Bug#910295: dput FTBFS: tests fail: socket.gaierror: [Errno -2] Name or service not known
Control: tags -1 + confirmed On 04-Oct-2018, Helmut Grohne wrote: > At least the vast majority of failures is due to a similar > socket.gaierror. I confirm that this behaviour is reproducible in a new SBuild chroot, created with ‘sbuild-debian-developer-setup’ (version “0.78.0-2”). The behaviour is not specific to SBuild chroot though. It also occurs when running the test suite in a normal development environment. I suspect there's something changed with the ‘httpretty’ testing library; either that, or something changed in recent Python 3 versions. -- \ “A man must consider what a rich realm he abdicates when he | `\ becomes a conformist.” —Ralph Waldo Emerson | _o__) | Ben Finney
Bug#912633: Possible conflict betwwen courier-imap and courier-imap-ssl?
Hi all, I have just run into this same issue and its a bit of a pain. One thing I notivce however is that I have: # dpkg -l | grep courier-imap ii courier-imap 5.0.5+1.0.5-1 amd64 Courier mail server - IMAP server ii courier-imap-ssl 4.18.1+0.78.0-2 all Courier mail server - IMAP over TLS [transitional] I also notice thatt these two are compiled from different source packages: # apt-cache show courier-imap Package: courier-imap Source: courier (1.0.5-1) Version: 5.0.5+1.0.5-1 # apt-cache show courier-imap-ssl Package: courier-imap-ssl Source: courier (0.78.0-2) Version: 4.18.1+0.78.0-2 I also know that courier-imap-ssl depends on courier-imap but I wonder if the fact they are compiled from different versions of the source package is relevant. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Bug#919543: apt: when installing with deb file, prerm maintainer script doesn't pass new-package-name before it's replaced due to conflict
Package: apt Version: 1.2.19 Severity: normal Dear Maintainer, I am creating a deb packages which will replace another package. And before the old package are removed, I want to check whether the package is remove due to **replace** operation or a simple **uninstall** operation. In man page of `deb-prerm`, I found that when a package is replaced due to conflict, the prerm script of old package can be called in the following way: `prerm remove in-favour new-package new-version`. Therefore, I add some script in prerm of old package and opreate with the shell script variables. If I use `dpkg` to install these .deb packages, it will work perfectly. However, it does not pass any new package information if I use `apt` to install these packages. Is it an existing bug? I have searched for a while and have not found any relevant content. Many thanks, Allen Yang -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^linux-image-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^linux-headers-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^linux-headers-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^gnumach-image-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^gnumach-image-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^.*-modules-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^.*-modules-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^.*-kernel-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^.*-kernel-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.15\.0-43-generic$"; APT::NeverAutoRemove:: "^linux-tools-4\.15\.0-42-generic$"; APT::NeverAutoRemove:: "^linux-tools-4\.15\.0-43-generic$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "0"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Periodic::Unattended-Upgrade "1"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "touch /var/lib/apt/periodic/update-success-stamp 2>/dev/null || true"; APT::Update::Post-Invoke-Success:: "[ ! -f /var/run/dbus/system_bus_socket ] || /usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt org.debian.apt.CacheChanged || true"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh > /dev/null; fi"; APT::Update::Post-Invoke-Success:: "/usr/lib/update-notifier/update-motd-updates-available 2>/dev/null || true"; APT::Archives ""; APT::Archives::MaxAge "30"; APT::Archives::MinAge "2"; APT::Archives::MaxSize "500"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Architectures:: "i386"; APT::Compressor ""; APT::Compressor::. "";
Bug#919542: RFA: nethack-el -- Emacs major-mode for playing NetHack
Package: wnpp Severity: normal I no longer use nethack-el nor have the time to maintain it properly anymore, so I'm looking for someone to take over this package. The package description is: Nethack is a wonderfully silly, yet quite addicting, Dungeons and Dragons-style adventure game. You play the part of a fierce fighter, wizard, or any of many other classes, fighting your way down to retrieve the Amulet of Yendor (try saying THAT one backwards!) for your god. On the way, you might encounter a quantum mechanic or two, or perhaps a microscopic space fleet, or -- if you're REALLY lucky -- the Ravenous Bugblatter Beast of Traal. . Features of NetHack for Emacs include: * Customizable Keys * Event Hooks * Customizable colors * And all the power of Emacs
Bug#656750: [monkeysphere] Bug#656750: monkeysphere: wrongly preserves TMPDIR across accounts
tags 656750 + patch
thanks
On Mon, 23 Jan 2012 12:55:58 -0500 Daniel Kahn Gillmor
wrote:
> On 01/23/2012 12:19 PM, Jameson Graef Rollins wrote:
> > It occurs to me that we already have/use a tmp directory in the
> > monkeysphere authentication directory
> > (/var/lib/monkeysphere/authentication/tmp). Maybe we should just
> > explicitly set TMPDIR for the monkeysphere user to be that?
>
> Doing this and documenting it clearly seems like a reasonable approach
> to me.
>
> --dkg
>
The attached patch fixes the problem. Patch sets TMPDIR to
/var/lib/monkeysphere/authentication/tmp only when needed, but I have
tested other cases where temporary directory was being created.
* Need Change
- monkeysphere-host: add_revoker: with key from a remote server and with
key file.
- monkeysphere-host: publish_key:
- monkeysphere-authentication: add_certifier: with key from remote
server and with key file.
* No change needed:
- monkeysphere-host: show_key: does not use monkeysphere user.
- monkeysphere-host: revoke_key: does not use monkeysphere user. So any
temporary directory works.
- monkeysphere: import_subkey: does not use monkeysphere user. Not
implemented yet.
- monkeysphere: gen_subkey: does not use monkeysphere user.
- monkeysphere-authentication: update_users: Creates files that are fed
to less privileged process via stdin. Could not test properly.
With this change, I am hoping for a new release of monkeysphere suitable
for FreedomBox in buster.
Thanks,
--
Sunil
From 34b83f6ee26d527d415f033fd57db6bfe81eed90 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa
Date: Wed, 16 Jan 2019 16:15:21 -0800
Subject: [PATCH] Better sharing of temp directory across root and monkeysphere
user
In a couple of cases, monkeysphere commands running as run create a temporary
directory in TMPDIR (provided by environment) and then change the
ownership/permissions on that directory for monkeysphere user to use that
directory.
This works in a normal setup but fails when libpam-tmpdir is installed. This PAM
module causes the tmp directory to be /tmp/user/0/ so that it is harder to for
users to access each other temporary files. This improves security but causes
problem for above situation as the parent directory of the directory to be
shared is not allowed access by other users.
To fix this, explicitly set the TMPDIR to a known location that can be used to
share files across users. /var/lib/monkeysphere/authentication/tmp is a
directory that is already being setup and used for such purposes. Reuse it
instead of created a new one. Apply the fix conservatively only in cases needed.
Closes: #656750.
Signed-off-by: Sunil Mohan Adapa
---
src/monkeysphere-host | 9 +
src/share/ma/add_certifier | 15 ++-
src/share/mh/add_revoker | 13 +++--
src/share/mh/publish_key | 1 +
4 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/src/monkeysphere-host b/src/monkeysphere-host
index 089c2b6..1f47df0 100755
--- a/src/monkeysphere-host
+++ b/src/monkeysphere-host
@@ -30,6 +30,15 @@ MHSHAREDIR="${SYSSHAREDIR}/mh"
# datadir for host functions
MHDATADIR="${SYSDATADIR}/host"
+# temp directory to enable sharing a temporary directory between root and
+# monkeysphere users. This is needed so that on secure environments with
+# libpam-tmpdir, simply changing ownership/permissions on a directory is not
+# enough to share the directory. Parent directories such as /tmp/user/0 will be
+# inaccessible to monkeysphere user.
+#
+# XXX: Reusing monkeysphere-authentication's tmp directory.
+MHTMPDIR="${SYSDATADIR}/authentication/tmp"
+
# host pub key files
HOST_KEY_FILE="${SYSDATADIR}/host_keys.pub.pgp"
diff --git a/src/share/ma/add_certifier b/src/share/ma/add_certifier
index bd9885c..498bb68 100644
--- a/src/share/ma/add_certifier
+++ b/src/share/ma/add_certifier
@@ -98,15 +98,28 @@ if [ -f "$keyID" -o "$keyID" = '-' ] ; then
log verbose "reading key from file '$keyID'..."
fi
+TMPDIR=$MATMPDIR
+tmpDir=$(msmktempdir)
+trap "rm -rf $tmpDir" EXIT
+
+# fix permissions and ownership on temporary directory which will
+# be used by monkeysphere user
+chmod 0700 "$tmpDir"
+chown "$MONKEYSPHERE_USER":"$MONKEYSPHERE_GROUP" "$tmpDir"
+
# check the key is ok as monkeysphere user before loading
log debug "checking keys in file..."
-fingerprint=$(run_as_monkeysphere_user \
+fingerprint=$(run_as_monkeysphere_user /usr/bin/env TMPDIR=$tmpDir \
bash -c "$(printf ". %q && list_primary_fingerprints" "${SYSSHAREDIR}/common")" < "$keyID")
if [ $(printf "%s" "$fingerprint" | egrep -c '^[A-F0-9]{40}$') -ne 1 ] ; then
failure "There was not exactly one gpg key in the file."
fi
+# remove the temporary directory
+trap - EXIT
+rm -rf "$tmpDir"
+
# load the key
gpg_sphere --import <"$keyID" 2>/dev/null \
|| failure "could not read key from '$keyID'"
diff --git a/src/share/mh/add_revoker
Bug#919541: RFS: blastem/0.6.1-1 [ITP] -- Fast and accurate Genesis emulator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "blastem" * Package name: blastem Version : 0.6.1-1 Upstream Author : Carlos Donizete Froes * URL : https://gitlab.com/coringao/blastem * License : GPL-3+ Section : games It builds those binary packages: blastem - Fast and accurate Genesis emulator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/blastem Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/blastem/blastem_0.6.1-1.dsc More information about BlastEm can be obtained from https://www.retrodev.com/blastem. Regards, Carlos Donizete Froes [a.k.a coringao]
Bug#912799: doxygen switch to llvm-toolchain-7
Hello Paolo, On 16. 01. 19 13:03, Paolo Greppi wrote: Hi Jiri, Il 16/01/19 03:05, Jiri Palecek ha scritto: Hello, On Mon, 3 Dec 2018 12:54:45 +0100 Paolo Greppi wrote: Hi, in preparation for this switch I am building doxygen from source with: ... I have been able to build the package successfully without this problem by patching the source with the attached llvm-7 patch. That was with release version 1.8.15. Thanks ! in the meantime I had created a similar one, inspired by an upstream issue: https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/patches/llvm_libs.diff The patch I picked is smaller than the other two, and seems to work so I'm inclined to keep it. But I am no cmake expert, so I am open to suggestions if there is a cmake/llvm specific reason to pick one or the other. I picked the gist of my patch from this email thread (about linking to llvm, read its other messages if you're interested): https://lists.llvm.org/pipermail/llvm-dev/2017-November/119119.html It says "the guidance should be to use the `llvm_config` CMake function instead. The proper usage of that in the example there would be to replace the call to `llvm_map_components_to_libnames` with `llvm_config(simple-tool support core irreader)`" and says you need the USE_SHARED parameter if you're linking dynamically. The macro then automatically computes which of the components are in the dynamic library and removes the static libraries from link. However if you just want to remove the components from the list and it works, I'm cool with that. I also needed an updated watch file and an updated no-rpath patch. watch file: check https://salsa.debian.org/paolog-guest/doxygen/commit/ab3cc38776cdef8fb18184fbc7290dd1bdaf3fa7 Good. re. rpath, while refreshing patches I removed a previous rpath patch: https://salsa.debian.org/paolog-guest/doxygen/commit/8622b2378a726a324266c2ccf234fa0f31e1551b#0e176d0b80fb8a20ce16f62f30644d9678caee76 can you explain the need to have this ? Simply, we don't want rpath binaries in Debian. See https://wiki.debian.org/RpathIssue. Solution taken directly from there. The doxygen library is linked with rpath set (and a mistaken one at that) therefore the need. But here we're talking about doxygen, which I ITA, that's why I have RFS an upload to experimental: https://bugs.debian.org/919413 BTW before we push to unstable, it would be great to building all (~700) reverse dependencies of doxygen against doxygen 1.8.15-1 . If you have comments/can help with that, you're welcome. Whoa, 700 packages! Are these reverse-BDs? what are you planning to check, just that it builds? Regards Jiri Palecek
Bug#919475: xterm: No resize larger than display size?
On Wed, Jan 16, 2019 at 01:10:24PM +0100, Jan-Benedict Glaw wrote: > Package: xterm > Version: 342-1 > > Hi! > > I was used to resize the uxterm window quite larger than the actual > root window size (and move the window to see parts of it), which may > be useful for stuff presenting quite long lines. This used to work at > least in version 327-2, and didn't work in 338-1 nor current 342-1. > > Bisecting it down, it seems this bug was introduced with the import > of 334. Though I didn't find an obvious entry in XTerm's changelog. How did you move it? Perhaps related to this, from #336: revise omitTranslation resource, e.g., splitting “default” into several more useful categories -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Bug#919540: ITP: blastem -- The fast and accurate Genesis emulator
Package: wnpp Severity: wishlist Owner: Carlos Donizete Froes * Package name: blastem Version : 0.6.1 Upstream Author : Carlos Donizete Froes * URL : https://www.retrodev.com/blastem * License : GPL-3+ Programming Lang: C Description : The fast and accurate Genesis emulator BlastEm is a highly precise multi-system emulator that emulates the Sega Genesis/Mega Drive, Master System and Game Gear. . Despite this high accuracy, even the most demanding software runs at full speed on modest hardware.
Bug#917812:
Sorry about the cut-off lines in the log. Here it is again. Jan 17 02:27:03 Melchior-2 dbus-daemon[870]: [session uid=1000 pid=870] Activating service name='org.gnome.Software' requested by ':1.10' (uid=1000 pid=907 comm="/usr/bin/gnome-shell ") Jan 17 02:27:03 Melchior-2 dbus-daemon[870]: [session uid=1000 pid=870] Successfully activated service 'org.gnome.Software' Jan 17 02:27:06 Melchior-2 gnome-software[1660]: plugin appstream took 3,0 seconds to do setup Jan 17 02:27:06 Melchior-2 gnome-software[1660]: enabled plugins: desktop-categories, fwupd, os-release, packagekit, packagekit-local, packagekit-offline, packagekit-proxy, packagekit-refine-repos, packagekit-refresh, packagekit-upgrade, packagekit-url-to-app, shell-extensions, appstream, desktop-menu-path, flatpak, hardcoded-blacklist, hardcoded-featured, hardcoded-popular, modalias, packagekit-refine, rewrite-resource, steam, odrs, packagekit-history, provenance, systemd-updates, generic-updates, provenance-license, icons, key-colors, key-colors-metadata Jan 17 02:27:06 Melchior-2 gnome-software[1660]: disabled plugins: dpkg, dummy, repos, epiphany Jan 17 02:27:06 Melchior-2 dbus-daemon[494]: [system] Activating via systemd: service name='org.freedesktop.PackageKit' unit='packagekit.service' requested by ':1.94' (uid=1000 pid=1660 comm="/usr/bin/gnome-software --gapplication-service ") Jan 17 02:27:06 Melchior-2 systemd[1]: Starting PackageKit Daemon... Jan 17 02:27:06 Melchior-2 PackageKit[1666]: daemon start Jan 17 02:27:06 Melchior-2 dbus-daemon[494]: [system] Successfully activated service 'org.freedesktop.PackageKit' Jan 17 02:27:06 Melchior-2 systemd[1]: Started PackageKit Daemon. Jan 17 02:27:06 Melchior-2 PackageKit[1666]: uid 1000 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0) Jan 17 02:27:06 Melchior-2 PackageKit[1666]: uid 1000 obtained auth for org.freedesktop.packagekit.system-sources-refresh Jan 17 02:27:10 Melchior-2 packagekitd[1666]: terminate called after throwing an instance of 'std::length_error' Jan 17 02:27:10 Melchior-2 packagekitd[1666]: what(): basic_string::_M_replace Jan 17 02:27:10 Melchior-2 systemd[1]: packagekit.service: Main process exited, code=killed, status=6/ABRT Jan 17 02:27:10 Melchior-2 systemd[1]: packagekit.service: Failed with result 'signal'.
Bug#382457: rp-pppoe: enable pppoe-server kernel mode
Control: tags -1 patch Dear Maintainer, In Ubuntu, the attached patch was applied to achieve the following: - debian/control: Add Build-Depend on ppp-dev. - debian/rules: Specify "--enable-plugin" to get kernel PPPoE support. - debian/patches/09_remove-ppp-plugin-path.patch: Remove plugin path so that pppoe-server uses ppp's plugin directory. - debian/patches/10_fix-in6.h-include.patch: Fix in6.h include to get kernel PPPoE support. * debian/patches/11_reorder-includes.patch: Reorder includes in src/rpppoe.h to fix FTBFS. Thanks for considering the patch. Logan Rosen -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-13-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru rp-pppoe-3.12/debian/control rp-pppoe-3.12/debian/control --- rp-pppoe-3.12/debian/control2016-12-25 05:07:18.0 -0500 +++ rp-pppoe-3.12/debian/control2019-01-15 22:02:09.0 -0500 @@ -3,7 +3,7 @@ Standards-Version: 3.9.8 Section: net Priority: optional -Build-Depends: debhelper (>= 9) +Build-Depends: debhelper (>= 9), ppp-dev Uploaders: Lee Garrett Package: pppoe diff -Nru rp-pppoe-3.12/debian/patches/09_remove-ppp-plugin-path.patch rp-pppoe-3.12/debian/patches/09_remove-ppp-plugin-path.patch --- rp-pppoe-3.12/debian/patches/09_remove-ppp-plugin-path.patch 1969-12-31 19:00:00.0 -0500 +++ rp-pppoe-3.12/debian/patches/09_remove-ppp-plugin-path.patch 2013-02-05 08:20:32.0 -0500 @@ -0,0 +1,11 @@ +--- a/src/Makefile.in b/src/Makefile.in +@@ -49,7 +49,7 @@ + + # Kernel-mode plugin gets installed here. + PLUGIN_DIR=/etc/ppp/plugins +-PLUGIN_PATH=$(PLUGIN_DIR)/rp-pppoe.so ++PLUGIN_PATH=rp-pppoe.so + + # Configuration file paths + PPPOESERVER_PPPD_OPTIONS=/etc/ppp/pppoe-server-options diff -Nru rp-pppoe-3.12/debian/patches/10_fix-in6.h-include.patch rp-pppoe-3.12/debian/patches/10_fix-in6.h-include.patch --- rp-pppoe-3.12/debian/patches/10_fix-in6.h-include.patch 1969-12-31 19:00:00.0 -0500 +++ rp-pppoe-3.12/debian/patches/10_fix-in6.h-include.patch 2019-01-15 22:01:50.0 -0500 @@ -0,0 +1,10 @@ +--- a/src/configure b/src/configure +@@ -3709,6 +3709,7 @@ + #include + #include + #include ++#include + + " + if test "x$ac_cv_header_linux_if_pppox_h" = xyes; then : diff -Nru rp-pppoe-3.12/debian/patches/11_reorder-includes.patch rp-pppoe-3.12/debian/patches/11_reorder-includes.patch --- rp-pppoe-3.12/debian/patches/11_reorder-includes.patch 1969-12-31 19:00:00.0 -0500 +++ rp-pppoe-3.12/debian/patches/11_reorder-includes.patch 2019-01-15 22:02:09.0 -0500 @@ -0,0 +1,22 @@ +--- a/src/pppoe.h b/src/pppoe.h +@@ -51,6 +51,10 @@ + #include + #endif + ++/* This has to be included before Linux 4.8's linux/in.h ++ * gets dragged in. */ ++#include ++ + /* Ugly header files on some Linux boxes... */ + #if defined(HAVE_LINUX_IF_H) + #include +@@ -131,8 +135,6 @@ + #include + #endif + +-#include +- + #ifdef HAVE_NETINET_IF_ETHER_H + #include + diff -Nru rp-pppoe-3.12/debian/patches/series rp-pppoe-3.12/debian/patches/series --- rp-pppoe-3.12/debian/patches/series 2018-12-02 10:24:34.0 -0500 +++ rp-pppoe-3.12/debian/patches/series 2019-01-15 22:02:09.0 -0500 @@ -1,3 +1,4 @@ +11_reorder-includes.patch 01_auto_ifup.patch 02_change_mac_option.patch 03_man_pages.patch @@ -5,3 +6,6 @@ 05_change_default_timeout.patch 06_typo_fixes.patch 07_pppoestart-echo.patch +09_remove-ppp-plugin-path.patch +10_fix-in6.h-include.patch diff -Nru rp-pppoe-3.12/debian/rules rp-pppoe-3.12/debian/rules --- rp-pppoe-3.12/debian/rules 2016-12-25 05:08:49.0 -0500 +++ rp-pppoe-3.12/debian/rules 2019-01-15 21:58:11.0 -0500 @@ -11,7 +11,7 @@ build-indep: build-stamp build-stamp: dh_testdir - test -f src/Makefile || (cd src && PPPD=/usr/sbin/pppd ./configure) + test -f src/Makefile || (cd src && PPPD=/usr/sbin/pppd ./configure --enable-plugin) $(MAKE) -C src touch build-stamp
Bug#917812:
I'm also affected by this bug. The following lines from journalctl appear to be relevant - PackageKit crashes like this every time gnome-software is started. Jan 17 02:27:03 Melchior-2 dbus-daemon[870]: [session uid=1000 pid=870] Activating service name='org.gnome.Software' requested by ':1.10' (uid=1000 pi Jan 17 02:27:03 Melchior-2 dbus-daemon[870]: [session uid=1000 pid=870] Successfully activated service 'org.gnome.Software' Jan 17 02:27:06 Melchior-2 gnome-software[1660]: plugin appstream took 3,0 seconds to do setup Jan 17 02:27:06 Melchior-2 gnome-software[1660]: enabled plugins: desktop-categories, fwupd, os-release, packagekit, packagekit-local, packagekit-offl Jan 17 02:27:06 Melchior-2 gnome-software[1660]: disabled plugins: dpkg, dummy, repos, epiphany Jan 17 02:27:06 Melchior-2 dbus-daemon[494]: [system] Activating via systemd: service name='org.freedesktop.PackageKit' unit='packagekit.service' requ Jan 17 02:27:06 Melchior-2 systemd[1]: Starting PackageKit Daemon... Jan 17 02:27:06 Melchior-2 PackageKit[1666]: daemon start Jan 17 02:27:06 Melchior-2 dbus-daemon[494]: [system] Successfully activated service 'org.freedesktop.PackageKit' Jan 17 02:27:06 Melchior-2 systemd[1]: Started PackageKit Daemon. Jan 17 02:27:06 Melchior-2 PackageKit[1666]: uid 1000 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0) Jan 17 02:27:06 Melchior-2 PackageKit[1666]: uid 1000 obtained auth for org.freedesktop.packagekit.system-sources-refresh Jan 17 02:27:10 Melchior-2 packagekitd[1666]: terminate called after throwing an instance of 'std::length_error' Jan 17 02:27:10 Melchior-2 packagekitd[1666]: what(): basic_string::_M_replace Jan 17 02:27:10 Melchior-2 systemd[1]: packagekit.service: Main process exited, code=killed, status=6/ABRT Jan 17 02:27:10 Melchior-2 systemd[1]: packagekit.service: Failed with result 'signal'.
Bug#919531: lintian: "Could not determine what you meant by: tag:foo"
Please see this MR for a fix: https://salsa.debian.org/lintian/lintian/merge_requests/129
Bug#919539: rsync: --preallocate is broken
Package: rsync Version: 3.1.3-1 The --preallocate flag is meant to allocate blocks in the filesystem without actually changing the filesize. In the most recent update, the --preallocate option stopped working; it now allocates but fails to keep_size. The expected behavior is for the filesize to start at zero and then grow during the transfer. The preallocation+keep_size failure has a significant negative impact on our backup system. This can lead to data-corruption. Upstream already has a patch in git master: f3873b3d88b61167b106e7b9227a20147f8f6197 Please pull this patch asap for Buster.
Bug#919538: /usr/bin/mnemosyne: can't activate cramming scheduler
Package: mnemosyne Version: 2.4-0.1 Severity: normal File: /usr/bin/mnemosyne Dear Maintainer, I wen't in to the Settings/Manage plugins menu. I clicked the checkbox for the Cramming scheduler. When I clicked Ok to activate it I got the following error message An unexpected error has occurred. Please forward the following info to the developers: Traceback (innermost last): File "/usr/lib/python3/dist-packages/mnemosyne/pyqt_ui/manage_plugins_dlg.py", line 84, in accept self.plugin_with_name[plugin_name].activate() File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/plugin.py", line 54, in activate component = component(self.component_manager) TypeError: 'PrefillTagBehaviourPlugin' object is not callable -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mnemosyne depends on: ii libjs-sphinxdoc 1.4.9-2 ii libqt5sql5-sqlite 5.7.1+dfsg-3+b1 ii python3 3.5.3-1 ii python3-cherrypy3 3.5.0-2 ii python3-matplotlib 2.0.0+dfsg1-2 ii python3-pyqt5 5.7+dfsg-5 ii python3-pyqt5.qtsql 5.7+dfsg-5 ii python3-pyqt5.qtwebchannel 5.7+dfsg-5 ii python3-pyqt5.qtwebengine 5.7+dfsg-5 ii python3-webob 1:1.6.2-2 mnemosyne recommends no packages. mnemosyne suggests no packages. -- no debconf information
Bug#919537: surf: fails to download files due to AppArmor profile
Package: surf Version: 2.0+git20181009-3 Severity: normal Dear Maintainer, I am unable to download files with surf. When I follow a link that should trigger a download, such as a link to a .tar.gz file, I see this error message in the terminal: surf: execvp x-terminal-emulator failed: Permission denied And I see this AppArmor audit message: [10250.579596] audit: type=1400 audit(1547686146.856:308): apparmor="DENIED" operation="exec" profile="/usr/bin/surf" name="/usr/bin/lxterm" pid=17839 comm="surf" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 Thanks, Leo -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages surf depends on: ii libc6 2.28-5 ii libgcr-base-3-1 3.28.0-4 ii libgcr-ui-3-1 3.28.0-4 ii libglib2.0-0 2.58.2-3 ii libgtk-3-03.24.2-3 ii libwebkit2gtk-4.0-37 2.22.5-1 ii libx11-6 2:1.6.7-1 Versions of packages surf recommends: ii curl 7.62.0-1 ii suckless-tools 44-1 ii x11-utils7.7+4 ii xterm [x-terminal-emulator] 342-1 Versions of packages surf suggests: ii apparmor 2.13.2-3 -- no debconf information
Bug#919371: mono won't migrate to testing, still b-d on gcc-5
OK, I have a status update on this. * I can't get a minimal patch set against mono-2018-06 branch (Mono 5.16) which builds the entire release to completion on s390x on versions of gcc with PIC/PIE by default (Debian gcc-6 or later) * I picked the version I uploaded, on the basis that it is part of the `vs` packaging branch on mono-project.com, which mirrors what last went into a stable release of Visual Studio for Mac (and hopefully should have something resembling a vendor support story) * I _can_ get a minimal patch set against mono-2018-08 (Mono 5.18) * 5.18 Should not cause any major changes at a packaging level, compared to 5.16 (i.e. it should not go into binary NEW) * 5.18 is considered "stable" by the Mono runtime team, but not yet by the Visual Studio for Mac team (the standalone runtime doesn't get QA before releases, only as part of a larger VSMac release cycle) * 5.18 might totally break on other architectures! There is no MIPS testing upstream, so mipsel might be broken on any given release (upstream builds for i386, armel, armhf, arm64, amd64, and ppc64el) I don't want to preempt any product announcements, but 5.18 may ship significantly faster than originally planned, meaning investing too much time in fixing up 5.16 this week may be wasted, compared to 5.18 closer to *mumble mumble*. I'll discuss with relevant stakeholders tomorrow. On 15/01/2019 07:37, Jo Shields wrote: > Thanks for the tracking bug. I spotted this last night and am working on > zelenka to convince the damn thing to build - it's something to do with PIE, > and only shows up as a problem with the Runtime crashing in the literal last > 30 seconds of the build step > > Sent from my iPhone > >> On 15 Jan 2019, at 05:45, Matthias Klose wrote: >> >> Package: src:mono >> Version: 5.16.0.220+dfsg3-2 >> Severity: serious >> Tags: sid buster >> >> mono won't migrate to testing, still b-d on gcc-5 on s390x. >> >
Bug#919458: lintian: add tag for empty executables
Emilio Pozuelo Monfort wrote... > Could we add a lintian tag for empty executables, particularly in PATH? Then > we > could turn that into an autoreject (after analysing the results when > lintian.debian.org is updated) and help prevent this kind of brokenness in the > future. As a data point: At least three packages that entered the archive in 2018 had zero-size executables in /usr/s?bin/. The interesting part though is these were built on Debian buildds (as part of a binNMU). All were from the same source package that probably has a flaw in the build system, the maintainer is already aware of that. Still I think it's a good idea to add the check as suggested. Addionally I'd like to suggest to check for zero-size compressed files as well since I fail to see why anyone would ship them[1] - severity not more than warning, though. There is already "empty-manual-page", my proposal was somewhat a superset of that. There a quite a few packages that ship such files. Besides manpages, there is often /usr/share/doc/*/changelog.gz for whatever reason. Empty files bzip2 or xz compressed have existed at least in the past, full mirror scan is still running. Christoph [1] Test data is a notable exception: /usr/lib/python3/dist-packages/khmer/tests/test-data/empty-file.bz2 /usr/lib/python3/dist-packages/khmer/tests/test-data/empty-file.gz signature.asc Description: PGP signature
Bug#704089: tzdata config script prevents non-interactive (re)configuration
On Wed, Jan 16, 2019 at 11:43:57AM +0100, Aurelien Jarno wrote: > I don't think the patch is correct. Debconf is not a registry, the > canonical location for the configuration is the configuration files, not > the debconf database. Quoting debconf-devel(7): > > "The issue to watch out for here is that debconf is not intended to be, > and must not be used as a registry." > > I think it also applies when DEBCONF_RECONFIGURE is set. That's interesting, but also very confusing. If your assumption is correct, what is the point of being able to run dpkg-reconfigure in non-interactive mode? You can only reconfigure a package that is already installed, so (as I understand it) if the debconf registry is supposed to be clobbered by whatever the actual system configuration is before use, that would mean `dpkg-reconfigure -fnoninteractive ` is a completely useless and pointless command. Let's look at the dash package $ sudo debconf-get-selections | grep dash # Use dash as the default system shell (/bin/sh)? dashdash/sh boolean true $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jan 24 2017 /bin/sh -> dash $ echo dash dash/sh boolean false | sudo debconf-set-selections $ sudo debconf-get-selections | grep dash # Use dash as the default system shell (/bin/sh)? dashdash/sh boolean false $ sudo dpkg-reconfigure -fnoninteractive dash Removing 'diversion of /bin/sh to /bin/sh.distrib by dash' Adding 'diversion of /bin/sh to /bin/sh.distrib by bash' Removing 'diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz by dash' Adding 'diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz by bash' $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jan 17 10:55 /bin/sh -> bash $ The dash package reconfiguration has no issues modifying the system configuration based on debconf. I would expect tzdata to behave in a consistent manner with other packages. Regards, Adam signature.asc Description: PGP signature
Bug#919507: Fw: Packaging policy to flag unattended-upgrades reboot
Begin forwarded message: Date: Wed, 16 Jan 2019 18:10:04 -0600 From: "Karl O. Pinc" To: Michael Vogt , Balint Reczey Subject: Packaging policy to flag unattended-upgrades reboot Hello, Do you have any suggestions for updating the Debian Policy docs so that packagers know what must be done to inform when an update requires a reboot? I filed the following bugs against debian-policy and systemd: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919507 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919509 thinking that packages are supposed to provide breadcrumbs so that unattended-upgrades knows when a package upgrade requires a reboot. I've been invited to submit a patch to Debian policy. But looking at the packaging of packages I _thought_ flagged reboots I don't see anything. I know the kernel flags a reboot, but see that unattended-upgrades is dropping a config into /etc/kernel/postinst.d/. I thought libc6 flagged a reboot, but can't find anything. I've got an email from a box that flagged a reboot on upgrade of tomcat8, but can't find anything in the packaging. Why I got an email is now a mystery. I would think that having the unattended-upgrade package have to keep track of which packages require reboot would not scale Thanks. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein P.S. Somebody on #debian-mentors was able to do a search today for all the packages which, I think, contained mention of "reboot-required". I don't know what they did or how they did it. There was a list of maybe 15 or 20 packages, but the remark was that some of these are tool-related. (?) I forget the details. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Bug#919507: debian-policy: Policy contains no mention of /var/run/reboot-required
On Wed, 16 Jan 2019 15:28:05 -0700 Sean Whitton wrote: > > If Debian supports user notification when reboot is required > > (or automatic rebooting) after automatic upgrade then there > > should be some consistent standard. And that standard > > should be documented. Someplace. > It seems fine to document this in Policy. > > A patch would be welcome. I have contacted the unattended-upgrade package maintainers for guidance. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
Bug#919162: lintian.d.o apears to report many failures twice
On Wed, Jan 16, 2019 at 11:03:25PM +, Chris Lamb wrote: > TIL we check both x86 architectures. Why do we do this out of > interest? Are there examples of tags we would only find on one but > not the other...? At the very least, the tag checking for LFS (large file support) is emitted only on i386 binaries. I expect there can easily be some other similar cases. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#919458: lintian: add tag for empty executables
tags 919458 + pending thanks Hi Emilio, > Could we add a lintian tag for empty executables, particularly in PATH? Then > we > could turn that into an autoreject (after analysing the results when > lintian.debian.org is updated) and help prevent this kind of brokenness in the > future. Note that this would have been picked up by: https://lintian.debian.org/tags/executable-not-elf-or-script.html … but a stronger/louder message is indeed warranted here. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#919536: surf: Warnings and AppError audit messages about GPU
Package: surf Version: 2.0+git20181009-2.1 Severity: minor Dear Maintainer, My apologies for spamming you with a bunch of different AppArmor issues. I am trying to understand and differentiate the issues myself; please let me know if it would be better for me just to send you a list of all of the errors. There are several error messages related to GL and Mesa, which I'm trying to understand better because of broader GPU stability issues on my Raspberry Pi 3B+. When I start surf, I see the following warnings: libGL error: MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information I also see the following AppArmor audit messages which look like they might be related: [ 6898.198526] audit: type=1400 audit(1547682794.480:160): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/class/video4linux/" pid=6003 comm="gst-plugin-scan" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6906.716855] audit: type=1400 audit(1547682802.996:161): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6906.720022] audit: type=1400 audit(1547682802.996:162): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6906.720086] audit: type=1400 audit(1547682802.996:163): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6906.720111] audit: type=1400 audit(1547682802.996:164): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6908.851155] audit: type=1400 audit(1547682805.132:165): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6908.852661] audit: type=1400 audit(1547682805.132:166): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6908.852715] audit: type=1400 audit(1547682805.132:167): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 6908.852745] audit: type=1400 audit(1547682805.132:168): apparmor="DENIED" operation="open" profile="/usr/bin/surf" name="/sys/devices/platform/soc/soc:gpu/uevent" pid=5984 comm="ositorWorkQueue" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Thanks, Leo -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages surf depends on: ii libc6 2.28-5 ii libgcr-base-3-1 3.28.0-4 ii libgcr-ui-3-1 3.28.0-4 ii libglib2.0-0 2.58.2-3 ii libgtk-3-03.24.2-3 ii libwebkit2gtk-4.0-37 2.22.5-1 ii libx11-6 2:1.6.7-1 Versions of packages surf recommends: ii curl 7.62.0-1 ii suckless-tools 44-1 ii x11-utils7.7+4 ii xterm [x-terminal-emulator] 342-1 Versions of packages surf suggests: ii apparmor 2.13.2-3 -- Configuration Files: /etc/apparmor.d/usr.bin.surf changed [not included] -- no debconf information
Bug#919535: surf: AppArmor profile forbids access to publicsuffix data
Package: surf
Version: 2.0+git20181009-2.1
Severity: normal
Tags: patch
Dear Maintainer,
surf is not able to access the following two files due to its apparmor
profile:
[ 5565.325749] audit: type=1400 audit(1547681461.606:127): apparmor="DENIED"
operation="open" profile="/usr/bin/surf"
name="/usr/share/publicsuffix/public_suffix_list.dafsa" pid=29897
comm="WebKitNetworkPr" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[ 5565.328420] audit: type=1400 audit(1547681461.610:128): apparmor="DENIED"
operation="open" profile="/usr/bin/surf"
name="/usr/share/publicsuffix/public_suffix_list.dat" pid=29897
comm="WebKitNetworkPr" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
I have included a patch.
Regards,
Leo
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armhf (armv7l)
Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages surf depends on:
ii libc6 2.28-5
ii libgcr-base-3-1 3.28.0-4
ii libgcr-ui-3-1 3.28.0-4
ii libglib2.0-0 2.58.2-3
ii libgtk-3-03.24.2-3
ii libwebkit2gtk-4.0-37 2.22.5-1
ii libx11-6 2:1.6.7-1
Versions of packages surf recommends:
ii curl 7.62.0-1
ii suckless-tools 44-1
ii x11-utils7.7+4
ii xterm [x-terminal-emulator] 342-1
Versions of packages surf suggests:
ii apparmor 2.13.2-3
-- Configuration Files:
/etc/apparmor.d/usr.bin.surf changed [not included]
-- no debconf information
>From 092793cac1b5dd01a62f910497c95b51d28dc674 Mon Sep 17 00:00:00 2001
From: Leo Singer
Date: Wed, 16 Jan 2019 23:40:11 +
Subject: [PATCH] Tell apparmor to allow access to publicsuffix data
---
debian/changelog| 7 +++
debian/usr.bin.surf | 1 +
2 files changed, 8 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 7e6f003..c002849 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+surf (2.0+git20181009-3.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Tell apparmor to allow read access to publicsuffix data.
+
+ -- Leo Singer Wed, 16 Jan 2019 23:39:11 +
+
surf (2.0+git20181009-3) unstable; urgency=medium
* Fix path pattern for usrmerged paths in AppArmor profile.
diff --git a/debian/usr.bin.surf b/debian/usr.bin.surf
index f204a83..3a9b2d6 100644
--- a/debian/usr.bin.surf
+++ b/debian/usr.bin.surf
@@ -31,6 +31,7 @@
/usr/lib/@{multiarch}/webkit2gtk-4.0/WebKit*Process ix,
/{dev,run}/shm/WK2SharedMemory.* rw,
/var/tmp/WebKit-Media-* rw,
+ /usr/share/publicsuffix/public_suffix_list.{dat,dafsa} r,
owner @{HOME}/.local/share/webkitgtk/ w,
owner @{HOME}/.local/share/webkitgtk/** rw,
owner @{HOME}/.cache/webkitgtk/ w,
--
2.20.1
Bug#919534: surf: AppArmor profile forbids creation of ~/.cache directory
Package: surf Version: 2.0+git20181009-2.1 Severity: normal Dear Maintainer, The AppArmor profile for surf prevents it from creating the ~/.cache directory. This might be a rare corner case since it is only likely to occur if surf is almost the first program that the user runs after they create the account. There is a simple workaround of just creating the ~/.cache directory before running surf. The AppArmor audit message looks like this: [ 6822.134705] audit: type=1400 audit(1547682718.416:151): apparmor="DENIED" operation="mkdir" profile="/usr/bin/surf" name="/home/leo/.cache/" pid=5877 comm="WebKitWebProces" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Thanks, Leo -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages surf depends on: ii libc6 2.28-5 ii libgcr-base-3-1 3.28.0-4 ii libgcr-ui-3-1 3.28.0-4 ii libglib2.0-0 2.58.2-3 ii libgtk-3-03.24.2-3 ii libwebkit2gtk-4.0-37 2.22.5-1 ii libx11-6 2:1.6.7-1 Versions of packages surf recommends: ii curl 7.62.0-1 ii suckless-tools 44-1 ii x11-utils7.7+4 ii xterm [x-terminal-emulator] 342-1 Versions of packages surf suggests: ii apparmor 2.13.2-3 -- Configuration Files: /etc/apparmor.d/usr.bin.surf changed [not included] -- no debconf information
Bug#919460: [Pkg-xen-devel] Bug#919460: xen: disk I/O problems on stretch PV guest restores after security update
Hi Sergio, On 1/16/19 10:31 AM, Sergio Gelato wrote: > Source: xen Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11 > > Yesterday I upgraded a test dom0 to this version (from > 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10; stretch amd64, Xeon E5430), > then rebooted. Running domU's were saved and restored in the usual > way. However, all PV domU's running stretch (both i386 and amd64, all > kernel 4.9.130-2) lost write access to xvda on restore due to I/O > errors. Sample kernel log attached. (/var/log/kern.log stopped > recording entries, so I grabbed dmesg output to show what happened > afterwards.) Thanks for your report. > and amd64). These were restored successfully. > > In all cases, xvda is backed by an LVM logical volume local to the > dom0. > > After "reboot -f"ing some of the affected domUs (which made them > functional again), I rebooted the dom0. This time all domUs were > restored normally. (Of course those that still had their filesystems > mounted read-only stayed that way.) > > Is anyone else seeing this? The usual questions here would be like "can you reproduce the issue" etc... Because if you consistently can cause the problem to happen, you're in a positition to start trying things. The following is not an answer to your question, but a personal suggestion: When speaking for myself, I've had major troubles with Linux 4.9 in the dom0 causing all kinds of crashes when using live migrate (similar to suspend/resume you're doing) and I've never been able to track them down, they were never explained or fixed. blk-mq or general storage related crashes where amongst them. At this point, with the 4.19 kernel for buster already in pretty good shape and in stretch-backports as well, I can recommend trying it out. Hans
Bug#877002: nslcd installation broken: missing ca-certificates.crt
On Tue, 8 Jan 2019 17:08:16 -0800 Sunil Mohan Adapa wrote: > severity 877002 important > tags 877002 + patch > thanks > > This bug is causing issues with autopkgtests for FreedomBox package. > Bumping severity as simple install on a minimal machine fails. > > On Wed, 27 Sep 2017 17:32:22 +0200 (CEST) Robert Wolf wrote: > [...] > > > > > > Either must nslcd depends on ca-certificates or nslcd.conf should not > > contain > > configuration: > > It seems reasonable to add ca-certificates as dependency as the initial > configuration for nslcd uses the certificates from the package. > > The attached patch adds ca-certificates as dependency. I have tested > that bug is indeed resolved after building nslcd package with change in > dependency. > > Please consider uploading a fix for the issue. > It would be nice to have fix for this in time for buster. Please consider uploading the proposed fix. Thanks, -- Sunil
Bug#919533: python3-oauthlib: New version available
Package: python3-oauthlib Version: 2.1.0-1 Severity: wishlist Dear Maintainer, oauthlib has new version released, that supports openid connect. Please update if it possible. Thanks! -- 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-1-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-oauthlib depends on: ii python3 3.7.1-3 ii python3-blinker 1.4+dfsg1-0.2 ii python3-cryptography 2.3-1 ii python3-jwt 1.7.0-2 python3-oauthlib recommends no packages. python3-oauthlib suggests no packages. -- no debconf information
Bug#919222: ubuntu-keyring: [INTL:pt] Updated Portuguese translation - debconf messages
A quarta-feira, 16 de janeiro de 2019 09:36:47 WET você escreveu: > On Sun, 13 Jan 2019 20:25:41 + > > Thanks for filing translation, but as #917352, templates in this package > was reviewed and updated. Could you update attached file, please? Hi New version translated Best regards Américo Monteiro ubuntu-keyring_pt.po.gz Description: application/gzip
Bug#919402: devscripts: [salsa] documentation mentions both SALSA_TOKEN and SALSA_PRIVATE_TOKEN
On Tue 2019-01-15 18:54:19 +0100, Xavier wrote: > this feature allows one to use another file that contains one of this > fields. This permits compatibility with dpt(1) tool (from > pkg-perl-tools) which uses a ~/.dpt.conf that contains > > DPT_SALSA_PRIVATE_TOKEN= > > So this is not a bug ;-). Maybe documentation isn't clear on this. definitely not clear! i was setting this up and trying to understand what i should choose here -- if i used _PRIVATE_, will it be treated differently than if i did not? why should i choose one or the other? an update to the documentation that makes it clearer what's happening would be great. thanks for helping to maintain devscripts! --dkg
Bug#919162: lintian.d.o apears to report many failures twice
Hi Ian & Niels, > I: grub-common binary (2.02+dfsg1-10) [amd64]: hardening-no-bindnow usr/ > bin/grub-editenv > I: grub-common binary (2.02+dfsg1-10) [i386]: hardening-no-bindnow usr/ > bin/grub-editenv TIL we check both x86 architectures. Why do we do this out of interest? Are there examples of tags we would only find on one but not the other...? If we retain it I guess we need to make this more concise or at least clearer; it certainly looks like a bug right now. So, to use the following as concrete example, here's what we currently display: aapt 1:8.1.0+r23-3 (binary) ($maintainer) * usr/lib/android-sdk/build-tools/debian/aapt * usr/lib/android-sdk/build-tools/debian/aapt2 * usr/lib/android-sdk/build-tools/debian/aapt … what would be the ideal output? Perhaps: aapt 1:8.1.0+r23-3 (binary) ($maintainer) * usr/lib/android-sdk/build-tools/debian/aapt [amd64, i386] * usr/lib/android-sdk/build-tools/debian/aapt2 Thoughts? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#919532: Problems with hfsprogs on G5 Power Macs (ppc64)
Package: hfsprogs Version: 332.25-11+b3 User: debian-powe...@lists.debian.org Usertags: ppc64 I experienced some major problems with hfsprogs (for ppc64) on G5 Power Macs. Once in a while (already seen multiple times on 11,2 and 7,3 type Power Macs) the OS refuses to mount the NewWorld bootstrap - or simply HFS - partition that hosts the GRUB installation at startup in read-write mode. Trying to check the HFS with `fsck.hfs` always leads to segmentation faults: ``` root@powermac-g5-2:~# dmesg | grep hfs [ 16.234586] hfs: filesystem was not cleanly unmounted, running fsck.hfs is recommended. mounting read-only. root@powermac-g5-2:~# fsck.hfs -d /dev/sda2 ** /dev/sda2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. Segmentation fault ``` The HFS could later be checked (and repaired) successfully from a Mac mini G4 with `fsck.hfs` from hfsprogs (for powerpc). For verification I first checked and repaired a HFS from a Mac mini G4 and then tried to check it with `fsck.hfs` from both powerpc and ppc64 versions of hfsprogs on a type 11,2 Power Mac G5: ``` ## On Mac mini G4 ### root@mac-mini:~# fsck.hfs -d -f /dev/sdb2 ** /dev/sdb2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. Reserved fields in the catalog record have incorrect data (4, 185) Reserved fields in the catalog record have incorrect data (4, 2) Reserved fields in the catalog record have incorrect data (4, 2) ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x, ABTStat = 0x EBTStat = 0x CBTStat = 0x0200 CatStat = 0x ** Repairing volume. ** Rechecking volume. ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume bootstrap was repaired successfully. root@mac-mini:~# echo $? 0 root@mac-mini:~# fsck.hfs -d -f /dev/sdb2 ** /dev/sdb2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume bootstrap appears to be OK. root@mac-mini:~# echo $? 0 ## On Power Mac G5 (11,2) ### ## with ppc64 userland root@powermac-g5:~# dpkg -l hfsprogs 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 hfsprogs 332.25-11+b3 ppc64mkfs and fsck for HFS and HFS+ file systems root@powermac-g5:~# file /sbin/fsck.hfs /sbin/fsck.hfs: symbolic link to fsck.hfsplus root@powermac-g5:~# file /sbin/fsck.hfsplus /sbin/fsck.hfsplus: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=9e14a88ea04ea0fc8a89f3d79b039cf1daa6f3ed, stripped root@powermac-g5:~# fsck.hfs -d -f /dev/sda2 ** /dev/sda2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. Segmentation fault ## with powerpc userland root@powermac-g5:~# dpkg -l hfsprogs 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 hfsprogs 332.25-11+b2 powerpc mkfs and fsck for HFS and HFS+ file systems root@powermac-g5:~# file /sbin/fsck.hfs /sbin/fsck.hfs: symbolic link to fsck.hfsplus root@powermac-g5:~# file /sbin/fsck.hfsplus /sbin/fsck.hfsplus: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=ce95122bcb0b56e4c1dc1b256cdf24135f6e4cad, stripped root@powermac-g5:~# fsck.hfs -d -f /dev/sda2 ** /dev/sda2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume bootstrap appears to be OK. root@powermac-g5:~# echo $? 0 ``` A run with gdb and ppc64 userland (with `fsck.hfs` with debug symbols included) yields the following information for a newly created HFS: ``` root@powermac-g5:~/hfsprogs/hfsprogs-332.25# gdb --args
Bug#918776: at-spi2-core: Warning "Couldn't register with accessibility bus:" when starting Emacs and other applications
Peter Hull, le mer. 09 janv. 2019 09:38:14 +, a ecrit: > On Wed, Jan 9, 2019 at 9:29 AM Samuel Thibault wrote: > > Which graphical desktop environment are you using? It seems like it > > disturbs the accessibility bus setup. > It is cinnamon. Is this under a Wayland session, or Xorg? Samuel
Bug#919527: [Pkg-libvirt-maintainers] Bug#919527: Missing dependency against python3-distutils
Le 16/01/19 à 23:38, Guido Günther a écrit : On Wed, Jan 16, 2019 at 11:08:21PM +0100, Laurent Bigonville wrote: Package: virtinst Version: 1:2.0.0-2 Severity: serious Hi, The regression tests are currently failing because the virtinst is missing a dependency against python3-distutils: autopkgtest [04:39:33]: test help.sh: - - - - - - - - - - stderr - - - - - - - - - - Traceback (most recent call last): File "/usr/share/virt-manager/virt-convert", line 19, in from virtconv import VirtConverter File "/usr/share/virt-manager/virtconv/__init__.py", line 10, in from virtconv.formats import VirtConverter File "/usr/share/virt-manager/virtconv/formats.py", line 10, in from distutils.spawn import find_executable ModuleNotFoundError: No module named 'distutils.spawn' https://ci.debian.net/data/autopkgtest/testing/amd64/v/virt-manager/1712093/log.gz Could you please add the needed dependency? Already fixed in git. Do you think you could do a new upload as well so the package can migrate to testing?
Bug#919529: CVE-2019-6256
Control: found -1 2016.11.28-1 On 2019-01-16 23:19:45, Moritz Muehlenhoff wrote: > Source: liblivemedia > Severity: grave > Tags: security > > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6256 > > Cheers, > Moritz Not sure if I'm missing something, but the PoC does not seem to work on buster/sid. On stretch I get segfaults, but only if I abort the PoC. So marking as found in stable and closing for sid. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#919417: orca: Orca reads character by character when holding navigation keys pressed
Control: tags -1 + moreinfo Hello, Robert Schindler, le mar. 15 janv. 2019 19:48:15 +0100, a ecrit: > When walking through a line of text quickly, e.g. by holding the right > arrow pressed, Orca reads character by character instead of staying in > sync with the cursor position, what makes releasing the key in the right > moment impossible. Do you mean: on your system the synthesis keeps saying the whole character, and all characters, while you would rather that the synthesis stops as soon as moving to another character, to the point that characters are never spoken entirely, but just a glimpse? If so, it happens that on my system I am getting that latter behavior, with speech dispatcher 0.8, espeak-ng, and orca 3.31.4, so it seems something is different with your system... Which desktop are you using? Which application are you trying with? Samuel
Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier
Hello, Robert Schindler, le mar. 15 janv. 2019 18:06:34 +0100, a ecrit: > I'm using the laptop layout with CapsLock key as Orca modifier. > Since upgrading from stretch to buster (verified with Orca 3.30 and 3.31), > CAPSLock is toggled when pressing, even when executinG AN Orca command, > such as CapsLock + S. Previously, pressing the key alone had no effect. Could you post the output of xkbcomp $DISPLAY - ? Samuel
Bug#919531: lintian: "Could not determine what you meant by: tag:foo"
Package: lintian Version: 2.5.121 Severity: normal X-Debbugs-Cc: Felix Lechner Hi Felix, Another test regression I'm afraid... This works: $ debian/rules runtests onlyrun=tag:wrong-path-for-interpreter running tests mkdir -p "/home/lamby/git/debian/lintian/lintian/debian/test-out" t/runtests -k -j 9 t "/home/lamby/git/debian/lintian/lintian/debian/test-out" tag:wrong-path-for-interpreter Host architecture is amd64. Latest policy version is 4.3.0 from Sun, 23 Dec 2018 10:17:55 + Using compat level 11 as a default for packages built with debhelper. Harness modified on Wed, 16 Jan 2019 22:45:20 + Lintian modified on Wed, 16 Jan 2019 22:45:45 + Environment: DEB_HOST_ARCH=amd64 DEFAULT_DEBHELPER_COMPAT=11 DUMP_LOGS=yes HARNESS_EPOCH=1547678720 IPCRUNDEBUG=none LINTIAN_DPLINT_FRONTEND=/home/lamby/git/debian/lintian/lintian/frontend/dplint LINTIAN_EPOCH=1547678745 LINTIAN_FRONTEND=/home/lamby/git/debian/lintian/lintian/frontend/lintian LINTIAN_ROOT=/home/lamby/git/debian/lintian/lintian LINTIAN_TEST_INSTALLED=no LINTIAN_TEST_ROOT=/home/lamby/git/debian/lintian/lintian NO_PKG_MANGLE=true PATH=/home/lamby/git/debian/lintian/lintian/t/helpers/bin:/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/lamby/.bashhub/bin POLICY_EPOCH=1545560275 POLICY_VERSION=4.3.0 TEST2_ACTIVE=1 TEST_ACTIVE=1 Preparing 3 work directories. t/harness/check-result.t .. ok t/harness/no-watch-file-in-native.t ... ok t/harness/watch-file-in-non-native.t .. ok debian/test-out/tests/scripts-control-interpreters/generic.t .. ok t/harness/logged-prepare.t ok debian/test-out/tests/legacy-scripts/generic.t ok debian/test-out/tests/scripts-interpreters/generic.t .. ok All tests successful. Files=7, Tests=35, 0 wallclock secs ( 0.04 usr 0.01 sys + 1.77 cusr 0.26 csys = 2.08 CPU) Result: PASS … but this does not: $ debian/rules runtests onlyrun=tag:package-contains-real-file-outside-of-usr running tests mkdir -p "/home/lamby/git/debian/lintian/lintian/debian/test-out" t/runtests -k -j 9 t "/home/lamby/git/debian/lintian/lintian/debian/test-out" tag:package-contains-real-file-outside-of-usr Host architecture is amd64. Latest policy version is 4.3.0 from Sun, 23 Dec 2018 10:17:55 + Using compat level 11 as a default for packages built with debhelper. Harness modified on Wed, 16 Jan 2019 22:45:20 + Lintian modified on Wed, 16 Jan 2019 22:45:45 + Environment: DEB_HOST_ARCH=amd64 DEFAULT_DEBHELPER_COMPAT=11 DUMP_LOGS=yes HARNESS_EPOCH=1547678720 IPCRUNDEBUG=none LINTIAN_DPLINT_FRONTEND=/home/lamby/git/debian/lintian/lintian/frontend/dplint LINTIAN_EPOCH=1547678745 LINTIAN_FRONTEND=/home/lamby/git/debian/lintian/lintian/frontend/lintian LINTIAN_ROOT=/home/lamby/git/debian/lintian/lintian LINTIAN_TEST_INSTALLED=no LINTIAN_TEST_ROOT=/home/lamby/git/debian/lintian/lintian NO_PKG_MANGLE=true PATH=/home/lamby/git/debian/lintian/lintian/t/helpers/bin:/home/lamby/git/projects/dotfiles/dotfiles/..//bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/lamby/.bashhub/bin POLICY_EPOCH=1545560275 POLICY_VERSION=4.3.0 TEST2_ACTIVE=1 TEST_ACTIVE=1 t/harness/check-result.t .. ok t/harness/no-watch-file-in-native.t ... ok t/harness/watch-file-in-non-native.t .. ok t/harness/logged-prepare.t ok All tests successful. Files=4, Tests=32, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.55 cusr 0.09 csys = 0.67 CPU) Result: PASS Could not determine what you meant by: tag:package-contains-real-file-outside-of-usr To select your tests, please use an appropriate argument with a selector like: 'suite:', 'test:', 'check:', 'tag:', or 'script:' You can also use 'harness:', which runs only the internal tests for the harness. $ echo $? Note that: * This second tag only exists in Git. * The UNIX exit code is wrong or at least grossly misleading. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#918627: node-cacache FTBFS with nodejs 10.15.0
Update to 11.3.2 fixes partially failing build. Last problem is in node-readable-stream
Bug#919527: [Pkg-libvirt-maintainers] Bug#919527: Missing dependency against python3-distutils
On Wed, Jan 16, 2019 at 11:08:21PM +0100, Laurent Bigonville wrote: > Package: virtinst > Version: 1:2.0.0-2 > Severity: serious > > Hi, > > The regression tests are currently failing because the virtinst is > missing a dependency against python3-distutils: > > autopkgtest [04:39:33]: test help.sh: - - - - - - - - - - stderr - - - - - - > - - - - > Traceback (most recent call last): > File "/usr/share/virt-manager/virt-convert", line 19, in > from virtconv import VirtConverter > File "/usr/share/virt-manager/virtconv/__init__.py", line 10, in > from virtconv.formats import VirtConverter > File "/usr/share/virt-manager/virtconv/formats.py", line 10, in > from distutils.spawn import find_executable > ModuleNotFoundError: No module named 'distutils.spawn' > > https://ci.debian.net/data/autopkgtest/testing/amd64/v/virt-manager/1712093/log.gz > > Could you please add the needed dependency? Already fixed in git. -- Guido
Bug#919530: please remove Depends on common-lisp-controller
Package: cl-awk Version: 1-4 Severity: serious Tags: patch sid buster Control: block 913649 by -1 Dear Maintainer, Please drop the Depends on common-lisp-controller. This package is obsolete, and will not ship with Buster. It has been superseded by ASDF, which is shipped by all Common Lisp implementations in Debian. Dropping the dependency and the postinst and prerm scripts should be enough. ASDF is able to locate the files where they are installed (i.e. under /usr/share/common-lisp/). Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#919507: debian-policy: Policy contains no mention of /var/run/reboot-required
Hello, On Wed 16 Jan 2019 at 12:29PM -0600, Karl O. Pinc wrote: > Recent systemd security updates ( > systemd (232-25+deb9u8) stretch-security; urgency=high, > systemd (232-25+deb9u7) stretch-security; urgency=high) > require a system reboot to take effect, but the > unattended-upgrades did not tell the user to reboot > (or auto-reboot). > > Apparently /var/run/reboot-required is touched to by > debian packages to provide notification when an update > of the package requires a system reboot to take effect. > https://sources.debian.org/src/unattended-upgrades/1.9/unattended-upgrade/#L83 > > "The Internet" says that it is the postinst script which > is supposed to touch /var/run/reboot-required when a reboot > is required. > > If Debian supports user notification when reboot is required > (or automatic rebooting) after automatic upgrade then there > should be some consistent standard. And that standard > should be documented. Someplace. > > I don't suppose that there are many packages which require > a reboot to take effect after update, but they are the > important packages. The kernel and libc6 packages > trigger reboot notification, but systemd does not. It seems fine to document this in Policy. A patch would be welcome. -- Sean Whitton signature.asc Description: PGP signature
Bug#919529: CVE-2019-6256
Source: liblivemedia Severity: grave Tags: security Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6256 Cheers, Moritz
Bug#919528: libpam-modules: pam_limits.so does not appear to read /etc/security/limits.{conf,d}
Package: libpam-modules Version: 1.1.8-4 Severity: normal Dear Maintainer, I use my Debian system for music production and so depend on various real-time features, including memory locking. Recently a program that I use (aeolus) started failing on launch when it could not lock the required shm segment. The shm segment, as it turns out, is about 85 MB. I'm not sure exactly when this behavior started; the last time I (successfully) attempted to use Aeolus was probably 3-4 months ago, and I first noticed the failure on 2019-01-12 on an up-to-date unstable system. For some time I have had this line in /etc/security/limits.d/audio.conf: @audio - memlock unlimited My main user account is in the audio group: grib@ghost:~$ groups grib cdrom floppy audio dip video plugdev staff netdev bluetooth Yet the memlock limit is not set as requested: grib@ghost:~$ ulimit -l 65536 I have attempted to set the "memlock" limit in /etc/security/limits.conf directly, to apply it to my user account specifically, to apply it to all users. Nothing works. The limit is always the same. To test the setting of limits in general, I performed some experiments with setting the limit on core size with the same results: regardless of the contents of /etc/security/limits.conf or /etc/security/limits.d/* the maximum core dump size is always 0. I have not modified the files in /etc/pam.d and the relevant ones all include pam_limits.so: grib@ghost:/etc/pam.d$ ack pam_limits gdm-autologin 18:session required pam_limits.so systemd-user 10:session required pam_limits.so common-session 28:session required pam_limits.so gdm-password 17:session required pam_limits.so gdm-launch-environment 6:session required pam_limits.so login 87:session required pam_limits.so sshd 40:session required pam_limits.so cron 20:session required pam_limits.so runuser 4:session required pam_limits.so su 52:session required pam_limits.so gdm-fingerprint 17:session required pam_limits.so -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-modules depends on: ii debconf [debconf-2.0] 1.5.70 ii libaudit1 1:2.8.4-2 ii libc6 2.28-5 ii libdb5.3 5.3.28+dfsg1-0.2 ii libpam-modules-bin 1.1.8-4 ii libpam0g 1.1.8-4 ii libselinux1 2.8-1+b1 libpam-modules recommends no packages. libpam-modules suggests no packages. -- Configuration Files: /etc/security/limits.conf changed [not included] -- debconf information: libpam-modules/disable-screensaver:
Bug#918567: Maintaining dlib in Debian Science team (Was: dlib: FTBFS when built with dpkg-buildpackage -A)
Hi Andreas, Sorry for the delay. Yes, I'm absoluetly fine with the maintenance between transfered to Debian science. That's were it belongs, and I do not have the time currently to properly care for the package anyway. Please proceed! Thanks! Severin On 16/01/2019 16:06, Andreas Tille wrote: Hi again, since #918567 is RC critical there is some urgency to get this fixed. If I do not hear from you until Saturday I will assume you are fine with dlib in Debian Science team maintenance. Kind regards Andreas. On Tue, Jan 15, 2019 at 11:36:14AM +0100, Andreas Tille wrote: Hi Séverin, I stumbled upon dlib since I maintain some rdepends (plastimatch) of this lib and due to #918567 I've got a warning about testing removal. Since machine learning is definitely a topic that is covered by Debian Science I'd consider it really appropriate to maintain this software inside the Debian Science team, which means the repository would be moved to https://salsa.debian.org/science-team/dlib and the maintainer would be set to Debian Science Maintainers while your ID would be added as Uploader. Would this course of action be OK for you? Kind regards Andreas. -- http://fam-tille.de
Bug#919527: Missing dependency against python3-distutils
Package: virtinst Version: 1:2.0.0-2 Severity: serious Hi, The regression tests are currently failing because the virtinst is missing a dependency against python3-distutils: autopkgtest [04:39:33]: test help.sh: - - - - - - - - - - stderr - - - - - - - - - - Traceback (most recent call last): File "/usr/share/virt-manager/virt-convert", line 19, in from virtconv import VirtConverter File "/usr/share/virt-manager/virtconv/__init__.py", line 10, in from virtconv.formats import VirtConverter File "/usr/share/virt-manager/virtconv/formats.py", line 10, in from distutils.spawn import find_executable ModuleNotFoundError: No module named 'distutils.spawn' https://ci.debian.net/data/autopkgtest/testing/amd64/v/virt-manager/1712093/log.gz Could you please add the needed dependency? Kind regards, Laurent Bigonville -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages virtinst depends on: ii e2fsprogs 1.44.5-1 ii genisoimage 9:1.1.11-3+b2 ii gir1.2-libosinfo-1.0 1.2.0-1 ii python3 3.7.1-3 ii python3-gi3.30.4-1 ii python3-libvirt 4.10.0-1 ii python3-libxml2 2.9.4+dfsg1-7+b3 ii python3-requests 2.20.0-2 Versions of packages virtinst recommends: ii qemu-utils 1:3.1+dfsg-2+b1 ii virt-viewer 7.0-1 virtinst suggests no packages. -- no debconf information
Bug#919453: mumble FTCBFS: builds for the wrong architecture
Lisandro Damián Nicanor Pérez Meyer:
> Hi everyone!
Greetings again Lisandro. :)
> El miércoles, 16 de enero de 2019 14:53:19 -03 Helmut Grohne escribió:
>> Hi Chris,
>>
> [snip]
>>> I had a chance to review the patch. The fix hinges on this function call:
>>>PKG_CONFIG = $$pkgConfigExecutable()
>>>
>>> Could you let me know where this function call exists, i.e. what package
>>> it's in so I can look at it? I haven't been able to find it, and to try
>>> to get a patch upstream I need to understand and be able to explain what
>>> this is for and what it does.
>>
>> Unfortunately, I cannot precisely answer that question. I'll have to
>> defer to Lisandro or Dmitry (both Cced here). In any case, the reason is
>> that your dependencies (aka .pc files) may be present for multiple
>> architectures and for cross building that matters. So you need to
>> somehow specify to pkg-config, which architecture you are interested in.
>> On Debian systems you do that by invoking a different pkg-config.
>> Typically, that's ${DEB_HOST_GNU_TYPE}-pkg-config. So I can tell, what
>> this call does (but not where it comes from): It returns the pkg-config
>> that the user (in this case dh_auto_configure) supplied to the build.
>>
>> A quick codesearch[1] reveals that it is defined somewhere in
>> qtbase-opensource-src, so it should come with any qmake installation
>> based on qt5.
>
> qmake as a build system has support for using pkgconfig. I have not used this
> myself (I strongly prefer CMake), but glazing at the code it's just the way
> qmake passes the path to pkgconfig.
Looking at the code (below), that sounds right.
This is what I was looking for:
root@code-devel:/# fgrep -r pkgConfigExecutable /usr/*
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf:defineReplace(pkgConfigExecutable)
{
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf:pkg_config =
$$pkgConfigExecutable()
root@code-devel:/# dpkg -S
/usr/lib/x85_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf
qt5-qmake:amd64: /usr/lib/x86_64-linux-gnu/qt5/mkspecs/features/qt_functions.prf
So it's part of the qt5-qmake package, thus part of Qt5 itself. That's most of
what I needed to know.
The code section in qt_functions.prf:
[...]
defineReplace(pkgConfigExecutable) {
isEmpty(PKG_CONFIG) {
!isEmpty(QMAKE_PKG_CONFIG): \
PKG_CONFIG = $$QMAKE_PKG_CONFIG
else: \
PKG_CONFIG = pkg-config
sysroot.name = PKG_CONFIG_SYSROOT_DIR
sysroot.value = $$PKG_CONFIG_SYSROOT_DIR
libdir.name = PKG_CONFIG_LIBDIR
libdir.value = $$PKG_CONFIG_LIBDIR
QT_TOOL_NAME = pkg-config
qtAddToolEnv(PKG_CONFIG, sysroot libdir, SYS)
}
equals(QMAKE_HOST.os, Windows): \
PKG_CONFIG += 2> NUL
else: \
PKG_CONFIG += 2> /dev/null
return($$PKG_CONFIG)
}
[...]
I'm satisfied. I'll open an issue with Mumble upstream to see if I can get the
patch incorporated for Mumble 1.3. The build for mumble
1.3.0~git20190114.9fcc588+dfsg-1 hasn't completed for 3 architectures, and I'd
like to wait the 5 days for the package to transition to Testing/Buster -- I
plan to upload a package with the patch after that.
Thanks very much for this work.
-- Chris
--
Chris Knadle
chris.kna...@coredump.us
signature.asc
Description: OpenPGP digital signature
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds.
* Elimar Riesebieter [2019-01-16 22:08 +0100]: > * Axel Beckert [2019-01-10 05:57 +0100]: > > > Hi, > > > > Elimar Riesebieter wrote: > > > At boottime I get: > > > > > > WARNING: Device /dev/md0 not initialized in udev database even after > > > waiting 1000 microseconds. > > > > I get the same warning, too, at boot time and so far also at any time > > I call a LVM command. In anycase the command (and hence the boot > > itself, too) takes about 7 minutes! (Which makes every reboot very > > annoying, and I had plenty of them recently due to #918764.) > > For my system this seems to be fixed. Can't reproduce which update > pulled the bug out: > > ii udev 240-4 > ii mdadm 4.1-1 > ii lvm2 2.03.02-1 > > Custom 4.19.15. > No custom lvm script. My /boot resides on a separated lv on a vg on top of a mdadm. I've installed grml-rescueboot. grub can't find vg0 and therefor doesn't boot a grml-image (2018-12). It did boot last in October with the very same layout Elimar -- Experience is something you don't get until just after you need it! signature.asc Description: PGP signature
Bug#919526: CVE-2018-20451 CVE-2018-20453
Package: catdoc Version: 1:0.95-4.1 Severity: normal Tags: security These are for libdoc, but the code seems to be present in catdoc: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20451 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20453 Cheers, Moritz
Bug#918925: i3: Status and title bar text do not appear with default config file
Sorry for the spam. I sent that last message to the wrong issue. Best, Leo > On Jan 16, 2019, at 00:45, Leo Pound Singer wrote: > > When I type ^g, I see this go by in dmesg: > > [ 778.791035] audit: type=1400 audit(1547617464.261:24): > apparmor="DENIED" operation="exec" profile="/usr/bin/surf" > name="/usr/bin/dash" pid=919 comm="surf" requested_mask="x" > denied_mask="x" fsuid=1000 ouid=0 > >> On 1/15/19, Leo Pound Singer wrote: >> I just reinstalled buster to switch from armhf to aarch64, so my system is >> now pretty bare and unmodified other than installing build-essential, i3, >> and some python3 packages. Nevertheless I was able to reproduce the issue. >> >> I installed and ran font-manager from within i3 and nothing looks out of the >> ordinary. >> >>> On Jan 11, 2019, at 11:59, Michael Stapelberg >>> wrote: >>> >>> Then use whichever tool has a font selection dialog :) >>> On Fri, Jan 11, 2019 at 5:18 PM Leo Pound Singer wrote: gnome-specimen is not in buster. It has been removed from Debian. Sent from my iPhone > On Jan 10, 2019, at 16:46, Michael Stapelberg > wrote: > > That’s weird. Something must be different in your system, though, as > this is the first time anyone has ever reported this issue. > > Can you check gnome-specimen and see if fonts show up correctly there? > Can you try using them with i3 and see if that works in general? > >> On Thu, Jan 10, 2019 at 7:41 PM Leo Pound Singer >> wrote: >> No, all of the packages recommended by i3-wm are installed. >> >>> On Jan 10, 2019, at 12:25, Michael Stapelberg >>> wrote: >>> >>> Did you disable apt recommendations? The i3-wm package recommends >>> fonts-dejavu-core, which should be picked up as a suitable font. Do >>> you have that package installed? >>> On Thu, Jan 10, 2019 at 5:48 PM Leo Singer wrote: Package: i3 Version: 4.16-1 Severity: normal Dear Maintainer, I installed i3 under Debian Buster (armhf) on a Raspberry Pi 3B+. With the automatically generated configuration file, the i3 title and status bars are blank. I found that I could get the title and status bar text to show up by employing the workaround of uncommenting the following font option in ~/.config/i3/config: font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1 I do not know if this issue also occurs on more commonplace amd64 systems. Would you please modify the package so that the title and status bar text are visible with the default, automatically generated i3 config file? Regards, Leo -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 4.19.0-1-armmp (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages i3 depends on: ii i3-wm 4.16-1 Versions of packages i3 recommends: ii dunst 1.3.2-1 ii i3lock 2.11.1-1 ii i3status2.12-1 ii suckless-tools 44-1 i3 suggests no packages. -- no debconf information >>> >>> >>> -- >>> Best regards, >>> Michael > > > -- > Best regards, > Michael >>> >>> >>> -- >>> Best regards, >>> Michael >>
Bug#919525: race condition between sshguard and ufw on startup
Package: sshguard Version: 1.7.1-1 On systems with ufw (uncomplicated firewall, a popular firewall manager/frontend) *and* sshguard installed, a race condition exists between sshguard's firewall setup script and ufw. As I understand it, ufw calls iptables-restore on multiple files on startup to create and populate its various chains. If, during one of those calls, /usr/lib/sshguard/firewall is called to add the sshguard chain, the iptable-restore call fails and ufw cracks open. This has bitten me a few times, leaving remote boxes unreachable over the network after a reboot since ufw was unable to restore all of its rules. sshguard's systemd service file seems to have an After= directive which should prevent this, as ufw specifies a Before=network.target directive. [Unit] Description=SSHGuard Documentation=man:sshguard(8) After=network.service Before=sshd.service Since none of my Debian systems have a network.service file, I tried changing "After=network.service" to "After=network.target", which did the trick: sshguard is now started well after ufw, and after tens of reboots I haven't seen the issue come up again. Given my limited systemd knowledge, this may or may not be the best fix, but I believe something along these lines should be changed and a new package published. This is on Debian 9.6 (latest at the time of this writing), all packages up to date. Cheers, -Simon -- -- Simon Vetter Embedded Software Engineer - EDF store & forecast Phone: +33 7 83 40 26 11
Bug#919524: node-groove: FTBFS in sid (no matching function for call to 'v8::Function::NewInstance()')
Package: src:node-groove
Version: 2.5.1-1
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in sid but it failed:
[...]
debian/rules build-arch
dh build-arch
dh_update_autotools_config -a
dh_autoreconf -a
debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
node-gyp configure build
gyp info it worked if it ends with ok
gyp info using node-gyp@3.8.0
gyp info using node@10.15.0 | linux | x64
gyp info spawn /usr/bin/python2
gyp info spawn args [ '/usr/share/node-gyp/gyp/gyp_main.py',
gyp info spawn args 'binding.gyp',
gyp info spawn args '-f',
gyp info spawn args 'make',
gyp info spawn args '-I',
gyp info spawn args '/<>/build/config.gypi',
gyp info spawn args '-I',
gyp info spawn args '/usr/share/node-gyp/addon.gypi',
gyp info spawn args '-I',
gyp info spawn args '/usr/include/nodejs/common.gypi',
gyp info spawn args '-Dlibrary=shared_library',
gyp info spawn args '-Dvisibility=default',
gyp info spawn args '-Dnode_root_dir=/usr/include/nodejs',
gyp info spawn args '-Dnode_gyp_dir=/usr/share/node-gyp',
gyp info spawn args
'-Dnode_lib_file=/usr/include/nodejs/<(target_arch)/node.lib',
gyp info spawn args '-Dmodule_root_dir=/<>',
gyp info spawn args '-Dnode_engine=v8',
gyp info spawn args '--depth=.',
gyp info spawn args '--no-parallel',
gyp info spawn args '--generator-output',
gyp info spawn args 'build',
gyp info spawn args '-Goutput_dir=.' ]
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make[2]: Entering directory '/<>/build'
CXX(target) Release/obj.target/groove/src/groove.o
In file included from ../src/groove.cc:2:
../../../../usr/lib/nodejs/nan/nan.h: In function 'void
Nan::AsyncQueueWorker(Nan::AsyncWorker*)':
../../../../usr/lib/nodejs/nan/nan.h:2232:62: warning: cast between
incompatible function types from 'void (*)(uv_work_t*)' {aka 'void
(*)(uv_work_s*)'} to 'uv_after_work_cb' {aka 'void (*)(uv_work_s*, int)'}
[-Wcast-function-type]
, reinterpret_cast(AsyncExecuteComplete)
^
../src/groove.cc: In function 'Nan::NAN_METHOD_RETURN_TYPE
SetLogging(Nan::NAN_METHOD_ARGS_TYPE)':
../src/groove.cc:21:45: warning: 'double v8::Value::NumberValue() const' is
deprecated: Use maybe version [-Wdeprecated-declarations]
groove_set_logging(info[0]->NumberValue());
^
In file included from /usr/include/nodejs/deps/v8/include/v8.h:26,
from /usr/include/nodejs/src/node.h:63,
from ../src/groove.cc:1:
/usr/include/nodejs/deps/v8/include/v8.h:2475:45: note: declared here
V8_DEPRECATED("Use maybe version", double NumberValue() const);
^~~
/usr/include/nodejs/deps/v8/include/v8config.h:324:3: note: in definition of
macro 'V8_DEPRECATED'
declarator __attribute__((deprecated(message)))
^~
In file included from ../src/groove.cc:1:
../src/groove.cc: At global scope:
/usr/include/nodejs/src/node.h:570:43: warning: cast between incompatible
function types from 'void (*)(Nan::ADDON_REGISTER_FUNCTION_ARGS_TYPE)' {aka
'void (*)(v8::Local)'} to 'node::addon_register_func' {aka 'void
(*)(v8::Local, v8::Local, void*)'} [-Wcast-function-type]
(node::addon_register_func) (regfunc), \
^
/usr/include/nodejs/src/node.h:604:3: note: in expansion of macro
'NODE_MODULE_X'
NODE_MODULE_X(modname, regfunc, NULL, 0) // NOLINT (readability/null_usage)
^
../src/groove.cc:101:1: note: in expansion of macro 'NODE_MODULE'
NODE_MODULE(groove, Initialize)
^~~
In file included from /usr/include/nodejs/src/node.h:63,
from ../src/groove.cc:1:
/usr/include/nodejs/deps/v8/include/v8.h: In instantiation of 'void
v8::PersistentBase::SetWeak(P*, typename v8::WeakCallbackInfo::Callback,
v8::WeakCallbackType) [with P = node::ObjectWrap; T = v8::Object; typename
v8::WeakCallbackInfo::Callback = void (*)(const
v8::WeakCallbackInfo&)]':
/usr/include/nodejs/src/node_object_wrap.h:85:78: required from here
/usr/include/nodejs/deps/v8/include/v8.h:9502:16: warning: cast between
incompatible function types from
'v8::WeakCallbackInfo::Callback' {aka 'void (*)(const
v8::WeakCallbackInfo&)'} to 'Callback' {aka 'void (*)(const
v8::WeakCallbackInfo&)'} [-Wcast-function-type]
reinterpret_cast(callback), type);
^~~~
/usr/include/nodejs/deps/v8/include/v8.h: In instantiation of 'void
v8::PersistentBase::SetWeak(P*, typename v8::WeakCallbackInfo::Callback,
v8::WeakCallbackType) [with P = Nan::ObjectWrap; T = v8::Object; typename
v8::WeakCallbackInfo::Callback = void (*)(const
v8::WeakCallbackInfo&)]':
/usr/include/nan_object_wrap.h:66:61:
Bug#919523: libmodule-install-readmefrompod-perl: FTBFS in sid (failing tests)
Package: src:libmodule-install-readmefrompod-perl Version: 0.30-1 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in sid but it failed: [...] debian/rules binary-indep dh binary-indep dh_update_autotools_config -i dh_auto_configure -i perl -I. Makefile.PL INSTALLDIRS=vendor "OPTIMIZE=-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "LD=x86_64-linux-gnu-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro" I can run 'make' good Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for Module::Install::ReadmeFromPod Writing MYMETA.yml and MYMETA.json dh_auto_build -i make -j1 make[1]: Entering directory '/<>' cp lib/Module/Install/ReadmeFromPod.pm blib/lib/Module/Install/ReadmeFromPod.pm Manifying 1 pod document make[1]: Leaving directory '/<>' dh_auto_test -i make -j1 test TEST_VERBOSE=1 make[1]: Entering directory '/<>' PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(1, 'inc', 'blib/lib', 'blib/arch')" t/*.t # Testing Module::Install::ReadmeFromPod 0.30, Perl 5.028001, /usr/bin/perl t/00_compile.t ... 1..1 ok 1 - use Module::Install::ReadmeFromPod; ok # Subroutine Module::Install::ReadmeFromPod::io redefined at /usr/share/perl5/IO/All/Base.pm line 24. # include /<>/dist/pOKZQrzH2U/inc/Module/Install.pm # include inc/Module/Install/Metadata.pm # include inc/Module/Install/Base.pm # include inc/Module/Install/ReadmeFromPod.pm # readme_from README.pm to txt # readme_from README.pm to htm # Subroutine Module::Install::ReadmeFromPod::io redefined at /usr/share/perl5/IO/All/Base.pm line 24. # Subroutine Module::Install::ReadmeFromPod::io redefined at /usr/share/perl5/IO/All/Base.pm line 24. # readme_from README.pm to man # readme_from README.pm to md # include inc/Module/Install/WriteAll.pm # include inc/Module/Install/Makefile.pm # include inc/Module/Install/Win32.pm # include inc/Module/Install/Can.pm # include inc/Module/Install/Fetch.pm # Generating a Unix-style Makefile # Writing Makefile for Foo::Bar # Writing MYMETA.yml and MYMETA.json # Writing META.yml # make[2]: Entering directory '/<>/dist/pOKZQrzH2U' # rm -f \ # Bar.bso Bar.def \ # Bar.exp Bar.x \ #blib/arch/auto/Foo/Bar/extralibs.all \ # blib/arch/auto/Foo/Bar/extralibs.ld Makefile.aperl \ # *.a *.o \ # *perl.core MYMETA.json \ # MYMETA.yml blibdirs.ts \ # core core.*perl.*.? \ # core.[0-9] core.[0-9][0-9] \ # core.[0-9][0-9][0-9] core.[0-9][0-9][0-9][0-9] \ # core.[0-9][0-9][0-9][0-9][0-9] libBar.def \ # mon.out perl \ # perl perl.exe \ # perlmain.c pm_to_blib \ # pm_to_blib.ts so_locations \ # tmon.out # rm -rf \ # blib # mv Makefile Makefile.old > /dev/null 2>&1 # rm -f \ # Makefile Makefile.old # rm -rf \ # Foo-Bar-0.01 MYMETA.yml # rm -f Foo-Bar-0.01.tar.gz # rm -f MANIFEST.bak _build # "/usr/bin/perl" "-Iinc" "-Ilib" "-MModule::Install::Admin" -e "remove_meta()" # rm -rf inc # "/usr/bin/perl" "-Iinc" "-MExtUtils::Manifest=fullcheck" -e fullcheck # Problem opening MANIFEST: No such file or directory at /usr/share/perl/5.28/ExtUtils/Manifest.pm line 349. # Problem opening MANIFEST: No such file or directory at /usr/share/perl/5.28/ExtUtils/Manifest.pm line 349. # Not in MANIFEST: Makefile.PL # Not in MANIFEST: README # Not in MANIFEST: README.1 # Not in MANIFEST: README.htm # Not in MANIFEST: README.md # Not in MANIFEST: README.pm # make[2]: Leaving directory '/<>/dist/pOKZQrzH2U' t/01_dist.t .. 1..13 ok 1 - Exists: 'inc/Module/Install/ReadmeFromPod.pm' ok 2 - There is a README file ok 3 - There is a README.htm file ok 4 - There is a README.md file ok 5 - There is a README.1 file ok 6 - README contains only unix newlines ok 7 - README.htm contains only unix newlines ok 8 - README.md contains only unix newlines ok 9 - README.1 contains only unix newlines ok 10 - There is a README file ok 11 - There is a README.htm file ok 12 - There is a README.md file ok 13 - There is a README.1 file ok # Subroutine Module::Install::ReadmeFromPod::io redefined at /usr/share/perl5/IO/All/Base.pm line 24. # include /<>/dist/rxpKpJcKFL/inc/Module/Install.pm # include inc/Module/Install/Metadata.pm # include inc/Module/Install/Base.pm # include inc/Module/Install/ReadmeFromPod.pm # readme_from README.pm to text # include inc/Module/Install/Makefile.pm # readme_from README.pm to html # Subroutine Module::Install::ReadmeFromPod::io redefined at /usr/share/perl5/IO/All/Base.pm line 24. # Subroutine Module::Install::ReadmeFromPod::io redefined at /usr/share/perl5/IO/All/Base.pm line 24. # readme_from README.pm to md # readme_from README.pm to man # include inc/Module/Install/WriteAll.pm # include
Bug#362146: Still relevant?
Hello, I don't remember seeing such values in Deb 7, 8, 9, all amd64. Is this entry still relevant or maybe close it? :wq! PoC PGP-Key: DDD3 4ABF 6413 38DE
Bug#620179: Sorted Entries
Hello, sorted entries are still not available with Sysstat 11.4.3-2 in Debian Stretch. :wq! PoC PGP-Key: DDD3 4ABF 6413 38DE
Bug#919521: RM: ceph-deploy -- ROM; Deprecated upstream, buggy, not useful
Package: ftp.debian.org Severity: normal Hi, Upstream is deprecating ceph-deploy, and it's currently buggy (FTBFS). Best course of action is probably removing the package. Cheers, Thomas Goirand (zigo)
Bug#919522: libqt5webkit5: incorrect page width for plain text messages when using trojita
Package: libqt5webkit5 Version: 5.212.0~alpha2-19 Severity: normal When using trojita from http://download.opensuse.org/repositories/home:/jkt-gentoo:/trojita/Debian_9.0/ I'm encountering the bug described at https://github.com/annulen/webkit/issues/511 : plain text messages are incorrectly displayed with a page width of 2 characters. If I rebuild the package using the patches specified in the bug thread: https://github.com/annulen/webkit/commit/6faf11215e1af27d35e921ae669aa0251a01a1ab and https://github.com/annulen/webkit/commit/76420459a13d9440b41864c93cb4ebb404bdab55 and install the resulting package, the messages are now displayed correctly. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) 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 libqt5webkit5 depends on: ii dpkg 1.19.2 ii libc6 2.28-5 ii libgcc11:8.2.0-14 ii libglib2.0-0 2.58.2-3 ii libgstreamer-plugins-base1.0-0 1.14.4-dmo1 ii libgstreamer1.0-0 1.14.4-1 ii libhyphen0 2.8.8-7 ii libicu63 63.1-5 ii libjpeg62-turbo1:1.5.2-2+b1 ii libpng16-161.6.36-3 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg-2 ii libqt5gui5 5.11.3+dfsg-2 ii libqt5network5 5.11.3+dfsg-2 ii libqt5positioning5 5.11.3+dfsg-2 ii libqt5printsupport55.11.3+dfsg-2 ii libqt5qml5 [qtdeclarative-abi-5-11-2] 5.11.3-2 ii libqt5quick5 5.11.3-2 ii libqt5sensors5 5.11.3-2 ii libqt5webchannel5 5.11.3-2 ii libqt5widgets5 5.11.3+dfsg-2 ii libsqlite3-0 3.26.0+fossilbc891ac6b-1 ii libstdc++6 8.2.0-14 ii libwebp6 0.6.1-2 ii libwoff1 1.0.2-1 ii libxml22.9.4+dfsg1-7+b3 ii libxslt1.1 1.1.32-2 ii zlib1g 1:1.2.11.dfsg-1 libqt5webkit5 recommends no packages. libqt5webkit5 suggests no packages. -- no debconf information
Bug#909510: Please report on unversioned Python shebangs (was: "Re: Bug#909510: please add a lintian note to inform/warn about python in the shebang (instead of python2/python2.7)")
retitle 909510 Please report on unversioned Python shebangs thanks Hi Matthias, > I don't agree with Adrian's view. If there is need to keep 2.7, then we > should > keep it to keep things running like mercurial, and afaik samba isn't yet ready > for 3.x. So yes, such a warning makes sense for bullseye. > > It's ok to stop building unused python 2.x nodules once buster released, but > that doesn't mean that we already are at the point to "aggressively to remove > any python2 usage". This bug report is less about the removal of Python 2.x modules per se but more about "unversioned" shebangs. I'm retitling this bug to match. If other distributions are going to change (re. PEP 394 [0]) then we should at least know where we stand and whether it would even be feasible. > Maybe first as a note so we can get an overview. I was also somewhat taken by this idea. I would be quite interested in knowing the numbers at the very least. Thoughts? [0] https://www.python.org/dev/peps/pep-0394/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#904674: pgzero: Please inline/summarise web-based licensing discussion in debian/copyright
Hi Peter, > > This URI can obviously go down, change (!) and/or require internet > > access so please mention the important bits in the debian/copyright file > > too. […] > I believe the important bits of what is posted there now are already in > Debian/copyright. Perhaps clarifying that you included the link on a "more information" basis would help the next reviewer. Feel free to close this bug with an upload that does that. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#919520: cpl FTCBFS: AC_RUN_IFELSE for cfitsio
Source: cpl
Version: 7.1-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
cpl fails to cross build from source, because it uses AC_RUN_IFELSE to
check the version of cfitsio. It does so in a quite questionable way.
For instance, the check - as currently implemented - would consier
version 3.4 greater than 3.350. It would also consider version 3.35
equal to 3.350. My patch changes that and makes the version check behave
"sanely". We can avoid AC_RUN_IFELSE, by not checking CFITSIO_VERSION
and instead checking CFITSIO_MAJOR and CFITSIO_MINOR. The latter two are
integers and AC_COMPUTE_INT works with cross compilation.
The patch only fixes one AC_RUN_IFELSE. It's quite invasive already, so
I'm filing it as an incremental improvement. At the same time, it is
quite a simplification. I intend to work on further AC_RUN_IFELSE if it
is acceptable (preferably upstream). Please close this bug when removing
that particular AC_RUN_IFELSE.
Helmut
--- cpl-7.1.orig/m4/cpl.m4
+++ cpl-7.1/m4/cpl.m4
@@ -171,41 +171,17 @@
CFLAGS="$CFITSIO_CFLAGS"
LDFLAGS="$CFITSIO_LDFLAGS"
LIBS="$LIBCFITSIO"
-
-AC_RUN_IFELSE([AC_LANG_PROGRAM(
- [[
- #include
- #include
- ]],
- [
- int vlib = 0;
- int vmin = (int)(1000. * $cpl_cfitsio_check_version + 0.5);
-
- float v = CFITSIO_VERSION;
-
- vlib = (int)(v * 1000 + 0.5);
-
- FILE* f = fopen("conftest.out", "w");
- fprintf(f, "%5.3f\n", v);
- fclose(f);
-
- if (vlib < vmin) {
- return 1;
- }
-
- return 0;
- ])],
- [
- cpl_cfitsio_version="`cat conftest.out`";
- rm -f conftest.out
- ],
- [
- cpl_cfitsio_version="no";
- cpl_cfitsio_version_found="unknown";
- test -r conftest.out && cpl_cfitsio_version_found="`cat conftest.out`";
- rm -f conftest.out
- ])
-
+
+ cpl_cfitsio_version=
+ AC_COMPUTE_INT([CFITSIO_MAJOR],[CFITSIO_MAJOR],[#include ],[cpl_cfitsio_version=no])
+ AC_COMPUTE_INT([CFITSIO_MINOR],[CFITSIO_MINOR],[#include ],[cpl_cfitsio_version=no])
+ AS_IF([test x$cpl_cfitsio_version = xno],
+ [AC_MSG_ERROR([version of cfitsio could not be determined])],
+ [cpl_cfitsio_version=$CFITSIO_MAJOR.$CFITSIO_MINOR])
+ AS_VERSION_COMPARE([$cpl_cfitsio_check_version],
+ [$cpl_cfitsio_version],[],[],
+ [AC_MSG_ERROR([Installed cfitsio ($cpl_cfitsio_version) is too old])])
+
AC_MSG_RESULT([$cpl_cfitsio_version])
AC_LANG_POP(C)
@@ -215,20 +191,9 @@
LIBS="$cpl_cfitsio_libs_save"
-if test x"$cpl_cfitsio_version" = xno; then
-
-AC_MSG_ERROR([Installed cfitsio ($cpl_cfitsio_version_found) is too old])
-
-CFITSIO_INCLUDES=""
-CFITSIO_CFLAGS=""
-CFITSIO_LDFLAGS=""
-LIBCFITSIO=""
-
-else
AC_DEFINE_UNQUOTED([CPL_CFITSIO_VERSION],
[$cpl_cfitsio_version],
[Minimum required version of CFITSIO])
-fi
fi
--- cpl-7.1.orig/configure.ac
+++ cpl-7.1/configure.ac
@@ -70,7 +70,7 @@
AC_CHECK_LIB(nsl, inet_ntoa, [LIBS="$LIBS -lnsl"])
CPL_CONFIG_CEXT
-CPL_CONFIG_CFITSIO([3.350])
+CPL_CONFIG_CFITSIO([3.35])
CPL_CHECK_WCS([4.16])
CPL_CHECK_FFTW([3.3.3])
Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds.
* Axel Beckert [2019-01-10 05:57 +0100]: > Hi, > > Elimar Riesebieter wrote: > > At boottime I get: > > > > WARNING: Device /dev/md0 not initialized in udev database even after > > waiting 1000 microseconds. > > I get the same warning, too, at boot time and so far also at any time > I call a LVM command. In anycase the command (and hence the boot > itself, too) takes about 7 minutes! (Which makes every reboot very > annoying, and I had plenty of them recently due to #918764.) For my system this seems to be fixed. Can't reproduce which update pulled the bug out: ii udev 240-4 ii mdadm 4.1-1 ii lvm2 2.03.02-1 Custom 4.19.15. No custom lvm script. Elimar -- Experience is something you don't get until just after you need it! signature.asc Description: PGP signature
Bug#904674: pgzero: Please inline/summarise web-based licensing discussion in debian/copyright
On 26/07/18 14:35, Chris Lamb wrote: Comment: see https://github.com/lordmauve/pgzero/issues/75 for discussion of licensing issues This URI can obviously go down, change (!) and/or require internet access so please mention the important bits in the debian/copyright file too. Sorry for the slow response. I believe the important bits of what is posted there now are already in Debian/copyright. I included the link in the hope that more information would become available and hence I (or whoever is working on the package in the future) would be able to move more files out of files-excluded and build some documentation/examples packages. Unfortunately so-far that hasn't happened.
Bug#919519: Revise d/p/path-issues.patch
Package: matlab2tikz Version: 1.1.0-6 Severity: wishlist Indeed, Sébastien's comment below is correct. When I adjusted the file d/matlab2tikz.links, in order to fix Bug#919100, I have not realized that an attempt to fix the path issues was done with the patch d/p/path-issues.patch. We may need to adjust this later file to the new situation. I am hereby opening a new bug report, tagged wishlist, just to help us not forgetting the issue. Best, Rafael * Jeremie Knuesel [2019-01-15 12:42]: Indeed the addpath is there, but just before the addpath there is a call to checkDeprecatedEnvironment(). This function is internal to the matlab2tikz.m file, but it calls getEnvironment() which is external, so that won't work before the addpath. Jeremie On Tue, Jan 15, 2019 at 10:24 AM Sébastien Villemot wrote: Le samedi 12 janvier 2019 à 21:06 +, Rafael Laboissiere a écrit : Bug #919100 in matlab2tikz reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/pkg-octave-team/matlab2tikz/commit/eefa0e90e4d6cfadb8991d7ff6c8e6e7a422d647 d/matlab2tikz.links: Fix link to the source directory Closes: #919100 I'm surprised that changing the symlink was necessary. There is actually a patch that precisely adds the whole /usr/share/matlab2tikz directory to the path: https://salsa.debian.org/pkg-octave-team/matlab2tikz/blob/master/debian/patches/path-issues.patch I think more investigation is needed here. Or at the very least the patch should be updated in order to match the new setup. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#919138: wpasupplicant: Fails to connect to some Wifi networks on version 2:2.7-3
Alright, not entirely sure if I did this right but I followed Debian's Building
Tutorial to download and build wpa_supplicant with the changes you linked. One
exception, I use wpa_supplicant through NetworkManager and could not work out
where I needed to create a wpa_supplicant.conf, so I changed the one line in
config.c to:
{ INT(no_oper_classes_ie), 1 },
which I'm hoping makes the default "on" instead of "off." Sadly doesn't appear
to have made a difference, although it didn't make anything worse either.
Tiny mostly-uninteresting side note, I gave wpa_supplicant 2.7 a try on my
desktop this morning and had the same problems with a Qualcomm Atheros AR9462
Wireless Adapter.
On Tuesday, January 15, 2019 11:53 AM, Ben Greear
wrote:
> You might try adding this patch and disabling the oper-class IE:
>
> http://lists.infradead.org/pipermail/hostap/2018-August/038792.html
>
> I'd be curious to know if it fixes the problem.
>
> Thanks,
> Ben
>
> On 1/14/19 4:35 PM, Different55 wrote:
>
> > On Monday, January 14, 2019 10:37 AM, Ben Greear gree...@candelatech.com
> > wrote:
> >
> > > What is the model number of your home AP?
> > > Thanks,
> > > Ben
> >
> > It is a Comtrend VR-3033
>
> --
>
> Ben Greear gree...@candelatech.com
> Candela Technologies Inc http://www.candelatech.com
Bug#919518: file:///usr/share/doc/ghc-doc/html/libraries/index.html hits the network
Package: ghc Version: 8.4.4+dfsg1-1 Severity: normal This script is loaded from the network: https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS-MML_HTMLorMML I suspect this violates some policies, but also it makes it very annoying to open that page in a web browser locally when there's a broken internet connection that might take a long time to time out the http request, or might hang for minutes in a DNS lookup. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ghc depends on: ii dpkg 1.19.2 ii gcc 4:8.2.0-2 ii libatomic18.2.0-14 ii libbsd-dev0.9.1-1 ii libc6 2.28-4 ii libc6-dev 2.28-4 ii libffi-dev3.2.1-9 ii libffi6 3.2.1-9 ii libgmp-dev2:6.1.2+dfsg-4 ii libgmp10 2:6.1.2+dfsg-4 ii libncurses-dev [libncurses5-dev] 6.1+20181013-1 ii libncurses5-dev 6.1+20181013-1 ii libtinfo6 6.1+20181013-1 ghc recommends no packages. Versions of packages ghc suggests: ii ghc-doc 8.4.4+dfsg1-1 pn ghc-prof pn haskell-doc pn llvm-6.0 ii perl 5.28.1-3 -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#919517: firewalld: Failure to start with OpenVPN installed and nftables backend
Package: firewalld Version: 0.6.3-4 Severity: important Tags: patch upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, Installing and setting up OpenVPN causes firewalld to fail to start when nftables backend is being used. The bug can be reproduced as follows: firewall-cmd --zone=internal --add-interface=tun+ shows: firewalld[459]: ERROR: Failed to apply rules. A firewall reload might solve the issue if the firewall has been modified using ip*tables or ebtables. firewalld[459]: ERROR: '/usr/sbin/nft insert rule inet firewalld raw_PREROUTING_ZONES iifname tun+ goto raw_PRE_internal' failed: Error: syntax error, un insert rule inet firewalld raw_PREROUTING_ZONES iifname tun+ goto raw_PRE_internal ^ Then adding the rule permanently (as is done during FreedomBox setup of OpenVPN): firewall-cmd --zone=internal --add-interface=tun+ --permanent leads to firewalld not starting properly due to above errors and blocking out the user from network completely. While this problem is only effecting OpenVPN there are other problems like functional test suite failing and restoring from backups (with OpenVPN data) triggering the issue. For FreedomBox this is an RC issue. This is a simple fix with nft rules insertion. This is already fixed in upstream about four weeks ago and that patch is attached. In case, upstream does not make a release soon, please consider adding this patch to Debian packaging due to severity of the issue. Thanks, - -- Sunil - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_IN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firewalld depends on: ii dbus 1.12.12-1 ii gir1.2-glib-2.0 1.58.3-2 ii init-system-helpers 1.56+nmu1 ii iptables 1.8.2-3 ii policykit-1 0.105-23 ii python3 3.7.1-3 ii python3-dbus 1.2.8-2+b3 ii python3-gi 3.30.4-1 ii python3-slip-dbus0.6.5-2 Versions of packages firewalld recommends: ii ebtables 2.0.10.4+snapshot20181205-1 ii ipset 6.38-1 firewalld suggests no packages. - -- Configuration Files: /etc/firewalld/firewalld.conf [Errno 13] Permission denied: '/etc/firewalld/firewalld.conf' /etc/firewalld/lockdown-whitelist.xml [Errno 13] Permission denied: '/etc/firewalld/lockdown-whitelist.xml' - -- no debconf information -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlw/k6ARHHN1bmlsQG1l ZGhhcy5vcmcACgkQQ+oc/wqnxfLZtQ//TWkFhcuX0tQ9HVZv2ltS5MHcBIDr4yMr uh4ChkvfZJGID0RJBxknlmwjDUHysw9769FWX7jRmci4C2VMjJIQhNm9nhdNzZ3w ajh+n7NXL58hF1tZx3QjQ7gdVRVSC83pXqn75L1aFghuIoFAADiDM8DgRuhvIdDP ufMmNgyBbyQ1G3F37FpcObiiMPBr2ibDakUrHD9VjKZk9xT/cltuBP5GPou3zwj2 S/Gs/Q4QamqeIyWMeioGzoDYGOQxCtuI38s8Cf+jbIPASdHRQ+dlfpjepSxjCBmZ 2yX0dBptStV9HH2mmFJkpKQzOnH6TZTYNj1vvD8eh14tZvV83AC618BvlQZC9Joz r7VbCAylpQf/Pf4WXTVzk/VV4/jXmtYVkASufk3Xj6wVepy+0Eij/gySJOl3b3C5 DCo0GbKkYMkZZxNFee/mm1be9QfVeeSqCvFEIyoQ/sj6Q3UTXkqXybH08OpUiTWY Rql1VZGUiezsxEh/6vG9XChZEDS0VFRrWAM/u1aO6JbmeJ7kEYaB0+ddlUYLd71R Y4F2dPAjr6YCQAoeYowMOj1Q1YbDfPhbUHmrhtkO0F3DEz3lpTspAuVVCSNrrB4c 5dkpzoeGdnvjbHqgb/hYez/5ox6VRtn+I5B07L2nd8iV0X/fvqO35Qy1vjDxkHmL DrRAV0JFIb0= =yirT -END PGP SIGNATURE- >From 687953defc201a69e77e8b8f9230cdd34df858db Mon Sep 17 00:00:00 2001 From: Eric Garver Date: Mon, 17 Dec 2018 12:53:30 -0500 Subject: [PATCH] nftables: Allow interfaces with wildcards Fixes: rhbz 1644025 (cherry picked from commit aa01eda4c87dd7b5c1f1e884fc7332c6317fed02) --- src/firewall/core/nftables.py | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/firewall/core/nftables.py b/src/firewall/core/nftables.py index a1cb2c47..50303e94 100644 --- a/src/firewall/core/nftables.py +++ b/src/firewall/core/nftables.py @@ -475,6 +475,9 @@ class nftables(object): "OUTPUT": "oifname", }[chain] +if interface[len(interface)-1] == "+": +interface = interface[:len(interface)-1] + "*" + target = DEFAULT_ZONE_TARGET.format(chain=SHORTCUTS[chain], zone=zone) if zone_target == DEFAULT_ZONE_TARGET: action = "goto" @@ -486,10 +489,10 @@ class nftables(object): rule = ["add", "rule", family, "%s" % TABLE_NAME, "%s_%s_ZONES" % (table, chain)] else: rule = ["delete", "rule", family, "%s" % TABLE_NAME, "%s_%s_ZONES" % (table, chain)] -if interface == "+": +if interface == "*": rule += [action, "%s_%s" % (table, target)] else: -rule += [opt, interface, action, "%s_%s" % (table, target)] +rule += [opt, "\"" + interface
Bug#919023: Simplification of BOOTCFG_CreateGUID function
Control: tags -1 +pending Le vendredi, 11 janvier 2019, 22.42:13 h CET Thomas Gaugler a écrit : > The conversion of an UUID value into a string can be achieved by just > using the g (GUID) type of the System plug-in. As a consequence the > Win32 API calls could be eliminated. Looks good to me; uploaded. Would you be interested in taking over win32-loader? It needs a knowledgeable maintainer, I have mostly lost interest, you look like the ideal person to maintain win32-loader (in conjunction with nsis); what do you say of this? :-) Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#919516: ruby2.5 ftbfs in testing/unstable: certificate verify failed (certificate has expired)
Package: src:ruby2.5 Version: 2.5.3-3 Severity: serious Tags: sid buster [...] 13) Error: TestNetHTTPS#test_get: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate has expired) /home/packages/tmp/ruby2.5-2.5.3/lib/net/protocol.rb:44:in `connect_nonblock' /home/packages/tmp/ruby2.5-2.5.3/lib/net/protocol.rb:44:in `ssl_socket_connect' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:981:in `connect' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:920:in `do_start' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:909:in `start' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:1455:in `request' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:1365:in `request_get' /home/packages/tmp/ruby2.5-2.5.3/test/net/http/test_https.rb:44:in `test_get' 14) Error: TestNetHTTPS#test_post: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (certificate has expired) /home/packages/tmp/ruby2.5-2.5.3/lib/net/protocol.rb:44:in `connect_nonblock' /home/packages/tmp/ruby2.5-2.5.3/lib/net/protocol.rb:44:in `ssl_socket_connect' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:981:in `connect' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:920:in `do_start' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:909:in `start' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:1455:in `request' /home/packages/tmp/ruby2.5-2.5.3/lib/net/http.rb:1409:in `request_post' /home/packages/tmp/ruby2.5-2.5.3/test/net/http/test_https.rb:58:in `test_post' Finished tests in 289.841475s, 59.8914 tests/s, 7810.6041 assertions/s. 17359 tests, 2263837 assertions, 5 failures, 9 errors, 19 skips ruby -v: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux-gnu] make[2]: *** [uncommon.mk:698: yes-test-almost] Error 14 make[2]: Leaving directory '/home/packages/tmp/ruby2.5-2.5.3' make[1]: *** [debian/rules:81: override_dh_auto_test-arch] Error 2 make[1]: Leaving directory '/home/packages/tmp/ruby2.5-2.5.3' make: *** [debian/rules:59: build] Error 2
Bug#911761: sphinxsearch: New upstream releases 3.1.x
the new upstream version you refer to is no longer released under GPL, also only binaries are made available. please see comment of the project author at http://sphinxsearch.com/blog/2017/12/18/sphinx-3-0-1-released/#comment-1501196 manticoresearch is a fork based on the sphinxsearch 2.x branch released under GPL 2.0. manticoresearch has been developed steadily since mid of 2017. take a look at https://manticoresearch.com/ and https://github.com/manticoresoftware/manticoresearch it would be great seeing manticoresearch replace sphinxsearch in the next Debian releases. -- regards, Pawel Kudzia
Bug#887557: www.debian.org: tech-ctte membership updates
On Wed, Jan 17, 2018 at 11:07:41PM +0200, Niko Tyni wrote: > Package: www.debian.org > Tags: patch > X-Debbugs-Cc: debian-c...@lists.debian.org > > Hi, please find attached a patch to update > https://www.debian.org/intro/organization > for the recent tech-ctte membership changes. > > It also updates the rather outdated list of past members on > https://www.debian.org/devel/tech-ctte Hi, a gentle ping on this? Marga has been TC chair since March, but the organization web page is still out of date... -- Niko Tyni nt...@debian.org
Bug#804299: smartmontools: update-smart-drivedb currently risky
Christoph Anton Mitterer wrote: ... I've just hat a quick glance at current upstream: https://svn.code.sf.net/p/smartmontools/code/trunk/smartmontools/update-smart-drivedb.in Comments are welcome. It seems it now contains some code verification, both X.509 CA based and/or OpenPGP based. I think the X.509 CA / TLS based one can be just tossed (because X.509 PKI is inherently flawed and insecure - just take the ~150 CAs Mozilla ships, many of them already completely untrustworthy, with even more sub-CAs (that are even more untrustworthy). Agree. OpenPGP would be in principle ok. However, I haven't really checked the implementation of it (i.e. how the code downloading, verification is done... on a first glance, I'd say it allows at least for replay attacks. Could you possibly describe an attack scenario? Plus it automatically imports the shipped public key into the keyring of the executing user… which is IMO also unacceptable. Of course this would be unacceptable. I'm at least somewhat sure that I didn't implement it that way :-) Cheers, Christian smartmontools.org
Bug#919515: RM: phpmyadmin/4:4.6.6-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove phpmyadmin from testing, it hasn't seen an update since 1.5 years and has 5 RC bugs at this point. The 4.6.x series is out of upstream support for quite a while and should not be in a new stable release (916310), it blocks the removal of tcpdf (915470), FTBFSes (917755, 883417) and has issues with current PHP (890595). I guess it wasn't auto-removed as it's considered a key package (I did a simulated dak removal run in testing and there were no blockers). Removing it now seems like the best course of action; if it's actually a key package, people can still step up and upgrade it to 4.8 (which would still be doable for buster). Cheers, Moritz
Bug#899058: Python issue
On another installation today, couldn't find the Zigate (Python-based) plugin in the Add Hardware pulldown I looked at /var/log/daemon.log domoticz[55195]: Status: EventSystem - Python: Failed dynamic library load, install the latest libpython3.x library that is available for your platform. Resolved by $ sudo apt install libpython3-dev which installed libpython3.5-dev. A -dev package probably shouldn't be a runtime dependency though, is it needed for plugins, or can this be satisfied in another way?
Bug#919300: ubuntu-keyring: [INTL:nl] Dutch translation of debconf messages
Hi, Hideki Yamane schreef op wo 16-01-2019 om 09:37 [+0900]: > Hi, > > On Mon, 14 Jan 2019 20:15:52 +0100 > Frans Spiesschaert wrote: > > Please find attached the Dutch translation of ubuntu-keyring > > debconf messages. > > It has been submitted for review to the debian-l10n-dutch mailing > > list. > > Please add it to your next package revision. > > Thanks for filing translation, but as #917352, templates in this > package > was reviewed and updated. Could you update attached file, please? Please find attached the updated Dutch translation. -- Regards, Frans Spiesschaert # Dutch translation of ubuntu-keyring debconf templates. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the ubuntu-keyring package. # FIRST AUTHOR , YEAR. # Frans Spiesschaert , 2018, 2019. # msgid "" msgstr "" "Project-Id-Version: ubuntu-keyring\n" "Report-Msgid-Bugs-To: ubuntu-keyr...@packages.debian.org\n" "POT-Creation-Date: 2019-01-16 09:30+0900\n" "PO-Revision-Date: 2019-01-16 20:31+0100\n" "Last-Translator: Frans Spiesschaert \n" "Language-Team: Debian Dutch l10n Team \n" "Language: nl\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" "X-Generator: Gtranslator 2.91.7\n" #. Type: multiselect #. Description #: ../ubuntu-keyring.templates:1001 ../ubuntu-cloud-keyring.templates:1001 #: ../ubuntu-dbgsym-keyring.templates:1001 msgid "Trusted GPG keyring for package authentication" msgstr "Vertrouwde GPG-sleutelbos voor pakket-authenticatie" #. Type: multiselect #. Description #: ../ubuntu-keyring.templates:1001 #| msgid "" #| "If you want to use Ubuntu archive as same as Debian archive in some " #| "situation (e.g. chdist from devscripts package), you should enable ubuntu-" #| "archive-keyring as whole system trusted GPG key (and also ubuntu-archive-" #| "removed-keys for obsolete Ubuntu archive)." msgid "" "If you want to use Ubuntu archive in place of Debian archive in some " "situation (e.g. chdist from devscripts package), you should enable ubuntu-" "keyring-*-archive as a system trusted GPG key (and also ubuntu-archive-" "removed-keys for the obsolete Ubuntu archive)." msgstr "" "Indien u in een bepaalde situatie (bv. chdist uit het pakket devscripts) het " "archief van Ubuntu wilt gebruiken in de plaats van het archief van Debian, " "moet u ubuntu-keyring-*-archive gebruiken als een door het systeem " "vertrouwde GPG-sleutel (en ook ubuntu-archive-removed-keys voor het archief " "van Ubuntu met oudere uitgaven)." #. Type: multiselect #. Description #: ../ubuntu-keyring.templates:1001 ../ubuntu-cloud-keyring.templates:1001 #: ../ubuntu-dbgsym-keyring.templates:1001 #| msgid "" #| "However, note that adding those keyring as system trusted key is not " #| "necessary in most cases (e.g. debootstrap) and may be a risk for your " #| "system." msgid "" "However, note that adding keyrings as system trusted keys is not necessary " "in most cases (just specify an appropriate keyring via options) and may be a " "risk for your system." msgstr "" "Merk evenwel op dat het toevoegen van sleutelbossen aan de door het systeem " "vertrouwde sleutels, onnodig is in de meeste gevallen (geef gewoon met een " "optie een passende sleutelbos op) en een risico kan inhouden voor uw systeem." #. Type: multiselect #. Description #: ../ubuntu-cloud-keyring.templates:1001 #| msgid "" #| "If you want to use Ubuntu archive as same as Debian archive in some " #| "situation (e.g. chdist from devscripts package), you should enable ubuntu-" #| "archive-keyring as whole system trusted GPG key (and also ubuntu-archive-" #| "removed-keys for obsolete Ubuntu archive)." msgid "" "If you want to use the Ubuntu cloud archive in place of the Debian archive " "in some situation (e.g. chdist from the devscripts package), you should " "enable ubuntu-keyring-*-archive as a system trusted GPG key (and also ubuntu-" "cloud-removed-keys for the obsolete Ubuntu cloud archive)." msgstr "" "Indien u in een bepaalde situatie (bv. chdist uit het pakket devscripts) het " "cloud-archief van Ubuntu wilt gebruiken in de plaats van het archief van " "Debian, moet u ubuntu-keyring-*-archive gebruiken als een door het systeem " "vertrouwde GPG-sleutel (en ook ubuntu-cloud-removed-keys voor het cloud-" "archief van Ubuntu met oudere uitgaven)." #. Type: multiselect #. Description #: ../ubuntu-dbgsym-keyring.templates:1001 #| msgid "" #| "If you want to use Ubuntu archive as same as Debian archive in some " #| "situation (e.g. chdist from devscripts package), you should enable ubuntu-" #| "archive-keyring as whole system trusted GPG key (and also ubuntu-archive-" #| "removed-keys for obsolete Ubuntu archive)." msgid "" "If you want to use the Ubuntu dbgsym archive in place of the Debian archive " "in some situation (e.g. chdist from the devscripts package), you should " "enable ubuntu-keyring-*-dbgsym as a system
Bug#919513: CVE-2019-6442 CVE-2019-6443 CVE-2019-6444 CVE-2019-6445
Thanks for letting me know. I was planning to package 1.1.3 in the next couple of days, but I was not aware there were CVEs fixed in this release. I will try to do a package release today. -- Richard > On Jan 16, 2019, at 13:21, Moritz Muehlenhoff wrote: > > Source: ntpsec > Severity: grave > Tags: security > > Please see > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6442 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6443 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6444 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6445 > > Cheers, >Moritz
Bug#919439: bash: new alias behavior may freeze interpreter
On 1/16/19 12:58 AM, Eduardo Bustamante wrote: > FYI, this issue was reported upstream in > https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00084.html. > This was fixed in the `devel' branch in git, but I'm not sure if a > patch for 5.0 has been released yet. > > The issue is caused by bash improperly handling the case where an > alias has trailing tab characters. Ah, this sounds definitely related! Many thanks for the notice Eduardo! Sorry I haven't checked by myself, it was quite late in my TZ, and initially intended to have a look upstream this evening CET. Let's wait for next upstream release then. :^) Kind Regards, -- Étienne Mollier
Bug#919514: abcm2ps: README.Debian is not more informative
Package: abcm2ps Version: 7.8.9-1+b1 Severity: minor Dear Maintainer, Regarding the version 8.14.2-0.1 of the package, there is still a README.Debian saying: "This is a Debianization of Jef Moine's abcm2ps package. It differs from the original in the following respects: acm2ps assumes A4 paper by default" which is no more true since the remove of upstream source discrepancy introduced in very old package and then using '--enable-a4' in build options introduced after, but it was not the case already in 7.8.9-1 (changed in upstream). Regards, Patrice -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages abcm2ps depends on: ii libc6 2.28-5 abcm2ps recommends no packages. abcm2ps suggests no packages. -- no debconf information
Bug#919513: CVE-2019-6442 CVE-2019-6443 CVE-2019-6444 CVE-2019-6445
Source: ntpsec Severity: grave Tags: security Please see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6442 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6443 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6444 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6445 Cheers, Moritz
Bug#908071: RM: sheepdog -- ROM; Not maintained, orphaned for 1.5 months
tags 908071 -moreinfo thanks On Sun, Nov 04, 2018 at 11:50:03AM -0500, Scott Kitterman wrote: > On Wed, 05 Sep 2018 22:46:27 +0200 Thomas Goirand wrote: > > Package: ftp.debian.org > > Severity: normal > > > > > > Hi, > > > > Since nobody is picking-up this bug: > > https://bugs.debian.org/903990 > > > > and that Sheepdog hasn't been updated for years, I think it's more > > reasonable to remove the package from Debian. > > Need to address rdepends first: > > Checking reverse dependencies... > # Broken Build-Depends: > libvirt: sheepdog > > Dependency problem found. > > Please remove the moreinfo tag once that has been resolved. sheepdog has been dropped in the latest libvirt upload. Cheers, Moritz
