Bug#949727: firmware-misc-nonfree: Missing dependency initramfs-tools-core

[mando]

Package: firmware-misc-nonfree
Version: 20190717-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I tried to install firmware-misc-nonfree and I got this error:

modprobe: ERROR: ../libkmod/libkmod.c:508 kmod_lookup_alias_from_builtin_file() 
could not open builtin file '/lib/modules/xxx/modules.builtin.bin'

... where xxx is the result of $(uname -r)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

apt install firmware-misc-nonfree

   * What was the outcome of this action?

This fixed the problem.

   * What outcome did you expect instead?

I'd like this dependency to be automatically installed with 
firmware-misc-nonfree.

Thanks, best regards

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


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

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

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.136

-- no debconf information

Bug#861789: Invitation for Data Management and Analysis with SAS Training

[Training in Analysis, M&E, Data Collection and GIS and Consulting Services]

To view the message, please use an HTML compatible email viewer

Link to the online version: 
http://t.emk03.com/weay_m/mXNkbFrGdmJoZWpnll3IoWeZZpqXZHCZjMh1aXBnlW1xXJVxZYqfbmNjZmSSZ5aRZ5lVkpptapSglGhYnm6VX6BzY2tlmXFiV59xmdNd1aFmi6ifyKCilJmSm6Gk

Unsubscribe Link: 
http://t.emk03.com/lvfZ_unsub/mXNkbFrGdmJoZWpnll3IoWeZZpqXZHCZjMh1aXBnlW1xXJVxZYqfbmNjZmSSZ5aRZ5lVkpptapSglGhYnm6VX6BzY2tlmXFiV59xmdNd1aFmi6ifyKCilJmSm6Gk

Foscore Development Center
Welcome to Foscore Development Center, we are a global training and consulting 
firm that has been assisting organizations and individuals to achieve their 
objectives and goals. We specialize in capacity building, consultancy and 
talent development solutions for individuals and organisations through our 
highly customized courses and experienced consultants.Course Title: 
Quantitative Data Management and Analysis with SAS CourseClick to view  all 
course content and register as individual or group to attendClick to Download 
2020 Course Calendar in PDFIntroductionSAS refers to statistical software which 
is used in the management of data, analysis, and graphics. It comprises of 
advanced functions which includes forecasting, survival analysis, data 
analysis, and time series analysis and survey methods. It can be utilized via 
graphical interface using very intuitive language. It benefits from the active 
user community which gives its support on a dedicated mailing. Duration5 Days 
Who Should Attend?Statistician, analyst, or a budding data scientist and 
beginners who want to learn how to analyze data with SAS· Research 
Design, Analysis and Interpretation· Understand the entire workflow 
from a high level perspective · Learn the SAS basic to advance to 
buildup solid understanding of SAS technical skills· Learn to 
accomplish a task with various SAS techniques· Learn step-by-step 
statistical analysis from descriptive statistics, hypothesis testing to linear 
regression · Learn data importing with different techniques for various 
type of data · Use many important functions to make SAS programming ·   
  Learn the important concepts of meta data: formats and informats, labels, 
lengths, etc. · Learn the manipulation techniques to prepare the data 
and make the data analysis-ready · Perform dataset manipulations: 
subsetting, transposition, etc. · Learn how to properly interpret the 
results from statistical analyses  Module 1: Research Design, Analysis and 
interpretation· Introduction to Research and the Research Process·  
   Problem Definition· Research Design and Secondary Data Sources·  
   Qualitative Methods· Descriptive Research Design and Observation·
 Causal Research Design· Measurement, Scaling and Sampling· 
Data Preparation and Analysis Strategy· Hypothesis testing, Frequencies 
and Cross-tabulation· Testing for Significant Differences – 
t-test/ANOVA·  Testing for Association – Correlation and Regression 
Module 2: Understanding the Workflow· The Workflow · SAS Basics 
· Data Importing - Instream data and Proc Import · Import 
Wizard for SAS 9.x · Data Importing in SAS Studio · Bring in 
Data from Pre-existing SAS Dataset and Create Permanent Dataset · Data 
importing - excel data  Module 3: Data Manipulation - Naming Convention and IF 
THEN/ELSE Statement· Naming Convention and Variable Types · IF 
THEN/ELSE Statement · Keep and Drop Variables · Data 
Manipulation - SAS Functions and DO Loop · SAS Functions · DO 
Loop · Dataset Manipulation - Subset and Append · Use WHERE 
statement to subset data · Concatenation (Append)  Module 4: Dataset 
Manipulation - Merge and Transposition · Merge · Merge two 
datasets into a single dataset · Project part 3: Merge two datasets ·   
  Transpose · A comprehensive task using several techniques to 
subset, transpose data  Module 6: Descriptive Statistics - Frequency and 
Univariate Analysis · Explore the Data Using PROC PRINT and CONTENTS 
Procedures · Descriptive Statistics · Calculate the mean of the 
sample · PROC FREQ  Module 7: Perform descriptive statistical analysis 
· One, Two Sample T-Test and ANOVA · One Sample T-Test ·
 Two Sample T-Test · Two Sample T-Test and paired T-Test · 
Sample ANOVA · Non-parametric Analysis  Module 8: Linear Regression - 
Predicting the Outcome · Linear Regression · Use Linear 
Regression model to predict the MSRP · Dummy Variable · Include 
some categorical variables into the model  Module 9: Report writing for 
surveys, data dissemination, demand and use· Writing a report from 
survey data· Communication and dissemination stra

Bug#949028: qtbase5-gles-dev: Try to remove all libkf5*-dev and qt*-dev packages

[Christian Marillat]

On 16 janv. 2020 21:06, Dmitry Shachnev  wrote:

[...]

>> The problem is that all (I didn't checked) qt*-dev packages depends
>> on qtbase5-dev instead of 'qtbase5-dev | qtbase5-gles-dev'
>>
>> I am wrong ?
>
> This is a valid bug, and we will update dependencies of qt*-dev packages.
>
> However please note that in most cases, you don't need to build anything
> against qtbase5-gles-dev.

You need to also fix all others qt*-src packages who also don't depends on
'qtbase5-dev | qtbase5-gles-dev'

Here I see (for now) :

qtx11extras-opensource-src
qttools-opensource-src

Do you need bug reports for these packages ?

Christian

Bug#805966: Invitation for Data Management and Analysis with SAS Training

[Training in Analysis, M&E, Data Collection and GIS and Consulting Services]

To view the message, please use an HTML compatible email viewer

Link to the online version: 
http://t.emk03.com/weay_m/mXNkbFrGdmJoZWpnll3IoWeZZpqXZG6VjMh1aXBnlW1xXJVxZYqfbmNjZmSSZ5aRZ5lVkpptapSglGhYnm6VX6BzY2tlmXFiV59xmdNd1aFmi6ifyKCilJmSm6Gk

Unsubscribe Link: 
http://t.emk03.com/lvfZ_unsub/mXNkbFrGdmJoZWpnll3IoWeZZpqXZG6VjMh1aXBnlW1xXJVxZYqfbmNjZmSSZ5aRZ5lVkpptapSglGhYnm6VX6BzY2tlmXFiV59xmdNd1aFmi6ifyKCilJmSm6Gk

Foscore Development Center
Welcome to Foscore Development Center, we are a global training and consulting 
firm that has been assisting organizations and individuals to achieve their 
objectives and goals. We specialize in capacity building, consultancy and 
talent development solutions for individuals and organisations through our 
highly customized courses and experienced consultants.Course Title: 
Quantitative Data Management and Analysis with SAS CourseClick to view  all 
course content and register as individual or group to attendClick to Download 
2020 Course Calendar in PDFIntroductionSAS refers to statistical software which 
is used in the management of data, analysis, and graphics. It comprises of 
advanced functions which includes forecasting, survival analysis, data 
analysis, and time series analysis and survey methods. It can be utilized via 
graphical interface using very intuitive language. It benefits from the active 
user community which gives its support on a dedicated mailing. Duration5 Days 
Who Should Attend?Statistician, analyst, or a budding data scientist and 
beginners who want to learn how to analyze data with SAS· Research 
Design, Analysis and Interpretation· Understand the entire workflow 
from a high level perspective · Learn the SAS basic to advance to 
buildup solid understanding of SAS technical skills· Learn to 
accomplish a task with various SAS techniques· Learn step-by-step 
statistical analysis from descriptive statistics, hypothesis testing to linear 
regression · Learn data importing with different techniques for various 
type of data · Use many important functions to make SAS programming ·   
  Learn the important concepts of meta data: formats and informats, labels, 
lengths, etc. · Learn the manipulation techniques to prepare the data 
and make the data analysis-ready · Perform dataset manipulations: 
subsetting, transposition, etc. · Learn how to properly interpret the 
results from statistical analyses  Module 1: Research Design, Analysis and 
interpretation· Introduction to Research and the Research Process·  
   Problem Definition· Research Design and Secondary Data Sources·  
   Qualitative Methods· Descriptive Research Design and Observation·
 Causal Research Design· Measurement, Scaling and Sampling· 
Data Preparation and Analysis Strategy· Hypothesis testing, Frequencies 
and Cross-tabulation· Testing for Significant Differences – 
t-test/ANOVA·  Testing for Association – Correlation and Regression 
Module 2: Understanding the Workflow· The Workflow · SAS Basics 
· Data Importing - Instream data and Proc Import · Import 
Wizard for SAS 9.x · Data Importing in SAS Studio · Bring in 
Data from Pre-existing SAS Dataset and Create Permanent Dataset · Data 
importing - excel data  Module 3: Data Manipulation - Naming Convention and IF 
THEN/ELSE Statement· Naming Convention and Variable Types · IF 
THEN/ELSE Statement · Keep and Drop Variables · Data 
Manipulation - SAS Functions and DO Loop · SAS Functions · DO 
Loop · Dataset Manipulation - Subset and Append · Use WHERE 
statement to subset data · Concatenation (Append)  Module 4: Dataset 
Manipulation - Merge and Transposition · Merge · Merge two 
datasets into a single dataset · Project part 3: Merge two datasets ·   
  Transpose · A comprehensive task using several techniques to 
subset, transpose data  Module 6: Descriptive Statistics - Frequency and 
Univariate Analysis · Explore the Data Using PROC PRINT and CONTENTS 
Procedures · Descriptive Statistics · Calculate the mean of the 
sample · PROC FREQ  Module 7: Perform descriptive statistical analysis 
· One, Two Sample T-Test and ANOVA · One Sample T-Test ·
 Two Sample T-Test · Two Sample T-Test and paired T-Test · 
Sample ANOVA · Non-parametric Analysis  Module 8: Linear Regression - 
Predicting the Outcome · Linear Regression · Use Linear 
Regression model to predict the MSRP · Dummy Variable · Include 
some categorical variables into the model  Module 9: Report writing for 
surveys, data dissemination, demand and use· Writing a report from 
survey data· Communication and dissemination stra

Bug#949726: mariadb-server-10.3: mariadb-server cannot be installed, fails to fetch .deb, 404 Not Found

[Tamás Stirling]

Package: mariadb-server-10.3
Version: 10.3.17
Severity: important

Dear Maintainer,

I could not install mariadb-server because apt was unable to fetch some
archives. sudo apt-get update was successful, and I don't have any issues
installing other packages.

E: Failed to fetch
http://deb.debian.org/debian/pool/main/m/mariadb-10.3/mariadb-client-
core-10.3_10.3.17-0+deb10u1_amd64.deb  404  Not Found [IP: 2a04:4e42:43::204
80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/m/mariadb-10.3/mariadb-
client-10.3_10.3.17-0+deb10u1_amd64.deb  404  Not Found [IP: 2a04:4e42:43::204
80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/m/mariadb-10.3/mariadb-server-
core-10.3_10.3.17-0+deb10u1_amd64.deb  404  Not Found [IP: 2a04:4e42:43::204
80]
E: Failed to fetch
http://deb.debian.org/debian/pool/main/m/mariadb-10.3/mariadb-
server-10.3_10.3.17-0+deb10u1_amd64.deb  404  Not Found [IP: 2a04:4e42:43::204
80]

Thank you for your help in advance.

Kind regards,
Tamás






-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
pn  galera-3  
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
pn  libdbi-perl   
ii  libgnutls30   3.6.7-4
ii  libpam0g  1.3.1-5
ii  libstdc++68.3.0-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
pn  mariadb-client-10.3   
ii  mariadb-common1:10.3.17-0+deb10u1
pn  mariadb-server-core-10.3  
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6
ii  psmisc23.2-1
ii  rsync 3.1.3-6
pn  socat 
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
pn  libhtml-template-perl  

Versions of packages mariadb-server-10.3 suggests:
pn  mailx   
pn  mariadb-test
pn  netcat-openbsd  
pn  tinyca  

Bug#949724: nmu: kalzium_4:19.08.1-1

[merkys]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 948477 by -1

nmu kalzium_4:19.08.1-1 . ANY . unstable . -m 'Rebuild with
libopenbabel-dev >= 3.0.0+dfsg-2'

Hello,

To complete the auto-openbabel transition [1], kalzium has to be rebuilt
to use libopenbabel6 instead of libopenbabel5.

Thanks,
Andrius

[1] https://release.debian.org/transitions/html/auto-openbabel.html




signature.asc
Description: OpenPGP digital signature

Bug#949725: onedrive: Fails to connect to service

[Bruno Kleinert]

Package: onedrive
Version: 2.3.13-1
Severity: important

Hi,

onedrive seems to be unable to connect to servers anymore. 'journalctl  --since
today --user --unit onedrive' contains repetitions of:

[…]
an 24 07:54:10 debian systemd[932]: Started OneDrive Free Client.
Jan 24 07:54:11 debian onedrive[20607]: ERROR: OneDrive returned a 'HTTP 401
Unauthorized' - Cannot Initialize Sync Engine
Jan 24 07:54:11 debian onedrive[20607]: ERROR: Check your configuration as your
access token may be empty or invalid
Jan 24 07:54:11 debian systemd[932]: onedrive.service: Main process exited,
code=killed, status=11/SEGV
Jan 24 07:54:11 debian systemd[932]: onedrive.service: Failed with result
'signal'.
Jan 24 07:54:14 debian systemd[932]: onedrive.service: Scheduled restart job,
restart counter is at 1473.
Jan 24 07:54:14 debian systemd[932]: Stopped OneDrive Free Client.
Jan 24 07:54:14 debian systemd[932]: Started OneDrive Free Client.
Jan 24 07:54:15 debian onedrive[20616]: ERROR: OneDrive returned a 'HTTP 401
Unauthorized' - Cannot Initialize Sync Engine
Jan 24 07:54:15 debian onedrive[20616]: ERROR: Check your configuration as your
access token may be empty or invalid
Jan 24 07:54:15 debian systemd[932]: onedrive.service: Main process exited,
code=killed, status=11/SEGV
Jan 24 07:54:15 debian systemd[932]: onedrive.service: Failed with result
'signal'.
Jan 24 07:54:18 debian systemd[932]: onedrive.service: Scheduled restart job,
restart counter is at 1474.
Jan 24 07:54:18 debian systemd[932]: Stopped OneDrive Free Client.
Jan 24 07:54:18 debian systemd[932]: Started OneDrive Free Client.
[…]

Running 'onedrive --get-O365-drive-id 'bruno.klein...@elektrobit.com' --debug-
https --verbose' results in:

Using Config Dir: /home/brkl270007/.config/onedrive
Initializing the OneDrive API ...
Opening the item database ...
All operations will be performed in: /home/brkl270007/OneDrive
*   Trying 20.190.129.2:443...
* TCP_NODELAY set
* Connected to login.microsoftonline.com (20.190.129.2) port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=stamp2.login.microsoftonline.com
*  start date: Sep 24 21:35:29 2018 GMT
*  expire date: Sep 24 21:35:29 2020 GMT
*  subjectAltName: host "login.microsoftonline.com" matched cert's
"login.microsoftonline.com"
*  issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation;
OU=Microsoft IT; CN=Microsoft IT TLS CA 1
*  SSL certificate verify ok.
> POST /common/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
User-Agent: OneDrive Client for Linux v2.3.13-1
Accept: */*
Content-Length: 1049
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue

* Mark bundle as not supporting multiuse
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Cache-Control: no-cache, no-store
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< Expires: -1
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Content-Type-Options: nosniff
< x-ms-request-id: a0d61489-4ede-4b40-818d-3b09ec073b00
< x-ms-ests-server: 2.1.9926.12 - CHI ProdSlices
< P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
< Set-Cookie: fpc=AqalyRCs2dNBt4ssODYYZ-0jJKg8AQAAADiMvNUO; expires=Sun,
23-Feb-2020 06:56:57 GMT; path=/; secure; HttpOnly; SameSite=None
< Set-Cookie: x-ms-gateway-slice=prod; path=/; SameSite=None; secure; HttpOnly
< Set-Cookie: stsservicecookie=ests; path=/; SameSite=None; secure; HttpOnly
< Date: Fri, 24 Jan 2020 06:56:56 GMT
< Content-Length: 737
<
OneDrive HTTP Server Response: 400
* Connection #0 to host login.microsoftonline.com left intact
OneDrive returned a 'HTTP 400 - Bad Request' - gracefully handling error
*   Trying 20.190.137.112:443...
* TCP_NODELAY set
* Connected to graph.microsoft.com (20.190.137.112) port 443 (#1)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=graph.microsoft.com
*  start date: Jan 27 19:09:45 2019 GMT
*  expire date: Jan 27 19:09:45 2021 GMT
*  subjectAltName: host "graph.microsoft.com" matched cert's
"graph.microsoft.com"
*  issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation;
OU=Microsoft IT; CN=Microsoft IT TLS CA 2
*  SSL certificate verify ok.
> GET /v1.0/me/drive HTTP/1.1
Host: graph.microsoft.com
User-Agent: OneDrive Client for Linux v2.3.13-1
Accept: */*

* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Cache-Control: private
< Content-Type: application/json
< request-id: c0ca1c93-fea5-43de-8fad-29399cec71bc
< client-request-id: c0ca1c93-fea5-43de-8fad-29399cec71bc
< x-ms-ags-diagnostic: {"ServerInf

Bug#877715: Invitation for Data Management and Analysis with SAS Training

[Training in Analysis, M&E, Data Collection and GIS and Consulting Services]

To view the message, please use an HTML compatible email viewer

Link to the online version: 
http://t.emk03.com/TFis_m/mXNkbFrGdmJoZWpnll3IoWeZZpqWY2-djMh1aXBnlW1wXJVxZYqfbmNjZmSSZ5aRZ5lVkpltbJSglGhYnm6VX6BzY2tlmXFhV59xmdNd1aFmi6ifyKCilJmSm6Gk

Unsubscribe Link: 
http://t.emk03.com/CEfv_unsub/mXNkbFrGdmJoZWpnll3IoWeZZpqWY2-djMh1aXBnlW1wXJVxZYqfbmNjZmSSZ5aRZ5lVkpltbJSglGhYnm6VX6BzY2tlmXFhV59xmdNd1aFmi6ifyKCilJmSm6Gk

Foscore Development Center
Welcome to Foscore Development Center, we are a global training and consulting 
firm that has been assisting organizations and individuals to achieve their 
objectives and goals. We specialize in capacity building, consultancy and 
talent development solutions for individuals and organisations through our 
highly customized courses and experienced consultants.Course Title: 
Quantitative Data Management and Analysis with SAS CourseClick to view  all 
course content and register as individual or group to attendClick to Download 
2020 Course Calendar in PDFIntroductionSAS refers to statistical software which 
is used in the management of data, analysis, and graphics. It comprises of 
advanced functions which includes forecasting, survival analysis, data 
analysis, and time series analysis and survey methods. It can be utilized via 
graphical interface using very intuitive language. It benefits from the active 
user community which gives its support on a dedicated mailing. Duration5 Days 
Who Should Attend?Statistician, analyst, or a budding data scientist and 
beginners who want to learn how to analyze data with SAS· Research 
Design, Analysis and Interpretation· Understand the entire workflow 
from a high level perspective · Learn the SAS basic to advance to 
buildup solid understanding of SAS technical skills· Learn to 
accomplish a task with various SAS techniques· Learn step-by-step 
statistical analysis from descriptive statistics, hypothesis testing to linear 
regression · Learn data importing with different techniques for various 
type of data · Use many important functions to make SAS programming ·   
  Learn the important concepts of meta data: formats and informats, labels, 
lengths, etc. · Learn the manipulation techniques to prepare the data 
and make the data analysis-ready · Perform dataset manipulations: 
subsetting, transposition, etc. · Learn how to properly interpret the 
results from statistical analyses  Module 1: Research Design, Analysis and 
interpretation· Introduction to Research and the Research Process·  
   Problem Definition· Research Design and Secondary Data Sources·  
   Qualitative Methods· Descriptive Research Design and Observation·
 Causal Research Design· Measurement, Scaling and Sampling· 
Data Preparation and Analysis Strategy· Hypothesis testing, Frequencies 
and Cross-tabulation· Testing for Significant Differences – 
t-test/ANOVA·  Testing for Association – Correlation and Regression 
Module 2: Understanding the Workflow· The Workflow · SAS Basics 
· Data Importing - Instream data and Proc Import · Import 
Wizard for SAS 9.x · Data Importing in SAS Studio · Bring in 
Data from Pre-existing SAS Dataset and Create Permanent Dataset · Data 
importing - excel data  Module 3: Data Manipulation - Naming Convention and IF 
THEN/ELSE Statement· Naming Convention and Variable Types · IF 
THEN/ELSE Statement · Keep and Drop Variables · Data 
Manipulation - SAS Functions and DO Loop · SAS Functions · DO 
Loop · Dataset Manipulation - Subset and Append · Use WHERE 
statement to subset data · Concatenation (Append)  Module 4: Dataset 
Manipulation - Merge and Transposition · Merge · Merge two 
datasets into a single dataset · Project part 3: Merge two datasets ·   
  Transpose · A comprehensive task using several techniques to 
subset, transpose data  Module 6: Descriptive Statistics - Frequency and 
Univariate Analysis · Explore the Data Using PROC PRINT and CONTENTS 
Procedures · Descriptive Statistics · Calculate the mean of the 
sample · PROC FREQ  Module 7: Perform descriptive statistical analysis 
· One, Two Sample T-Test and ANOVA · One Sample T-Test ·
 Two Sample T-Test · Two Sample T-Test and paired T-Test · 
Sample ANOVA · Non-parametric Analysis  Module 8: Linear Regression - 
Predicting the Outcome · Linear Regression · Use Linear 
Regression model to predict the MSRP · Dummy Variable · Include 
some categorical variables into the model  Module 9: Report writing for 
surveys, data dissemination, demand and use· Writing a report from 
survey data· Communication and dissemination stra

Bug#867565: Invitation for Data Management and Analysis with SAS Training

[Training in Analysis, M&E, Data Collection and GIS and Consulting Services]

To view the message, please use an HTML compatible email viewer

Link to the online version: 
http://t.emk03.com/TFis_m/mXNkbFrGdmJoZWpnll3IoWeZZpqVamyVjMh1aXBnlW1wXJVxZYqfbmNjZmSSZ5aRZ5lVkpltbJSglGhYnm6VX6BzY2tlmXFhV59xmdNd1aFmi6ifyKCilJmSm6Gk

Unsubscribe Link: 
http://t.emk03.com/CEfv_unsub/mXNkbFrGdmJoZWpnll3IoWeZZpqVamyVjMh1aXBnlW1wXJVxZYqfbmNjZmSSZ5aRZ5lVkpltbJSglGhYnm6VX6BzY2tlmXFhV59xmdNd1aFmi6ifyKCilJmSm6Gk

Foscore Development Center
Welcome to Foscore Development Center, we are a global training and consulting 
firm that has been assisting organizations and individuals to achieve their 
objectives and goals. We specialize in capacity building, consultancy and 
talent development solutions for individuals and organisations through our 
highly customized courses and experienced consultants.Course Title: 
Quantitative Data Management and Analysis with SAS CourseClick to view  all 
course content and register as individual or group to attendClick to Download 
2020 Course Calendar in PDFIntroductionSAS refers to statistical software which 
is used in the management of data, analysis, and graphics. It comprises of 
advanced functions which includes forecasting, survival analysis, data 
analysis, and time series analysis and survey methods. It can be utilized via 
graphical interface using very intuitive language. It benefits from the active 
user community which gives its support on a dedicated mailing. Duration5 Days 
Who Should Attend?Statistician, analyst, or a budding data scientist and 
beginners who want to learn how to analyze data with SAS· Research 
Design, Analysis and Interpretation· Understand the entire workflow 
from a high level perspective · Learn the SAS basic to advance to 
buildup solid understanding of SAS technical skills· Learn to 
accomplish a task with various SAS techniques· Learn step-by-step 
statistical analysis from descriptive statistics, hypothesis testing to linear 
regression · Learn data importing with different techniques for various 
type of data · Use many important functions to make SAS programming ·   
  Learn the important concepts of meta data: formats and informats, labels, 
lengths, etc. · Learn the manipulation techniques to prepare the data 
and make the data analysis-ready · Perform dataset manipulations: 
subsetting, transposition, etc. · Learn how to properly interpret the 
results from statistical analyses  Module 1: Research Design, Analysis and 
interpretation· Introduction to Research and the Research Process·  
   Problem Definition· Research Design and Secondary Data Sources·  
   Qualitative Methods· Descriptive Research Design and Observation·
 Causal Research Design· Measurement, Scaling and Sampling· 
Data Preparation and Analysis Strategy· Hypothesis testing, Frequencies 
and Cross-tabulation· Testing for Significant Differences – 
t-test/ANOVA·  Testing for Association – Correlation and Regression 
Module 2: Understanding the Workflow· The Workflow · SAS Basics 
· Data Importing - Instream data and Proc Import · Import 
Wizard for SAS 9.x · Data Importing in SAS Studio · Bring in 
Data from Pre-existing SAS Dataset and Create Permanent Dataset · Data 
importing - excel data  Module 3: Data Manipulation - Naming Convention and IF 
THEN/ELSE Statement· Naming Convention and Variable Types · IF 
THEN/ELSE Statement · Keep and Drop Variables · Data 
Manipulation - SAS Functions and DO Loop · SAS Functions · DO 
Loop · Dataset Manipulation - Subset and Append · Use WHERE 
statement to subset data · Concatenation (Append)  Module 4: Dataset 
Manipulation - Merge and Transposition · Merge · Merge two 
datasets into a single dataset · Project part 3: Merge two datasets ·   
  Transpose · A comprehensive task using several techniques to 
subset, transpose data  Module 6: Descriptive Statistics - Frequency and 
Univariate Analysis · Explore the Data Using PROC PRINT and CONTENTS 
Procedures · Descriptive Statistics · Calculate the mean of the 
sample · PROC FREQ  Module 7: Perform descriptive statistical analysis 
· One, Two Sample T-Test and ANOVA · One Sample T-Test ·
 Two Sample T-Test · Two Sample T-Test and paired T-Test · 
Sample ANOVA · Non-parametric Analysis  Module 8: Linear Regression - 
Predicting the Outcome · Linear Regression · Use Linear 
Regression model to predict the MSRP · Dummy Variable · Include 
some categorical variables into the model  Module 9: Report writing for 
surveys, data dissemination, demand and use· Writing a report from 
survey data· Communication and dissemination stra

Bug#914606: Invitation for Data Management and Analysis with SAS Training

[Training in Analysis, M&E, Data Collection and GIS and Consulting Services]

To view the message, please use an HTML compatible email viewer

Link to the online version: 
http://t.emk03.com/TFis_m/mXNkbFrGdmJoZWpnll3IoWeZZpqVZWeWjMh1aXBnlW1wXJVxZYqfbmNjZmSSZ5aRZ5lVkpltbJSglGhYnm6VX6BzY2tlmXFhV59xmdNd1aFmi6ifyKCilJmSm6Gk

Unsubscribe Link: 
http://t.emk03.com/CEfv_unsub/mXNkbFrGdmJoZWpnll3IoWeZZpqVZWeWjMh1aXBnlW1wXJVxZYqfbmNjZmSSZ5aRZ5lVkpltbJSglGhYnm6VX6BzY2tlmXFhV59xmdNd1aFmi6ifyKCilJmSm6Gk

Foscore Development Center
Welcome to Foscore Development Center, we are a global training and consulting 
firm that has been assisting organizations and individuals to achieve their 
objectives and goals. We specialize in capacity building, consultancy and 
talent development solutions for individuals and organisations through our 
highly customized courses and experienced consultants.Course Title: 
Quantitative Data Management and Analysis with SAS CourseClick to view  all 
course content and register as individual or group to attendClick to Download 
2020 Course Calendar in PDFIntroductionSAS refers to statistical software which 
is used in the management of data, analysis, and graphics. It comprises of 
advanced functions which includes forecasting, survival analysis, data 
analysis, and time series analysis and survey methods. It can be utilized via 
graphical interface using very intuitive language. It benefits from the active 
user community which gives its support on a dedicated mailing. Duration5 Days 
Who Should Attend?Statistician, analyst, or a budding data scientist and 
beginners who want to learn how to analyze data with SAS· Research 
Design, Analysis and Interpretation· Understand the entire workflow 
from a high level perspective · Learn the SAS basic to advance to 
buildup solid understanding of SAS technical skills· Learn to 
accomplish a task with various SAS techniques· Learn step-by-step 
statistical analysis from descriptive statistics, hypothesis testing to linear 
regression · Learn data importing with different techniques for various 
type of data · Use many important functions to make SAS programming ·   
  Learn the important concepts of meta data: formats and informats, labels, 
lengths, etc. · Learn the manipulation techniques to prepare the data 
and make the data analysis-ready · Perform dataset manipulations: 
subsetting, transposition, etc. · Learn how to properly interpret the 
results from statistical analyses  Module 1: Research Design, Analysis and 
interpretation· Introduction to Research and the Research Process·  
   Problem Definition· Research Design and Secondary Data Sources·  
   Qualitative Methods· Descriptive Research Design and Observation·
 Causal Research Design· Measurement, Scaling and Sampling· 
Data Preparation and Analysis Strategy· Hypothesis testing, Frequencies 
and Cross-tabulation· Testing for Significant Differences – 
t-test/ANOVA·  Testing for Association – Correlation and Regression 
Module 2: Understanding the Workflow· The Workflow · SAS Basics 
· Data Importing - Instream data and Proc Import · Import 
Wizard for SAS 9.x · Data Importing in SAS Studio · Bring in 
Data from Pre-existing SAS Dataset and Create Permanent Dataset · Data 
importing - excel data  Module 3: Data Manipulation - Naming Convention and IF 
THEN/ELSE Statement· Naming Convention and Variable Types · IF 
THEN/ELSE Statement · Keep and Drop Variables · Data 
Manipulation - SAS Functions and DO Loop · SAS Functions · DO 
Loop · Dataset Manipulation - Subset and Append · Use WHERE 
statement to subset data · Concatenation (Append)  Module 4: Dataset 
Manipulation - Merge and Transposition · Merge · Merge two 
datasets into a single dataset · Project part 3: Merge two datasets ·   
  Transpose · A comprehensive task using several techniques to 
subset, transpose data  Module 6: Descriptive Statistics - Frequency and 
Univariate Analysis · Explore the Data Using PROC PRINT and CONTENTS 
Procedures · Descriptive Statistics · Calculate the mean of the 
sample · PROC FREQ  Module 7: Perform descriptive statistical analysis 
· One, Two Sample T-Test and ANOVA · One Sample T-Test ·
 Two Sample T-Test · Two Sample T-Test and paired T-Test · 
Sample ANOVA · Non-parametric Analysis  Module 8: Linear Regression - 
Predicting the Outcome · Linear Regression · Use Linear 
Regression model to predict the MSRP · Dummy Variable · Include 
some categorical variables into the model  Module 9: Report writing for 
surveys, data dissemination, demand and use· Writing a report from 
survey data· Communication and dissemination stra

Bug#949723: python-jsonschema's autopkg tests fail, when python3-json-pointer is installed

[Matthias Klose]

Package: python-jsonschema,python-json-pointer
Severity: important
Tags: sid bullseye

python-jsonschema's autopkg tests fail, when python3-json-pointer is installed.

Looking at jsonschema's setup.cfg:

[options.extras_require]
format =
idna
jsonpointer>1.13
rfc3987
strict-rfc3339
webcolors

and indeed after updating json-pointer to 2.0, the tests pass.

Two action items:

 - update json-pointer to a new upstream (2.0 seems to work)

 - python3-jsonschema should break python3-json-pointer (<< 1.14)

Bug#949703: thunderbird doesn' start on Sid

[Carsten Schoenert]

Control: forcemerge 949703 949695

Hello Mauro,

this is already reported within #949695.

Am 23.01.20 um 22:41 schrieb Mauro Sacchetto:
> Package: Thunderbird
> Version: 1:68.4.1-1+b1
> 
> after the last today update, thunderbird doesn' start on Sid.
> from console:
> ===
> samiel@darkstar:~$ thunderbird
> ExceptionHandler::GenerateDump cloned child 4951
> ExceptionHandler::SendContinueSignalToChild sent continue signal to child
> ExceptionHandler::WaitForContinueSignal waiting for continue signal...
> ===
> 
> ms
> 

-- 
Regards
Carsten Schoenert

Bug#900710: a man page should be provided for kdeconnect-cli

[Pino Toscano]

Hi Nicholas,

In data giovedì 23 gennaio 2020 14:46:04 CET, Nicholas D Steeves ha scritto:
> > Date: Mon, 12 Nov 2018 08:41:46 +
> > From: Pino Toscano 
> > To: 900710-cl...@bugs.debian.org
> > Subject: Bug#900710: fixed in kdeconnect 1.3.3-1
> > 
> > Source: kdeconnect
> > Source-Version: 1.3.3-1
> >
> [snip]
> >  kdeconnect (1.3.3-1) unstable; urgency=medium
> [snip]
> >* Drop the Debian-provided kdeconnect-cli man page: very outdated, not
> >  touched in the last 4 years, and thus not useful. (Closes: #900710)
> 
> This bug was closed in error at a time I was swamped with work, and I
> didn't notice until now.

No, this bug was definitely not closed in error. The original bug was
about the man page being very outdated (and it was), so the removal was
one possible way to fix this issue, in particular the one I chose.

Because of this, I disagree with the reopening of this old bug and
turning it into something else than it was originally. Opening a *new*
wishlist bug "please provide a man page" would had been a better idea.

> Please consult Policy §12.1 for why it was
> wrong to close it.  tldr;
> 
> If no manual page is available, this is considered as a bug and
> should be reported to the Debian Bug Tracking System (the
> maintainer of the package is allowed to write this bug report
> themselves, if they so desire). Do not close the bug report until
> a proper man page is available.

It is a *should*, so there is no requirement on us to either ship a man
page, or even do the work to provide one as part of the Debian
packaging.

In general, we (Debian Qt/KDE) ought to *not* provide man pages
ourselves, as it has many drawbacks:

- the man page must be maintained by the team and, considering the huge
  amount of work the team already has, this means that a man page is
  rarely (if ever) updated after its first introduction; and this very
  reply of yours show this very well: if the person that adds a man
  page is busy or does not contribute to the team anymore, then nobody
  else will work on it

- the man page is available only to Debian users

- the man page is only in English

- the Debian-provided man page will silently overwrite an upstream
  provided one (!); this actually happened in two cases that I spotted
  when updating KDE Applications to 17.08 a couple of years ago

- unless the executable has any option other than the usual
  --help/--version/--author, a man page does not add any value to the
  package, and becomes just a bureaucratic formality than a real need

So our guideline for this ought to be:

- do not provide Debian-specific man page

- *iff* (if and only if) a man page is requested for a real reason [1],
  forward the request upstream to provide a man page, if they desire;
  optionally submitting one in DocBook format (in case of KDE projects)

- if there is no request it means there is no demand for it

[1] for "real reason" I mean that the request is justified because of
the executable, and not requested like "lintian complains" or
"Policy says"

Having a man page shipped by upstream has multiple advantages:

- the man page is available to all the users, not just Debian ones
  (and thus more people can read it and spot issues, provide
  enhancements, etc)

- the man page is available also in other languages

- upstream (the developers directly, or the KDE documentation team)
  will keep the man page up-to-date

- there is no additional work required on the Debian side, nor
  additional files in our debian/ directories

Hope this clarifies the situation.

-- 
Pino Toscano

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

Bug#949722: openldap: rename stage1 build profile

[Helmut Grohne]

Hi Ryan,

On Thu, Jan 23, 2020 at 09:48:33PM -0800, Ryan Tandy wrote:
> I won't spend too long bikeshedding the name, but would "noslapd" be at least 
> as informative as "nodaemon"?

I don't mind using noslapd. Indeed, that has come to my mind as an
alternative as it closely mirrors the relevant configure option. Just
please avoid "stage1" and use the "pkg.openldap." prefix since neither
is a registered[1] profile name. It really is a minor issue of cleaning
up the profile namespace.

Helmut

[1] https://wiki.debian.org/BuildProfileSpec#Registered_profile_names

Bug#949722: openldap: rename stage1 build profile

[Ryan Tandy]

Hello Helmut, thanks for the patch and I will apply it in the next upload.

I won't spend too long bikeshedding the name, but would "noslapd" be at least as 
informative as "nodaemon"?

Bug#949722: openldap: rename stage1 build profile

[Helmut Grohne]

Source: openldap
Version: 2.4.48+dfsg-1
Severity: minor
Tags: patch

openldap has implemented a "stage1" build profile to help bootstrapping
architectures. Unfortunately, "stage1" is only meaningful when you look
at many packages. You cannot easily tell what it means for openldap just
by looking at openldap. We have since implemented a number of standard
profile names. The most common ones disable language bindings (e.g.
"nopython"). However, none of the established ones seem a good fit for
openldap. I'm therefore proposing a custom profile name
"pkg.openldap.nodaemon" here. Just reading the name should make it
obvious, what this profile does. I've attached a patch implementing this
rename. Please consider applying it if you agree with my proposal.
Otherwise, let's talk about a better name. In any case, we want to stop
using "stage1" as much as possible to enable building whole package sets
with the same set of profiles, but "stage1" doesn't have uniform meaning
across packages.

Helmut
diff --minimal -Nru openldap-2.4.48+dfsg/debian/changelog 
openldap-2.4.48+dfsg/debian/changelog
--- openldap-2.4.48+dfsg/debian/changelog   2019-07-25 17:32:00.0 
+0200
+++ openldap-2.4.48+dfsg/debian/changelog   2020-01-24 06:24:45.0 
+0100
@@ -1,3 +1,10 @@
+openldap (2.4.48+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename stage1 build profileto pkg.openldap.nodaemon. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 24 Jan 2020 06:24:45 +0100
+
 openldap (2.4.48+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru openldap-2.4.48+dfsg/debian/control 
openldap-2.4.48+dfsg/debian/control
--- openldap-2.4.48+dfsg/debian/control 2019-07-25 02:14:43.0 +0200
+++ openldap-2.4.48+dfsg/debian/control 2020-01-24 06:22:47.0 +0100
@@ -8,17 +8,17 @@
 Build-Depends: debhelper (>= 10),
dpkg-dev (>= 1.17.14),
groff-base,
-   heimdal-multidev (>= 7.4.0.dfsg.1-1~) ,
-   libdb5.3-dev ,
+   heimdal-multidev (>= 7.4.0.dfsg.1-1~) ,
+   libdb5.3-dev ,
libgnutls28-dev,
-   libltdl-dev ,
-   libperl-dev (>= 5.8.0) ,
+   libltdl-dev ,
+   libperl-dev (>= 5.8.0) ,
libsasl2-dev,
-   libwrap0-dev ,
-   nettle-dev ,
+   libwrap0-dev ,
+   nettle-dev ,
perl:any,
po-debconf,
-   unixodbc-dev 
+   unixodbc-dev 
 Build-Conflicts: libbind-dev, bind-dev, libicu-dev, autoconf2.13
 Standards-Version: 4.4.0
 Homepage: http://www.openldap.org/
@@ -28,7 +28,7 @@
 
 Package: slapd
 Architecture: any
-Build-Profiles: 
+Build-Profiles: 
 Pre-Depends: debconf (>= 0.5) | debconf-2.0, ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, libldap-2.4-2 (= ${binary:Version}),
  coreutils (>= 4.5.1-1), psmisc, perl (>> 5.8.0) | libmime-base64-perl,
@@ -46,7 +46,7 @@
 
 Package: slapd-contrib
 Architecture: any
-Build-Profiles: 
+Build-Profiles: 
 Depends: slapd (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
 Provides: slapd-smbk5pwd
 Breaks: slapd-smbk5pwd (<< 2.4.47+dfsg-2~)
@@ -59,7 +59,7 @@
 Package: slapd-smbk5pwd
 Architecture: all
 Section: oldlibs
-Build-Profiles: 
+Build-Profiles: 
 Depends: slapd-contrib, ${misc:Depends}
 Breaks: slapd (<< 2.4.47+dfsg-2~)
 Description: transitional package for slapd-contrib
@@ -118,7 +118,7 @@
 Package: slapi-dev
 Section: libdevel
 Architecture: any
-Build-Profiles: 
+Build-Profiles: 
 Depends: slapd (= ${binary:Version}), ${misc:Depends}
 Description: development libraries for OpenLDAP SLAPI plugin interface
  This package allows development of plugins for the OpenLDAP slapd server
diff --minimal -Nru openldap-2.4.48+dfsg/debian/rules 
openldap-2.4.48+dfsg/debian/rules
--- openldap-2.4.48+dfsg/debian/rules   2019-07-25 02:14:43.0 +0200
+++ openldap-2.4.48+dfsg/debian/rules   2020-01-24 06:24:41.0 +0100
@@ -17,7 +17,7 @@
 ifeq ($(DEB_HOST_ARCH_OS),hurd)
CONFIG += --disable-bdb --disable-hdb --disable-mdb
 endif
-ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+ifneq ($(filter pkg.openldap.nodaemon,$(DEB_BUILD_PROFILES)),)
CONFIG += --disable-slapd
 endif
 
@@ -110,7 +110,7 @@
 
 override_dh_auto_build:
dh_auto_build -- $(MAKEVARS)
-ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+ifeq ($(filter pkg.openldap.nodaemon,$(DEB_BUILD_PROFILES)),)
for mod in $(CONTRIB_MODULES); do \
dh_auto_build -Dcontrib/slapd-modules/$$mod 
-Bcontrib/slapd-modules/$$mod -- $(CONTRIB_MAKEVARS) || exit $$?; \
done
@@ -125,7 +125,7 @@
 
 override_dh_auto_install:
dh_auto_install -- $(MAKEVARS)
-ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+ifeq ($(filter pkg.openldap.nodaemon,$(DEB_BUILD_PROFILES)),)
for mod in $(CONTRIB_MODULES); do \
dh_auto_install -Dcontrib/slapd-modules/$$mod 
-Bcontrib/s

Bug#949721: newt: rename stage1 build profile to nopython

[Helmut Grohne]

Source: newt
Version: 0.52.21-4
Severity: minor
Tags: patch

newt was one of the early adopters of build profiles. As such it used
the "stage1" profile. We've now deprecated that profile name, because it
does not convey meaning. You can only understand what stage1 means for
newt if you look at many other packages. For that reason, we've
deprecated stage1. Please use "nopython" instead. I guess you'll
immediately see what "nopython" means. That's the way it is supposed to
work now. Please consider applying the attached patch.

Helmut
diff --minimal -Nru newt-0.52.21/debian/changelog newt-0.52.21/debian/changelog
--- newt-0.52.21/debian/changelog   2019-12-17 08:32:55.0 +0100
+++ newt-0.52.21/debian/changelog   2020-01-24 06:03:24.0 +0100
@@ -1,3 +1,10 @@
+newt (0.52.21-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename stage1 build profile to nopython. Closes: #-1
+
+ -- Helmut Grohne   Fri, 24 Jan 2020 06:03:24 +0100
+
 newt (0.52.21-4) unstable; urgency=medium
 
   * Switch from sgmltools-lite to docbook-utils for py2, sgmltools orphaned.
diff --minimal -Nru newt-0.52.21/debian/control newt-0.52.21/debian/control
--- newt-0.52.21/debian/control 2019-12-17 08:32:55.0 +0100
+++ newt-0.52.21/debian/control 2020-01-24 06:02:50.0 +0100
@@ -14,9 +14,9 @@
  gettext, 
  libfribidi-dev, 
  tcl8.6-dev, 
- dh-python , 
- python3-all-dev:any , 
- libpython3-all-dev 
+ dh-python , 
+ python3-all-dev:any , 
+ libpython3-all-dev 
 
 Package: libnewt-dev
 Architecture: any
@@ -63,7 +63,7 @@
 Section: python
 Provides: ${python3:Provides}
 Depends: libnewt0.52 (=${binary:Version}) , ${python3:Depends}, 
${misc:Depends}, ${shlibs:Depends}
-Build-Profiles: 
+Build-Profiles: 
 Description: NEWT module for Python3
  This module allows you to build a text UI for your Python3 scripts
  using newt.
diff --minimal -Nru newt-0.52.21/debian/rules newt-0.52.21/debian/rules
--- newt-0.52.21/debian/rules   2019-12-17 08:32:55.0 +0100
+++ newt-0.52.21/debian/rules   2020-01-24 06:03:13.0 +0100
@@ -11,7 +11,7 @@
 
 # Magic debhelper rule.
 %:
-ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+ifeq ($(filter nopython,$(DEB_BUILD_PROFILES)),)
dh $@ --with python3
 else
dh $@ 
@@ -59,7 +59,7 @@
 
 override_dh_auto_install:
dh_auto_install 
-ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+ifeq ($(filter nopython,$(DEB_BUILD_PROFILES)),)
for v in $(PY3VERS); do \
pylib=usr/lib/python3/dist-packages ; \
abitag=.$$($$v -c "import sysconfig; 
print(sysconfig.get_config_var('SOABI'))"); \

Bug#938478: shortuuid: diff for NMU version 0.5.0-1.1

[Sandro Tosi]

Control: tags 938478 + patch


Dear maintainer,

I've prepared an NMU for shortuuid (versioned as 0.5.0-1.1). The diff
is attached to this message.

Consider maintaining this package with the DPMT

Regards.

diff -Nru shortuuid-0.5.0/debian/changelog shortuuid-0.5.0/debian/changelog
--- shortuuid-0.5.0/debian/changelog	2017-09-16 04:22:09.0 -0400
+++ shortuuid-0.5.0/debian/changelog	2020-01-24 00:05:18.0 -0500
@@ -1,3 +1,10 @@
+shortuuid (0.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938478
+
+ -- Sandro Tosi   Fri, 24 Jan 2020 00:05:18 -0500
+
 shortuuid (0.5.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru shortuuid-0.5.0/debian/control shortuuid-0.5.0/debian/control
--- shortuuid-0.5.0/debian/control	2017-09-16 04:22:01.0 -0400
+++ shortuuid-0.5.0/debian/control	2020-01-24 00:01:34.0 -0500
@@ -4,29 +4,13 @@
 Maintainer: Kouhei Maeda 
 Build-Depends: debhelper (>= 8.0.0),
dh-python,
-   python-all (>= 2.6),
-   python-setuptools,
-   python-pep8,
python3-all (>= 3.2),
python3-setuptools,
python3-pep8,
quilt
 Standards-Version: 4.0.0
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
 Homepage: https://github.com/stochastic-technologies/shortuuid/
 
-Package: python-shortuuid
-Architecture: all
-Provides: ${python:Provides}
-Depends: ${python:Depends}, ${misc:Depends}
-Description: generates concise, unambiguous, URL-safe UUIDs
- Often, one needs to use non-sequential IDs in places where users will see them,
- but the IDs must be as concise and easy to use as possible. shortuuid solves
- this problem by generating uuids using Python's built-in uuid module and then
- translating them to base57 using lowercase and uppercase letters and digits,
- and removing similar-looking characters such as l, 1, I, O and 0.
-
 Package: python3-shortuuid
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru shortuuid-0.5.0/debian/rules shortuuid-0.5.0/debian/rules
--- shortuuid-0.5.0/debian/rules	2017-09-16 04:07:56.0 -0400
+++ shortuuid-0.5.0/debian/rules	2020-01-24 00:00:31.0 -0500
@@ -1,35 +1,7 @@
 #!/usr/bin/make -f
-# -*- makefile -*-
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
 
 %:
-	dh $@ --with python2,python3
-
-override_dh_auto_build:
-	set -e ; \
-	for py in 2.7 $(shell py3versions -vr); do \
-		python$$py setup.py build --build-base=build$$py; \
-	done
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
-	set -e ; \
-	python2.7 build2.7/lib.*-2.7/shortuuid/tests.py
-	for py in $(shell py3versions -vr); do \
-		python$$py build$$py/lib/shortuuid/tests.py; \
-	done
-
-override_dh_auto_install:
-	python setup.py install --no-compile -O0 --install-layout=deb \
-		--root $(CURDIR)/debian/python-shortuuid && \
-	python3 setup.py install --no-compile -O0 --install-layout=deb \
-		--root $(CURDIR)/debian/python3-shortuuid
-
-override_dh_auto_clean:
-	dh_clean
-	for py in 2.7 $(shell py3versions -vr); do \
-		python$$py setup.py clean --build-temp=build && \
-		python$$py setup.py clean --build-temp=build$$py; \
-	done
-	find $(CURDIR) -name "*.pyc" -delete
-
+PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS='{interpreter} {build_dir}/shortuuid/tests.py' dh_auto_test
diff -Nru shortuuid-0.5.0/debian/uscan.log shortuuid-0.5.0/debian/uscan.log
--- shortuuid-0.5.0/debian/uscan.log	2016-02-13 00:43:44.0 -0500
+++ shortuuid-0.5.0/debian/uscan.log	1969-12-31 19:00:00.0 -0500
@@ -1,4 +0,0 @@
-# uscan log
-# == shortuuid-0.4.3.tar.gz	-->	shortuuid_0.4.3.orig.tar.gz	(same)
-4f70db8174c0b7b8cad36de48b529947  shortuuid-0.4.3.tar.gz
-4f70db8174c0b7b8cad36de48b529947  shortuuid_0.4.3.orig.tar.gz

Bug#949205: please close this report

[neo]

Hello,
Assuming this email reaches you - everything works as expected now, feel free 
to close this bug report

With best regards

Bug#872788: heimdall-flash: package appears to be a salvaging candidate

[Nicholas D Steeves]

Hi Moritz,

Moritz Mühlenhoff  writes:

> On Tue, Dec 03, 2019 at 10:53:54PM +0100, Moritz Mühlenhoff wrote:
>> 
>> I suggest that you go ahead with the salvaging, we're closing in on
>> the Qt4 removal and we'll ask for removal of the remaining rdeps in
>> about two months.
>
> Status update: Qt4 has now been droppped from testing, qt4 will be removed
> from unstable by end of February (along with the remaining rdeps (currently 
> 15)).
>
> Nicholas, since you're a DM; if you need a sponsor for the initial upload
> after adopting it, feel free to ping me.

Yes, thank you, I would appreciate your review and sponsorship!  This
package is ready for an initial review.  I have created a temporary repo
here: https://salsa.debian.org/sten-guest/heimdall-flash
and hope you will also be willing to create the project under debian
namespace (the new collab-maint).  Please don't create it before the
package is ready for sponsorship though, because I haven't yet finalised
the git repo format (see below for why).

Here is the lint I believe may be a priority for this upload:

W: heimdall-flash: appstream-metadata-missing-modalias-provide 
lib/udev/rules.d/60-heimdall-flash.rules
W: heimdall-flash: appstream-metadata-missing-modalias-provide 
lib/udev/rules.d/60-heimdall-flash.rules match rule  usb:v04E8p6601d*
W: heimdall-flash: appstream-metadata-missing-modalias-provide 
lib/udev/rules.d/60-heimdall-flash.rules match rule usb:v04E8p685Dd*
W: heimdall-flash: appstream-metadata-missing-modalias-provide 
lib/udev/rules.d/60-heimdall-flash.rules match rule usb:v04E8p68C3d*

1. I'm not sure what the correct approach is here, because we
   shouldn't suggest that a new user install a custom firmware to
   their device, just because they plugged it in.  eg: a user who
   plugs in their phone or tablet to copy photos off of it shouldn't
   be presented (due to appstream) with software to replace their
   devices' OS!
2. I believe that many more devices are supported than this, and a
   list of USB manufacturer:product IDs feel like something that
   should be maintained upstream and not specifically in Debian.
   Moving forward, I suspect that a wiki page somewhere would be
   useful for collecting success/failure reports from users for a
   wider range of devices.

W: heimdall-flash: manpage-has-bad-whatis-entry usr/share/man/man1/heimdall.1.gz

I attempted to fix this with more comprehensive txt2man arguments,
and concede that there are (arguably jarring) cosmetic issues with
the resulting man page.  I plan to work with upstream to provide the
README in a format suitable for conversion to groff (eg: RST), so
that one file can act as both README and man page source.  OTTO
upstream, I'm planning to also expand my CMake knowledge enough to
fix the deficiencies in the existing CMakeLists.txt; Lisandro
pointed me in the right direction for this :-)

W: heimdall-flash source: source-contains-prebuilt-windows-binary 
Win32/Drivers/zadig.exe

I haven't decided whether to go with a custom merge driver, gbp +
d/copyright "Excluded-Files" + uscan, or something else.  Please let
me know what you'd prefer!

I: heimdall-flash: hardening-no-bindnow usr/bin/heimdall
I: heimdall-flash-frontend: hardening-no-bindnow usr/bin/heimdall-frontend

In this case, I erred on the side of caution and left the
"DEB_CFLAGS_MAINT_APPEND" added by Steve Langasek intact.  I'd
prefer to defer these changes to the next upload.


Thank you for periodically asking me to check in, I appreciate the
reminders and they motivate me to get the work done, and to do it well
:-)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#949720: Please port to enchant-2

[Laurent Bigonville]

Source: sylpheed
Version: 3.7.0-5
Severity: important
Control: block 947979 by -1

Hi,

I just uploaded gtkspell to debian unstable to port (trivial patch) it to use 
enchant-2 instead of enchant

AFAICS, sylpheed links against both gtkspell and enchant(1), that means
that with my upload, sylpheed will transitively link against enchant(1)
and enchant-2

Could you please port sylpheed to use enchant-2 in debian?

Kind regards,

Laurent Bigonville

-- System Information:
Debian Release: bullseye/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 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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

Bug#948490: gcc-9: -std=c11 prevents the use of decimal FP

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410

On 2020-01-23 14:04:59 +0100, Matthias Klose wrote:
> please could you recheck with trunk,

This is still OK with the trunk (e9ee848dcdc).

> and report that upstream?

Done.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#949384: sendmail: milter expansion of "$b" macro is unreliable

[Andreas Beckmann]

Control: tag -1 upstream
Control: found -1 8.15.2-8

Hi Bjørn,

interesting problem.

On Mon, 20 Jan 2020 14:26:27 +0100 =?utf-8?Q?Bj=C3=B8rn_Mork?=
 wrote:
> The bug is that sendmail returns sendmail process start time instead of
> current time when milters request the "$b" macro ("The current date in
> RFC822 format").  This happens often, but not on every milter excution.
> Sometimes the correct current time is returned. I do not know the exact
> trigger...

>From your timestamps it looks a bit like the first one of some "batch"
gets the correct time, but any subsequent ones the wrong one. A "batch"
could be multiple recipients in a message or multiple messages received
in a single smtp connection. The wallclock timestamps are quite tight
within such a "batch": e.g. 13:51:02-13:52:28, 14:06:49-14:08:03
Your mail logfiles might reveal more of the nature of these batches (but
you probably should not post them publically!)

You could try your luck upstream at
sendmail-bugs-2...@support.sendmail.org
I hope that these addresses still work after sendmail changing ownership.
Please keep this bug in Cc:

Andreas

Bug#913149: gtkspell: diff for NMU version 2.0.16-1.3

[Laurent Bigonville]

Dear maintainer,

I've prepared an NMU for gtkspell (versioned as 2.0.16-1.3). The diff
is attached to this message.

Regards.

diff -Nru gtkspell-2.0.16/debian/changelog gtkspell-2.0.16/debian/changelog
--- gtkspell-2.0.16/debian/changelog2018-01-26 10:54:50.0 +0100
+++ gtkspell-2.0.16/debian/changelog2020-01-24 03:17:20.0 +0100
@@ -1,3 +1,17 @@
+gtkspell (2.0.16-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  [ Laurent Bigonville ]
+  * debian/patches/enchant-2.patch: Switch to enchant version 2, replace
+deprecated enchant_dict_add_to_pwl() function by enchant_dict_add()
+  * debian/control: Bump Standards-Version to 4.5.0 (no further changes)
+
+  [ Helmut Grohne ]
+  * Drop unused Build-Depends: libxml-parser-perl as gtkspell no longer
+embeds intltool. (Closes: #913149)
+
+ -- Laurent Bigonville   Fri, 24 Jan 2020 03:17:20 +0100
+
 gtkspell (2.0.16-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gtkspell-2.0.16/debian/control gtkspell-2.0.16/debian/control
--- gtkspell-2.0.16/debian/control  2018-01-26 10:37:06.0 +0100
+++ gtkspell-2.0.16/debian/control  2020-01-24 02:52:40.0 +0100
@@ -2,8 +2,8 @@
 Section: libs
 Priority: optional
 Maintainer: Ari Pollak 
-Build-Depends: debhelper (>= 11), libenchant-dev, libgtk2.0-dev (>= 2.4.0), 
libltdl3-dev, libxml-parser-perl, intltool (>= 0.35.0), gtk-doc-tools
-Standards-Version: 4.1.3
+Build-Depends: debhelper (>= 11), libenchant-2-dev, libgtk2.0-dev (>= 2.4.0), 
libltdl3-dev, intltool (>= 0.35.0), gtk-doc-tools
+Standards-Version: 4.5.0
 
 Package: libgtkspell0
 Architecture: any
@@ -17,7 +17,7 @@
 Package: libgtkspell-dev
 Section: libdevel
 Architecture: any
-Depends: libenchant-dev, libgtk2.0-dev, libgtkspell0 (= ${binary:Version}),
+Depends: libenchant-2-dev, libgtk2.0-dev, libgtkspell0 (= ${binary:Version}),
  ${misc:Depends}
 Description: Development files for GtkSpell
  This package contains the headers and static libraries for developing
diff -Nru gtkspell-2.0.16/debian/patches/enchant-2.patch 
gtkspell-2.0.16/debian/patches/enchant-2.patch
--- gtkspell-2.0.16/debian/patches/enchant-2.patch  1970-01-01 
01:00:00.0 +0100
+++ gtkspell-2.0.16/debian/patches/enchant-2.patch  2020-01-24 
02:47:39.0 +0100
@@ -0,0 +1,32 @@
+Description: Port to enchant-2
+Author: Laurent Bigonville 
+Forwarded: no
+
+--- a/configure.ac
 b/configure.ac
+@@ -12,12 +12,12 @@ AC_CONFIG_SRCDIR(gtkspell/gtkspell.c)
+ AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION)
+ AC_CONFIG_HEADERS([config.h])
+ 
+-SPELLER_LIB=-lenchant
++SPELLER_LIB=-lenchant-2
+   
+ AC_SUBST(SPELLER_LIB)
+ GTKSPELL_PACKAGES=gtk+-2.0
+ AC_SUBST(GTKSPELL_PACKAGES)
+-PKG_CHECK_MODULES(GTKSPELL, $GTKSPELL_PACKAGES enchant >= 0.4.0 )
++PKG_CHECK_MODULES(GTKSPELL, $GTKSPELL_PACKAGES enchant-2 >= 2.2.0 )
+ AC_SUBST(GTKSPELL_CFLAGS)
+ AC_SUBST(GTKSPELL_LIBS)
+ 
+--- a/gtkspell/gtkspell.c
 b/gtkspell/gtkspell.c
+@@ -277,7 +277,7 @@ add_to_dictionary(GtkWidget *menuitem, G
+   get_word_extents_from_mark(spell->buffer, &start, &end, 
spell->mark_click);
+   word = gtk_text_buffer_get_text(spell->buffer, &start, &end, FALSE);
+   
+-  enchant_dict_add_to_pwl( spell->speller, word, strlen(word));
++  enchant_dict_add( spell->speller, word, strlen(word));
+ 
+   gtkspell_recheck_all(spell);
+ 
diff -Nru gtkspell-2.0.16/debian/patches/series 
gtkspell-2.0.16/debian/patches/series
--- gtkspell-2.0.16/debian/patches/series   2018-01-26 10:37:25.0 
+0100
+++ gtkspell-2.0.16/debian/patches/series   2020-01-24 02:19:00.0 
+0100
@@ -1 +1,2 @@
 01_update_gtkdoc.patch
+enchant-2.patch

Bug#937969: python-omemo-backend-signal: diff for NMU version 0.2.3-1.1

[Sandro Tosi]

Control: tags 937969 + patch


Dear maintainer,

I've prepared an NMU for python-omemo-backend-signal (versioned as 0.2.3-1.1). 
The diff
is attached to this message.

Regards.

diff -Nru python-omemo-backend-signal-0.2.3/debian/changelog python-omemo-backend-signal-0.2.3/debian/changelog
--- python-omemo-backend-signal-0.2.3/debian/changelog	2019-01-16 12:27:58.0 -0500
+++ python-omemo-backend-signal-0.2.3/debian/changelog	2020-01-23 21:04:01.0 -0500
@@ -1,3 +1,10 @@
+python-omemo-backend-signal (0.2.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937969
+
+ -- Sandro Tosi   Thu, 23 Jan 2020 21:04:01 -0500
+
 python-omemo-backend-signal (0.2.3-1) unstable; urgency=medium
 
   * Initial package (Closes: #919367)
diff -Nru python-omemo-backend-signal-0.2.3/debian/control python-omemo-backend-signal-0.2.3/debian/control
--- python-omemo-backend-signal-0.2.3/debian/control	2019-01-16 12:27:58.0 -0500
+++ python-omemo-backend-signal-0.2.3/debian/control	2020-01-23 21:03:47.0 -0500
@@ -6,13 +6,6 @@
 Build-Depends: debhelper (>= 11),
 	dh-python,
 	protobuf-compiler,
-	python-all,
-	python-cryptography,
-	python-doubleratchet,
-	python-omemo,
-	python-protobuf,
-	python-setuptools,
-	python-x3dh,
 	python3-all,
 	python3-cryptography,
 	python3-doubleratchet,
@@ -26,17 +19,6 @@
 Vcs-Git: https://salsa.debian.org/xmpp-team/python-omemo-backend-signal.git
 Vcs-Browser: https://salsa.debian.org/xmpp-team/python-omemo-backend-signal
 
-Package: python-omemo-backend-signal
-Architecture: all
-Depends: ${misc:Depends},
-	${python:Depends},
-Description: Python 2 backend for python-omemo with libsignal compatibility
- This library implements a backend for python-omemo offering
- compatibility with libsignal (C, Java, JavaScript). Look at
- python-omemo for further usage information.
- .
- This package provides the Python 2.7 module.
-
 Package: python3-omemo-backend-signal
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru python-omemo-backend-signal-0.2.3/debian/rules python-omemo-backend-signal-0.2.3/debian/rules
--- python-omemo-backend-signal-0.2.3/debian/rules	2019-01-16 10:52:19.0 -0500
+++ python-omemo-backend-signal-0.2.3/debian/rules	2020-01-23 21:03:57.0 -0500
@@ -3,7 +3,7 @@
 export PYBUILD_NAME=omemo_backend_signal
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_build:
 	cd omemo_backend_signal && $(MAKE)

Bug#949692: ITP: tpot -- Automated Machine Learning built on top of scikit-learn

[Mo Zhou]

Hi Christian,

Thank you for working on this. AutoML is indeed a significant trend in
the industry, and I think packaging AutoML toolkit is valuable for
Debian.

On Thu, Jan 23, 2020 at 06:50:51PM +0100, Christian Kastner wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Christian Kastner 
> 
> * Package name: TPOT
>   Version : 0.11.1
>   Upstream Author : Epistasis Lab, Inst.for Biomedical Informatics, UPenn
> * URL : https://epistasislab.github.io/
> * License : GPL-3+
>   Programming Lang: Python
>   Description : Automated Machine Learning built on top of scikit-learn
> 
> Consider TPOT your Data Science Assistant. TPOT is a Python Automated
> Machine Learning tool that optimizes machine learning pipelines using
> genetic programming.
> 
> TPOT will automate the most tedious part of machine learning by
> intelligently exploring thousands of possible pipelines to find the best
> one for your data.
> 
> Once TPOT is finished searching (or you get tired of waiting), it
> provides you with the Python code for the best pipeline it found so you
> can tinker with the pipeline from there.
> 
> TPOT is built on top of scikit-learn, so all of the code it generates
> should look familiar... if you're familiar with scikit-learn, anyway.
> 
> 
> I intend to maintain this within the Debian Science Team.
> 

Bug#944092: I'm in

[kts]

Where do I patch?  

Bug#949719: ntopng missing startup depenency on redis-server in systemd

[Dave Johnson]

Package: ntopng
Version: 3.8+dfsg1-2.1

There is a system boot race between ntopng and redis-server because
ntopng doesn't have the dependency in the systemd config (it is
present in init.d but not systemd)


root@ganges:~# systemctl status ntopng
...
Jan 23 19:25:02 ganges ntopng[7891]: 23/Jan/2020 19:25:02 [Redis.cpp:111] 
ERROR: ntopng requires redis server to be up and running
Jan 23 19:25:02 ganges ntopng[7891]: 23/Jan/2020 19:25:02 [Redis.cpp:112] 
ERROR: Please start it and try again or use -r
Jan 23 19:25:02 ganges ntopng[7891]: 23/Jan/2020 19:25:02 [Redis.cpp:113] 
ERROR: to specify a redis server other than the default

root@ganges:~# systemctl status redis-server
...
Jan 23 19:25:03 ganges systemd[1]: Started Advanced key-value store.


Note ntopng was started prior to redis-server on server boot.


root@ganges:~# grep redis /etc/init.d/ntopng 
# Required-Start:$remote_fs $syslog redis-server
# Required-Stop: $remote_fs $syslog redis-server
root@ganges:~# grep redis 
/etc/systemd/system/multi-user.target.wants/ntopng.service
root@ganges:~# 

An 'After=redis-server.service' would seem approprate in ntopng.service



-- 
Dave

Bug#944092: Context

[kts]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948144

Bug#949716: qa.debian.org: DDPO doesn't show packages with version 0

[James Clarke]

On Thu, Jan 23, 2020 at 11:58:14PM +0100, Adam Borowski wrote:
> Package: qa.debian.org
> Severity: normal
>
> Hi!
> If you have a package with version "0" (a valid version number) -- like
> "fonts-recommended" at the moment, DDPO won't show it.  On the other hand,
> a non-native package versioned "0-1" does show up.
>
> This suggests a type confusion bug, like something equalling string "0" to
> NULL.

Heh. From staring at the code for a little, my guess is that it is the
following snippet in wml/developer.wml's print_package_entry at fault:

> /* don't display this package if it doesn't have any version or wnpp info */
> if (empty(array_filter($version)) and empty($wnpp_info)) return "";

The documentation for array_filter[1] says:

> If no callback is supplied, all entries of array equal to FALSE (see 
> converting to boolean) will be removed.

and if you follow the reference to the implicit boolean conversions
documentation[2], it indeed has the following:

> When converting to boolean, the following values are considered FALSE:
>   ...
>   * the empty string, and the string "0"

(because Javascript isn't the only language with "helpful" design
decisions)

So, I think you have to have *every* version in the archive as "0";
later checks in that function explicitly compare against "".

It's worth noting that there's also

> $pack_array = array_filter(explode(" ", $packages));

in the caller (print_package_entries), so if a src:0 were ever uploaded
to the archive it would feel left out of all the DDPO fun, although such
a source package name would surely be rejected...

As for the fix, you can (ab)use strlen as the callback (though of
*course* you have to pass the function name as a string...), so:

> if (empty(array_filter($version, 'strlen')) and empty($wnpp_info)) return "";

and

> $pack_array = array_filter(explode(" ", $packages), 'strlen');

I use the word "fix" loosely here though, I've only convinced myself
it's correct; it has not seen an interpreter, let alone been tested on
this input!

James

[1] 
https://www.php.net/manual/en/function.array-filter.php#refsect1-function.array-filter-parameters
[2] 
https://www.php.net/manual/en/language.types.boolean.php#language.types.boolean.casting

Bug#940461: imap-dl: maybe we should use Mail::Box ?

[Sean Whitton]

Hello,

On Thu 23 Jan 2020 at 06:15PM -05, Daniel Kahn Gillmor wrote:

> I'm also not convinced that the above code enforces tls, checks
> certificates, etc.
>
> Also, have you compared the speed of the above code against the current
> python implementation when fetching an off-site mailbox with some
> noticeable latency and a decent-sized spool?
>
> I found that imap-dl is several orders of magnitude faster than getmail,
> because it avoids additional roundtrips based on its deliberate use of
> the IMAP protocol.  I don't know whether that's the case for Mail::Box
> (i haven't tested!) but i would be pretty sad to go back to waiting
> dozens of seconds to fetch hundreds of messages that could be fetched
> instead in a couple seconds.

Thank you for the feedback -- just thought I'd share my research.

Let's continue to work on your imap-dl.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd

[Samuel Thibault]

Hello,

On 20.11.19 11:43, Fabian Kloetzl wrote:
> Recently, the build of one of my packages failed on hurd-i386 and
> kfreebsd-* due to unsupported ifuncs [1]. However, I had that code guarded
> by __has_attribute(ifunc) which, unfortunately, evaluates to 1 on said
> platforms. A minimal testcase is attached.

AIUI, that is expected by gcc people: the gcc documentation says:

“to test whether the attribute referenced by its operand is recognized
by GCC”

Strictly speaking, being recognized by GCC doesn't mean being supported
on the target platform. I agree that it makes it not really useful
here, but I'm not the one to be convinced :) I'd say bring the issue to
upstream gcc.

Samuel

Bug#898246: git-lab requires golang-github-xanzy-go-gitlab

[Felix Lechner]

Hi,

On Sun, Dec 15, 2019 at 7:46 AM Dominique Dumont  wrote:
>
> Felix, could you resume packaging this software ?

Do you know anyone with upload privileges? :) Please feel free to
upload the required prerequisite

golang-github-xanzy-go-gitlab

in #947304. My RFS had no takers for a month. I will package git-lab
for you afterwards.

Kind regards
Felix

Bug#949718: netifaces: missing pristine-tar branch

[Sandro Tosi]

Source: netifaces
Severity: important

Hello,
the DPMT policy[1], which everyone in the team should read and accept, states:

  DPMT requires a pristine-tar branch, and only upstream tarballs can be used
  to advance the upstream branch.

[1] 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#id3

but netifaces git repo is missing this branch.

please fix at the earliest.

-- System Information:
Debian Release: 10.0
  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-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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

Bug#949717: Please update Speex and SpeexDSP to latest upstream version 1.2.0

[Amr Ibrahim]

Package: speex

Please update Speex and SpeexDSP to latest upstream version 1.2.0.

https://git.xiph.org/?p=speex.git;a=summary

https://git.xiph.org/?p=speexdsp.git;a=summary

Bug#949715: lintian: add check that ${python3:Versions} should not be used in Depends

[Chris Lamb]

affects 949715 + dh-python
thanks

Hi Daniel,

I guess this just goes to show the "power" of warnings; something the
Lintian maintainers should always keep in mind. :)

> It turns out i actually have no idea where the ${python3:Versions}
> substvar *should* be used in debian/control, but it should certainly
> never be used in Depends:.

Full ACK. Can you think of any other "illegal" items that should never
be in Depends/Recommends/Suggests? Might as well add them all at the
same time with a general tag.

> Contro: affects -1 dh-python
   ^^^

(Am fixing this bit in BCC, just FYI...)


Regards,

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

Bug#940461: imap-dl: maybe we should use Mail::Box ?

[Daniel Kahn Gillmor]

On Thu 2020-01-23 12:51:47 -0700, Sean Whitton wrote:

> I just discovered that it is possible to implement imap-dl using the
> Mail::Box suite.  This would mean we would not need to include any code
> parsing and emitting the IMAP protocol in mailscripts.  That seems
> strongly preferable.  Let me know what you think.
>
> Here is what the fetch code becomes:
>
> #!/usr/bin/perl
>
> use 5.028;
> use strict;
> use warnings;
>
> use Mail::Box::Manager;
>
> my $mgr = Mail::Box::Manager->new;
> my $imap_folder = $mgr->open('imap://user:passwd@host:port/INBOX');
> my $maildir = $mgr->open(
> '/home/spwhitton/Maildir',
> access=> 'a',
> create=> 1,
> keep_dups => 1,
> type  => 'maildir'
> );
> $mgr->moveMessage($maildir, $_) for $imap_folder->messages();
> $mgr->closeAllFolders();
>
> We could even keep all dkg's existing code for parsing getmail configs,
> etc., and use Mail::Box only to do the actual fetch and insert.

If you want to do this in perl, you're welcome to.  I won't be able to
help much in maintaining it, though, as my perl is super weak, and i
have to thrash around a lot just to test things and make sure that
they're doing what i expect them to do.

In contrast, i find python to be cleaner and simpler to understand an to
annotate.

I'm also not convinced that the above code enforces tls, checks
certificates, etc.

Also, have you compared the speed of the above code against the current
python implementation when fetching an off-site mailbox with some
noticeable latency and a decent-sized spool?

I found that imap-dl is several orders of magnitude faster than getmail,
because it avoids additional roundtrips based on its deliberate use of
the IMAP protocol.  I don't know whether that's the case for Mail::Box
(i haven't tested!) but i would be pretty sad to go back to waiting
dozens of seconds to fetch hundreds of messages that could be fetched
instead in a couple seconds.

--dkg


signature.asc
Description: PGP signature

Bug#949716: qa.debian.org: DDPO doesn't show packages with version 0

[Adam Borowski]

Package: qa.debian.org
Severity: normal

Hi!
If you have a package with version "0" (a valid version number) -- like
"fonts-recommended" at the moment, DDPO won't show it.  On the other hand,
a non-native package versioned "0-1" does show up.

This suggests a type confusion bug, like something equalling string "0" to
NULL.


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

Kernel: Linux 5.5.0-rc7-00053-gc71e02c982e3 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#949715: lintian: add check that ${python3:Versions} should not be used in Depends

[Daniel Kahn Gillmor]

Package: lintian
Severity: wishlist
Contro: affects -1 dh-python

When trying to build gpgme1.0 version 1.13.1-2, i encountered the
following warning from dpkg-gencontrol:

dpkg-gencontrol: warning: package python3-gpg: substitution variable 
${python3:Versions} unused, but is defined

Thinking i knew what i was doing, i added ${python3:Versions} to the
Depends: line of python3-gpg in debian/control.

This resulted in python3-gpg version 1.13.1-2 having a dependency on
packages named "3.7" and "3.8" (you can see my brown paper bag bug in
the archive, sigh).

It turns out i actually have no idea where the ${python3:Versions}
substvar *should* be used in debian/control, but it should certainly
never be used in Depends:.

It would be great if lintian could catch this kind of embarassing
mistake during the build just by inspecting the source.

I'm assuming that this substvar came from dh_python3 from the dh-python
package, so i'm marking this bug as affecting dh-python.

--dkg


signature.asc
Description: PGP signature

Bug#949714: RM: twitter-bootstrap -- RoQA; Obsoleted by twitter-bootstrap3

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove twitter-bootstrap. It was replaced by twitter-bootstrap3 and
all reverse deps have been migrated or removed.

Cheers,
 Moritz

Bug#949713: rsyslog: file write error: Input/output error with imuxsock module

[Adam Lewenberg]

Package: rsyslog
Version: 8.1901.0-1
Severity: important

Dear Maintainer,

(Note: most of the content of this report is also here:
https://github.com/rsyslog/rsyslog/issues/4126)

When using the imuxsock module we see these errors:

Jan 15 11:35:27 radius02.example.com systemd[1]: Starting System Logging
Service...
Jan 15 11:35:27 radius02.example.com rsyslogd[359]: imuxsock: Acquired
UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd.
[v8.1901.0]
Jan 15 11:35:27 radius02.example.com systemd[1]: Started System Logging
Service.
Jan 15 11:35:27 radius02.example.com rsyslogd[359]:  [origin
software="rsyslogd" swVersion="8.1901.0" x-pid="359"
x-info="https://www.rsyslog.com";] start
Jan 15 11:35:27 radius02.example.com rsyslogd[359]: file '9' write
error: Input/output error [v8.1901.0 try https://www.rsyslog.com/e/2027
]
Jan 15 11:35:27 radius02.example.com rsyslogd[359]: file '9' write
error: Input/output error [v8.1901.0 try https://www.rsyslog.com/e/2027
]
Jan 15 11:35:27 radius02.example.com rsyslogd[359]: file '9' write
error: Input/output error [v8.1901.0 try https://www.rsyslog.com/e/2027
]
...forever...

If we stop and start the service the error usually goes away. But if we
reboot the server the error returns.

Looking at the unix sockets, on a server where rsyslog is working
properly I see these file descriptors owned by the rsyslogd process:

lr-x-- 1 root root 64 Jan 15 11:35 0 -> /dev/null
l-wx-- 1 root root 64 Jan 15 11:35 1 -> /dev/null
l-wx-- 1 root root 64 Jan 15 11:35 2 -> /dev/null
lrwx-- 1 root root 64 Jan 15 11:35 3 -> 'socket:[10211]'
(/run/systemd/journal/syslog)
lr-x-- 1 root root 64 Jan 15 11:35 4 -> /dev/urandom
lrwx-- 1 root root 64 Jan 15 11:35 5 -> 'socket:[14849]'
(/var/spool/postfix/dev/log)
lr-x-- 1 root root 64 Jan 15 11:35 6 -> /proc/kmsg
l-wx-- 1 root root 64 Jan 15 11:35 7 -> /dev/console
l-wx-- 1 root root 64 Jan 15 11:35 8 -> /var/log/messages
lrwx-- 1 root root 64 Jan 15 11:35 9 -> 'socket:[30511]'

On a server where rsyslog is not working I see the same set except the
file descriptor corresponding to the number in the error message (in the
example above this is '9') is missing and the last socket (the one not
pointing at a file) keeps getting re-generated.

Here is the main configuration file:

# /etc/rsyslog.conf
$ModLoad imuxsock
$ModLoad imklog
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$FileOwner root
$FileGroup root
$WorkDirectory /var/spool/rsyslog
$FileCreateMode 0640
$DirCreateMode 0755
$SystemLogRateLimitInterval 0
$IncludeConfig /etc/rsyslog.d/*.conf



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libestr0 0.1.10-2.1
ii  libfastjson4 0.99.8-2
ii  liblognorm5  2.0.5-1
ii  libsystemd0  241-7~deb10u2
ii  libuuid1 2.33.1-0.1
ii  lsb-base 10.2019051400
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.14.0-4

Versions of packages rsyslog suggests:
pn  rsyslog-doc
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- Configuration Files:
/etc/rsyslog.conf changed [not included]

-- no debconf information

Bug#949398: marked as pending in lintian

[Felix Lechner]

Hi Chris,

On Thu, Jan 23, 2020 at 2:20 PM Chris Lamb  wrote:
>
> I plan to release Lintian tomorrow (ie. Friday 24th Jan) or
> more accurately when the current version in unstable migrates to
> testing.

Please note that the next release will probably not migrate until
#949066 is fixed. I am working on it with the dpkg maintainers.

Kind regards
Felix Lechner

Bug#949712: please provide an udeb to be used by rsync-udeb

[Samuel Henrique]

Package: libacl1
Version: 2.2.53-5
Severity: wishlist

Hello Maintainer, as per requested in #729069 (rsync package)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729069

I would like to provide an udeb for rsync, It seems that the only thing
missing is to have libacl1-udeb available.

Could you please provide an udeb for the package?

Thanks

--
Samuel Henrique 

Bug#947027: linphone does not block sgmltools-lite removal

[Moritz Mühlenhoff]

On Fri, Dec 20, 2019 at 05:38:25PM +, Dimitri John Ledkov wrote:
> unblock 938473 by 943162
> unblock 947027 by 943162
> thanks
> 
> linphone used to have an unused build-dependency on sgmltools-lite.
> 
> Which has now been dropped. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947065
> 
> Thus, sgmltools-lite can be removed from unstable now.

Unfortunately not, it's still used by aboot (which is RC-buggy
and hasn't seen an upload since 2013), I just filed another
RC bug for it.

Cheers,
Moritz

Bug#949711: Build-depends on sgmltools-lite, which is being removed

[Moritz Muehlenhoff]

Source: aboot
Severity: serious

sgmltools-lite is scheduled for removal and aboot is the last package
build depending on it.

There hasn't been any aboot upload since 2013 and it's RC-buggy for a
long time, should we simply remove it?

Cheers,
Moritz

Bug#949398: marked as pending in lintian

[Niels Thykier]

Chris Lamb:
> Hi Felix,
> 
>> Please feel free to restart lintian.d.o. (I do not have access.) I
>> think it's been down for months.
>  
> Good thinking. :)
> 
> Just for a bit of background my preference is to keep lintian.d.o
> running a specific released version of Lintian, otherwise we make our
> bug reports ambiguous about what version they are using and thus cause
> more work for everyone.
> 
> However, I plan to release Lintian tomorrow (ie. Friday 24th Jan) or
> more accurately when the current version in unstable migrates to
> testing. I will assume that (another 24 hours delay would not be a
> problem for you both.
> 
> 
> Regards,
> 

Hi,

Personally, I am fine with the delay.

Though I can tell you it already migrated:

"""
$ dak ls lintian
lintian| 2.5.30+deb8u4  | oldoldstable  | source, all
lintian| 2.5.50.4   | oldstable | source, all
lintian| 2.15.0 | stable| source, all
lintian| 2.45.0~bpo9+1  | stretch-backports | source, all
lintian| 2.45.0~bpo10+1 | buster-backports  | source, all
lintian| 2.46.0 | testing   | source, all
lintian| 2.46.0 | unstable  | source, all
"""

It will probably be several hours until it will be published on the
mirrors and the migration mail will be sent.

Thanks,
~Niels

Bug#949398: marked as pending in lintian

[Niels Thykier]

Felix Lechner:
> Hi,
> 
> On Thu, Jan 23, 2020 at 1:57 PM Niels Thykier  wrote:
>>
>> Thanks for the quick response time and a fix. :)
> 
> Please feel free to restart lintian.d.o. (I do not have access.) I
> think it's been down for months.
> 

I do not have write access either any more.  We will need Chris or
another lintian maintainer to do that.

Technically, lintian.d.o should be running already, but this bug is/was
causing lintian to skip all the work making it appear as if lintian on
lintian.d.o was stopped.

> Also, please note that I fixed much of the blacklist (per #946320) but
> cannot adjust it.
> 
> Kind regards
> Felix
> 

Same issue here for me.  Perhaps it would make sense to move the live
config file under git and enable you to make changes to it via git /
merge requests.

Thanks,
~Niels

Bug#949710: /usr/bin/plasmashell: segfaults sporadically but only when using app dropdown menu

[Sarah Stoffels]

Package: plasma-workspace
Version: 4:5.14.5.1-1
Severity: normal

Sporadically, when using the app dropdown menu (to select one of several
windows of the same app), the dropdown menu is empty (and its width is
only narrow) and when selecting this with mouseover, plasmashell crashes
with segmentation fault. Attaching console output of such a crash.

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 plasma-workspace depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.16-1
ii  drkonqi  5.14.5-1
ii  frameworkintegration 5.54.0-1
ii  gdb-minimal [gdb]8.2.1-2+b3
ii  iso-codes4.2-1
ii  kactivitymanagerd5.14.5-1
ii  kded55.54.0-1
ii  kinit5.54.0-1
ii  kio  5.54.1-1
ii  kpackagetool55.54.0-1
ii  kwin-common  4:5.14.5-1
ii  libappstreamqt2  0.12.5-1
ii  libc62.28-10
ii  libcolorcorrect5 4:5.14.5.1-1
ii  libgcc1  1:8.3.0-6
ii  libgps23 3.17-7
ii  libice6  2:1.0.9-2
ii  libkf5activities55.54.0-1
ii  libkf5auth5  5.54.0-2
ii  libkf5baloo5 5.54.0-1
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarevents55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5config-bin 5.54.0-1+deb10u1
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5configgui5 5.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5declarative5   5.54.0-1
ii  libkf5globalaccel-bin5.54.0-1
ii  libkf5globalaccel5   5.54.0-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5holidays5  1:5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5idletime5  5.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5js55.54.0-1
ii  libkf5jsembed5   5.54.0-1
ii  libkf5kdelibs4support5   5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiogui55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5networkmanagerqt6  5.54.0-1
ii  libkf5newstuff5  5.54.0-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5package5   5.54.0-1
ii  libkf5plasma55.54.0-1
ii  libkf5plasmaquick5   5.54.0-1
ii  libkf5prison55.54.0-1+b2
ii  libkf5quickaddons5   5.54.0-1
ii  libkf5runner55.54.0-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5solid5 5.54.0-1
ii  libkf5texteditor55.54.0-1
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5waylandclient5 4:5.54.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libkscreenlocker55.14.5-1
ii  libksgrd74:5.14.5-1
ii  libkworkspace5-5 4:5.14.5.1-1
ii  libphonon4qt5-4  4:4.10.2-1
ii  libplasma-geolocation-interface5 4:5.14.5.1-1
ii  libprocesscore7  4:5.14.5-1
ii  libprocessui74:5.14.5-1
ii  libqalculate20   2.8.2-1
ii  libqt5core5a 5.11

Bug#949709: Consider linking against archive version of libstb

[Moritz Muehlenhoff]

Source: libsfml
Severity: important

libsfml contains extlibs/headers/stb_image/stb_image_write.h and
extlibs/headers/stb_image/stb_image.h

These are also available in src:libstb, so please consider switching to the 
in-archive copy.

Cheers,
Moritz

Bug#949398: marked as pending in lintian

[Chris Lamb]

Hi Felix,

> Please feel free to restart lintian.d.o. (I do not have access.) I
> think it's been down for months.
 
Good thinking. :)

Just for a bit of background my preference is to keep lintian.d.o
running a specific released version of Lintian, otherwise we make our
bug reports ambiguous about what version they are using and thus cause
more work for everyone.

However, I plan to release Lintian tomorrow (ie. Friday 24th Jan) or
more accurately when the current version in unstable migrates to
testing. I will assume that (another 24 hours delay would not be a
problem for you both.


Regards,

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

Bug#949695: thunderbird does not start anymore

[Sebastiaan Couwenberg]

On Thu, 23 Jan 2020 20:15:20 +0100 Birger Schacht wrote:
> I just had the same problem. For me, downgrading libsqlite3 to
> libsqlite3-0_3.30.1+fossil191229-1 made thunderbird start again.

Same for firefox, see: #949644

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#949708: Consider linking against archive version of libstb

[Moritz Muehlenhoff]

Package: retroarch
Severity: important

retroarch contains deps/stb/stb_rect_pack.h, deps/stb/stb_vorbis.h, 
deps/stb/stb_truetype.h,
and deps/stb/stb_image.h

These are also available in src:libstb, so please consider switching to the 
in-archive copy.

Cheers,
Moritz

Bug#949707: Consider linking against archive version of libstb

[Moritz Muehlenhoff]

Source: libsixel
Severity: important

libsixel contains src/stb_image.h and src/stb_image_write.h

These are also available in src:libstb, so please consider switching to the 
in-archive copy.

Cheers,
Moritz

Bug#949706: RM: gbirthday -- RoQA; Depends on pygtk, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gbirthday. It depends on pygtk, which is going away
and dead upstream.

Cheers,
Moritz

Bug#936585: gbirthday: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Sun, Dec 15, 2019 at 10:44:22PM +0100, Moritz Mühlenhoff wrote:
> On Tue, Oct 22, 2019 at 10:04:35PM +0200, Jérôme wrote:
> > Hi.
> > 
> > Last gbirthday maintainer speaking.
> > 
> > The gbirthday package is more or less dead upstream, unless someone
> > volunteers to take it over.
> 
> Hi Rolf,
> are you planning to port it yourself or switch to the mentioned
> qt port? Otherwise we should remove it from the archive.

I've filed a removal bug now.

Cheers,
Moritz

Bug#949398: marked as pending in lintian

[Felix Lechner]

Hi,

On Thu, Jan 23, 2020 at 1:57 PM Niels Thykier  wrote:
>
> Thanks for the quick response time and a fix. :)

Please feel free to restart lintian.d.o. (I do not have access.) I
think it's been down for months.

Also, please note that I fixed much of the blacklist (per #946320) but
cannot adjust it.

Kind regards
Felix

Bug#885505: bumping severity of pygtk bugs

[Moritz Mühlenhoff]

On Wed, Dec 11, 2019 at 09:52:15AM +0100, Thibaut Paumard wrote:
> Le 10/12/2019 à 19:59, Moritz Mühlenhoff a écrit :
> > On Mon, Oct 07, 2019 at 04:51:09PM +0200, Thibaut Paumard wrote:
> >> Dear Jeremy,
> >>
> >> Thanks, I have warned upstream that spydr will be removed if not updated
> >> to Python 3 and Gtk 3.
> > 
> > Was there any reaction? Otherwise let's go ahead with the removal from
> > the archive.
> > 
> > Cheers,
> > Moritz
> 
> Yes, upstream did say they would fix this. As this is a leaf package, I
> would propose to wait until after the vacation and remove it on, say,
> Jan. 15th. In the meantime I ill ping them and maybe they manage by then.
> 
> Else, I can always reintroduce it later.

Did you hear anything back? Shall we remove it?

Cheers,
Moritz

Bug#949398: marked as pending in lintian

[Niels Thykier]

Felix Lechner:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #949398 in lintian 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/lintian/lintian/commit/544acaf9d364fb8285b8e79d3d4dadb56d9ce1db
> 
> 
> Skip only empty lines when packages are specified in a file. (Closes: #949398)
> 
> All lines were skipped before the end-of-string marker was added.
> 
> 
> (this message was generated automatically)
> 

Thanks for the quick responds time and a fix. :)

Thanks,
~Niels

Bug#949705: libidn2: binary-arch target depends on makeinfo (but texinfo is in Build-Depends-Indep)

[Salvatore Bonaccorso]

Source: libidn2
Version: 2.2.0-2
Severity: serious
Justification: FTBFS
Control: found -1 2.0.5-1

Hi

The binary-arch target would depend on makeinfo, but texinfo is only
listed in Build-Depends-Indep. 

When there is need to patch libidn2 and builds are then done by
buildds this would cause FTBFS on every architecture. How to
reproduce:

Install only the Build-Depends as done on buildds.

touch lib/lookup.c and only build the arch:any binary packages
(dpkg-buildpackage -G or debian/rules build-arch). From the build log:

> [...]
> mkdir -p `dirname texi/lookup.c.texi`
> ../doc/gdoc -texinfo  ../lib/lookup.c > texi/lookup.c.texi
> mkdir -p `dirname texi/idn2_lookup_u8.texi`
> ../doc/gdoc -texinfo  -function idn2_lookup_u8 ../lib/lookup.c > 
> texi/idn2_lookup_u8.texi
> mkdir -p `dirname texi/idn2_lookup_ul.texi`
> ../doc/gdoc -texinfo  -function idn2_lookup_ul ../lib/lookup.c > 
> texi/idn2_lookup_ul.texi
> mkdir -p `dirname texi/idn2_to_ascii_4i.texi`
> ../doc/gdoc -texinfo  -function idn2_to_ascii_4i ../lib/lookup.c > 
> texi/idn2_to_ascii_4i.texi
> mkdir -p `dirname texi/idn2_to_ascii_4i2.texi`
> ../doc/gdoc -texinfo  -function idn2_to_ascii_4i2 ../lib/lookup.c > 
> texi/idn2_to_ascii_4i2.texi
> mkdir -p `dirname texi/idn2_to_ascii_4z.texi`
> ../doc/gdoc -texinfo  -function idn2_to_ascii_4z ../lib/lookup.c > 
> texi/idn2_to_ascii_4z.texi
> mkdir -p `dirname texi/idn2_to_ascii_8z.texi`
> ../doc/gdoc -texinfo  -function idn2_to_ascii_8z ../lib/lookup.c > 
> texi/idn2_to_ascii_8z.texi
> mkdir -p `dirname texi/idn2_to_ascii_lz.texi`
> ../doc/gdoc -texinfo  -function idn2_to_ascii_lz ../lib/lookup.c > 
> texi/idn2_to_ascii_lz.texi
> restore=: && backupdir=".am$$" && \
> am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
> rm -rf $backupdir && mkdir $backupdir && \
> if (/bin/bash /build/libidn2-2.2.0/build-aux/missing makeinfo --version) 
> >/dev/null 2>&1; then \
>   for f in libidn2.info libidn2.info-[0-9] libidn2.info-[0-9][0-9] 
> libidn2.i[0-9] libidn2.i[0-9][0-9]; do \
> if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
>   done; \
> else :; fi && \
> cd "$am__cwd"; \
> if /bin/bash /build/libidn2-2.2.0/build-aux/missing makeinfo   -I . \
>  -o libidn2.info libidn2.texi; \
> then \
>   rc=0; \
>   CDPATH="${ZSH_VERSION+.}:" && cd .; \
> else \
>   rc=$?; \
>   CDPATH="${ZSH_VERSION+.}:" && cd . && \
>   $restore $backupdir/* `echo "./libidn2.info" | sed 's|[^/]*$||'`; \
> fi; \
> rm -rf $backupdir; exit $rc
> /build/libidn2-2.2.0/build-aux/missing: line 81: makeinfo: command not found
> WARNING: 'makeinfo' is missing on your system.
>  You should only need it if you modified a '.texi' file, or
>  any other file indirectly affecting the aspect of the manual.
>  You might want to install the Texinfo package:
>  
>  The spurious makeinfo call might also be the consequence of
>  using a buggy 'make' (AIX, DU, IRIX), in which case you might
>  want to install GNU make:
>  
> make[6]: *** [Makefile:1173: libidn2.info] Error 127
> make[6]: Leaving directory '/build/libidn2-2.2.0/doc'
> make[5]: *** [Makefile:1426: all-recursive] Error 1
> make[5]: Leaving directory '/build/libidn2-2.2.0/doc'
> make[4]: *** [Makefile:1131: all] Error 2
> make[4]: Leaving directory '/build/libidn2-2.2.0/doc'
> make[3]: *** [Makefile:1098: all-recursive] Error 1
> make[3]: Leaving directory '/build/libidn2-2.2.0'
> make[2]: *** [Makefile:1007: all] Error 2
> make[2]: Leaving directory '/build/libidn2-2.2.0'
> dh_auto_build: error: make -j1 returned exit code 2
> make[1]: *** [debian/rules:34: override_dh_auto_build] Error 25
> make[1]: Leaving directory '/build/libidn2-2.2.0'
> make: *** [debian/rules:7: build-arch] Error 2

Regards,
Salvatore

Bug#949704: buster-pu: package opensmtpd/6.0.3p1-5

[Ryan Kavanagh]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

The proposed change fixes bug #948824, which rendered the package
uninstallable when `hostname --fqdn` exited with a non-zero exit code.
I've tested it locally and the bug reporter has also confirmed that the
patch fixes the bug. The bug was fixed by opensmtpd 6.6.1p1-5 (already
in unstable).

A debdiff is attached. Please let me know if I'm free to upload.

Thanks,
Ryan

-- System Information:
Debian Release: bullseye/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 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A
diff --git a/debian/changelog b/debian/changelog
index f40f3ef2..45834712 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+opensmtpd (6.0.3p1-5+deb10u2) buster; urgency=medium
+
+  * Handle non-zero exit code from hostname during config phase
+(Closes: #948824)
+
+ -- Ryan Kavanagh   Thu, 23 Jan 2020 16:36:09 -0500
+
 opensmtpd (6.0.3p1-5+deb10u1) buster; urgency=medium
 
   * Warn users of change of smtpd.conf syntax (Closes: #944268)
diff --git a/debian/config b/debian/config
index 96401633..455d9483 100644
--- a/debian/config
+++ b/debian/config
@@ -28,12 +28,10 @@ else
 else
 # Otherwise, default to our FQDN
 # /etc/mailname and opensmtpd/mailname are both empty
-# Default to the FQDN
-MAILNAME=`hostname --fqdn 2> /dev/null`
-# Something when wrong; resort to localdomain
-if [ $? -ne 0 ]; then
-MAILNAME="localdomain"
-fi
+# Default to the FQDN. hostname will exit with a non-zero
+# exit code if something goes wrong, in which case we resort
+# to the value localdomain.
+MAILNAME=`hostname --fqdn 2> /dev/null || echo "localdomain"`
 # Update our DB with this default for when we prompt the user
 db_set opensmtpd/mailname "${MAILNAME}"
 fi


signature.asc
Description: PGP signature

Bug#949703: thunderbird doesn' start on Sid

[Mauro Sacchetto]

Package: Thunderbird
Version: 1:68.4.1-1+b1

after the last today update, thunderbird doesn' start on Sid.
from console:
===
samiel@darkstar:~$ thunderbird
ExceptionHandler::GenerateDump cloned child 4951
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
===

ms

Bug#949702: buster-pu: package lemonldap-ng/2.0.2+ds-7+deb10u3

[Xavier Guimard]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

lemonldap-ng is vulnerable to several security issues. This cumulative
patch fixes them:
 - CVE-2019-19791: bad default configuration which does not really
   protect SOAP/REST endpoints
 - When 2FA is used, the grantSession plugin does not filter successful
   connections
 - OIDC relying party restriction introduced in 2.0.0 does not work when
   a previous federation was granted in the same session

Cheers,
Xavier
diff --git a/debian/NEWS b/debian/NEWS
index 454e18b..58fe7cf 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -1,3 +1,17 @@
+lemonldap-ng (2.0.2+ds-7+deb10u3) buster-security; urgency=high
+
+  This version fixes 3 security issues. However, you must verify 2 things:
+   * if you enabled SOAP/REST plugins, verify in your portal web configuration
+ file that they are well protected (see new default configuration files:
+ /etc/lemonldap-ng/portal-apache2.X.conf and
+ /etc/lemonldap-ng/portal-nginx.conf)
+   * if you enabled OpenID-Connect identity provider, your relaying parties
+ must have a redirection uri. You just have to save a new configuration
+ using the manager and automatic tests will fail if one relying party is
+ misconfigured
+
+ -- Xavier Guimard   Fri, 20 Dec 2019 18:12:54 +0100
+
 lemonldap-ng (2.0.0+ds-1) unstable; urgency=medium
 
   2.0 is a major release, many things have been changed. You must read
diff --git a/debian/changelog b/debian/changelog
index 0c99af8..e30c7ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+lemonldap-ng (2.0.2+ds-7+deb10u3) buster; urgency=medium
+
+  * Fix default configuration to prevent unwanted access to admin endpoints
+(Closes: CVE-2019-19791)
+  * Fix the GrantSession plugin which could not prohibit logon when a 2FA was
+used
+  * Fix for OIDC: any redirection where allowed when relaying party was
+configured without redirect_uri
+  * Update debian/NEWS
+
+ -- Xavier Guimard   Thu, 23 Jan 2020 22:28:01 +0100
+
 lemonldap-ng (2.0.2+ds-7+deb10u2) buster-security; urgency=high
 
   * Add patch to fix OIDC vulnerabilities (Closes: CVE-2019-15941)
diff --git a/debian/patches/CVE-2019-19791.patch 
b/debian/patches/CVE-2019-19791.patch
new file mode 100644
index 000..908e49f
--- /dev/null
+++ b/debian/patches/CVE-2019-19791.patch
@@ -0,0 +1,219 @@
+Description: default configuration didn't really protect admin endpoint
+ These files are used to provide default LLNG files
+Author: LLNG Authors 
+Origin: upstream, https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1943
+Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1943
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-12-20
+
+--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/PSGI/Request.pm
 b/lemonldap-ng-common/lib/Lemonldap/NG/Common/PSGI/Request.pm
+@@ -27,9 +27,9 @@
+   if ( $self->env->{X_ORIGINAL_URI} );
+ $self->env->{PATH_INFO} =~ s|//+|/|g;
+ 
+-if ( my $tmp = $self->script_name ) {
+-$self->env->{PATH_INFO} =~ s|^$tmp|/|;
+-}
++#if ( my $tmp = $self->script_name ) {
++#$self->env->{PATH_INFO} =~ s|^$tmp|/|;
++#}
+ $self->env->{PATH_INFO} ||= '/';
+ $self->{uri} = uri_unescape( $self->env->{REQUEST_URI} );
+ $self->{uri} =~ s|^//+|/|g;
+--- a/_example/etc/manager-apache2.4.conf
 b/_example/etc/manager-apache2.4.conf
+@@ -34,10 +34,10 @@
+ # (configuration, sessions, notifications) as manager.html, sessions.html,
+ # notifications.html and uncomment the 2 following lines:
+ # DirectoryIndex manager.html
+-# RewriteCond "%{REQUEST_FILENAME}" "!\.html$"
++# RewriteCond "%{REQUEST_URI}" "!\.html(?:/.*)?$"
+ 
+ # REST URLs
+-RewriteCond "%{REQUEST_FILENAME}" 
"!^/(?:static|doc|lib|javascript|favicon).*"
++RewriteCond "%{REQUEST_URI}" "!^/(?:static|doc|lib|javascript|favicon).*"
+ RewriteRule "^/(.+)$" "/manager.fcgi/$1" [PT]
+ 
+ # 2) FastCGI engine
+--- a/_example/etc/manager-apache2.X.conf
 b/_example/etc/manager-apache2.X.conf
+@@ -28,10 +28,10 @@
+ # (configuration, sessions, notifications) as manager.html, sessions.html,
+ # notifications.html and uncomment the 2 following lines:
+ # DirectoryIndex manager.html
+-# RewriteCond "%{REQUEST_FILENAME}" "!\.html$"
++# RewriteCond "%{REQUEST_URI}" "!\.html(?:/.*)?$"
+ 
+ # REST URLs
+-RewriteCond "%{REQUEST_FILENAME}" 
"!^/(?:static|doc|lib|javascript|favicon).*"
++RewriteCond "%{REQUEST_URI}" "!^/(?:static|doc|lib|javascript|favicon).*"
+ RewriteRule "^/(.+)$" "/manager.fcgi/$1" [PT]
+ 
+ # 2) FastCGI engine
+--- a/_example/etc/manager-apache2.conf
 b/_example/etc/manager-apache2.conf
+@@ -28,10 +28,10 @@
+ # (configuration, sessions, notifications) as manager.html, sessions.html,
+ # notifications.html and uncomment the 2 following lines:
+ # DirectoryIndex manager.ht

Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

[Bill Allombert]

On Thu, Jan 23, 2020 at 12:43:34PM -0800, Russ Allbery wrote:
> Simon McVittie  writes:
> 
> > If a package has a single system service with a systemd service unit,
> > and the system service's name does not match the package's name, current
> > Policy implies that this is probably a (non-RC) bug.
> 
> > I think that's too strong. In particular, because the name of the service
> > unit is part of the "API surface" of the system service, aligning the
> > name of the service unit with the name used by upstream is usually
> > more important than aligning it with the name of the Debian package,
> > unless the name used by upstream results in conflicts or is otherwise
> > poorly-chosen. This is analogous to the names of executables in the PATH
> > and the SONAMEs of libraries, both of which we try not to change.
> 
> Ah, hm, yes, that's a good point that I didn't notice when copying that
> Policy recommendation over from the recommendations on init scripts.
> 
> The obvious concern here is that multiple packages could use the same
> service name, and making the service name match the package name reduces
> that risk considerably.  But I think I agree that staying consistent with
> upstream is more important than adopting that policy in a strong sense.
> 
> Do you have a suggestion for alternative wording?  I think we still need
> to say something about matching the name of the init script if any, and if
> upstream doesn't provide a service unit, it seems reasonable to use the
> name of the package (but maybe that should be encouraged rather than
> recommended?).

... or maybe also if the package ship a service unit that is very
different from upstream.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

[Thorsten Glaser]

Control: severity -1 grave

On Thu, 23 Jan 2020, Mark Hindley wrote:

> > thanks, yes, this provides the behaviour necessary for proper system
> > operation. Please make it the default.
> 
> Good!

Yes, but…

> Downgrading severity to important.

disagreed: this impacts other software that uses shared memory.

> I will explore the implications of changing the default.

Please leave it as release-critical until solved.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#949326: [Pkg-kde-extras] Bug#949326: transition: libgwenhywfar

[Micha Lenk]

Control: tags -1 - moreinfo

Hi Pino,

Today libaqbanking/6.0.1 cleared new and entered experimental. As you 
asked for it, I did a test build of kmymoney 5.0.8 using the new 
Gwenhywfar and AqBanking version (see attached patch for the changes I 
made to the package in unstable). It seems to build just fine (if 
required I can also send the full build log).


On 21.01.20 06:43, Pino Toscano wrote:

In data lunedì 20 gennaio 2020 22:10:38 CET, Micha Lenk ha scritto:

On 20.01.20 09:52, Pino Toscano wrote:

The newly released version of KMyMoney (5.0.8) requires:
- Gwenhywfar >= 5.1.2
- AqBanking >= 6.0.1


I looked into that and just realized this version of AqBanking did a
SONAME bump as well. This means its uploads will go through NEW. :(


Ouch... OTOH, the AqBanking transition is basically a subset of the
Gwenhywfar transition, so packing these two transitions together should
simplify things a bit.


Full ACK from my end.


Considering the requirements of KMyMoney 5.0.8, I will upload this new
version once the Gwenhywfar/AqBanking transition starts -- let me know
when that happens.


I think we are now ready to start the transition (moreinfo tag removed). 
Let me summarize again the planned transition actions:

- micha: upload libgwenhywfar/5.1.2-1 (in experimental) to unstable
- micha: upload libaqbanking/6.0.1-1 (in experimental) to unstable
- micha: upload libchipcard/5.1.5rc2-3 (in experimental) to unstable
- micha(?): schedule binNMU for gnucash to pickup the new SONAMEs.
- pino: upload kmymoney/5.0.8-1 to unstable

Please let me know if you have any comments or suggestions. Release 
team, your turn. :)


Best regards,
Micha
commit cb4b0e0f49ca671f2dc4a076f04f1b8811b91b78
Author: Micha Lenk 
Date:   Thu Jan 23 20:34:20 2020 +

New upstream version 5.0.8

diff --git a/debian/changelog b/debian/changelog
index 848f8dc..b52e74f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+kmymoney (5.0.8-1) experimental; urgency=medium
+
+  * New upstream version.
+  * Update the build dependencies according to the upstream build system:
+- bump libaqbanking-dev to 6.0.1,
+- bump libgwenhywfar-core-dev, and libgwengui-qt5-dev to 5.1.2.
+
+ -- Micha Lenk   Thu, 23 Jan 2020 20:28:35 +
+
 kmymoney (5.0.7-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 0c36c63..f55b9f8 100644
--- a/debian/control
+++ b/debian/control
@@ -34,8 +34,8 @@ Build-Depends: debhelper (>= 11), cmake, pkg-kde-tools (>= 0.15.16),
  libkf5wallet-dev,
  libkf5webkit-dev,
  libkf5xmlgui-dev,
- libaqbanking-dev (>= 5.99.32~),
- libgwenhywfar-core-dev (>= 4.99.16~), libgwengui-qt5-dev (>= 4.99.16~),
+ libaqbanking-dev (>= 6.0.1~),
+ libgwenhywfar-core-dev (>= 5.1.2~), libgwengui-qt5-dev (>= 5.1.2~),
  libgpgmepp-dev, libgpg-error-dev, libgpgme-dev,
  libalkimia5-dev (>= 7.0),
  libical-dev, libofx-dev, libgmp-dev,

Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

[Mark Hindley]

Control: severity -1 important

Thorsten,

On Thu, Jan 23, 2020 at 10:10:03PM +0100, Thorsten Glaser wrote:
> > This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. 
> > See
> 
> > Perhaps you could confirm that this configuration change provides the 
> > behaviour
> > you want?
> 
> thanks, yes, this provides the behaviour necessary for proper system
> operation. Please make it the default.

Good!

Downgrading severity to important.

I will explore the implications of changing the default.

Thanks.

Mark

Bug#949572: debian-installer: Do not install Python2 by default.

[Witold Baryluk]

I don't think python3 need to be standard. Better keep it optional as it is.

As of of Python 2, indeed there are overrides for Python 2:

$ zgrep ^python override.sid.main.gz  | grep standard
python standard python
python-minimal standard python
python2.7 standard python
python3-reportbug standard python  # This one is ok.
$

Lets make them (the three first ones) optional or remove from the overrides.

I also checked libpython* overrides, and there are some, but they are
all `optional`:

$ zgrep ^libpython override.sid.main.gz | grep -v libpython3
libpython-all-dbg optional debug
libpython-dbg optional debug
libpython2-dbg optional debug
libpython2.7-dbg optional debug
libpython-all-dev optional libdevel
libpython-dev optional libdevel
libpython2-dev optional libdevel
libpython2.7-dev optional libdevel
libpython2.7-testsuite optional libdevel
libpython2.7 optional libs
libpython-stdlib optional python
libpython2-stdlib optional python
libpython2.7-minimal optional python
libpython2.7-stdlib optional python
$

Why they are in this file in the first place I don't know. Maybe
because of Section.

If Python2 maintainers agree, I guess it is appropriate to reassign
the bug to `ftp.debian.org` pseudo-package.

Regards,
Witold

On Thu, 23 Jan 2020 at 13:01, Samuel Thibault  wrote:
>
> Matthias Klose, le jeu. 23 janv. 2020 10:33:48 +0100, a ecrit:
> > On 22.01.20 23:07, Samuel Thibault wrote:
> > > Priority: standard is exactly what defines what will be installed when
> > > you select the "standard" task in tasksel. All of python-minimal,
> > > python2.7, and python have Priority: standard.
> > >
> > > So this is to be changed in the python-defaults and python2.7 packages.
> > > (and possibly set the python3 equivalents' priority to standard
> > > instead).
> >
> > No, these are already set to optional in python-defaults and python2.7.
>
> In the source package, apparently yes, but in
> http://ftp.fr.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz
>
> Package: python
> ...
> Priority: standard
>
> I guess you need to ask ftpmaster for updating the indices override:
>
> http://ftp.fr.debian.org/debian/indices/override.sid.main.gz
>
>
> > Why would you want to set the python3 equivalents to standard now?
>
> I didn't say I wanted, I just meant that it could be wanted. I don't
> know why python itself was set so, I don't know if the reasons are still
> valid either.
>
> Samuel

Bug#949432: The crash under gdb seems to depend on disk speed

[Karl O. Pinc]

Hello,

I notice that whether or not I get the segfault when
running chromium --debug seems to depend on whether
my disk buffers have been recently cleared.  If so
then I get the crash.  If this is true then it's a
race condition.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#949701: libguestfs should be able to mount exfat when exfat-fuse is installed

[Hauke Heidtmann]

Package: libguestfs0
Version: 1:1.40.2-2

Currently guestmount/libguestfs is unable to mount an exfat fs inside a
vmdk even with exfat-fuse installed, failing with an error message like

libguestfs: error: mount_options: mount exited with status 32: mount:
/sysroot: unknown filesystem type 'exfat'.
guestmount: ‘/dev/sda1’ could not be mounted.
guestmount: Did you mean to mount one of these filesystems?
guestmount: /dev/sda1 (exfat)

although exfat-fuse is installed on the system.

Helping libguestfs by adding "exfat-fuse" to e.g.
/usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages[1] leads to the
expected result, guestmount/libguestfs is then able to mount the exfat
filesystem.

Since there already is a dependency on exfat-utils, I presume exfat is
intended to be a usable/mountable/supported filesystem in this version
of libguestfs.

Cheers,

Hauke

[1] inspired by

Bug#949626: busybox-static: Please include less and ftpput in busybox-udeb

[Witold Baryluk]

Hi Ian!

Indeed in the installer, there is openssh-client-udev, and I just
tested it, and `scp` works. Good enough.

Also very cool to see rsync available soon. That is very useful.

So no need for ftpput.

Lets focus on the `less` in this bug then.

Thank you.

On Thu, 23 Jan 2020 at 12:15, Ian Campbell  wrote:
>
> On Wed, 2020-01-22 at 22:42 +, Witold Baryluk wrote:
> > > The age of FTP has long passed.
> >
> > You think you can fit the scp or ssh then? :D I doubt so.
>
> If you have a network to scp over then you can `anna-install` the ssh
> udebs on the fly first, no need to have them in the initrd.
>
> Soon you'll be able to install rsync that way too:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729069
>
> Ian.
>

Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

[Thorsten Glaser]

Hi Mark,

> This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. See

> Perhaps you could confirm that this configuration change provides the 
> behaviour
> you want?

thanks, yes, this provides the behaviour necessary for proper system
operation. Please make it the default.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#949677: mesa breaks build of kcrash, konsole and libkscreen as tested in autopkgtest migration setup

[Paul Gevers]

Hi Timo,

On 23-01-2020 22:01, Timo Aaltonen wrote:
> Look at the error above, the file shipped by qtbase5-dev requires
> libEGL.so which the libegl-dev dependency provides. It used to be in
> libglvnd-dev but moved to a new package when the EGL headers were added
> upstream.

So, libglvnd-dev should add a versioned breaks on the old qtbase5-dev,
right?

Paul

Bug#949677: mesa breaks build of kcrash, konsole and libkscreen as tested in autopkgtest migration setup

[Timo Aaltonen]

On 23.1.2020 22.07, Paul Gevers wrote:
> Hi Timo,
> 
> On 23-01-2020 19:32, Timo Aaltonen wrote:
>> The relevant part of the build log was:
>>
>> CMake Error at
>> /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:27 (message):
>>   The imported target "Qt5::Gui" references the file
>>
>>  "/usr/lib/x86_64-linux-gnu/libEGL.so"
>>
>>   but this file does not exist.
>>
>>
>> So you need at least qtbase5-dev version 5.12.5+dfsg-3 which added
>> libegl-dev to it's Depends.
> 
> Which package (source or binary) do you refer here with "you"? As I
> noted before, the interesting thing is that the autopkgtest passes both
> in a pure testing environment and a pure unstable environment, but not
> in testing with the following packages from unstable:
> unstable/main amd64 libglvnd0 amd64 1.3.0-7 [51.5 kB]
> unstable/main amd64 libglapi-mesa amd64 19.3.2-1 [69.9 kB]
> unstable/main amd64 libgl1-mesa-dri amd64 19.3.2-1 [9,187 kB]
> unstable/main amd64 libglx-mesa0 amd64 19.3.2-1 [182 kB]
> unstable/main amd64 libglx0 amd64 1.3.0-7 [34.6 kB]
> unstable/main amd64 libgl1 amd64 1.3.0-7 [88.8 kB]
> unstable/main amd64 libglx-dev amd64 1.3.0-7 [16.2 kB]
> unstable/main amd64 libgl-dev amd64 1.3.0-7 [100 kB]
> unstable/main amd64 libgl1-mesa-dev amd64 19.3.2-1 [49.1 kB]
> unstable/main amd64 libgbm1 amd64 19.3.2-1 [70.5 kB]
> unstable/main amd64 libegl-mesa0 amd64 19.3.2-1 [139 kB]
> unstable/main amd64 libegl1 amd64 1.3.0-7 [34.1 kB]
> 
> A successful run in testing doesn't pull in libegl-dev either, so it
> seems that the file is not a hard requirement.

Look at the error above, the file shipped by qtbase5-dev requires
libEGL.so which the libegl-dev dependency provides. It used to be in
libglvnd-dev but moved to a new package when the EGL headers were added
upstream.


-- 
t

Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong

[Russ Allbery]

Simon McVittie  writes:

> If a package has a single system service with a systemd service unit,
> and the system service's name does not match the package's name, current
> Policy implies that this is probably a (non-RC) bug.

> I think that's too strong. In particular, because the name of the service
> unit is part of the "API surface" of the system service, aligning the
> name of the service unit with the name used by upstream is usually
> more important than aligning it with the name of the Debian package,
> unless the name used by upstream results in conflicts or is otherwise
> poorly-chosen. This is analogous to the names of executables in the PATH
> and the SONAMEs of libraries, both of which we try not to change.

Ah, hm, yes, that's a good point that I didn't notice when copying that
Policy recommendation over from the recommendations on init scripts.

The obvious concern here is that multiple packages could use the same
service name, and making the service name match the package name reduces
that risk considerably.  But I think I agree that staying consistent with
upstream is more important than adopting that policy in a strong sense.

Do you have a suggestion for alternative wording?  I think we still need
to say something about matching the name of the init script if any, and if
upstream doesn't provide a service unit, it seems reasonable to use the
name of the package (but maybe that should be encouraged rather than
recommended?).

-- 
Russ Allbery (r...@debian.org)  

Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

[Thorsten Glaser]

On Thu, 23 Jan 2020, Dolphin Oracle wrote:

> should you not be using /tmp for that rather that /dev/shm?

No, /tmp is not guaranteed to be tmpfs and so can persist across boots.
On a moderate wide scale of GNU/Linux installations /dev/shm is the
(only) location that fits my (modest — we’re talking about several dozen
bytes and a FIFO or two) needs.

> I think /tmp should be set up as a tmpfs and will then not persist across

Yes, but that’s a local admin choice, and it often is not because some
“enterprise” software writes a lot into it and does not use /var/tmp for
large content.


But that’s besides the question. This behaviour is a grave bug because:

> > logged out from all ssh sessions. In particular, this will also break
> > software that runs as the user, dæmonised, that uses shared memory.

This is inacceptable.


In the meantime, someone told me…

> > If you have to clean up after yourselves, keep a list and track of the
> > files you created and will later need to delete.
> >
> > It might be a good idea to see whether systemd does the same and, if

… that They don’t do that, au contraire, they often leave tons of crap
around in /dev/shm…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

[Mark Hindley]

On Thu, Jan 23, 2020 at 08:32:46PM +0100, Thorsten Glaser wrote:
> Package: elogind
> Version: 241.3-1+debian2
> Severity: critical
> Justification: breaks unrelated software
> 
> I’m using a scheme in which I store ssh-agent and gpg-agent information
> across all logins (local X session or ssh or xrdp) under /dev/shm/ since
> I needed space that an unprivileged user can use and that doesn’t persist
> across reboots.
> 
> Since installing elogind, logging out from SSH sessions then on again
> both breaks gpg-agent as well as makes ssh-agent instances multiply and,
> thus, lose their loaded keys to the user.

Thorsten,

Thanks for this.

This behaviour is configurable via RemoveIPC in /etc/elogind/logind.conf. See
man logind.conf(5).

I accept that the documentation for the behaviour is difficult to find (I had to
search quite hard) and it may be that the default ought to be different.

Perhaps you could confirm that this configuration change provides the behaviour
you want?

Many thanks.

Mark

Bug#870396: [PATCH 2/3] pcm: explicitly cast time types to types printf can handle

[mirabilos]

Signed-off-by: mirabilos 
---
 src/pcm/pcm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index 1064044c..eb53311c 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -2329,11 +2329,11 @@ int snd_pcm_status_dump(snd_pcm_status_t *status, 
snd_output_t *out)
 {
assert(status);
snd_output_printf(out, "  state   : %s\n", 
snd_pcm_state_name((snd_pcm_state_t) status->state));
-   snd_output_printf(out, "  trigger_time: %ld.%06ld\n",
- status->trigger_tstamp.tv_sec,
- status->trigger_tstamp.tv_nsec / 1000);
-   snd_output_printf(out, "  tstamp  : %ld.%06ld\n",
-   status->tstamp.tv_sec, status->tstamp.tv_nsec / 1000);
+   snd_output_printf(out, "  trigger_time: %lld.%06ld\n",
+ (long long)status->trigger_tstamp.tv_sec,
+ (long)status->trigger_tstamp.tv_nsec / 1000L);
+   snd_output_printf(out, "  tstamp  : %lld.%06ld\n",
+   (long long)status->tstamp.tv_sec, (long)status->tstamp.tv_nsec 
/ 1000L);
snd_output_printf(out, "  delay   : %ld\n", (long)status->delay);
snd_output_printf(out, "  avail   : %ld\n", (long)status->avail);
snd_output_printf(out, "  avail_max   : %ld\n", 
(long)status->avail_max);
-- 
2.25.0

Bug#870396: [PATCH 1/3] pcm: ensure amd64-specific asm code is not used on x32

[mirabilos]

This fixes segfaults on x32 systems.

Signed-off-by: mirabilos 
---
 src/pcm/pcm_dmix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pcm/pcm_dmix.c b/src/pcm/pcm_dmix.c
index d533f40c..407f644d 100644
--- a/src/pcm/pcm_dmix.c
+++ b/src/pcm/pcm_dmix.c
@@ -142,7 +142,7 @@ static void dmix_server_free(snd_pcm_direct_t *dmix)
 #include "pcm_dmix_generic.c"
 #if defined(__i386__)
 #include "pcm_dmix_i386.c"
-#elif defined(__x86_64__)
+#elif defined(__x86_64__) && !defined(__ILP32__)
 #include "pcm_dmix_x86_64.c"
 #else
 #ifndef DOC_HIDDEN
-- 
2.25.0

Bug#870396: [PATCH 3/3] test: explicitly cast time types to types printf can handle

[mirabilos]

Also (as requested by Takashi Iwai), convert timediff() to time_t,
as it’s the proper return type.

Signed-off-by: mirabilos 
---
 test/latency.c | 10 +-
 test/queue_timer.c | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/test/latency.c b/test/latency.c
index 298bab8a..cf39d319 100644
--- a/test/latency.c
+++ b/test/latency.c
@@ -325,7 +325,7 @@ void setscheduler(void)
printf("!!!Scheduler set to Round Robin with priority %i FAILED!!!\n", 
sched_param.sched_priority);
 }
 
-long timediff(snd_timestamp_t t1, snd_timestamp_t t2)
+time_t timediff(snd_timestamp_t t1, snd_timestamp_t t2)
 {
signed long l;
 
@@ -683,12 +683,12 @@ int main(int argc, char *argv[])
snd_pcm_nonblock(phandle, !block ? 1 : 0);
if (ok) {
 #if 1
-   printf("Playback time = %li.%i, Record time = %li.%i, 
diff = %li\n",
-  p_tstamp.tv_sec,
+   printf("Playback time = %lli.%i, Record time = %lli.%i, 
diff = %lli\n",
+  (long long)p_tstamp.tv_sec,
   (int)p_tstamp.tv_usec,
-  c_tstamp.tv_sec,
+  (long long)c_tstamp.tv_sec,
   (int)c_tstamp.tv_usec,
-  timediff(p_tstamp, c_tstamp));
+  (long long)timediff(p_tstamp, c_tstamp));
 #endif
break;
}
diff --git a/test/queue_timer.c b/test/queue_timer.c
index c4ffb192..c5ce5866 100644
--- a/test/queue_timer.c
+++ b/test/queue_timer.c
@@ -99,11 +99,11 @@ main(int argc ATTRIBUTE_UNUSED, char **argv 
ATTRIBUTE_UNUSED)
normalize(&diffdiff);
prevdiff = diff;
 
-   fprintf(stderr, " real time: %12ld sec %8ld usec\nqueue time: %12ld sec 
%8ld usec\n  diff: %12ld sec %8ld usec\n  diffdiff: %12ld sec %8ld usec\n",
-   tv.tv_sec, tv.tv_usec,
-   (long)rtime->tv_sec, (long)rtime->tv_nsec / 1000,
-   diff.tv_sec, diff.tv_usec,
-   (long)diffdiff.tv_sec, (long)diffdiff.tv_usec);
+   fprintf(stderr, " real time: %12lld sec %8ld usec\nqueue time: %12lld 
sec %8ld usec\n  diff: %12lld sec %8ld usec\n  diffdiff: %12lld sec %8ld 
usec\n",
+   (long long)tv.tv_sec, (long)tv.tv_usec,
+   (long long)rtime->tv_sec, (long)rtime->tv_nsec / 1000,
+   (long long)diff.tv_sec, (long)diff.tv_usec,
+   (long long)diffdiff.tv_sec, (long)diffdiff.tv_usec);
 
if (diffdiff.tv_usec >  5000 ||
diffdiff.tv_usec < -5000) {
-- 
2.25.0

Bug#870396: [alsa-devel] [PATCH] fix segfault on x32, 64-bit time_t-related format strings

[Thorsten Glaser]

On Fri, 22 Nov 2019, Takashi Iwai wrote:

> > I’ve sent them as two separate patch files attachments.
> 
> Then please make them cleanly applicable via git-am, with a proper
> subject, a proper changelog and your sign-off, etc.

I’ll resend them like that now. Sorry it took a bit, I was busy.

> At best send one patch per mail (and with a cover letter for multiple
> patches).

This is a bit tricky, as I can’t easily inject git format-patch
output into this mail setup. I will try sending them from home.

> > > Also, using time_t would be better if possible.  Unfortunately a cast
> > > is needed for printf usage, but other than that, time_t would leave us
> > > the right size.
> > 
> > In timediff() you mean? Hrm, indeed. I tried to be minimal-invasive
> > at first.
> 
> I meant using time_t as much as possible instead of long long.

I’ve done this now.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

[Dolphin Oracle]

should you not be using /tmp for that rather that /dev/shm?

I think /tmp should be set up as a tmpfs and will then not persist across
reboots.  /var/tmp is for tmp space that needs to persist across reboots.



On Thu, Jan 23, 2020 at 2:36 PM Thorsten Glaser  wrote:

> Package: elogind
> Version: 241.3-1+debian2
> Severity: critical
> Justification: breaks unrelated software
>
> I’m using a scheme in which I store ssh-agent and gpg-agent information
> across all logins (local X session or ssh or xrdp) under /dev/shm/ since
> I needed space that an unprivileged user can use and that doesn’t persist
> across reboots.
>
> Since installing elogind, logging out from SSH sessions then on again
> both breaks gpg-agent as well as makes ssh-agent instances multiply and,
> thus, lose their loaded keys to the user.
>
> Tons of searching and debugging eventuall led me, with strace as root on
> it, to the culprit: elogind
>
> lrwxrwxrwx 1 root root 0 Jan 23 20:21 /proc/3061/exe ->
> /lib/elogind/elogind*
>
> 3061  unlinkat(22, "info2", 0)  = 0
> 3061  unlinkat(21, ".ssh-2339", AT_REMOVEDIR) = 0
>
>
> Cease that instantly. This breaks unrelated software on the system,
> considering that the user’s processes are still running, even if they
> logged out from all ssh sessions. In particular, this will also break
> software that runs as the user, dæmonised, that uses shared memory.
>
> If you have to clean up after yourselves, keep a list and track of the
> files you created and will later need to delete.
>
> It might be a good idea to see whether systemd does the same and, if
> so, clone this bugreport and assign the clone to them. I’m not running
> systemd, so I can’t do that myself easily.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500,
> 'unstable'), (100, 'experimental')
> Architecture: x32 (x86_64)
> Foreign Architectures: i386, amd64
>
> Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
>
> Versions of packages elogind depends on:
> ii  dbus 1.12.16-2
> ii  debconf  1.5.73
> ii  libacl1  2.2.53-5
> ii  libc62.29-9
> ii  libcap2  1:2.27-1
> ii  libelogind0  241.3-1+debian2
> ii  libselinux1  3.0-1
> ii  libudev1 244-3
> ii  lsb-base 11.1.0
>
> Versions of packages elogind recommends:
> ii  libpam-elogind  241.3-1+debian2
> ii  policykit-1 0.105-26
>
> elogind suggests no packages.
>
> -- no debconf information
>

Bug#949689: mpg123: please add temporary mute key

[Thorsten Glaser]

Dennis Braun dixit:

>first of all this is a feature request for the upstream project and not
>for debian.

Yes, I know, hence I tagged it with “upstream”, and…

>here you can go to make a feature request for mpg123: 
>https://sourceforge.net/p/mpg123/bugs/

… while maybe I could, I would have needed to find that out, and I
find SourceFrog cumbersome to use, and Debian package maintainers are
required to forward such issues upstream anyway, AND I happen to know
that Thomas reads the Debian bugtracker ☻

>what you can do meanwhile is for example to use a keyboard shortcut.

A keyboard shortcut to do WHAT, precisely?

There’s no keyboard shortcut to mute mpg123 temporarily and on second
press restore the original volume inside mpg123, which is the reason
for this feature request in the first place.

>in gnome-shell you can do this with:  gnome-control-center
>choose key combinations and scroll down, there is already an entry for it.

I won’t use GNOME.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Bug#949677: mesa breaks build of kcrash, konsole and libkscreen as tested in autopkgtest migration setup

[Paul Gevers]

Hi Timo,

On 23-01-2020 19:32, Timo Aaltonen wrote:
> The relevant part of the build log was:
> 
> CMake Error at
> /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:27 (message):
>   The imported target "Qt5::Gui" references the file
> 
>  "/usr/lib/x86_64-linux-gnu/libEGL.so"
> 
>   but this file does not exist.
> 
> 
> So you need at least qtbase5-dev version 5.12.5+dfsg-3 which added
> libegl-dev to it's Depends.

Which package (source or binary) do you refer here with "you"? As I
noted before, the interesting thing is that the autopkgtest passes both
in a pure testing environment and a pure unstable environment, but not
in testing with the following packages from unstable:
unstable/main amd64 libglvnd0 amd64 1.3.0-7 [51.5 kB]
unstable/main amd64 libglapi-mesa amd64 19.3.2-1 [69.9 kB]
unstable/main amd64 libgl1-mesa-dri amd64 19.3.2-1 [9,187 kB]
unstable/main amd64 libglx-mesa0 amd64 19.3.2-1 [182 kB]
unstable/main amd64 libglx0 amd64 1.3.0-7 [34.6 kB]
unstable/main amd64 libgl1 amd64 1.3.0-7 [88.8 kB]
unstable/main amd64 libglx-dev amd64 1.3.0-7 [16.2 kB]
unstable/main amd64 libgl-dev amd64 1.3.0-7 [100 kB]
unstable/main amd64 libgl1-mesa-dev amd64 19.3.2-1 [49.1 kB]
unstable/main amd64 libgbm1 amd64 19.3.2-1 [70.5 kB]
unstable/main amd64 libegl-mesa0 amd64 19.3.2-1 [139 kB]
unstable/main amd64 libegl1 amd64 1.3.0-7 [34.1 kB]

A successful run in testing doesn't pull in libegl-dev either, so it
seems that the file is not a hard requirement.

Paul

Bug#949700: mc: extfs for .deb regression against 3:4.8.23-1 (makes it mostly unusable)

[Thorsten Glaser]

Package: mc
Version: 3:4.8.24-1
Severity: normal

$ apt-get download mc
$ mc

Then navigate to mc_3%3a4.8.24-1_amd64.deb and press Enter,
go to CONTENTS/ and press Enter again. It’s empty.

Downgrading mc and mc-data to 3:4.8.23-1 makes it work again,
so it’s a regression.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages mc depends on:
ii  libc6 2.29-9
ii  libext2fs21.45.5-2
ii  libglib2.0-0  2.62.4-1+b1
ii  libgpm2   1.20.7-5+b1
ii  libslang2 2.3.2-4
ii  libssh2-1 1.8.0-2.1
ii  mc-data   3:4.8.24-1

Versions of packages mc recommends:
ii  mime-support  3.64
ii  perl  5.30.0-9
ii  unzip 6.0-25

Versions of packages mc suggests:
pn  arj  
ii  bzip21.0.8-2
pn  dbview   
pn  djvulibre-bin
pn  epub-utils   
ii  file 1:5.38-4
ii  genisoimage  9:1.1.11-3.1
ii  gv [pdf-viewer]  1:3.7.4-2+b1
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
pn  libaspell-dev
ii  lynx 2.9.0dev.4-1
ii  mupdf [pdf-viewer]   1.15.0+ds1-1+b1
pn  odt2txt  
ii  okular [pdf-viewer]  4:17.12.2-2.2+b2
ii  poppler-utils0.71.0-6
ii  python   2.7.17-2
pn  python-boto  
pn  python-tz
ii  texlive-binaries 2019.20190605.51237-3
ii  w3m  0.5.3-37+b1
ii  zip  3.0-11+b1

-- no debconf information

Bug#949665: [Info-mtools] Error when operating on large files

[Pali Rohár]

On Thursday 23 January 2020 17:01:00 Chris Lamb wrote:
> [please retain all CCs upon replying, I am not subscribed to this list]
> 
> Hi,
> 
> I'm the maintainer of the "mtools" package in Debian. The following
> bug report was just filed there which I will quote in full, but it can
> also be viewed here:
> 
> https://bugs.debian.org/949665
> 
> > Running e.g. mdir -i $SOMEFILE@@$LARGEOFFSET fails when the offset
> > exceeds around 2GB. The error message is:
> > 
> > | seek: Invalid argument
> > | init :: could not read boot sector
> > | Cannot initialize '::'
> >
> > Using strace one can see that mtools tries to seek the image to a
> > negative offset that results from treating the desired offset as a
> > signed 32bit number.
> […]
> > Most likely, it can be fixed by adding -D_FILE_OFFSET_BITS=64 to the
> > CFLAGS.
> 
> I then briefly asked whether this would be suitable for inclusion
> upstream, to which the reporter was in agreement. Please see https://
> bugs.debian.org/949665#15 for more on this, including the sketchings
> of a patch.

Hello!

For handling problems with large files, autoconf has m4 macro:

AC_SYS_LARGEFILE

It automatically checks if some special compiler flags are needed for
handling large files and if yes, this macro automatically modifies
compiler flags.

So I think adding AC_SYS_LARGEFILE into configure.ac should fix this
problem for all platforms (supported by autoconf).

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#940461: imap-dl: maybe we should use Mail::Box ?

[Sean Whitton]

Hello,

I just discovered that it is possible to implement imap-dl using the
Mail::Box suite.  This would mean we would not need to include any code
parsing and emitting the IMAP protocol in mailscripts.  That seems
strongly preferable.  Let me know what you think.

Here is what the fetch code becomes:

#!/usr/bin/perl

use 5.028;
use strict;
use warnings;

use Mail::Box::Manager;

my $mgr = Mail::Box::Manager->new;
my $imap_folder = $mgr->open('imap://user:passwd@host:port/INBOX');
my $maildir = $mgr->open(
'/home/spwhitton/Maildir',
access=> 'a',
create=> 1,
keep_dups => 1,
type  => 'maildir'
);
$mgr->moveMessage($maildir, $_) for $imap_folder->messages();
$mgr->closeAllFolders();

We could even keep all dkg's existing code for parsing getmail configs,
etc., and use Mail::Box only to do the actual fetch and insert.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#948656: firejail-profiles: firefox-esr running under firejail does not load correct preferences

[Reiner Herrmann]

On Thu, Jan 23, 2020 at 08:25:10PM +0100, /dev/fra wrote:
> Just a quick update, upgrading to firejail-profiles 0.9.62-3 does not fix the 
> issue while downgrading to version 0.9.60-2 does it. So it seems that this 
> issue is definitely caused by a change introduced after 0.9.60-2.

Thanks for the update.
Unfortunately I wasn't able to reproduce that issue yet.

The changes between these two version were not so big.
In firefox.profile these two lines are new:

whitelist /usr/share/mozilla
include whitelist-usr-share-common.inc

And in firefox-common.profile (included by firefox.profile),
the only effective change (ignoring comments) was the seccomp line to:

seccomp !chroot

Could you maybe install 0.9.62 again and try to figure out which of
these changes is causing your problem?
Maybe also start firejail with the --trace parameter, as it will tell
which files are being accessed by the program.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#942146: koji: CVE-2019-17109

[Holger Levsen]

On Thu, Jan 23, 2020 at 08:42:03PM +0100, Moritz Muehlenhoff wrote:
> Let's remove it in the upcoming stretch/buster point releases, then?

seems reasonable to me.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#942146: koji: CVE-2019-17109

[Moritz Muehlenhoff]

On Thu, Jan 23, 2020 at 04:37:15PM +, Holger Levsen wrote:
> Hi Salvatore,
> 
> On Sun, Jan 05, 2020 at 09:02:20PM +0100, Salvatore Bonaccorso wrote:
> > Any news on this issue? AFAICT, the issue is fixed as well in 1.16.3,
> > so the smaller jump should be possible. Once fixed in unstable, can
> > you adress the issue as well via point release?
> 
> I think it's pointless to have 1.16.x in unstable and newer koji needs
> newer dnf (and some other stuff, iirc), which isnt packaged in Debian,
> so this is not as straightforward as it seems.
> 
> I'm also not sure there are many (or any?) users of koji from stable. If
> I were to use it, I would use koji from Fedora...
> https://qa.debian.org/popcon.php?package=koji seems to confirm this.

Let's remove it in the upcoming stretch/buster point releases, then?

Cheers,
Moritz

Bug#949699: 0ad dies with 'Assertion failed: "cache.Validate()"'

[Bob Ham]

Package: 0ad
Version: 0.0.23.1-2
Severity: normal

Hi,

Running 0ad on the command line gives me a window with an error and a
backtrace.  Clicking on the "Continue" button gives me another error.
Repeared clicking "Continue" gives me the following output and
eventually the main menu:

=
$ 0ad
TIMER| InitVfs: 685.04 us
Writing the mainlog at /home/rah/.config/0ad/logs/mainlog.html
TIMER| CONFIG_Init: 765.932 us
Sound: AlcInit success, using OpenAL Soft
TIMER| shutdown ConfigDB: 0.962 us
TIMER| resource modules: 181.38 ms
TIMER TOTALS (9 clients)
-
  tc_pool_alloc: 0 c (0x)
  tc_png_decode: 0 c (0x)
  tc_dds_transform: 0 c (0x)
  tc_transform: 0 c (0x)
  tc_plain_transform: 0 c (0x)
  tc_ShaderGLSLLink: 0 c (0x)
  tc_ShaderGLSLCompile: 0 c (0x)
  tc_ShaderValidation: 0 c (0x)
  xml_validation: 0 c (0x)
-
TIMER| shutdown misc: 257.835 us
TIMER| InitVfs: 57.3602 ms
Writing the mainlog at /home/rah/.config/0ad/logs/mainlog.html
TIMER| CONFIG_Init: 802.952 us
Sound: AlcInit success, using OpenAL Soft
cache.cpp(43): Assertion failed: "cache.Validate()"
Assertion failed: "cache.Validate()"
Location: cache.cpp:43 (AddCache)

Call stack:

(0x56b651de) /usr/games/pyrogenesis(+0x6121de) [0x56b651de]
(0x56b10c51) /usr/games/pyrogenesis(+0x5bdc51) [0x56b10c51]
(0x56b12148) /usr/games/pyrogenesis(+0x5bf148) [0x56b12148]
(0x56b12648) /usr/games/pyrogenesis(+0x5bf648) [0x56b12648]
(0x56b5d59e) /usr/games/pyrogenesis(+0x60a59e) [0x56b5d59e]
(0x56b5dbf4) /usr/games/pyrogenesis(+0x60abf4) [0x56b5dbf4]
(0x56b5e0b5) /usr/games/pyrogenesis(+0x60b0b5) [0x56b5e0b5]
(0x56b93343) /usr/games/pyrogenesis(+0x640343) [0x56b93343]
(0x56b5e8fe) /usr/games/pyrogenesis(+0x60b8fe) [0x56b5e8fe]
(0x56b5f78a) /usr/games/pyrogenesis(+0x60c78a) [0x56b5f78a]
(0x56b93343) /usr/games/pyrogenesis(+0x640343) [0x56b93343]
(0x56b5f36a) /usr/games/pyrogenesis(+0x60c36a) [0x56b5f36a]
(0x5680061f) /usr/games/pyrogenesis(+0x2ad61f) [0x5680061f]
(0x567f7329) /usr/games/pyrogenesis(+0x2a4329) [0x567f7329]
(0x56607691) /usr/games/pyrogenesis(+0xb4691) [0x56607691]
(0x565f30b7) /usr/games/pyrogenesis(+0xa00b7) [0x565f30b7]

errno = 0 (Error during IO)
OS error = ?


cache.cpp(637): Assertion failed: "caches[L1D+idxLevel].Validate() == true"
Assertion failed: "caches[L1D+idxLevel].Validate() == true"
Location: cache.cpp:637 (DetectCacheAndTLB)

Call stack:

(0x56b651de) /usr/games/pyrogenesis(+0x6121de) [0x56b651de]
(0x56b10c51) /usr/games/pyrogenesis(+0x5bdc51) [0x56b10c51]
(0x56b12148) /usr/games/pyrogenesis(+0x5bf148) [0x56b12148]
(0x56b12648) /usr/games/pyrogenesis(+0x5bf648) [0x56b12648]
(0x56b5e392) /usr/games/pyrogenesis(+0x60b392) [0x56b5e392]
(0x56b93343) /usr/games/pyrogenesis(+0x640343) [0x56b93343]
(0x56b5e8fe) /usr/games/pyrogenesis(+0x60b8fe) [0x56b5e8fe]
(0x56b5f78a) /usr/games/pyrogenesis(+0x60c78a) [0x56b5f78a]
(0x56b93343) /usr/games/pyrogenesis(+0x640343) [0x56b93343]
(0x56b5f36a) /usr/games/pyrogenesis(+0x60c36a) [0x56b5f36a]
(0x5680061f) /usr/games/pyrogenesis(+0x2ad61f) [0x5680061f]
(0x567f7329) /usr/games/pyrogenesis(+0x2a4329) [0x567f7329]
(0x56607691) /usr/games/pyrogenesis(+0xb4691) [0x56607691]
(0x565f30b7) /usr/games/pyrogenesis(+0xa00b7) [0x565f30b7]
(0x7efbfd48209b) /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) 
[0x7efbfd48209b]
(0x566017ea) /usr/games/pyrogenesis(+0xae7ea) [0x566017ea]

errno = 0 (No error reported here)
OS error = ?


cache.cpp(641): Assertion failed: "caches[L1I+idxLevel].Validate() == true"
Assertion failed: "caches[L1I+idxLevel].Validate() == true"
Location: cache.cpp:641 (DetectCacheAndTLB)

Call stack:

(0x56b651de) /usr/games/pyrogenesis(+0x6121de) [0x56b651de]
(0x56b10c51) /usr/games/pyrogenesis(+0x5bdc51) [0x56b10c51]
(0x56b12148) /usr/games/pyrogenesis(+0x5bf148) [0x56b12148]
(0x56b12648) /usr/games/pyrogenesis(+0x5bf648) [0x56b12648]
(0x56b5e332) /usr/games/pyrogenesis(+0x60b332) [0x56b5e332]
(0x56b93343) /usr/games/pyrogenesis(+0x640343) [0x56b93343]
(0x56b5e8fe) /usr/games/pyrogenesis(+0x60b8fe) [0x56b5e8fe]
(0x56b5f78a) /usr/games/pyrogenesis(+0x60c78a) [0x56b5f78a]
(0x56b93343) /usr/games/pyrogenesis(+0x640343) [0x56b93343]
(0x56b5f36a) /usr/games/pyrogenesis(+0x60c36a) [0x56b5f36a]
(0x5680061f) /usr/games/pyrogenesis(+0x2ad61f) [0x5680061f]
(0x567f7329) /usr/games/pyrogenesis(+0x2a4329) [0x567f7329]
(0x56607691) /usr/games/pyrogenesis(+0xb4691) [0x56607691]
(0x565f30b7) /usr/games/pyrogenesis(+0xa00b7) [0x565f30b7]
(0x7efbfd48209b) /lib/x86_64-linux-gnu/libc.so.6(__li

Bug#949698: elogind: deletes users’ files under /dev/shm/ on logout

[Thorsten Glaser]

Package: elogind
Version: 241.3-1+debian2
Severity: critical
Justification: breaks unrelated software

I’m using a scheme in which I store ssh-agent and gpg-agent information
across all logins (local X session or ssh or xrdp) under /dev/shm/ since
I needed space that an unprivileged user can use and that doesn’t persist
across reboots.

Since installing elogind, logging out from SSH sessions then on again
both breaks gpg-agent as well as makes ssh-agent instances multiply and,
thus, lose their loaded keys to the user.

Tons of searching and debugging eventuall led me, with strace as root on
it, to the culprit: elogind

lrwxrwxrwx 1 root root 0 Jan 23 20:21 /proc/3061/exe -> /lib/elogind/elogind*

3061  unlinkat(22, "info2", 0)  = 0
3061  unlinkat(21, ".ssh-2339", AT_REMOVEDIR) = 0


Cease that instantly. This breaks unrelated software on the system,
considering that the user’s processes are still running, even if they
logged out from all ssh sessions. In particular, this will also break
software that runs as the user, dæmonised, that uses shared memory.

If you have to clean up after yourselves, keep a list and track of the
files you created and will later need to delete.

It might be a good idea to see whether systemd does the same and, if
so, clone this bugreport and assign the clone to them. I’m not running
systemd, so I can’t do that myself easily.

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

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages elogind depends on:
ii  dbus 1.12.16-2
ii  debconf  1.5.73
ii  libacl1  2.2.53-5
ii  libc62.29-9
ii  libcap2  1:2.27-1
ii  libelogind0  241.3-1+debian2
ii  libselinux1  3.0-1
ii  libudev1 244-3
ii  lsb-base 11.1.0

Versions of packages elogind recommends:
ii  libpam-elogind  241.3-1+debian2
ii  policykit-1 0.105-26

elogind suggests no packages.

-- no debconf information

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

[Sean Whitton]

Hello Daniel,

On Wed 22 Jan 2020 at 04:52PM -05, Daniel Kahn Gillmor wrote:

> The attached git-formatted patch is also present on the imap-dl-squashed
> branch on https://salsa.debian.org/dkg/mailscripts.  jrollins confirmed
> that it was OK, which is why it bears both of our signoffs.

Thanks for sorting that out.  Here are my comments on the current
version of imap-dl.  Looking forward to including it in mailscripts.

> diff --git a/imap-dl b/imap-dl
> new file mode 100755
> index 000..f5d7a85
> --- /dev/null
> +++ b/imap-dl
> +
> +_summary_splitter = re.compile(rb'^(?P[0-9]+) \(UID (?P[0-9]+) 
> RFC822.SIZE (?P[0-9]+)\)$')
> +def break_fetch_summary(line:bytes) -> Dict[str,int]:
> +'''b'1 (UID 160 RFC822.SIZE 1867)' -> {id: 1, uid: 160, size: 1867}'''
> +match = _summary_splitter.match(line)
> +if not match:
> +raise Exception(f'malformed summary line {line!r}')
> +ret:Dict[str,int] = {}
> +i:str
> +for i in ['id', 'uid', 'size']:
> +ret[i] = int(match[i])
> +return ret
> +
> +_fetch_splitter = re.compile(rb'^(?P[0-9]+) \(UID (?P[0-9]+) (FLAGS 
> \([\\A-Za-z ]*\) )?BODY\[\] \{(?P[0-9]+)\}$')
> +def break_fetch(line:bytes) -> Dict[str,int]:
> +'''b'1 (UID 160 BODY[] {1867}' -> {id: 1, uid: 160, size: 1867}'''
> +match = _fetch_splitter.match(line)
> +if not match:
> +raise Exception(f'malformed fetch line {line!r}')
> +ret:Dict[str,int] = {}
> +i:str
> +for i in ['id', 'uid', 'size']:
> +ret[i] = int(match[i])
> +return ret

These two functions are almost identical; please refactor.

> +if verbose: # only enable debugging after login to avoid leaking 
> credentials in the log
> +imap.debug = 4
> +logging.info("capabilities reported: %s", ', 
> '.join(imap.capabilities))

I am not familiar with idiomatic logging in Python, but shouldn't the
logging.info call be outside of the 'if' block, like all the others?

And shouldn't this be `if verbose or conf_verbose`?

> +if n == 0:
> +logging.info('No messages to retrieve')
> +logging.getLogger().setLevel(oldloglevel)
> +return

This is not a blocker, but it would be better to refactor such that
resetting the log level does not involve you repeating yourself here and
at the end of pull_msgs.

Can you use a 'with' keyword to temporarily set the loglevel, perhaps?
Or move the part of pull_msgs after config parsing into its own
subroutine.

> +uids = ','.join(map(lambda x: str(x['uid']), sorted(pending, 
> key=lambda x: x['uid'])))

This line could be shorter and easier to read, afaict.  How about:

from operator import itemgetter
uids = ','.join(map(str, sorted(map(itemgetter('uid'), pending

or

uids = ','.join(map(str, sorted([x['uid'] for x in pending])))

(untested)

> +for f in resp[1]:
> +# these objects are weirdly structured. i don't know why
> +# these trailing close-parens show up.  so this is very
> +# ad-hoc and nonsense
> +if isinstance(f, bytes):
> +if f != b')':
> +raise Exception('got bytes object of length %d but 
> expected simple closeparen'%(len(f),))
> +elif isinstance(f, tuple):

What is f is neither bytes nor tuple?  Should probably raise an
exception in that case.

Is there really no documentation from the IMAP library you're using
about the closeparens?

> +if on_size_mismatch == 'warn':
> +if len(sizes_mismatched) == 0:
> +logging.warning('size mismatch: summary said %d 
> octets, fetch sent %d',
> +sizes[m['uid']], m['size'])
> +elif len(sizes_mismatched) == 1:
> +logging.warning('size mismatch: (mismatches 
> after the first suppressed until summary)')
> +sizes_mismatched.append(sizes[m['uid']] - m['size'])
> +elif on_size_mismatch == 'exception':
> +raise Exception('size mismatch: summary said %d 
> octets, fetch sent %d\n(set options.on_size_mismatch to none or warn to avoid 
> hard failure)',
> +sizes[m['uid']], m['size'])
> +elif on_size_mismatch != 'none':
> +raise Exception('size_mismatch: 
> options.on_size_mismatch should be none, warn, or exception (found "%s")', 
> on_size_mismatch)

Checking whether size_mismatch contains the wrong sort of value should
not happen in the middle of the IMAP response processing code.  Please
move the check to where on_size_mismatch gets set.

Would be nice if you could avoid the really long lines here.

> +fname = mdst.add(f[1].replace(b'\r\n', b'\n'))

Could a message contain a mixture of UNIX and Windows line endings, such
that this line corrupts the message?  If not, ple

Bug#948656: firejail-profiles: firefox-esr running under firejail does not load correct preferences

[/dev/fra]

Hi,

Just a quick update, upgrading to firejail-profiles 0.9.62-3 does not fix the 
issue while downgrading to version 0.9.60-2 does it. So it seems that this 
issue is definitely caused by a change introduced after 0.9.60-2.

Cheers,

Bug#949689: mpg123: please add temporary mute key

[Thorsten Glaser]

Thomas Orgis dixit:

>any special reason why this suggestion is not posted to the mpg123 bug tracker,
>or just even just mailed to upstream, but reported to the Debian project 
>instead?

Because reportbug is easier and the package maintainer should
forward them as part of their regular duties and so I don’t have
to register another bugtracker account or deal with eMail inter‐
change problems…

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#938987: Overly restrictive CapabilityBoundingSet

[David Croft]

Confirmed, on every system upgraded to buster, nsd fails to start (even
with a blank configuration file i.e. all settings at defaults):

systemd[1]: Starting Name Server Daemon...
nsd[10191]: error: could not open zone list /var/lib/nsd/zone.list:
Permission denied
nsd[10191]: error: could not read zonelist file /var/lib/nsd/zone.list
systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: nsd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Name Server Daemon.

Since the default for the config parameter "zonelistfile"
is "/var/lib/nsd/zone.list", the process needs access to this file
(seemingly even if you do not use dynamic zones).

I don't pretend to understand all this .service file gubbins, I note that
it already has ReadWritePaths=/var/lib/nsd so I don't know what's wrong.
Since I didn't feel it wise to give the process full root access to the
filesystem, I simply commented out the CapabilityBoundingSet line

Please can you fix this regression.

Thanks
David

Bug#869224: RFA: scoop -- Python library for concurrent parallel programming

[Christian Kastner]

Control: retitle -1 ITA: scoop -- Python library for concurrent parallel
programming

On Fri, 21 Jul 2017 19:25:05 +0200 Daniel Stender
 wrote:

> I'm seeking for somebody to adopt this package [1]. If you are a
member of Debian Science, you could
> just take over without contacting me. But if you are not, please talk
to me first.
>
> Thanks,
> Daniel Stender

This is a dependency of a package I'm looking into, so I'll continue to
maintain it within Debian Science.

Bug#949695: thunderbird does not start anymore

[Birger Schacht]

Hi,

I just had the same problem. For me, downgrading libsqlite3 to
libsqlite3-0_3.30.1+fossil191229-1 made thunderbird start again.

cheers,
Birger

Bug#949697: samba4: samba 4 with ntpd wrong permission on /var/lib/samba/ntp_signd/socket

[Jens Schmidt]

Package: samba
Version: 2:4.9.5+dfsg-5+deb10u1
Severity: important
File: samba4

Dear Maintainer,

when using samba as pdc with ntpd time synchronisation on windows clients
fails because ntp cannot write to /var/lib/samba/ntp_signd/socket.

Following the descriptions on 
https://wiki.samba.org/index.php/Time_Synchronisation
samba should provide time to windows clients.

However, doing "w32tm /resync /rediscover" on a windows client yields an
error "no time data available".

Further investigation with strace found the following on the pdc when w32tm was 
run on the client:

[pid  9063] 19:08:52 --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid  9063] 19:08:52 rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system 
call)
[pid  9063] 19:08:52 select(23, [16 17 18 19 20 21 22], NULL, NULL, NULL) = 1 
(in [19])
[pid  9063] 19:08:52 recvmsg(19, {msg_name={sa_family=AF_INET, 
sin_port=htons(123), sin_addr=inet_addr("192.168.43.183")}, msg_namelen=28->16, 
msg_iov=[{iov_base="\333\0\21\351\0\0\10\25\0\t\7\205\0\0\0\0\341\324_\21\316,\220\201\0\0\0\0\0\0\0\0"...,
 iov_len=2120}], msg_iovlen=1, msg_control=[{cmsg_len=32, 
cmsg_level=SOL_SOCKET, cmsg_type=SCM_TIMESTAMPNS, cmsg_data={tv_sec=1579802932, 
tv_nsec=860702542}}], msg_controllen=32, msg_flags=0}, 0) = 68
[pid  9063] 19:08:52 recvmsg(19, {msg_namelen=28}, 0) = -1 EAGAIN (Resource 
temporarily unavailable)
[pid  9063] 19:08:52 socket(AF_UNIX, SOCK_STREAM, 0) = 7
[pid  9063] 19:08:52 connect(7, {sa_family=AF_UNIX, 
sun_path="/var/lib/samba/ntp_signd//socket"}, 110) = -1 EACCES (Permission 
denied)
[pid  9063] 19:08:52 close(7)   = 0

Clearly ntp cannot access the socket which produces the error on the client.


Doing a 
#chmod g+w /var/lib/samba/ntp_signd/socket
resultet in the following on the pdc when w32tm was run on the client:

[pid  9075] 19:09:55 --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid  9075] 19:09:55 rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system 
call)
[pid  9075] 19:09:55 select(23, [16 17 18 19 20 21 22], NULL, NULL, NULL) = 1 
(in [19])
[pid  9075] 19:09:55 recvmsg(19, {msg_name={sa_family=AF_INET, 
sin_port=htons(123), sin_addr=inet_addr("192.168.43.183")}, msg_namelen=28->16, 
msg_iov=[{iov_base="\333\0\21\351\0\0\10\25\0\t\7\205\0\0\0\0\341\324_\21\3169q:\0\0\0\0\0\0\0\0"...,
 iov_len=2120}], msg_iovlen=1, msg_control=[{cmsg_len=32, 
cmsg_level=SOL_SOCKET, cmsg_type=SCM_TIMESTAMPNS, cmsg_data={tv_sec=1579802995, 
tv_nsec=938174583}}], msg_controllen=32, msg_flags=0}, 0) = 68
[pid  9075] 19:09:55 recvmsg(19, {msg_namelen=28}, 0) = -1 EAGAIN (Resource 
temporarily unavailable)
[pid  9075] 19:09:55 socket(AF_UNIX, SOCK_STREAM, 0) = 7
[pid  9075] 19:09:55 connect(7, {sa_family=AF_UNIX, 
sun_path="/var/lib/samba/ntp_signd//socket"}, 110) = 0
[pid  9075] 19:09:55 write(7, "\0\0\0@", 4) = 4
[pid  9075] 19:09:55 write(7, 
"\0\0\0\0\0\0\0\0\1\0\0\0\210\5\0\0\34\3\21\351\0\0\10Z\0\0005\f\271\220\241\252"...,
 64) = 64
[pid  9075] 19:09:55 read(7, "\0\0\0P", 4) = 4
[pid  9075] 19:09:55 read(7, 
"\0\0\0\0\0\0\0\3\0\0\1\0\34\3\21\351\0\0\10Z\0\0005\f\271\220\241\252\341\324_\332"...,
 80) = 80
[pid  9075] 19:09:55 sendto(19, 
"\34\3\21\351\0\0\10Z\0\0005\f\271\220\241\252\341\324_\332X?\336\333\341\324_\363\346I\372\37"...,
 68, 0, {sa_family=AF_INET, sin_port=htons(123), 
sin_addr=inet_addr("192.168.43.183")}, 16) = 68
[pid  9075] 19:09:55 close(7)   = 0

Now ntp can access the socket and the client gets the new time.  But this is 
only a temporary fix.
When samba is restarted it sets the permissions on
/var/lib/samba/ntp_signd/socket back to the ones found below.

This appears to be not the intended behavior since clients in a domain
should be able to query the pdc for time.

Cheers Jens


#ll /var/lib/samba/
...
drwxr-x---+  2 root ntp 4096 Jan 23 19:20 ntp_signd
...

#ll /var/lib/samba/ntp_signd
srwxr-xr-x 1 root root 0 Jan 23 19:20 socket


#getent group | grep ntp
ntp:x:120:ntp


== ntp.conf ==
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile   /var/lib/ntp/ntp.drift
logfile /var/log/ntp
ntpsigndsocket  /var/lib/samba/ntp_signd/

# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# Local clock. Note that is not the "localhost" address!
server 127.127.1.0
fudge  127.127.1.0 stratum 10

# Where to retrieve the time from
server 0.pool.ntp.org iburst prefer
server 1.pool.ntp.org iburst prefer
server 2.pool.ntp.org iburst prefer

# Access control
# Default restriction: Allow clients only to query the time
restrict default kod nomodify notrap nopeer mssntp

# No restrictions for "localhost"
restrict 127.0.0.1

# Enable the time sources

Bug#949696: (build)-dependency on python3-importlib-metadata missing

[Matthias Klose]

Package: src:python-jsonschema
Version: 3.0.2-4
Severity: serious
Tags: sid bullseye

For python 3.7, the package still needs to (build)-depend on
python3-importlib-metadata, see jsonschema/__init__.py

Bug#949695: thunderbird does not start anymore

[Patrick Matthäi]

Source: thunderbird
Version: 1:68.4.1-1+b1
Severity: serious

Hey,

one of the last days testing and or unstable updates let thunderbird stop 
starting.
I just get:

$ thunderbird
ExceptionHandler::GenerateDump cloned child 3482
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
me@gnu:~$ Exception ignored in: <_io.TextIOWrapper name='' mode='w' 
encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

Also with a new profile, also with the version from testing and unstable. So I 
think some dependecie
crashes thunderbird

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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