date:20210115

Control: reassign -1 debian-installer

On Vi, 15 ian 21, 22:56:45, Dave Dyer wrote:
> package: installer
> 
> debian-10.7.0-i386-netinst.iso
> 
> This installation was attempted on an old x86 laptop, for which 
> the native wifi is non-functional without "non free" drivers. I
> worked around the wifi problem by using a usb wifi dongle, which
> configures and works correctly for the first part of the installation.
> 
> However, at the point where "choose a mirror" is supposed to happen,
> all mirrors appear to be invalid.
> 
> From a shell, I determined that the network has lost its gateway
> and dns service.
> 
> My guess is that some network reset operation has happened, as
> part of the normal installation process, and in the process
> the nonfunctional native network hardware was selected instead of 
> the usb network.
> 
> in any case, from this point it's possible to continue and 
> finish with a very minimal command line installation with
> no network.

Reassigning to correct package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#980209: installation fails at the "install boot loader" phase

Control: reassign -1 debian-installer

On Vi, 15 ian 21, 22:38:12, Dave Dyer wrote:
> package: installer
> 
> installing debian-live-10.7.0-i386-kde+nonfree.iso using the live option
> and installing from the booted memory stick.
> 
> On an old x86 notebook, installation fails with an informative message, 
> 
> "bootloader-config failed, package grub-efi-amd64 is not available."
> 
> this looks like a goof related to the fact that this is a 32bit machine, but
> whatever - what do I do about it?  The whole install process is automated,
> except for partioning the disk.  The system is non-bootable, and even
> if booted through some other magic, the file is still in some transitional
> state.
> 
> Here's the result of booting the current live cd, and running the install 
> item from the
> desktop. Note that no network is set up at any point up to this message. Also
> note this is on an old x32 laptop.
> 
> https://drive.google.com/file/d/1WtuRoJ
>  ... sp=sharing
> 
> and as you can see here, the file system is in some intermediate loading state
> and there's no grub-install in the path and no apparent advice about what to
> do next.
> 
> https://drive.google.com/file/d/1HfPUt7
>  ... sp=sharing 
> 

Reassigning to correct package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#980205: installation missing "non free" drivers.

Control: reassign -1 debian-installer

Hello,

The installer including firmware is probably easier to use if firmware 
is needed during the install.

On Vi, 15 ian 21, 20:04:44, Dave Dyer wrote:
> package: installer
> 
> Installing on an old x86 cpu which requires "non free" drivers, the
> installer correctly quotes the needed driver's name.  Bravo. but...
> 
> 1) it suggests adding removable media, which is basically impossible
> in the context of the installer running from a memory stick
> 
> 2) it doesn't tell you in what path on the media to place the driver.
> I still don't know what path would be appropriate if I could figure out how
> and where to mount an additional memory stick where it would be seen,
> but if (instead) I go back and insert the file on the installer stick
> memory stick, it apparently has to go in /firmware
> 
> 3) in my particular case, the driver is brcm/brcmfmac43340-sdio.bin, which
> *also* requires a text file, brcm/brcmfmac43340-sdio.txt.  I know this because
> I figured out case 2B and got the installer to accept the .bin; it then
> it mentions the need for the .txt file.  (Again, thanks, it would have
> been impossible to proceed without this key information).  However,
> there's apparently no way to get the installer to accept the .txt
> file in the same way that it finds the .bin.
> 
> 4) a workaround, if you can complete the installation without
> the network working, is to copy both files into /lib/firmware/ and
> magically the network will work.
> 
> --
> 
> This whole process is very user unfriendly - especially for for 
> the case of a novice user (I'm not) trying to install linux for
> the first time.  Rather than trying to put the whole book of 
> possibilities in the installer, how about if such messages were
> accompanied by links pointing to detailed explanations.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#980196: getting information about a failed installation

Control: reassign -1 debian-installer

On Vi, 15 ian 21, 13:22:07, Dave Dyer wrote:
> package: installer
> 
> This applies to the current installer image
> debian-live-10.7.0-i386-cinnamon+nonfree.iso 
> 
> 
> running the current installer I got to "installation failed" 
> and went back to the main installer menu. There were three options
> listed under "save debug logs"
> 
> 1) floppy
> 2) web
> 3) mounted file system
> 
> #1 - gimmie a break. they're extinct.
> 
> #2 - it says a web server was started, but no host is apparent at the
> quoted ip address - which is the one I assigned it earlier in the 
> installation.
> One of the contributing causes to my installation failing was *probably* that 
> the
> native wifi wasn't recognised, and the networking in the installer was 
> nonfunctional.
> 
> #3 - fails with a red screen background using the offered default /mnt 
> -at this point, the file system has been trashed and I have no idea
> what might be a valid file name other than /mnt.  From the shell, /mnt
> is reported as 100% full, so that could account for the failure.
> Later, I discovered that the info was *already* written to /var/logs/.
> That might have been nice to mention.  Or even offer to view them directly.
> 
> 
> --
> 
> one of the choices in the installation menu is "check the integrity of the 
> cdrom"
> nice idea, but this is a stick install, and trying the check anyway just 
> complains
> about the absence of the cdrom.   Elsewhere in the installer, all the 
> verbiage 
> uses "cd" o "cdrom" even though this was a memory stick install, so I had 
> every
> reason to expect that "check integrity" was a reasonable thing to try.
> 
> --
> 
> Generally, the installer is the first point of contact that a newb would have 
> with linux,
> and this interaction is a pretty awful introduction.

Reassigning to correct package.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#980192: ruby-2.7: autopkgtest regression in testing: Errno::ENAMETOOLONG: File name too long

Control: reassign -1 ruby2.7 2.7.2-3

On Vi, 15 ian 21, 21:51:44, Paul Gevers wrote:
> Source: ruby-2.7
> Version: 2.7.2-3
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s),
> 
> With a recent (december 2020) in testing the autopkgtest of your package
> started to fail. I copied some of the output at the bottom of this
> report. Can you please investigate the situation and fix it?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby2.7/9537123/log.gz
> 
> 
> 264) Error:
> TestTempfile#test_open_traversal_dir:
> Errno::ENAMETOOLONG: File name too long @ rb_sysopen -
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/..tmpautopkgtest-lxc.r54r7gkwdowntmpautopkgtest_tmptmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmpd20210109-4115-ihpyim20210109-4115-1l9j1dpfoo
> /usr/lib/ruby/2.7.0/tempfile.rb:129:in `initialize'
> /usr/lib/ruby/2.7.0/tempfile.rb:129:in `open'
> /usr/lib/ruby/2.7.0/tempfile.rb:129:in `block in initialize'
> /usr/lib/ruby/2.7.0/tmpdir.rb:129:in `create'
> /usr/lib/ruby/2.7.0/tempfile.rb:127:in `initialize'
> /usr/lib/ruby/2.7.0/tempfile.rb:287:in `new'
> /usr/lib/ruby/2.7.0/tempfile.rb:287:in `open'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:368:in
> `block in test_open_traversal_dir'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:401:in
> `block in assert_mktmpdir_traversal'
> /usr/lib/ruby/2.7.0/tmpdir.rb:89:in `mktmpdir'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:397:in
> `assert_mktmpdir_traversal'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:367:in
> `test_open_traversal_dir'
> 
> 265) Error:
> TestTmpdir#test_mktmpdir_traversal:
> Errno::ENAMETOOLONG: File name too long @ dir_s_mkdir -
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/..tmpautopkgtest-lxc.r54r7gkwdowntmpautopkgtest_tmptmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmpd20210109-4115-c6vju4foo20210109-4115-o3w6ci
> /usr/lib/ruby/2.7.0/tmpdir.rb:85:in `mkdir'
> /usr/lib/ruby/2.7.0/tmpdir.rb:85:in `block in mktmpdir'
> /usr/lib/ruby/2.7.0/tmpdir.rb:129:in `create'
> /usr/lib/ruby/2.7.0/tmpdir.rb:83:in `mktmpdir'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:68:in
> `block in test_mktmpdir_traversal'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:87:in
> `block in assert_mktmpdir_traversal'
> /usr/lib/ruby/2.7.0/tmpdir.rb:89:in `mktmpdir'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:83:in
> `assert_mktmpdir_traversal'
> 
> /tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:67:in
> `test_mktmpdir_traversal'
> 
> 266) Error:
> TestTmpdir#test_mktmpdir_traversal_array:
> Errno::ENAMETOOLONG: File name too long @ dir_s_mkdir -
>

Bug#980211: libextractor: FTBFS against librpm9 (test failure)

2021-01-15 Thread Graham Inggs

Source: libextractor
Version: 1:1.10-2
Severity: serious
Tags: ftbfs

Hi Maintainer

During a recent rebuild against librpm9, libextractor FTBFS on several
architectures where it built previously [1].

I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=libextractor


===
   libextractor 1.10: src/plugins/test-suite.log
===

# TOTAL: 32
# PASS:  31
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test_rpm
==

FAIL test_rpm (exit status: 141)

Bug#980210: netinstaller installation fails at the "designate mirror" phase

package: installer

debian-10.7.0-i386-netinst.iso

This installation was attempted on an old x86 laptop, for which 
the native wifi is non-functional without "non free" drivers. I
worked around the wifi problem by using a usb wifi dongle, which
configures and works correctly for the first part of the installation.

However, at the point where "choose a mirror" is supposed to happen,
all mirrors appear to be invalid.

>From a shell, I determined that the network has lost its gateway
and dns service.

My guess is that some network reset operation has happened, as
part of the normal installation process, and in the process
the nonfunctional native network hardware was selected instead of 
the usb network.

in any case, from this point it's possible to continue and 
finish with a very minimal command line installation with
no network.

Bug#980209: installation fails at the "install boot loader" phase

package: installer

installing debian-live-10.7.0-i386-kde+nonfree.iso using the live option
and installing from the booted memory stick.

On an old x86 notebook, installation fails with an informative message, 

"bootloader-config failed, package grub-efi-amd64 is not available."

this looks like a goof related to the fact that this is a 32bit machine, but
whatever - what do I do about it?  The whole install process is automated,
except for partioning the disk.  The system is non-bootable, and even
if booted through some other magic, the file is still in some transitional
state.

Here's the result of booting the current live cd, and running the install item 
from the
desktop. Note that no network is set up at any point up to this message. Also
note this is on an old x32 laptop.

https://drive.google.com/file/d/1WtuRoJ
 ... sp=sharing

and as you can see here, the file system is in some intermediate loading state
and there's no grub-install in the path and no apparent advice about what to
do next.

https://drive.google.com/file/d/1HfPUt7
 ... sp=sharing

Bug#957577: nast: ftbfs with GCC-10

2021-01-15 Thread Logan Rosen

Package: nast
Version: 0.2.0-7
Followup-For: Bug #957577
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10: Fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru nast-0.2.0/debian/patches/gcc-10 nast-0.2.0/debian/patches/gcc-10
--- nast-0.2.0/debian/patches/gcc-101969-12-31 19:00:00.0 -0500
+++ nast-0.2.0/debian/patches/gcc-102021-01-15 23:30:25.0 -0500
@@ -0,0 +1,327 @@
+--- a/include/nast.h
 b/include/nast.h
+@@ -95,32 +95,32 @@
+ void init_scr(void);
+ 
+ /* variable */
+-FILE *logd;
+-short offset;
+-int npkt;
+-u_char *packet;
+-u_char *buf;
+-struct pcap_pkthdr hdr;
+-pcap_t* descr;
+-pcap_dumper_t *dumper;
+-struct pcap_stat statistic;
+-bpf_u_int32 maskp;  /* subnet mask   */
+-bpf_u_int32 netp; /* ip*/
+-int datalink;
+-struct bpf_program fp;  /* hold compiled program */
+-char *logname;
+-char *tcpdl;
+-u_short tr,tl;
+-u_short graph;  /* global var for ncurses mode */
+-u_short cont;
++extern FILE *logd;
++extern short offset;
++extern int npkt;
++extern u_char *packet;
++extern u_char *buf;
++extern struct pcap_pkthdr hdr;
++extern pcap_t* descr;
++extern pcap_dumper_t *dumper;
++extern struct pcap_stat statistic;
++extern bpf_u_int32 maskp;  /* subnet mask   */
++extern bpf_u_int32 netp;  /* ip*/
++extern int datalink;
++extern struct bpf_program fp;  /* hold compiled program */
++extern char *logname;
++extern char *tcpdl;
++extern u_short tr,tl;
++extern u_short graph;  /* global var for ncurses mode */
++extern u_short cont;
+ /* golbal var*/
+-int stream_glob;
+-int bc_glob;
+-int sniff_glob;
+-int rst_glob;
+-int arp_glob;
+-pthread_t pt[2];
+-int lg;
++extern int stream_glob;
++extern int bc_glob;
++extern int sniff_glob;
++extern int rst_glob;
++extern int arp_glob;
++extern pthread_t pt[2];
++extern int lg;
+ 
+ struct host
+ {
+@@ -129,13 +129,13 @@
+ };
+ 
+ /* time variable */
+-time_t tm;
+-char timed[60];
++extern time_t tm;
++extern char timed[60];
+ 
+ /* for demonize nast */
+-u_short demonize;
++extern u_short demonize;
+ 
+-int line_s;
+-int row_s;
++extern int line_s;
++extern int row_s;
+ 
+ 
+--- a/main.c
 b/main.c
+@@ -26,6 +26,43 @@
+ # include "missing/getopt.h"
+ #endif
+ 
++/* variable */
++FILE *logd;
++short offset;
++int npkt;
++u_char *packet;
++u_char *buf;
++struct pcap_pkthdr hdr;
++pcap_t* descr;
++struct pcap_stat statistic;
++bpf_u_int32 maskp;  /* subnet mask   */
++bpf_u_int32 netp; /* ip*/
++int datalink;
++struct bpf_program fp;  /* hold compiled program */
++char *logname;
++char *tcpdl;
++u_short tr,tl;
++u_short graph;  /* global var for ncurses mode */
++u_short cont;
++/* golbal var*/
++int stream_glob;
++int bc_glob;
++int sniff_glob;
++int rst_glob;
++int arp_glob;
++pthread_t pt[2];
++int lg;
++
++/* time variable */
++time_t tm;
++char timed[60];
++
++/* for demonize nast */
++u_short demonize;
++
++int line_s;
++int row_s;
++
+ void usage(char *name);
+ 
+ int main(int argc,char **argv)
+--- a/ncurses/n_nast.c
 b/ncurses/n_nast.c
+@@ -21,6 +21,48 @@
+ 
+ #ifdef HAVE_LIBNCURSES
+ 
++WINDOW *query;
++WINDOW *werror;
++WINDOW *help;
++N_SCROLLWIN *princ;
++N_SCROLLWIN *winfo;
++N_SCROLLWIN *wstream;
++N_SCROLLWIN *wconn;
++
++MENU *my_nmenu;
++ITEM *curr_item;
++WINDOW *my_nmenu_win;
++WINDOW *pop_up;
++
++u_short mvar;
++u_short promisc,hex,ascii,ld,f,lr,l;
++u_short flg;
++int linm;
++int fileds;
++char dev[10];
++char n_filter[60];
++char ldfile[50];
++char tcpdfile[50];
++char reportl[50];
++char logfile[50];
++/*descriptor for stream*/
++pcap_t* str;
++pcap_dumper_t *dumper;
++
++/* thread for database connections */
++pthread_t thID[7];
++
++struct thread_conn th_data[1];
++struct thread_conn_rst th_r_data[1];
++struct thread_arp th_arp_data[1];
++
++struct connections c_inf[30];
++
++struct cnn sf[30];
++
++/* num max of db connections */
++int nmax;
++
+ void init_curs(void);
+ void title(void);
+ int get_info(void);
+--- a/ncurses/n_nast.h
 b/ncurses/n_nast.h
+@@ -84,36 +84,36 @@
+ int shutdown_thread(void);
+ void help_win(void);
+ 
+-WINDOW *query;
+-WINDOW *werror;
+-WINDOW *help;
+-N_SCROLLWIN *princ;
+-N_SCROLLWIN *winfo;
+-N_SCROLLWIN *wstream;
+-N_SCROLLWIN *wconn;
+-
+-MENU *my_nmenu;
+-ITEM *curr_item;
+-WINDOW *my_nmenu_win;
+-WINDOW *pop_up;
+-
+-u_short mvar;
+-u_short promisc,hex,ascii,ld,f,lr,l;
+-u_short flg;
+-int linm;
+-int fileds;
+-char dev[10];
+-char n_filter[60];
+-char ldfile[50];
+-char tcpdfile[50];
+-char reportl[50];
+-char logfile[50];
++extern WINDOW *query;
++extern WINDOW *werror;
++extern WINDOW *help;
++extern N_SCROLLWIN *princ;
++extern N_SCROLLWIN *winfo;
++extern N_SCROLLWIN *wstream;

Bug#972573: RFP: crowdsec -- lightweight agent to detect and respond to bad behaviours. It also automatically benefits from our global community-wide IP reputation database

2021-01-15 Thread Cyril Brulebois

Hi anarcat,

And thanks for the swift answer.

Antoine Beaupré  (2021-01-14):
> I guess that if it's made clear in the package description, it's fair
> to phone home by default. After all, you could argue you opt in by
> installing the package, and can still opt out.

Yeah, I've tried to make that pretty obvious. Since it doesn't seem
entirely out of line, I think I'll go with this approach.

> Or it could be split into a separate binary package which would
> explicitly act as an opt-in?

I think I'd rather avoid having to handle different binaries to
distinguish between those two modes.

Upstream already has a wizard to detect various services and perform
some configuration accordingly. I haven't dived into it yet, but it
could be a nice basis for some debconf prompt(s), so that one can
dpkg-reconfigure at will for both the “which mode do you want to be
in?” and the “which services do you want to handle?” aspects.

We will likely make progress on further integration next week. If we
indeed rely on debconf, that would also mean that people wanting to
install crowdsec in some automated/non-interactive fashion could just
preseed some setting to make sure the right mode is picked from the
get-go. (No pun intended, they just write themselves…)


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#980208: /usr/lib/ispell/british.aff: No such string character

2021-01-15 Thread Paul Wise

Package: ibritish
Version: 3.4.02-1
Severity: normal
File: /usr/lib/ispell/british.aff
Usertags: warnings

When upgrading ibritish I get the following warnings:

   Preparing to unpack .../ibritish_3.4.02-1_all.deb ...
   Unpacking ibritish (3.4.02-1) over (3.4.00-8) ...
   Preparing to unpack .../ienglish-common_3.4.02-1_all.deb ...
   Unpacking ienglish-common (3.4.02-1) over (3.4.00-8) ...
   Setting up ienglish-common (3.4.02-1) ...
   Setting up ibritish (3.4.02-1) ...
   Processing triggers for dictionaries-common (1.28.3) ...
   ispell-autobuildhash: Processing 'british' dict.
   /usr/lib/ispell/british.aff line 191: No such string character
   /usr/lib/ispell/british.aff line 203: No such string character
   /usr/lib/ispell/british.aff line 229: No such string character
   /usr/lib/ispell/british.aff line 267: No such string character
   /usr/lib/ispell/british.aff line 324: No such string character
   /usr/lib/ispell/british.aff line 324: No such string character
   /usr/lib/ispell/british.aff line 326: No such string character
   /usr/lib/ispell/british.aff line 326: No such string character
   /usr/lib/ispell/british.aff line 330: No such string character
   /usr/lib/ispell/british.aff line 330: No such string character
   /usr/lib/ispell/british.aff line 339: No such string character
   /usr/lib/ispell/british.aff line 339: No such string character
   /usr/lib/ispell/british.aff line 341: No such string character
   /usr/lib/ispell/british.aff line 341: No such string character
   /usr/lib/ispell/british.aff line 343: No such string character
   /usr/lib/ispell/british.aff line 343: No such string character
   /usr/lib/ispell/british.aff line 345: No such string character
   /usr/lib/ispell/british.aff line 345: No such string character
   /usr/lib/ispell/british.aff line 347: No such string character
   /usr/lib/ispell/british.aff line 347: No such string character
   /usr/lib/ispell/british.aff line 349: No such string character
   /usr/lib/ispell/british.aff line 349: No such string character
   /usr/lib/ispell/british.aff line 351: No such string character
   /usr/lib/ispell/british.aff line 351: No such string character
   /usr/lib/ispell/british.aff line 353: No such string character
   /usr/lib/ispell/british.aff line 353: No such string character
   /usr/lib/ispell/british.aff line 355: No such string character
   /usr/lib/ispell/british.aff line 355: No such string character
   /usr/lib/ispell/british.aff line 357: No such string character
   /usr/lib/ispell/british.aff line 357: No such string character
   /usr/lib/ispell/british.aff line 359: No such string character
   /usr/lib/ispell/british.aff line 359: No such string character
   /usr/lib/ispell/british.aff line 361: No such string character
   /usr/lib/ispell/british.aff line 361: No such string character
   /usr/lib/ispell/british.aff line 363: No such string character
   /usr/lib/ispell/british.aff line 363: No such string character
   /usr/lib/ispell/british.aff line 365: No such string character
   /usr/lib/ispell/british.aff line 365: No such string character
   /usr/lib/ispell/british.aff line 367: No such string character
   /usr/lib/ispell/british.aff line 367: No such string character
   /usr/lib/ispell/british.aff line 369: No such string character
   /usr/lib/ispell/british.aff line 369: No such string character
   /usr/lib/ispell/british.aff line 373: No such string character
   /usr/lib/ispell/british.aff line 373: No such string character
   /usr/lib/ispell/british.aff line 375: No such string character
   /usr/lib/ispell/british.aff line 375: No such string character
   /usr/lib/ispell/british.aff line 377: No such string character
   /usr/lib/ispell/british.aff line 377: No such string character
   /usr/lib/ispell/british.aff line 379: No such string character
   /usr/lib/ispell/british.aff line 379: No such string character
   /usr/lib/ispell/british.aff line 381: No such string character
   /usr/lib/ispell/british.aff line 381: No such string character
   /usr/lib/ispell/british.aff line 383: No such string character
   /usr/lib/ispell/british.aff line 383: No such string character
   /usr/lib/ispell/british.aff line 385: No such string character
   /usr/lib/ispell/british.aff line 385: No such string character
   /usr/lib/ispell/british.aff line 387: No such string character
   /usr/lib/ispell/british.aff line 387: No such string character
   /usr/lib/ispell/british.aff line 388: No such string character
   /usr/lib/ispell/british.aff line 390: No such string character
   /usr/lib/ispell/british.aff line 390: No such string character
   /usr/lib/ispell/british.aff line 392: No such string character
   /usr/lib/ispell/british.aff line 392: No such string character
   /usr/lib/ispell/british.aff line 394: No such string character
   /usr/lib/ispell/british.aff line 394: No such string character
   /usr/lib/ispell/british.aff line 396: No such string character
   /usr/lib/ispell/british.aff line 396: No such

Bug#980207: /usr/lib/ispell/american.aff: No such string character

2021-01-15 Thread Paul Wise

Package: iamerican
Version: 3.4.02-1
Severity: normal
File: /usr/lib/ispell/american.aff
Usertags: warnings

When upgrading iamerican I get the following warnings:

   ...
   Preparing to unpack .../iamerican_3.4.02-1_all.deb ...
   Unpacking iamerican (3.4.02-1) over (3.4.00-8) ...
   Preparing to unpack .../ienglish-common_3.4.02-1_all.deb ...
   Unpacking ienglish-common (3.4.02-1) over (3.4.00-8) ...
   Setting up ienglish-common (3.4.02-1) ...
   Setting up iamerican (3.4.02-1) ...
   Processing triggers for dictionaries-common (1.28.3) ...
   ispell-autobuildhash: Processing 'american' dict.
   /usr/lib/ispell/american.aff line 191: No such string character
   /usr/lib/ispell/american.aff line 203: No such string character
   /usr/lib/ispell/american.aff line 229: No such string character
   /usr/lib/ispell/american.aff line 267: No such string character
   /usr/lib/ispell/american.aff line 324: No such string character
   /usr/lib/ispell/american.aff line 324: No such string character
   /usr/lib/ispell/american.aff line 326: No such string character
   /usr/lib/ispell/american.aff line 326: No such string character
   /usr/lib/ispell/american.aff line 330: No such string character
   /usr/lib/ispell/american.aff line 330: No such string character
   /usr/lib/ispell/american.aff line 339: No such string character
   /usr/lib/ispell/american.aff line 339: No such string character
   /usr/lib/ispell/american.aff line 341: No such string character
   /usr/lib/ispell/american.aff line 341: No such string character
   /usr/lib/ispell/american.aff line 343: No such string character
   /usr/lib/ispell/american.aff line 343: No such string character
   /usr/lib/ispell/american.aff line 345: No such string character
   /usr/lib/ispell/american.aff line 345: No such string character
   /usr/lib/ispell/american.aff line 347: No such string character
   /usr/lib/ispell/american.aff line 347: No such string character
   /usr/lib/ispell/american.aff line 349: No such string character
   /usr/lib/ispell/american.aff line 349: No such string character
   /usr/lib/ispell/american.aff line 351: No such string character
   /usr/lib/ispell/american.aff line 351: No such string character
   /usr/lib/ispell/american.aff line 353: No such string character
   /usr/lib/ispell/american.aff line 353: No such string character
   /usr/lib/ispell/american.aff line 355: No such string character
   /usr/lib/ispell/american.aff line 355: No such string character
   /usr/lib/ispell/american.aff line 357: No such string character
   /usr/lib/ispell/american.aff line 357: No such string character
   /usr/lib/ispell/american.aff line 359: No such string character
   /usr/lib/ispell/american.aff line 359: No such string character
   /usr/lib/ispell/american.aff line 361: No such string character
   /usr/lib/ispell/american.aff line 361: No such string character
   /usr/lib/ispell/american.aff line 363: No such string character
   /usr/lib/ispell/american.aff line 363: No such string character
   /usr/lib/ispell/american.aff line 365: No such string character
   /usr/lib/ispell/american.aff line 365: No such string character
   /usr/lib/ispell/american.aff line 367: No such string character
   /usr/lib/ispell/american.aff line 367: No such string character
   /usr/lib/ispell/american.aff line 369: No such string character
   /usr/lib/ispell/american.aff line 369: No such string character
   /usr/lib/ispell/american.aff line 373: No such string character
   /usr/lib/ispell/american.aff line 373: No such string character
   /usr/lib/ispell/american.aff line 375: No such string character
   /usr/lib/ispell/american.aff line 375: No such string character
   /usr/lib/ispell/american.aff line 377: No such string character
   /usr/lib/ispell/american.aff line 377: No such string character
   /usr/lib/ispell/american.aff line 379: No such string character
   /usr/lib/ispell/american.aff line 379: No such string character
   /usr/lib/ispell/american.aff line 381: No such string character
   /usr/lib/ispell/american.aff line 381: No such string character
   /usr/lib/ispell/american.aff line 383: No such string character
   /usr/lib/ispell/american.aff line 383: No such string character
   /usr/lib/ispell/american.aff line 385: No such string character
   /usr/lib/ispell/american.aff line 385: No such string character
   /usr/lib/ispell/american.aff line 387: No such string character
   /usr/lib/ispell/american.aff line 387: No such string character
   /usr/lib/ispell/american.aff line 388: No such string character
   /usr/lib/ispell/american.aff line 390: No such string character
   /usr/lib/ispell/american.aff line 390: No such string character
   /usr/lib/ispell/american.aff line 392: No such string character
   /usr/lib/ispell/american.aff line 392: No such string character
   /usr/lib/ispell/american.aff line 394: No such string character
   /usr/lib/ispell/american.aff line 394: No such string character
   /usr/lib/ispell/american.aff line

Bug#957585: ncurses-hexedit: ftbfs with GCC-10

2021-01-15 Thread Logan Rosen

Package: ncurses-hexedit
Version: 0.9.7+orig-7
Followup-For: Bug #957585
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc_10.patch: Fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru ncurses-hexedit-0.9.7+orig/debian/patches/gcc_10.patch 
ncurses-hexedit-0.9.7+orig/debian/patches/gcc_10.patch
--- ncurses-hexedit-0.9.7+orig/debian/patches/gcc_10.patch  1969-12-31 
19:00:00.0 -0500
+++ ncurses-hexedit-0.9.7+orig/debian/patches/gcc_10.patch  2021-01-15 
23:13:37.0 -0500
@@ -0,0 +1,44 @@
+--- a/src/hexedit.h
 b/src/hexedit.h
+@@ -343,7 +343,7 @@
+ 
+ 
+/* Global structure, keep most global variables here. */
+-struct
++struct Globals_t
+ {
+WINDOW *wmain, *wstatus, *whelp; /* three windows used throughout. */
+unsigned long filesize;  /* size of the file buffer. */
+@@ -365,7 +365,9 @@
+ /* buf end. */
+int beeping; /* Allow beeping or not. */
+int help_msg_count;  /* Number of messages in help menu. */
+-} Globals;
++};
++
++extern struct Globals_t Globals;
+ 
+ 
+ struct foundit
+@@ -400,7 +402,9 @@
+int s;
+struct Change *base;
+struct Change *top;
+-} UndoStack;
++};
++
++extern struct ChangeLog UndoStack;
+ 
+ 
+ struct FileNames
+--- a/src/init.c
 b/src/init.c
+@@ -35,6 +35,8 @@
+ 
+ extern char **environ;
+ 
++struct ChangeLog UndoStack;
++struct Globals_t Globals;
+ 
+/* This is called once at the start of the program.  Handles HEXEDIT
+ * Environment variable, command line arguments, sets up signal
diff -Nru ncurses-hexedit-0.9.7+orig/debian/patches/series 
ncurses-hexedit-0.9.7+orig/debian/patches/series
--- ncurses-hexedit-0.9.7+orig/debian/patches/series2019-01-30 
22:29:46.0 -0500
+++ ncurses-hexedit-0.9.7+orig/debian/patches/series2021-01-15 
23:11:19.0 -0500
@@ -16,3 +16,4 @@
 enforce_readonly_mode.patch
 fix_buffer_overruns.patch
 fix_spelling_errors.patch
+gcc_10.patch

Bug#980206: (LXC: lxc-start fails and cgroup IO error

2021-01-15 Thread shan . bharani

Package: lxc
Version: 1:4.0.5-2


I would like to file a bug for this.

The recent update of packages made lxc malfunction. Unable to start
containers.I have also noted that "Input/ouput Error" in /var/lib/lxcfs
directory. I dont think this is disk IO issue as this can reproduced. I
do have a VM with debian-bullseye-DI-alpha3-amd64-DVD-1.iso. I was able
create a lxc container there and it worked fine. However when I
upgraded to the latest packages I can see the same problem there.

Unable to find the package causing the problem.


Error
==

Output of lxc-start [ --logfile with --logpriority used ]
lxc-start $servername 20210110050338.110 ERROR cgfsng -
cgroups/cgfsng.c:__cgfsng_delegate_controllers:3091 - Device or
resource busy - Could not enable "+memory +pids" controllers in the
unified cgroup
"/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/
app-org.gnome.Terminal.slice/vte-spawn-4a7e535f-f58e-44f0-a6dc-
9f85d15cd939.scope/cgroup.subtree_control"


$user:/var/lib/lxcfs$ ls -ltr
ls: cannot access 'cgroup': Input/output error
total 0
?? ? ? ? ? ? cgroup
dr-xr-xr-x 2 root root 0 Jan 11 10:59 proc
dr-xr-xr-x 2 root root 0 Jan 11 10:59 sys

System Information
==
$uname -a
Linux coffee 5.10.0-1-amd64 #1 SMP Debian 5.10.4-1 (2020-12-31) x86_64
GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux bullseye/sid
Release: testing
Codename: bullseye


$ apt list lxc
Listing... Done
lxc/testing,now 1:4.0.5-2 amd64 [installed]

$apt list liblxc1
Listing... Done
liblxc1/testing,now 1:4.0.5-2 amd64 [installed,automatic]

$apt list lxcfs
Listing... Done
lxcfs/testing,now 4.0.5-1 amd64 [installed]

$apt list libpam-cgfs
Listing... Done
libpam-cgfs/testing,now 1:4.0.5-2 amd64 [installed]

$apt list libpam-systemd 
Listing... Done
libpam-systemd/testing,now 247.2-4 amd64 [installed]


$ lxc-checkconfig
LXC version 4.0.5
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-5.10.0-1-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled

--- Control groups ---
Cgroups: enabled

Cgroup v1 mount points: 


Cgroup v2 mount points: 
/sys/fs/cgroup

Cgroup v1 systemd controller: missing
Cgroup v1 freezer controller: missing
Cgroup namespace: required
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled, not loaded
Macvlan: enabled, not loaded
Vlan: enabled, not loaded
Bridges: enabled, loaded
Advanced netfilter: enabled, loaded
CONFIG_NF_NAT_IPV4: missing
CONFIG_NF_NAT_IPV6: missing
CONFIG_IP_NF_TARGET_MASQUERADE: enabled, not loaded
CONFIG_IP6_NF_TARGET_MASQUERADE: enabled, not loaded
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled, loaded
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, not loaded
FUSE (for use with lxcfs): enabled, loaded

--- Checkpoint/Restore ---
checkpoint restore: enabled
CONFIG_FHANDLE: enabled
CONFIG_EVENTFD: enabled
CONFIG_EPOLL: enabled
CONFIG_UNIX_DIAG: enabled
CONFIG_INET_DIAG: enabled
CONFIG_PACKET_DIAG: enabled
CONFIG_NETLINK_DIAG: enabled
File capabilities: 

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig


Output of the /var/log/apt/history.log
==
Start-Date: 2021-01-08 14:42:15
Commandline: apt upgrade
Install: libbpf0:amd64 (1:0.2-1, automatic), libcapstone4:amd64 (4.0.2-
3, automatic)
@
@
@
Upgrade: libgoa-backend-1.0-1:amd64 (3.38.0-1, 3.38.0-3),
libdeflate0:amd64 (1.6-1, 1.7-1), bluez:amd64 (5.55-1, 5.55-3),
python3-jedi:amd64 (0.17.0-1, 0.18.0-1), libcrack2:amd64 (2.9.6-3.2+b3,
2.9.6-3.4), diffutils:amd64 (1:3.7-3, 1:3.7-5), gir1.2-nm-1.0:amd64
(1.28.0-1, 1.28.0-2), libcups2:amd64 (2.3.3op1-3, 2.3.3op1-4), mobile-
broadband-provider-info:amd64 (20190618-3, 20201225-1), xserver-xorg-
video-amdgpu:amd64 (19.1.0-1, 19.1.0-2), python3-distutils:amd64
(3.8.6-1, 3.9.1-1), libcurl4:amd64 (7.72.0-1, 7.74.0-1), libgtk2.0-
bin:amd64 (2.24.32-5, 2.24.33-1), libdw1:amd64 (0.182-1, 0.182-2),
libgoa-1.0-0b:amd64 (3.38.0-1, 3.38.0-3), cracklib-runtime:amd64
(2.9.6-3.2+b3, 2.9.6-3.4), libcairo-gobject2:amd64 (1.16.0-4, 1.16.0-
5), libjpeg-dev:amd64 (1:2.0.5-1.1, 1:2.0.5-2), libgoa-1.0-common:amd64
(3.38.0-1, 3.38.0-3), libwbclient0:amd64 (2:4.13.2+dfsg-3,
2:4.13.3+dfsg-1), libsystemd0:amd64 (247.1-3+deb11u1, 247.2-4), grub-
common:amd64 (2.04-11, 2.04-12), libpocketsphinx3:amd64
(0.8+5prealpha+1-12, 0.8+5prealpha+1-13), apt:amd64 (2.1.12+deb11u1,
2.1.15), mailcap:amd64 (3.67, 3.68), media-types:amd64 (1.0.1, 1.1.0),
libasound2-data:amd64 (1.2.4-1, 1.2.4-1.1), ipp-usb:amd64 (0.9.14-2,
0.9.16-1), libatkmm-1.6-1v5:amd64 (2.28.0-2, 2.28.0-3), libelf1:amd64
(0.182-1, 0.182-2), python3-urllib3:amd64 (1.25.11-1, 1.26.2-1),

Bug#970210: forcemerge vs. pkgreport.cgi

2021-01-15 Thread Don Armstrong

retitle 970210 repeatmerged=no can't be configured to show a bug other than the 
lowest numbered bug
severity 970210 wishlist
tag 970210 wontfix
thanks

On Sun, 10 Jan 2021, Robert Luberda wrote:
> I agree with Dan. I've just forcemerged 979575 979549 979565, and then
> marked 979575 as affecting a few packages, for example ifrench.
> When I was doing this, I expected 979575 to be the "master" bug, that
> will be displayed in bug pages for both ispell and affected packages. 

forcemerge doesn't do anything but adjust all of the settings that are
required to be equal and then merge the bugs.

The documentation is pretty clear: "Forcibly merges two or more bug
reports. The settings of the first bug listed which must be equal in a
normal merge are assigned to the bugs listed next. To avoid typos
erroneously merging bugs, bugs must be in the same package. "

It doesn't cause a bug to be listed when repeatmerged=no, change the
title, or anything like that.

Hope that clarifies things a bit.

-- 
Don Armstrong  https://www.donarmstrong.com

Science is a way of trying not to fool yourself. The first principle
is that you must not fool yourself, and you are the easiest person to
fool.
 -- Richard Feynman "What is and What Should be the Role of Scientific
Culture in Modern Society"; 1964

Bug#980205: installation missing "non free" drivers.

package: installer

Installing on an old x86 cpu which requires "non free" drivers, the
installer correctly quotes the needed driver's name.  Bravo. but...

1) it suggests adding removable media, which is basically impossible
in the context of the installer running from a memory stick

2) it doesn't tell you in what path on the media to place the driver.
I still don't know what path would be appropriate if I could figure out how
and where to mount an additional memory stick where it would be seen,
but if (instead) I go back and insert the file on the installer stick
memory stick, it apparently has to go in /firmware

3) in my particular case, the driver is brcm/brcmfmac43340-sdio.bin, which
*also* requires a text file, brcm/brcmfmac43340-sdio.txt.  I know this because
I figured out case 2B and got the installer to accept the .bin; it then
it mentions the need for the .txt file.  (Again, thanks, it would have
been impossible to proceed without this key information).  However,
there's apparently no way to get the installer to accept the .txt
file in the same way that it finds the .bin.

4) a workaround, if you can complete the installation without
the network working, is to copy both files into /lib/firmware/ and
magically the network will work.

--

This whole process is very user unfriendly - especially for for 
the case of a novice user (I'm not) trying to install linux for
the first time.  Rather than trying to put the whole book of 
possibilities in the installer, how about if such messages were
accompanied by links pointing to detailed explanations.

Bug#957596: netdiag: ftbfs with GCC-10

2021-01-15 Thread Logan Rosen

Package: netdiag
Version: 1.2-1
Followup-For: Bug #957596
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/p/gcc-10.diff: Fix FTBFS with GCC 10.
  * d/p/pcap_init.diff: Rename pcap_init() to traf_pcap_init() to avoid
conflict with libpcap.

Thanks for considering the patch.

Logan
diff -u netdiag-1.2/debian/patches/series netdiag-1.2/debian/patches/series
--- netdiag-1.2/debian/patches/series
+++ netdiag-1.2/debian/patches/series
@@ -6,3 +6,5 @@
 adapt_netload_to_bsd.diff
 adaption_to_kfreebsd.diff 
 clang-ftbfs.diff
+gcc-10.diff
+pcap_init.diff
only in patch2:
unchanged:
--- netdiag-1.2.orig/debian/patches/gcc-10.diff
+++ netdiag-1.2/debian/patches/gcc-10.diff
@@ -0,0 +1,39 @@
+--- a/netwatch-1.3.1-2/netwatch.c
 b/netwatch-1.3.1-2/netwatch.c
+@@ -151,6 +151,10 @@
+ #include "netresolv.h"
+ #include "netwatch.h"
+ 
++struct port_info *tcp_port_types[TCPHASH];
++
++struct port_info *udp_port_types[UDPHASH];
++
+ extern int errno;
+ 
+ #define MAXFILENAME 256
+--- a/netwatch-1.3.1-2/netwatch.h
 b/netwatch-1.3.1-2/netwatch.h
+@@ -209,10 +209,10 @@
+ };
+ 
+ #define TCPHASH 1786
+-struct port_info *tcp_port_types[TCPHASH];
++EXTERN_DEF struct port_info *tcp_port_types[TCPHASH];
+ 
+ #define UDPHASH 1786
+-struct port_info *udp_port_types[UDPHASH];
++EXTERN_DEF struct port_info *udp_port_types[UDPHASH];
+ 
+ int hashport( int port, int hash);
+ void initlist(struct port_info *first[], int hash);
+--- a/netwatch-1.3.1-2/dispdata.c
 b/netwatch-1.3.1-2/dispdata.c
+@@ -178,7 +178,7 @@
+ extern int simchange;
+ extern int simfwdir;
+ extern int simarr[8];
+-char *simfmt;
++extern char *simfmt;
+ extern int iseth;
+ extern int nw_logall;
+ extern char nw_allname[256];
only in patch2:
unchanged:
--- netdiag-1.2.orig/debian/patches/pcap_init.diff
+++ netdiag-1.2/debian/patches/pcap_init.diff
@@ -0,0 +1,29 @@
+--- a/trafshow-5.2.3/trafshow.c
 b/trafshow-5.2.3/trafshow.c
+@@ -58,7 +58,7 @@
+ static void vers();
+ static void usage();
+ static pcap_if_t *pcap_matchdev(pcap_if_t *dp, const char *name);
+-static int pcap_init(PCAP_HANDLER **ph_list, pcap_if_t *dp);
++static int traf_pcap_init(PCAP_HANDLER **ph_list, pcap_if_t *dp);
+ static void *pcap_feed(void *arg); /* PCAP_HANDLER *ph */
+ #ifdefHAVE_PCAP_GET_SELECTABLE_FD
+ static void *pcap_feed2(void *arg); /* PCAP_HANDLER *ph */
+@@ -172,7 +172,7 @@
+   }
+ 
+   /* initialize list of pcap handlers */
+-  if ((op = pcap_init(_list, dev_list)) < 1) {
++  if ((op = traf_pcap_init(_list, dev_list)) < 1) {
+   fprintf(stderr, "No packet capture device available (no 
permission?)\n");
+   exit(1);
+   }
+@@ -301,7 +301,7 @@
+ }
+ 
+ static int
+-pcap_init(ph_list, dp)
++traf_pcap_init(ph_list, dp)
+   PCAP_HANDLER **ph_list;
+   pcap_if_t *dp;
+ {

Bug#977081: fixed in pytest-rerunfailures 9.1.1-1

2021-01-15 Thread Paul Wise

On Mon, 04 Jan 2021 04:49:07 + Paul Wise wrote:

>* New upstream release.
>  - Increases pytest requirement to 5.0
>  - Fixes FTBFS with pytest 6 (Closes: #977081)

This hasn't migrated yet because of the pytest transition.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#976192: ncal: incorrect week numbers for 2021

2021-01-15 Thread Kate

Hi again,

I have a patch: 
https://github.com/kit-ty-kate/bsdmainutils/commit/d7c1e6309c41f3d0e9d0350acc55488ba4e979b0

$ ./usr.bin/ncal/ncal -Mbw 01 2020
  January 2020
 w| Mo Tu We Th Fr Sa Su
 1|1  2  3  4  5
 2|  6  7  8  9 10 11 12
 3| 13 14 15 16 17 18 19
 4| 20 21 22 23 24 25 26
 5| 27 28 29 30 31

$ ./usr.bin/ncal/ncal -Mbw 12 2020
  December 2020
 w| Mo Tu We Th Fr Sa Su
49| 1  2  3  4  5  6
50|  7  8  9 10 11 12 13
51| 14 15 16 17 18 19 20
52| 21 22 23 24 25 26 27
53| 28 29 30 31

$ ./usr.bin/ncal/ncal -Mbw 01 2021
  January 2021
 w| Mo Tu We Th Fr Sa Su
53|  1  2  3
 1|  4  5  6  7  8  9 10
 2| 11 12 13 14 15 16 17
 3| 18 19 20 21 22 23 24
 4| 25 26 27 28 29 30 31


Do I need to submit the patch on 
https://bugs.launchpad.net/ubuntu/+source/bsdmainutils or is there already 
someone with the rights on the upstream repo in the debian maintainers 
subscribed to this bugreport?

Cheers,
Kate

Bug#980204: gdc: Resulting executables segfault on mipsel architecture (signal 11)

2021-01-15 Thread Matija Nalis

Package: gdc
Version: 4:10.2.1-1
Severity: normal
X-Debbugs-Cc: mnalis-debian...@voyager.hr

Dear Maintainer,

compiling D programs with gdc produces excutable, but trying to run that 
executable segfaults.
I've tried various gdc flags, but never managed to produce even the simplest 
working program.

on Debian Sid in chroot:

(mipsel-chroot)$ printf 'import std.stdio;\nvoid main()  { writeln("Hello, 
World!"); }\n' > hello.d ; gdc  hello.d && ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

This is with host running Buster with qemu-user 1:5.2+dfsg-3~bpo10+1
but the other not-too-complicated D programs fail on Debian buildd 
infrastructure too:
https://buildd.debian.org/status/fetch.php?pkg=ironseed=mipsel=0.3.6-4=1610676343=0


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: mipsel (mips)

Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages gdc depends on:
ii  gdc-10  10.2.1-6
ii  libgphobos-dev  10.2.1-1

gdc recommends no packages.

gdc suggests no packages.

-- no debconf information

Bug#980095: Security issue fixed in 6.20.11

2021-01-15 Thread Robin Gustafsson

Hi David,

On Thu, Jan 14, 2021 at 2:03 PM David Prévot  wrote:
> Upstream just released a security fix [1]

Thanks for bringing this to my attention.

> Feel free to ping me when you have something ready if you need a
> sponsor, or earlier you need help for this update.

I've prepared version 6.20.11. I'd happily take you up on the offer of
sponsorship. The new version is on Salsa [1] and mentors.debian.net
[2].

[1] https://salsa.debian.org/php-team/pear/php-laravel-framework/
[2] https://mentors.debian.net/package/php-laravel-framework/

Bug#978353: serf: FTBFS: test_ssl_handshake fails with OpenSSL 1.1.1i

2021-01-15 Thread James McCoy

On Fri, Jan 15, 2021 at 08:36:22AM -0500, Justin Erenkrantz wrote:
> Sadly, my Debian sid box ran into other issues and is currently inaccessible.
> 
> I *think* that this would address the 1.3.x test issues, but 1.3.x doesn't
> build on Mac OS for me for other reasons...so, let me know how it goes?  =)  
> --

Success!

Thanks,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#980193: [Pkg-rust-maintainers] Bug#980193: rust-flate2: autopkgtest regression in testing: [librust-flate2-dev] build failed

2021-01-15 Thread peter green


This test has never passed, it failed back in December 2019, then was
neutral for some time, before returning to failure recently/

Unfortunately debci doesn't keep logs long-term, but I suspect that
the test was neutral due to unsatisfiable test dependencies.

The first error in the log is


[crossbeam-utils 0.7.2] error[E0412]: cannot find type `AtomicU128` in module 
`core::sync::atomic`
[crossbeam-utils 0.7.2] --> :1:38
[crossbeam-utils 0.7.2]  |
[crossbeam-utils 0.7.2] 1|   pub type Probe = 
core::sync::atomic::AtomicU128;
[crossbeam-utils 0.7.2]  |
^^ help: a struct with a similar name exists: `AtomicU16`
[crossbeam-utils 0.7.2] 
[crossbeam-utils 0.7.2] error: aborting due to previous error
[crossbeam-utils 0.7.2] 
[crossbeam-utils 0.7.2] For more information about this error, try `rustc --explain E0412`.


But after some googling I belive this is a false positive.

The real errors seem to start at.


error[E0433]: failed to resolve: use of undeclared crate or module `miniz_oxide`
 --> src/ffi/rust.rs:6:5
  |
6 | use miniz_oxide::deflate::core::CompressorOxide;
  | ^^^ use of undeclared crate or module `miniz_oxide`


I suspect this is a case of a crate that is simply not buildable
in a plain no-default-features configuration.

Bug#980161: Acknowledgement (tex-common fails to update to 6.15 - fmtutil failed)

2021-01-15 Thread Rann Bar-On

So that worked, and then completing the install from apt-get worked as 
well. So I suppose this can be closed, but I have no idea why this happened.



On 1/15/21 8:29 PM, Norbert Preining wrote:

Hmmm interesting.

Can you run
   sudo fmtutil-sys -all
? Does that give the same error again, i.e., is this reproducible?

Best

Norbert


--
--
Rann Bar-On
he/him/his

Bug#980203: linux-image-5.10.0-1-686:i386 ipw2200 returns bogus MAC address. Security implications????

2021-01-15 Thread Charles Curley

Package: src:linux
Version: 5.10.4-1
Severity: normal
X-Debbugs-Cc: charlescur...@charlescurley.com

Dear Maintainer,

   * What led up to the situation?

Testing the Bullseye installer lead to several installations on this
computer, an IBM R51 Thinkpad, which uses the IPW2200 kernel module and
associated firmware blob. The firmware blob is in package
firmware-ipw2x00 20201118-1.

On boot, NetworkManager does its thing correctly, and gets the machine
on the network. However, I use DHCP with fixed addresses. Getting the
wrong MAC address throws this off, which is how the problem came to my
attention. This is an intermittent problem. Not every boot results in
the wrong MAC address.

Work-around: run

rmmod ipw2200 ; sleep 2 ; modprobe ipw2200

This immediately produces the correct MAC address, and DHCP assigns the
correct IP address. Several iterations of this all resulted in the
correct MAC address.

This problem has apparently been around for a while.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893283

-- Package-specific info:
** Version:
Linux version 5.10.0-1-686 (debian-ker...@lists.debian.org) (gcc-10
(Debian 10.2.1-3) 10.2.1 20201224, GNU ld (GNU Binutils for Debian)
2.35.1) #1 SMP Debian 5.10.4-1 (2020-12-31)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-1-686
root=/dev/mapper/dragon2020vg-dragon2020root ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

The kernel reports an occasional firmware error, and transparently
restarts it. None of those messages are associated with booting.

I see the following in syslog:

Jan 15 16:15:45 dragon kernel: [278773.780936] wlp2s2: Setting MAC to
8a:f5:74:20:7c:9e Jan 15 16:15:45 dragon kernel: [278774.145493]
wlp2s2: Setting MAC to 00:13:ce:70:53:c8

Those shortly after the most recent reboot, about the time I tried the
rmmod command above.

** Model information

** Loaded modules:
ipw2200
ctr
ccm
lib80211_crypt_ccmp
uas
usb_storage
iTCO_wdt
intel_pmc_bxt
iTCO_vendor_support
ppdev
watchdog
snd_intel8x0m
snd_intel8x0
libipw
pcmcia
lib80211
snd_ac97_codec
cfg80211
pcspkr
ac97_bus
joydev
sr_mod
snd_pcm
cdrom
snd_timer
i2c_i801
yenta_socket
e100
pcmcia_rsrc
i2c_smbus
sg
pcmcia_core
mii
thinkpad_acpi
nvram
ledtrig_audio
snd
soundcore
rfkill
uhci_hcd
ehci_pci
ehci_hcd
lpc_ich
parport_pc
video
battery
usbcore
ac
parport
usb_common
rng_core
button
acpi_cpufreq
fuse
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
ecb
aes_generic
libaes
xts
dm_crypt
dm_mod
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
ata_generic
radeon
i2c_algo_bit
drm_kms_helper
syscopyarea
sysfillrect
sysimgblt
fb_sys_fops
cec
ata_piix
ttm
libata
drm
scsi_mod
psmouse
evdev
serio_raw

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback


** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp2s8:  mtu 1500 qdisc
pfifo_fast state DOWN group default qlen 1000 link/ether
00:10:c6:c0:aa:26 brd ff:ff:ff:ff:ff:ff 4: wlp2s2:
 mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000 link/ether 00:13:ce:70:53:c8 brd
ff:ff:ff:ff:ff:ff inet 192.168.100.4/24 brd 192.168.100.255 scope
global dynamic noprefixroute wlp2s2 valid_lft 84663sec preferred_lft
84663sec inet6 fe80::185f:8122:4ddc:e185/64 scope link noprefixroute
valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|
Transmit face |bytespackets errs drop fifo frame compressed
multicast|bytespackets errs drop fifo colls carrier compressed lo:
1017531260000 0  0 0   101753
1260000 0   0  0 enp2s8:   0   0
000 0  0 00   000
0 0   0  0 wlp2s2: 13898021980230
0  0 0   2484931580000 0
0  0

*** Protocol statistics:
Ip:
Forwarding: 2
3079 total packets received
6 with invalid addresses
0 forwarded
0 incoming packets discarded
2925 incoming packets delivered
2752 requests sent out
302 outgoing packets dropped
Icmp:
617 ICMP messages received
0 input ICMP message failed
ICMP input histogram:
destination unreachable: 612
echo replies: 5
618 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 613
echo requests: 5
IcmpMsg:
InType0: 5
InType3: 612
OutType3: 613
OutType8: 5
Tcp:
42 active connection openings
0 passive connection openings
8 failed connection attempts

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-15 Thread Gunnar Wolf

Matthew Vernon dijo [Mon, Jan 11, 2021 at 09:07:03PM +]:
> > If you intend the scope of this bug to involve overruling maintainers'
> > decisions in packages other than NM, what other packages/bugs did you
> > have in mind? Is it just udisks2/#923387, or are there more?
> 
> I understand (but I don't think it has been explicitly stated) that the TC
> is going to decline to overrule on the question of init scripts?[0] I'm
> going to beg that question for the rest of this mail, but obviously if I'm
> wrong that will increase the scope somewhat.

I cannot say we will always decline to overrule. But -talking just for
myself, not for the whole TC- overruling a maintainer on
_anything_ is something that I really really really prefer not to
do. I understand the TC is summoned often as a last-resort decision
making body. But forcing a maintainer to do something they are against
in their own package is too harsh -- And demotivating. A maintainer
forced to go against their best decision on an a matter important to
them (otherwise the issue would not get to the TC) is very much more
likely to lose interest in keeping up the maintenance, or even their
participation in the project. 

> Please overrule the maintainer in #923387 so that it is can be used on
> systems with elogind; it has been tested and shown to work thus as well as
> being supported by upstream[1].

As it was mentioned on a previous mail to this thread, this discussion
on including an elogind dependency was done WRT network-manager. An
agreeable solution was brought forward by the maintainer. #923387
(udisks2) was just mentioned in this discussion. Maybe an amicable
solution can be tried before asking the TC outright to overrule the
maintainer?

> Mark tells us that there are not currently any other packages which could be
> used with elogind were it not for an incorrect dependency on libpam-systemd,
> so I hope we don't need to worry about the broader question any further.

Given the arguments are prone to be very similar, and the issue itself
will unfold in a similar fashion, can we try to have a different
process? One that does not bring so much heat? I hope a very similar
resolution can be had for #923387 - without needing a six-week-long discussion.

Bug#980161: Acknowledgement (tex-common fails to update to 6.15 - fmtutil failed)

2021-01-15 Thread Norbert Preining

Hmmm interesting.

Can you run
  sudo fmtutil-sys -all
? Does that give the same error again, i.e., is this reproducible?

Best

Norbert
-- 
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



Jan 16, 2021 10:27:12 Rann Bar-On :

> Filesystem  Size  Used Avail Use% Mounted on
> tmpfs   7.8G  208M  7.6G   3% /tmp
> 
> On 1/15/21 5:53 PM, Norbert Preining wrote:
>> On Fri, 15 Jan 2021, Rann Bar-On wrote:
>>> $ df -h /var
>>> Filesystem  Size  Used Avail Use% Mounted on
>>> /dev/nvme0n1p3   10G  7.8G  2.0G  80% /var
>> What about /tmp?
>> 
>> Norbert
>> 
>> -- 
>> PREINING Norbert  
>> https://urldefense.com/v3/__https://www.preining.info__;!!OToaGQ!-y7xxvBW8HYtaNjT8s4X9oAIkyhB4q-QKlUUz7otfD2WTQ2J2N1sjiiE7G2IxA$
>> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
>> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>

Bug#976192: ncal: incorrect week numbers for 2021

2021-01-15 Thread Kate

Hi,

I'm getting the same issue. I believe the issue comes from this commit: 
https://salsa.debian.org/meskes/bsdmainutils/-/commit/34bf2cd955305983e58447b46e1f927e82106da1
 
(https://salsa.debian.org/meskes/bsdmainutils/-/commit/34bf2cd955305983e58447b46e1f927e82106da1)
 from the ncal_fdow.diff patch

On my system (Debian Sid), *nl_langinfo(_NL_TIME_WEEK_1STWEEK) returns 4, which 
is different from the default (3).
Locales: LC_ALL=en_GB.UTF-8

I've tested on FreeBSD-current (which does not have those linux-only 
patches) and the week number was correct.

Cheers,

Kate

Bug#980161: Acknowledgement (tex-common fails to update to 6.15 - fmtutil failed)

2021-01-15 Thread Rann Bar-On


Filesystem  Size  Used Avail Use% Mounted on
tmpfs   7.8G  208M  7.6G   3% /tmp

On 1/15/21 5:53 PM, Norbert Preining wrote:

On Fri, 15 Jan 2021, Rann Bar-On wrote:

$ df -h /var
Filesystem  Size  Used Avail Use% Mounted on
/dev/nvme0n1p3   10G  7.8G  2.0G  80% /var

What about /tmp?

Norbert

--
PREINING Norbert  
https://urldefense.com/v3/__https://www.preining.info__;!!OToaGQ!-y7xxvBW8HYtaNjT8s4X9oAIkyhB4q-QKlUUz7otfD2WTQ2J2N1sjiiE7G2IxA$
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13


--
--
Rann Bar-On
Senior Lecturer
Math Department
Duke University

he/him/his

Bug#980186: nvidia-driver does not support rt kernels

2021-01-15 Thread Scorpion2185

You cannot use the nvidia-driver package with rt kernels:
"The kernel you are installing for is a PREEMPT_RT kernel!

The NVIDIA driver does not support real-time kernels. If you
are using a stock distribution kernel, please install
a variant of this kernel that does not have the PREEMPT_RT
patch set applied; if this is a custom kernel, please
install a standard Linux kernel. Then try installing the
NVIDIA kernel module again."

Bug#961227: pbuilder misparses build dependencies specifying a version range that have multiple profiles

2021-01-15 Thread Mattia Rizzolo

On Fri, Jan 15, 2021 at 10:48:05PM +0100, Helmut Grohne wrote:
> On Fri, Jan 15, 2021 at 09:43:05PM +0100, Helmut Grohne wrote:
> > Duh! I ran into this as well now. Thanks for filing it. I think the
> > patch mostly explains itself. <.*> matches e.g. "<< 2:8) 
> > " or "<< 2:8)  ".

How (if you did) test your patch?
Trying here after adding a test didn't quite work:

--- a/pbuilder-satisfydepends-funcs
+++ b/pbuilder-satisfydepends-funcs
@@ -202,7 +202,8 @@ filter_restriction_deps() {
 echo "$INSTALLPKG"
 done |
 # remove the restriction list and add " | " between entries
-sed 's/<.*>//; $,$! s/$/ |/' |
+#sed 's/<.*>//; $,$! s/$/ |/' |
+sed 's/<[^)(]*>//; $,$! s/$/ |/' |
 xargs --no-run-if-empty
 done |
 # add ", " between entries
--- a/t/test_pbuilder-satisfydepends-funcs
+++ b/t/test_pbuilder-satisfydepends-funcs
@@ -234,6 +234,15 @@ expect_output "" test_filter_arch_restriction_deps "foo 
[amd64] " "amd64
 expect_output "foo" test_filter_arch_restriction_deps "foo [amd64] " 
"amd64" ""
 expect_output "" test_filter_arch_restriction_deps "foo [i386] " 
"amd64" "stage1"
 
+test_filter_version_restriction_deps() {
+echo "$1" | filter_restriction_deps "$2"
+}
+
+expect_output "foo (<< 2:8)" test_filter_version_restriction_deps "foo (<< 
2:8)  " ""
+expect_output "" test_filter_version_restriction_deps "foo (<< 2:8)  
" "nocheck"
+expect_output "" test_filter_version_restriction_deps "foo (<< 2:8)  
" "noinsttest"
+expect_output "" test_filter_version_restriction_deps "foo (<< 2:8)  
" "nocheck noinsttest"
+
 expect_output "debhelper (>= 7)" test_get_build_deps_dsc
 expect_output "debhelper (>= 9), haskell-devscripts (>= 0.8.15), cdbs, ghc, 
ghc-prof, libghc-hashable-dev (<< 1.3), libghc-hashable-prof (<< 1.3), ghc-doc, 
libghc-hashable-doc (<< 1.3)" test_get_parsed_build_deps_dsc


The test:
[FAIL] test_filter_version_restriction_deps expected [foo (<< 2:8)] but got 
[foo (]
[FAIL] test_filter_version_restriction_deps expected [] but got [foo (]
./test_pbuilder-satisfydepends-funcs: Ran 65 tests and 63 succeeded, 2 failed

(apparently, of the 4 added tests, it's the first 2 that fails.  So,
there is also *another* bug: pbuilder can't correctly handle multiple
profiles specified separatedly: it wants them within a single < >)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#980202: FTBFS: gscan2pdf tests fail

2021-01-15 Thread Sergio Durigan Junior

Source: gscan2pdf
Version: 2.10.2-1
Severity: serious
Justification: FTBFS on amd64
Tags: sid ftbfs

While trying to rebuild gscan2pdf on a clean amd64 schroot using sbuild,
I found this FTBFS:

--8<---cut here---start->8---
ok 27 - POD test for blib/script/gscan2pdf
ok

Test Summary Report
---
t/1122_save_pdf_with_hocr.t (Wstat: 512 Tests: 2 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
t/113_save_pdf_with_downsample.t(Wstat: 512 Tests: 2 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
t/134_save_tiff_alpha.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=242, Tests=1168, 276 wallclock secs ( 0.48 usr  0.18 sys + 108.21 cusr 
19.84 csys = 128.71 CPU)
Result: FAIL
Failed 3/242 test programs. 5/1168 subtests failed.
make[2]: *** [Makefile:912: test_dynamic] Error 255
make[2]: Leaving directory '/<>'
dh_auto_test: error: make -j32 test TEST_VERBOSE=1 returned exit code 2
make[1]: *** [debian/rules:9: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:3: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 2021-01-16T00:02:23Z

Finished



+--+
| Cleanup  |
+--+

Purging /<>
Not cleaning session: cloned chroot in use
E: Build failure (dpkg-buildpackage died)
--8<---cut here---end--->8---

I tried running the build twice, and both attempts failed with the same
reason.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#980176: hplip: ScanJet Pro 2500 f1 isn't recognized

2021-01-15 Thread Alejandro Colomar (man-pages)

On 1/15/21 6:45 PM, Alejandro Colomar wrote:
> Package: hplip
> Version: 3.20.11+dfsg0-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: alx.manpa...@gmail.com
> 
> Dear Maintainer,
> 
>   I bought a new ScanJet Pro 2500 f1.
>   After plugging it, I tried to scan a document,
>   but it is not detected by the scanning programs.
> 
>   $ lsusb | grep -i hp;
>   Bus 001 Device 005: ID 03f0:6005 HP, Inc HP ScanJet Pro 2500 f1 
>   
>   I tried to follow the instructions I found here:
>   https://bugs.launchpad.net/hplip/+bug/1847142
> 
>   However, the ones I could follow, didn't work
>   (as happened to the reporter of that bug too),
>   and there were others (at the end of that discussion;
>   about rebuilding hplip),
>   that I didn't understand, and so I couldn't follow.
> 
>   I'm running sid, with a few experimental packages.
>   If you update experimental with a fix for this,
>   I'll be happy to test it.

Actually... after trying the many things in that link,
some of which I repeated with sudo just to try
(some had slightly better results with sudo, but still no luck),
nothing worked, but much later, I rebooted the PC,
and it then worked.

So, some of the steps in that link worked,
although I don't know which,
and it/they need a restart (or re-login?) to work.

BTW, one thing that still doesn't work is the feeder,
although I haven't found any command/program
that is compatible with the feeder AND
documents its usage properly,
so it may be the fault of those commands, and not of hplip.

Thanks,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#979607: texlive-bin: reduce Build-Depends

2021-01-15 Thread Norbert Preining

Hi Helmut,

thanks for the report, indeed, indeed. I looked into the deps and you
are seemingly right:

 * libgd-dev
used by dvipng which is separately packages, but too old there
 * libgs-dev
dvisvgm
 * libncurses5-dev
nobody seems to need it
 * libpotrace-dev
dvisvgm separate
 * libwoff-dev
dvisvgm
 * libxxhash-dev
dvisvgm
 * sharutils
uuen/decode for binary files in debian/ can be done differently
(include-binaries)
 * texinfo
no idea what this was used for
 * time
no idea why

Most libs were used for dvisvgm which was split out some time ago.
libgd is for dvipng which is build separately (but the Debian package is
out of date compared to the TL version, so I might build it from TL).

sharutils is a left over from debian.diff.gz times where binaries
couldn't be included (the packages have 15 years with not too much
changes).

texinfo no idea, time the same

I will check with the dvipng maintainers, and upload a package with
reduced deps.

Thanks for looking into this!

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#978954: pepperflashplugin-nonfree: should not be part of next stable Debian release

2021-01-15 Thread Gunnar Hjalmarsson


On 2021-01-15 17:30, Andreas Beckmann wrote:

I've just uploaded 1.8.8 turning the package into a dummy removing
the broken download/install functionality and the chromium
integration s.t. people will upgrade to a "fixed" version (that does
not block trying to download unavailable bits). That should be
cleaner than removing it from the archive while leaving it installed
in broken state on users systems.


Thanks Andreas!

Is there a plan to backport the dummy to Debian's stable releases? (I'm 
about to do that on the Ubuntu side.)


--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980186: RFP: nvidia-driver-rt -- Nvidia driver for real time kernels.

2021-01-15 Thread scorpion2185

Package: wnpp
Severity: wishlist

* Package name: nvidia-driver-rt
  Version : -
  Upstream Author : Nvidia
* URL : https://www.nvidia.com/Download/index.aspx?lang=en-us
* License : Proprietary
  Programming Lang: -
  Description : Nvidia driver for real time kernels.

Nvidia driver for real time kernel packages.

For example Arch linux has this package
https://aur.archlinux.org/packages/nvidia-rt/.

Bug#980201: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.141-2~deb10u1

Followup-For: Bug #980201

And the patch, the diffstat looks huge only due to the changelog

 README.source |   15 
 changelog | 8147 +-
 control   |6 
 control.in|6 
 control.md5sum|8 
 copyright |9 
 gbp.conf  |   10 
 libcuda1.lintian-overrides.in |1 
 libegl-nvidia0.lintian-overrides.in   |1 
 libegl1-glvnd-nvidia.lintian-overrides.in |1 
 libegl1-nvidia.lintian-overrides.in   |2 
 libgl1-glvnd-nvidia-glx.lintian-overrides.in  |2 
 libgl1-glvnd-nvidia-glx.symbols   |   54 
 libgl1-nvidia-glx.lintian-overrides.in|1 
 libgles-nvidia1.lintian-overrides.in  |1 
 libgles-nvidia2.lintian-overrides.in  |1 
 libgles1-glvnd-nvidia.lintian-overrides.in|2 
 libgles1-glvnd-nvidia.symbols |   18 
 libgles2-glvnd-nvidia.lintian-overrides.in|2 
 libgles2-glvnd-nvidia.symbols |   18 
 libglvnd0-nvidia.lintian-overrides.in |2 
 libglx-nvidia0.lintian-overrides.in   |1 
 libglx0-glvnd-nvidia.lintian-overrides.in |2 
 libnvcuvid1.lintian-overrides |1 
 libnvidia-cfg1.lintian-overrides  |1 
 libnvidia-cfg1.symbols|2 
 libnvidia-compiler.lintian-overrides.in   |1 
 libnvidia-eglcore.lintian-overrides.in|1 
 libnvidia-fatbinaryloader.lintian-overrides.in|1 
 libnvidia-glcore.lintian-overrides.in |1 
 libnvidia-ml1.lintian-overrides   |1 
 libnvidia-ptxjitcompiler1.lintian-overrides.in|1 
 libopengl0-glvnd-nvidia.lintian-overrides.in  |2 
 libopengl0-glvnd-nvidia.symbols   |   18 
 module/debian/patches/arm-outer-sync.patch|2 
 module/debian/patches/cc_version_check-gcc5.patch |2 
 module/debian/patches/ignore_xen_on_arm.patch |2 
 module/debian/patches/include-swiotlb-header-on-arm.patch |4 
 module/debian/patches/kernel-5.7.0-set-memory-array.patch |   12 
 module/debian/patches/nvidia-drm-arm-cflags.patch |2 
 module/debian/rules.in|2 
 nvidia-kernel-dkms.dkms.in|8 
 nvidia-kernel-dkms.install.in |3 
 nvidia-kernel-source.install.in   |4 
 nvidia-opencl-icd.lintian-overrides.in|1 
 nvidia-smi.lintian-overrides.in   |1 
 nvidia-vdpau-driver.lintian-overrides |1 
 patches/man-fixes-nvidia-smi.patch|1 
 rules |  123 
 rules.defs|6 
 source/lintian-overrides  |3 
 watch |5 
 watch.in  |5 
 xserver-xorg-video-nvidia.lintian-overrides.in|1 
 54 files changed, 8347 insertions(+), 181 deletions(-)


ngd-390xx-390.141-2~deb10u1.patch.xz
Description: application/xz

Bug#980201: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.141-2~deb10u1

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

Hi,

I'd like to upload a new upstream release of the nvidia legacy driver 390xx
to buster in order to fix CVE-2021-1056.

This will be a rebuild of the package in sid and thus includes a few
packaging updates similarily to the current 390.138-1~deb10u1.
(nvidia-graphics-drivers-legacy-390xx in sid still has a small userbase and
therefore this should be the package with the best testing we can get.)

There are several changelog entries mentioning support for newer Linux
kernels (patches etc.), these changes have been superseded by the new upstream
release and the patches are gone ;-)

The new symbols are in *-glvnd-* packages which are not built from
src:nvidia-graphics-drivers-legacy-390xx (only built by
src:nvidia-graphics-drivers in stretch) and therefore are irrelevant.

There are many ancient changelog entries being added back, since I reverted a
decision to drop them because that only made comparing and merging branches
more difficult.


Andreas

Bug#979541: sylpheed: [regression] spell check no longer recognizes some correct Italian words

2021-01-15 Thread Francesco Poli

On Fri, 8 Jan 2021 19:17:45 +0100 Francesco Poli wrote:

[...]
> Please take into account that I am experiencing the same exact issue
> with claws-mail (which is known to be a fork of sylpheed, although the
> two code bases have probably diverged significantly in so much time...)
> and with libreoffice-writer (which really surprised me, as I thought it
> was not even using the same spell checker library: libhunspell-1.7-0,
> rather than libaspell15...).

Hello again,
it seems that sylpheed and libreoffice-writer (can) use the same
dictionary: hunspell-it (for Italian spell checking).
I thought that this dictionary was usable only with libhunspell, but I
was probably wrong.

And it seems that the regression I reported was introduced by the
upgrade of hunspell-it (which, on my system, happened on January, the
6th):

  [UPGRADE] hunspell-it:amd64 1:7.0.1-1 -> 1:7.1.0~rc1-1

The [bug] has been reported against package hunspell-it and
subsequently fixed in version 1:7.1.0~rc2-1 of hunspell-it.

[bug]: 

I've just upgraded to hunspell-it/1:7.1.0~rc2-2 (currently in Debian
unstable) and I can confirm that it fixes the regression:

  [UPGRADE] hunspell-it:amd64 1:7.1.0~rc1-1 -> 1:7.1.0~rc2-2

Feel free to reassign this bug report to package hunspell-it and to
forcemerge it with the already closed bug report #979439.

Sorry for reporting a regression that was not actually caused by
package sylpheed!
And thanks for your time and patience.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgpkQAZ5qlWB9.pgp
Description: PGP signature

Bug#980194: [Pkg-privacy-maintainers] Bug#980194: mat2: autopkgtest regression in testing: AssertionError: ValueError not raised

2021-01-15 Thread Georg Faerber

Hi Paul,

Thanks for telling!

On 21-01-15 22:09:18, Paul Gevers wrote:
> With a very recent change in testing the autopkgtest of your package
> started to fail. I copied some of the output at the bottom of this
> report. Can you please investigate the situation and fix it?

I'm wondering if this is related to the recent upload of media-types
[1].

This test [2], which installed media-types 1.0.1, was successful,
whereas the test [3], which installed media-types 1.1.0, wasn't.

Cheers,
Georg

[1] 
https://tracker.debian.org/news/1208854/accepted-media-types-110-source-into-unstable/
[2] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9452897/log.gz
[3] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9663226/log.gz

Bug#980161: Acknowledgement (tex-common fails to update to 6.15 - fmtutil failed)

2021-01-15 Thread Norbert Preining

On Fri, 15 Jan 2021, Rann Bar-On wrote:
> $ df -h /var
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/nvme0n1p3   10G  7.8G  2.0G  80% /var

What about /tmp?

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#864338: gpsd: Provide a way to initialize GPS mode on cards like Ericsson F5521gw or F3507g

2021-01-15 Thread Ben Ruhnow

Package: gpsd
Version: 3.20-12+b2
Followup-For: Bug #864338
X-Debbugs-Cc: b.ruh...@web.de

Dear Maintainer, dear Benoit,

I am an owner of an Ericsson H5321 gw module and experienced gpsd user. Since
my last approach to finally make use of my gps receiver, there must have
happend something with the debian configuration. The information from the
thinkwiki.org pages were, as you already mentioned here, useful for me and
turned out to make the gps receiver work for me. I already tested out functions
of the F3507g receiver and posted a working solution on ubuntuforums about 7
years ago. Now I use a different receiver and when first tested everything
seemed working well. This was about 3 years ago. Now I am confused that none of
the previously working steps led to any output on my device port. When last
tested I recognized that something had changed in the way gpsd can operate on
the port. In the past it wasn't possible to directly read /dev/ttyACM2 because
of permission issues. The necessary information are posted here:
https://forum.ubuntuusers.de/topic/gpsd-mit-ericsson-f5521gw-mobile-broadband-mod/#post-6727147
.
For now I can only report that gpsd can't read from the pipe mentioned in this
post. So for me it's not reproduceable anymore. Maybe I'm missing something. I
searched the web again but didn't find a solution.
I turned the gps receiver on in the way I was able to remember, went outside,
but couldn't get any output of the NMEA stream when reading from /dev/ttyACM2.
I tried around with hard-resets and different ways connecting clients, reading
directly from port, but nothing turned out to work for me.

Any further help would be appreciated,

Ben

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

Kernel: Linux 5.10.4 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gpsd depends on:
ii adduser3.118
ii libbluetooth3 5.55-2
ii libc6 2.31-6
ii libdbus-1-31.12.20-1
ii libgps26 3.20-12+b2
ii libusb-1.0-0 2:1.0.24-2
ii lsb-base 11.1.0
ii netbase6.2
ii python33.9.1-1
ii systemd-sysv 247.2-3

Versions of packages gpsd recommends:
ii gpsd-tools 3.20-12+b2
ii udev247.2-3

Versions of packages gpsd suggests:
ii apparmor 2.13.6-3
ii dbus 1.12.20-1
ii gpsd-clients 3.20-12+b2

-- Configuration Files:
/etc/default/gpsd changed:
DEVICES="/dev/ttyACM2"
GPSD_OPTIONS=""
USBAUTO="true"
START_DAEMON="false"

-- no debconf information

Bug#932114: bridge-utils: outdated scripts make the kernel complain

2021-01-15 Thread Santiago Garcia Mantinan

> That doesn't reflect what's happening here. The host in question has no 
> firewalling whatsoever. This is the result of merely launching a bridge. 
> Whatever commands bridge-utils issue as a result of reading the 
> /etc/network/interfaces stanza for br0 is what produces this.

Like I said, this is not related to bridge-utils of course bridge-utils does
things, it sets up a bridge, but nothing more.

However to be able to create a bridge the kernel needs to have bridge
support and it if is not available the bridge module gets loaded, it is this
module which outputs this warning, that's it.

You can test this on any machine without even bridge-utils loaded, you do a
modprobe bridge and you'll get the kernel warning.

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#980182: Package upload fails with latin-1-encoded GPG UID in signing key

2021-01-15 Thread Toke Høiland-Jørgensen

Package: ftp.debian.org
Severity: important
X-Debbugs-Cc: ans...@debian.org

When uploading a new package to the FTP-master signed with a GPG key
that has latin-1 encoded UID(s), processing of the package fails with
a unicode error in dak.

I discovered this when trying to upload a new version of the 'flent' package.

Bug#980200: ITP: pappl -- C-based framework/library for developing CUPS Printer Applications

2021-01-15 Thread Didier 'OdyX' Raboud

Package: wnpp
Severity: wishlist
Owner: Didier 'OdyX' Raboud 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-print...@lists.debian.org

Package name: pappl
Version : 1.0.1
Upstream Author : Michael R Sweet 
URL : hhttps://www.msweet.org/pappl
License : Apache License Version 2.0 with an (optional) exception to 
allow linking against GPL2/LGPL2 software
Programming Lang: C
Description : C-based framework/library for developing CUPS Printer 
Applications

 PAPPL is a simple C-based framework/library for developing CUPS Printer
 Applications, which are the recommended replacement for printer drivers. It
 was specifically developed to support LPrint and a future Gutenprint Printer
 Application but is sufficiently general purpose to support any kind of printer
 or driver that can be used on desktops, servers, and in embedded environments.

I'll be maintaining this under the Debian Printing Team umbrella. Current 
packaging
is hosted at https://salsa.debian.org/printing-team/pappl/.

Bug#980199: erlang: CVE-2020-35733

Source: erlang
Version: 1:23.2.1+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for erlang.

CVE-2020-35733[0]:
| An issue was discovered in Erlang/OTP before 23.2.2. The ssl
| application 10.2 accepts and trusts an invalid X.509 certificate chain
| to a trusted root Certification Authority.

It is specific to OTP-23.2, see the security-tracker information.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-35733
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35733
[1] https://erlang.org/pipermail/erlang-questions/2021-January/100357.html

Regards,
Salvatore

Bug#980198: jsusfx FTCBFS: confuses build vs host

Source: jsusfx
Version: 0.4.0-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

jsusfx fails to cross build from source for architectures other than
amd64 when built on amd64, because it confuses the terms build and host
and makes the build non-portable. For a definition of these terms refer
to man dpkg-architecture. Please consider applying the attached patch.

Helmut
diff --minimal -Nru jsusfx-0.4.0/debian/changelog jsusfx-0.4.0/debian/changelog
--- jsusfx-0.4.0/debian/changelog   2020-01-08 16:54:46.0 +0100
+++ jsusfx-0.4.0/debian/changelog   2021-01-15 21:47:54.0 +0100
@@ -1,3 +1,10 @@
+jsusfx (0.4.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Fix build vs host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 15 Jan 2021 21:47:54 +0100
+
 jsusfx (0.4.0-2) unstable; urgency=medium
 
   * Build portable binaries on non-amd64
diff --minimal -Nru jsusfx-0.4.0/debian/rules jsusfx-0.4.0/debian/rules
--- jsusfx-0.4.0/debian/rules   2020-01-08 16:54:46.0 +0100
+++ jsusfx-0.4.0/debian/rules   2021-01-15 21:47:53.0 +0100
@@ -5,7 +5,7 @@
 DEB_COPYRIGHT_CHECK_IGNORE_REGEX = \
^(\./\.git(/.*)?|\./debian(/.*)?|.*\.xcuserstate)$
 
-ifeq (,$(findstring amd64,$(DEB_BUILD_ARCH)))
+ifeq (,$(findstring amd64,$(DEB_HOST_ARCH)))
PORTABLE=ON
 else
PORTABLE=OFF

Bug#961227: pbuilder misparses build dependencies specifying a version range that have multiple profiles

On Fri, Jan 15, 2021 at 09:43:05PM +0100, Helmut Grohne wrote:
> Duh! I ran into this as well now. Thanks for filing it. I think the
> patch mostly explains itself. <.*> matches e.g. "<< 2:8) 
> " or "<< 2:8)  ".

And I managed to miss the patch. Thanks Jessica.

Helmut
diff --minimal -Nru pbuilder-0.230.4/debian/changelog 
pbuilder-0.230.4+nmu1/debian/changelog
--- pbuilder-0.230.4/debian/changelog   2019-04-02 11:32:38.0 +0200
+++ pbuilder-0.230.4+nmu1/debian/changelog  2021-01-15 22:46:35.0 
+0100
@@ -1,3 +1,11 @@
+pbuilder (0.230.4+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix parsing of build-depends with version and profile restrictions.
+(Closes: #961227)
+
+ -- Helmut Grohne   Fri, 15 Jan 2021 22:46:35 +0100
+
 pbuilder (0.230.4) unstable; urgency=medium
 
   * createbuildenv:
diff --minimal -Nru pbuilder-0.230.4/pbuilder-satisfydepends-funcs 
pbuilder-0.230.4+nmu1/pbuilder-satisfydepends-funcs
--- pbuilder-0.230.4/pbuilder-satisfydepends-funcs  2018-11-23 
11:51:49.0 +0100
+++ pbuilder-0.230.4+nmu1/pbuilder-satisfydepends-funcs 2021-01-15 
22:46:32.0 +0100
@@ -202,7 +202,7 @@
 echo "$INSTALLPKG"
 done |
 # remove the restriction list and add " | " between entries
-sed 's/<.*>//; $,$! s/$/ |/' |
+sed 's/<[^)(]*>//; $,$! s/$/ |/' |
 xargs --no-run-if-empty
 done |
 # add ", " between entries

Bug#953289: ABI change in libsoxr 0.1.3

Hi all,

On Sat, 7 Mar 2020 09:57:02 +0100 Max Kellermann  wrote:
> Package: libsoxr0
> Version: 0.1.3-2
> 
> In version 0.1.3, libsoxr has made an undocumented ABI change which
> causes MPD (Music Player Daemon) to crash:
> 
>  https://github.com/MusicPlayerDaemon/MPD/issues/773
> 
> The commit which changed the ABI was:
>  
> https://sourceforge.net/p/soxr/code/ci/52888cd410ae356bf3aa26d8fa106754b8fd8990

Any progress here? The transition freeze already started. How do you
propose we solve this issue?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980195: ts-node: autopkgtest regression in testing: Cannot find name 'process'

2021-01-15 Thread Xavier

Control: reassign -1 pkg-js-autopkgtest
Control: affects -1 ts-node

Le 15/01/2021 à 22:14, Paul Gevers a écrit :
> Source: ts-node
> Version: 9.1.1-4
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s),
> 
> With a very recent change in testing the autopkgtest of your package
> started to fail. I copied some of the output at the bottom of this
> report. Can you please investigate the situation and fix it?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul

This is due to a Perl change:

Now:
  $ cat debian/nodejs/extcopies|perl -pe 's/\s+.*$//'
  axiossemver@types/node@types/react

Before:
  $ cat debian/nodejs/extcopies|perl -pe 's/\s+.*$//'
  axios
  semver
  @types/node
  @types/react

I'm going to fix pkg-js-autopkgtest

Bug#971754: ABI breakage from 1.4.1 to 1.4.2

2021-01-15 Thread Sebastian Dröge

On Fri, 2021-01-15 at 22:37 +0100, Paul Gevers wrote:
> Hi Sebastian,
> 
> On Thu, 14 Jan 2021 11:39:24 +0200 Sebastian =?ISO-8859-1?Q?Dr=F6ge?=
>  wrote:
> > Upstream fixed this now by making the soversion 1.4 and from now on
> > guaranteeing that patch versions (1.4.0 -> 1.4.X) do not break ABI.
> > 
> > It would make sense to backport that fix and then rename the
> > library package accordingly to libsrt1.4.
> > 
> > For gst-plugins-bad1.0 only a binNMU would be needed once this is
> > all
> > sorted out here.
> 
> Can you do this please? srt is orphaned, your package depend on it,
> could you please help us get us out of this situation? (if this
> happens soon, we'll accept the transition to fix this).

I'll try to have some time for that this weekend.


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

Bug#971754: ABI breakage from 1.4.1 to 1.4.2

Hi Sebastian,

On Thu, 14 Jan 2021 11:39:24 +0200 Sebastian =?ISO-8859-1?Q?Dr=F6ge?=
 wrote:
> Upstream fixed this now by making the soversion 1.4 and from now on
> guaranteeing that patch versions (1.4.0 -> 1.4.X) do not break ABI.
> 
> It would make sense to backport that fix and then rename the library
> package accordingly to libsrt1.4.
> 
> For gst-plugins-bad1.0 only a binNMU would be needed once this is all
> sorted out here.

Can you do this please? srt is orphaned, your package depend on it,
could you please help us get us out of this situation? (if this happens
soon, we'll accept the transition to fix this).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#966233: pyyaml: CVE-2020-14343

Hi,

On Sat, Jul 25, 2020 at 09:32:25AM +0200, Salvatore Bonaccorso wrote:
> Source: pyyaml
> Version: 5.3.1-2
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/yaml/pyyaml/issues/420
> X-Debbugs-Cc: Debian Security Team 
> 
> Hi,
> 
> The following vulnerability was published for pyyaml.
> 
> CVE-2020-14343[0]:
> | .load() and FullLoader still vulnerable to fairly trivial RCE
> 
> The CVE is for an incomplete fix of CVE-2020-1747, see [1].
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2020-14343
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14343
> [1] https://github.com/yaml/pyyaml/issues/420

If I understand the situation correctly, then this has been fixed via
https://github.com/yaml/pyyaml/pull/472/commits/7adc0db3f613a82669f2b168edd98379b83adb3c
.

As such can you check and make it enter bullseye?

Regards,
Salvatore

Bug#980197: sensible-utils [INTL:pt] Update on Portuguese translation of MANPAGE

2021-01-15 Thread Américo Monteiro

Package: sensible-utils
Version: 0.0.14
Tags: l10n, patch-
Severity: wishlist

Updated Portuguese translation for  sensible-utils's manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro



sensible-utils_0.0.14_pt.po.gz
Description: application/gzip

Bug#980196: getting information about a failed installation

package: installer

This applies to the current installer image
debian-live-10.7.0-i386-cinnamon+nonfree.iso 


running the current installer I got to "installation failed" 
and went back to the main installer menu. There were three options
listed under "save debug logs"

1) floppy
2) web
3) mounted file system

#1 - gimmie a break. they're extinct.

#2 - it says a web server was started, but no host is apparent at the
quoted ip address - which is the one I assigned it earlier in the installation.
One of the contributing causes to my installation failing was *probably* that 
the
native wifi wasn't recognised, and the networking in the installer was 
nonfunctional.

#3 - fails with a red screen background using the offered default /mnt 
-at this point, the file system has been trashed and I have no idea
what might be a valid file name other than /mnt.  From the shell, /mnt
is reported as 100% full, so that could account for the failure.
Later, I discovered that the info was *already* written to /var/logs/.
That might have been nice to mention.  Or even offer to view them directly.


--

one of the choices in the installation menu is "check the integrity of the 
cdrom"
nice idea, but this is a stick install, and trying the check anyway just 
complains
about the absence of the cdrom.   Elsewhere in the installer, all the verbiage 
uses "cd" o "cdrom" even though this was a memory stick install, so I had every
reason to expect that "check integrity" was a reasonable thing to try.

--

Generally, the installer is the first point of contact that a newb would have 
with linux,
and this interaction is a pretty awful introduction.

Bug#980195: ts-node: autopkgtest regression in testing: Cannot find name 'process'

Source: ts-node
Version: 9.1.1-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a very recent change in testing the autopkgtest of your package
started to fail. I copied some of the output at the bottom of this
report. Can you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/t/ts-node/9718737/log.gz

  39 passing (1m)
  8 failing

  1) ts-node
   cli
 should provide registered information globally:
 Uncaught expected [Error: Command failed:
"/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/tests/node_modules/.bin/ts-node"
--project
"/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/tests/tsconfig.json"
tests/env

/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:513
return new TSError(diagnosticText, diagnosticCodes)
   ^
TSError: ⨯ Unable to compile TypeScript:
tests/env.ts(1,20): error TS2580: Cannot find name 'process'. Do you
need to install type definitions for node? Try `npm i --save-dev
@types/node`.

at createTSError
(/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:513:12)
at reportTSError
(/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:517:19)
at getOutput
(/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:752:36)
at Object.compile
(/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:968:32)
at Module.m._compile
(/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:1056:42)
at Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
at Object.require.extensions. [as .ts]
(/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:1059:12)
at Module.load (internal/modules/cjs/loader.js:879:32)
at Function.Module._load (internal/modules/cjs/loader.js:724:14)
at Function.executeUserEntryPoint [as runMain]
(internal/modules/run_main.js:60:12)
] to equal null
  AssertionError: expected [Error: Command failed:
"/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/tests/node_modules/.bin/ts-node"
--project
"/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/tests/tsconfig.json"
tests/env


/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/src/index.ts:513
  return new TSError(diagnosticText, diagnosticCodes)
 ^
  TSError: ⨯ Unable to compile TypeScript:
  tests/env.ts(1,20): error TS2580: Cannot find name 'process'. Do you
need to install type definitions for node? Try `npm i --save-dev
@types/node`.

  at createTSError (src/index.ts:513:12)
  at reportTSError (src/index.ts:517:19)
  at getOutput (src/index.ts:752:36)
  at Object.compile (src/index.ts:968:32)
  at Module.m._compile (src/index.ts:1056:42)
  at Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
  at Object.require.extensions. [as .ts]
(src/index.ts:1059:12)
  at Module.load (internal/modules/cjs/loader.js:879:32)
  at Function.Module._load (internal/modules/cjs/loader.js:724:14)
  at Function.executeUserEntryPoint [as runMain]
(internal/modules/run_main.js:60:12)
  ] to equal null
  at
/tmp/autopkgtest-lxc.cgibtj7d/downtmp/autopkgtest_tmp/smokeed1RaQ/dist/index.spec.js:123:39
  at ChildProcess.exithandler (child_process.js:315:5)
  at maybeClose (internal/child_process.js:1021:16)
  at Process.ChildProcess._handle.onexit
(internal/child_process.js:286:5)

  2) ts-node
   cli
 should provide registered information on register:
 Uncaught AssertionError: expected [Error: Command failed: node -r
ts-node/register env.ts

/usr/share/nodejs/ts-node/src/index.ts:513
return new TSError(diagnosticText, diagnosticCodes)
   ^
TSError: ⨯ Unable to compile TypeScript:
env.ts(1,20): error TS2580: Cannot find name 'process'. Do you need to
install type definitions for node? Try `npm i --save-dev @types/node`.

at createTSError (/usr/share/nodejs/ts-node/src/index.ts:513:12)
at reportTSError (/usr/share/nodejs/ts-node/src/index.ts:517:19)
at getOutput (/usr/share/nodejs/ts-node/src/index.ts:752:36)
at Object.compile (/usr/share/nodejs/ts-node/src/index.ts:968:32)
at Module.m._compile (/usr/share/nodejs/ts-node/src/index.ts:1056:42)
at Module._extensions..js (internal/modules/cjs/loader.js:1035:10)
at Object.require.extensions. [as .ts]
(/usr/share/nodejs/ts-node/src/index.ts:1059:12)
at Module.load (internal/modules/cjs/loader.js:879:32)
at Function.Module._load (internal/modules/cjs/loader.js:724:14)
at Function.executeUserEntryPoint [as runMain]

Bug#980194: mat2: autopkgtest regression in testing: AssertionError: ValueError not raised

Source: mat2
Version: 0.12.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a very recent change in testing the autopkgtest of your package
started to fail. I copied some of the output at the bottom of this
report. Can you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9718736/log.gz

=== FAILURES
===
_ TestGetMeta.test_png
_

self = 

def test_png(self):
proc = subprocess.Popen(mat2_binary + ['--show',
'./tests/data/dirty.png'],
stdout=subprocess.PIPE)
stdout, _ = proc.communicate()
>   self.assertIn(b'Comment: This is a comment, be careful!', stdout)
E   AssertionError: b'Comment: This is a comment, be careful!' not
found in b"[-] ./tests/data/dirty.png's format (image/vnd.mozilla.apng)
is not supported\n"

tests/test_climat2.py:192: AssertionError
___ TestCorruptedEmbedded.test_docx


self = 

def test_docx(self):
shutil.copy('./tests/data/embedded_corrupted.docx',
'./tests/data/clean.docx')
parser, _ = parser_factory.get_parser('./tests/data/clean.docx')
with self.assertRaises(ValueError):
>   parser.remove_all()
E   AssertionError: ValueError not raised

tests/test_corrupted_files.py:69: AssertionError
_ TestCorruptedFiles.test_png2
_

self = 

def test_png2(self):
shutil.copy('./tests/test_libmat2.py', './tests/clean.png')
with self.assertRaises(ValueError):
>   parser_factory.get_parser('./tests/clean.png')
E   AssertionError: ValueError not raised

tests/test_corrupted_files.py:126: AssertionError
_ TestCorruptedFiles.test_tar
__

self = 

def test_tar(self):
with tarfile.TarFile.open('./tests/data/clean.tar', 'w') as zout:
zout.add('./tests/data/dirty.flac')
zout.add('./tests/data/dirty.docx')
zout.add('./tests/data/dirty.jpg')
zout.add('./tests/data/embedded_corrupted.docx')
tarinfo = tarfile.TarInfo(name='./tests/data/dirty.png')
tarinfo.mtime = time.time()
tarinfo.uid = 1337
tarinfo.gid = 1338
tarinfo.size = os.stat('./tests/data/dirty.png').st_size
with open('./tests/data/dirty.png', 'rb') as f:
zout.addfile(tarinfo, f)
p, mimetype = parser_factory.get_parser('./tests/data/clean.tar')
self.assertEqual(mimetype, 'application/x-tar')
with self.assertRaises(ValueError):
>   p.get_meta()
E   AssertionError: ValueError not raised

tests/test_corrupted_files.py:321: AssertionError
_ TestCorruptedFiles.test_zip
__

self = 

def test_zip(self):
with zipfile.ZipFile('./tests/data/clean.zip', 'w') as zout:
zout.write('./tests/data/dirty.flac')
zout.write('./tests/data/dirty.docx')
zout.write('./tests/data/dirty.jpg')
zout.write('./tests/data/embedded_corrupted.docx')
p, mimetype = parser_factory.get_parser('./tests/data/clean.zip')
self.assertEqual(mimetype, 'application/zip')
with self.assertRaises(ValueError):
>   p.get_meta()
E   AssertionError: ValueError not raised

tests/test_corrupted_files.py:243: AssertionError
 TestReadOnlyArchiveMembers.test_onlymember_tar


self = 

def test_onlymember_tar(self):
with tarfile.open('./tests/data/clean.tar', 'w') as zout:
zout.add('./tests/data/dirty.png')
tarinfo = tarfile.TarInfo('./tests/data/dirty.jpg')
tarinfo.mtime = time.time()
tarinfo.uid = 1337
tarinfo.gid = 0
tarinfo.mode = 0o000
tarinfo.size = os.stat('./tests/data/dirty.jpg').st_size
with open('./tests/data/dirty.jpg', 'rb') as f:
zout.addfile(tarinfo=tarinfo, fileobj=f)
p, mimetype = parser_factory.get_parser('./tests/data/clean.tar')
self.assertEqual(mimetype, 'application/x-tar')
meta = p.get_meta()
self.assertEqual(meta['./tests/data/dirty.jpg']['uid'], '1337')
>   self.assertTrue(p.remove_all())
E   AssertionError: False is not true

tests/test_corrupted_files.py:347: AssertionError
___ TestZipMetadata.test_libreoffice
___

self = 

def test_libreoffice(self):
shutil.copy('./tests/data/dirty.odt', './tests/data/clean.odt')
p =

Bug#980175: "cut -b FROM-TO": wrong byte selection

2021-01-15 Thread Philipp Marek

Package: coreutils
Version: 8.32-4+b1
Severity: normal
File: /usr/bin/cut
X-Debbugs-Cc: phil...@marek.priv.at


Yeah, I read the manpage - "cut" counts from 1 ;)

When using the "FROM">1 in "cut -b FROM-TO", the output is wrong:

$ openssl rand 16777216 > /tmp/zeroes
$ cut -b1-1200 < /tmp/zeroes > /tmp/zeroes2 
 
$ ls -la /tmp/zeroes*
-rw-r--r-- 1 user user 16777216 15. Jän 17:53 /tmp/zeroes
-rw-r--r-- 1 user user 16777217 15. Jän 17:53 /tmp/zeroes2
$ cut -b65-1200 < /tmp/zeroes > /tmp/zeroes2
$ ls -la /tmp/zeroes*   
   
-rw-r--r-- 1 user user 16777216 15. Jän 17:53 /tmp/zeroes
-rw-r--r-- 1 user user 13075377 15. Jän 17:53 /tmp/zeroes2
$ cut -b2-1200 < /tmp/zeroes > /tmp/zeroes2 

 
$ ls -la /tmp/zeroes*   

-rw-r--r-- 1 user user 16777216 15. Jän 17:53 /tmp/zeroes
-rw-r--r-- 1 user user 16711969 15. Jän 17:53 /tmp/zeroes2

It doesn't happen with /dev/zero - so I guess some byte value isn't sent 
through properly (NUL, or CRLF mismatch or something like that?).

Anyway, with byte positions I'd expect it to be clean and not do
any processing!


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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-9
ii  libattr1 1:2.4.48-6
ii  libc62.31-9
ii  libgmp10 2:6.2.1+dfsg-1
ii  libselinux1  3.1-2+b2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#980193: rust-flate2: autopkgtest regression in testing: [librust-flate2-dev] build failed

Source: rust-flate2
Version: 1.0.13-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent in testing the autopkgtest of your package started to
fail. I copied some of the output at the bottom of this report. Can you
please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-flate2/9658111/log.gz


   Compiling crossbeam-queue v0.2.1
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=crossbeam_queue
CARGO_MANIFEST_DIR=/tmp/tmp.5okCKKABz7/registry/crossbeam-queue-0.2.1
CARGO_PKG_AUTHORS='The Crossbeam Project Developers'
CARGO_PKG_DESCRIPTION='Concurrent queues'
CARGO_PKG_HOMEPAGE='https://github.com/crossbeam-rs/crossbeam/tree/master/crossbeam-utils'
CARGO_PKG_LICENSE='MIT/Apache-2.0 AND BSD-2-Clause'
CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=crossbeam-queue
CARGO_PKG_REPOSITORY='https://github.com/crossbeam-rs/crossbeam'
CARGO_PKG_VERSION=0.2.1 CARGO_PKG_VERSION_MAJOR=0
CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_VERSION_PATCH=1
CARGO_PKG_VERSION_PRE=''
LD_LIBRARY_PATH='/tmp/tmp.5okCKKABz7/target/debug/deps:/usr/lib' rustc
--crate-name crossbeam_queue
/tmp/tmp.5okCKKABz7/registry/crossbeam-queue-0.2.1/src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi,artifacts
--crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C
debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C
metadata=36555ddb05f00958 -C extra-filename=-36555ddb05f00958 --out-dir
/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps --target
x86_64-unknown-linux-gnu -L
dependency=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps -L
dependency=/tmp/tmp.5okCKKABz7/target/debug/deps --extern
cfg_if=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps/libcfg_if-87dc31f0cbfaa003.rmeta
--extern
crossbeam_utils=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps/libcrossbeam_utils-e6652b26c70c443c.rmeta
--cap-lints warn -C debuginfo=2 --cap-lints warn -C
linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix
/usr/share/cargo/registry/flate2-1.0.13=/usr/share/cargo/registry/flate2-1.0.13`
error: aborting due to 29 previous errors; 2 warnings emitted

Some errors have detailed explanations: E0412, E0425, E0432, E0433.
For more information about an error, try `rustc --explain E0412`.
error: could not compile `flate2`.

Caused by:
  process didn't exit successfully: `CARGO=/usr/bin/cargo
CARGO_CRATE_NAME=flate2
CARGO_MANIFEST_DIR=/usr/share/cargo/registry/flate2-1.0.13
CARGO_PKG_AUTHORS='Alex Crichton '
CARGO_PKG_DESCRIPTION='Bindings to miniz.c for DEFLATE compression and
decompression exposed as
  Reader/Writer streams. Contains bindings for zlib, deflate, and gzip-based
  streams.
  ' CARGO_PKG_HOMEPAGE='https://github.com/alexcrichton/flate2-rs'
CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE=''
CARGO_PKG_NAME=flate2
CARGO_PKG_REPOSITORY='https://github.com/alexcrichton/flate2-rs'
CARGO_PKG_VERSION=1.0.13 CARGO_PKG_VERSION_MAJOR=1
CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=13
CARGO_PKG_VERSION_PRE=''
LD_LIBRARY_PATH='/tmp/tmp.5okCKKABz7/target/debug/deps:/usr/lib' rustc
--crate-name flate2 --edition=2018 src/lib.rs --error-format=json
--json=diagnostic-rendered-ansi --crate-type lib
--emit=dep-info,metadata,link -Cembed-bitcode=no -C debuginfo=2 -C
metadata=75ebde93a25b92f7 -C extra-filename=-75ebde93a25b92f7 --out-dir
/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps --target
x86_64-unknown-linux-gnu -C
incremental=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/incremental
-L
dependency=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps -L
dependency=/tmp/tmp.5okCKKABz7/target/debug/deps --extern
cfg_if=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps/libcfg_if-87dc31f0cbfaa003.rmeta
--extern
crc32fast=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps/libcrc32fast-57af730d59c7a53c.rmeta
--extern
libc=/tmp/tmp.5okCKKABz7/target/x86_64-unknown-linux-gnu/debug/deps/liblibc-fcc534cc5513956a.rmeta
-C debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C
link-arg=-Wl,-z,relro --remap-path-prefix
/usr/share/cargo/registry/flate2-1.0.13=/usr/share/cargo/registry/flate2-1.0.13`
(exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: build failed
autopkgtest [18:00:00]: test librust-flate2-dev: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#980192: ruby-2.7: autopkgtest regression in testing: Errno::ENAMETOOLONG: File name too long

Source: ruby-2.7
Version: 2.7.2-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent (december 2020) in testing the autopkgtest of your package
started to fail. I copied some of the output at the bottom of this
report. Can you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby2.7/9537123/log.gz


264) Error:
TestTempfile#test_open_traversal_dir:
Errno::ENAMETOOLONG: File name too long @ rb_sysopen -
/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/..tmpautopkgtest-lxc.r54r7gkwdowntmpautopkgtest_tmptmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmpd20210109-4115-ihpyim20210109-4115-1l9j1dpfoo
/usr/lib/ruby/2.7.0/tempfile.rb:129:in `initialize'
/usr/lib/ruby/2.7.0/tempfile.rb:129:in `open'
/usr/lib/ruby/2.7.0/tempfile.rb:129:in `block in initialize'
/usr/lib/ruby/2.7.0/tmpdir.rb:129:in `create'
/usr/lib/ruby/2.7.0/tempfile.rb:127:in `initialize'
/usr/lib/ruby/2.7.0/tempfile.rb:287:in `new'
/usr/lib/ruby/2.7.0/tempfile.rb:287:in `open'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:368:in
`block in test_open_traversal_dir'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:401:in
`block in assert_mktmpdir_traversal'
/usr/lib/ruby/2.7.0/tmpdir.rb:89:in `mktmpdir'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:397:in
`assert_mktmpdir_traversal'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tempfile.rb:367:in
`test_open_traversal_dir'

265) Error:
TestTmpdir#test_mktmpdir_traversal:
Errno::ENAMETOOLONG: File name too long @ dir_s_mkdir -
/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/test_rubygems_4115/tmp/..tmpautopkgtest-lxc.r54r7gkwdowntmpautopkgtest_tmptmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmptest_rubygems_4115tmpd20210109-4115-c6vju4foo20210109-4115-o3w6ci
/usr/lib/ruby/2.7.0/tmpdir.rb:85:in `mkdir'
/usr/lib/ruby/2.7.0/tmpdir.rb:85:in `block in mktmpdir'
/usr/lib/ruby/2.7.0/tmpdir.rb:129:in `create'
/usr/lib/ruby/2.7.0/tmpdir.rb:83:in `mktmpdir'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:68:in
`block in test_mktmpdir_traversal'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:87:in
`block in assert_mktmpdir_traversal'
/usr/lib/ruby/2.7.0/tmpdir.rb:89:in `mktmpdir'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:83:in
`assert_mktmpdir_traversal'

/tmp/autopkgtest-lxc.r54r7gkw/downtmp/autopkgtest_tmp/test/test_tmpdir.rb:67:in
`test_mktmpdir_traversal'

266) Error:
TestTmpdir#test_mktmpdir_traversal_array:
Errno::ENAMETOOLONG: File name too long @ dir_s_mkdir -

Bug#980191: ITP: r-cran-gitcreds -- query 'git' credentials from GNU R

2021-01-15 Thread Andreas Tille

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gitcreds -- query 'git' credentials from GNU R
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-gitcreds
  Version : 0.1.1
  Upstream Author : Gábor Csárdi
* URL : https://cran.r-project.org/package=gitcreds
* License : MIT
  Programming Lang: GNU R
  Description : query 'git' credentials from GNU R
 Query, set, delete credentials from the 'git' credential
 store. Manage 'GitHub' tokens and other 'git' credentials. This package
 is to be used by other packages that need to authenticate to 'GitHub'
 and/or other 'git' repositories.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gitcreds

Bug#961227: pbuilder misparses build dependencies specifying a version range that have multiple profiles

Control: tags -1 + patch

Hi,

On Thu, May 21, 2020 at 07:17:31PM +0300, Adrian Bunk wrote:
> Depends: apache2 (>= 2.4), curl, debhelper-compat (= 12), dh-sequence-gir, 
> dh-sequence-gnome, glib-networking (>= 2.32.0), gtk-doc-tools, 
> libapache2-mod-php (, libapache2-mod-php (>= 2:7), libbrotli-dev, 
> libgirepository1.0-dev (>= 0.9.5), libglib2.0-dev (>= 2.58), libkrb5-dev, 
> libnss-myhostname, libpsl-dev (>= 0.20), libsqlite3-dev, libxml2-dev, meson 
> (>= 0.48), php (, php (>= 2:7), php-xmlrpc, python3, valac, libglib2.0-doc
> dpkg-deb: warning: parsing file 
> '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
> near line 8 package 'pbuilder-satisfydepends-dummy':
>  'Depends' field, reference to 'libapache2-mod-php':
>  implicit exact match on version number, suggest using '=' instead
> dpkg-deb: warning: parsing file 
> '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
> near line 8 package 'pbuilder-satisfydepends-dummy':
>  'Depends' field, reference to 'libapache2-mod-php':
>  version value starts with non-alphanumeric, suggest adding a space
> dpkg-deb: error: parsing file 
> '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy/DEBIAN/control' 
> near line 8 package 'pbuilder-satisfydepends-dummy':
>  'Depends' field, reference to 'libapache2-mod-php': version contains ' '
> E: pbuilder-satisfydepends failed.

Duh! I ran into this as well now. Thanks for filing it. I think the
patch mostly explains itself. <.*> matches e.g. "<< 2:8) 
" or "<< 2:8)  ".

Helmut

Bug#980132: openvswitch: CVE-2020-27827

Hi Thomas,

On Fri, Jan 15, 2021 at 01:59:18PM +0100, Salvatore Bonaccorso wrote:
> Hi Thomas,
> 
> On Fri, Jan 15, 2021 at 09:29:47AM +0100, Thomas Goirand wrote:
> > On 1/14/21 10:38 PM, Salvatore Bonaccorso wrote:
> > > Source: openvswitch
> > > Version: 2.15.0~git20210104.def6eb1ea+dfsg1-3
> > > Severity: grave
> > > Tags: security upstream
> > > Justification: user security hole
> > > X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> > > 
> > > Control: found -1 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2
> > > Control: found -1 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12
> > > 
> > > Hi,
> > > 
> > > The following vulnerability was published for openvswitch.
> > > 
> > > CVE-2020-27827[0]:
> > > | lldp: avoid memory leak from bad packets
> > > 
> > > If you fix the vulnerability please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > > 
> > > For further information see:
> > > 
> > > [0] https://security-tracker.debian.org/tracker/CVE-2020-27827
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27827
> > > [1] 
> > > https://mail.openvswitch.org/pipermail/ovs-announce/2021-January/000269.html
> > > [2] 
> > > https://github.com/openvswitch/ovs/commit/78e712c0b1dacc2f12d2a03d98f083d8672867f0
> > > 
> > > Regards,
> > > Salvatore
> > 
> > Hi Salvatore,
> > 
> > Thanks for the bug report.
> > 
> > Please find, attached, the debdiff to fix the CVE in Buster. Note that
> > Unstable/Sid has already been patched.
> > 
> > Please allow me to upload this to buster-security.
> 
> Thanks, this is probably fine for a DSA.
> 
> *but* please respin the package and include the fix for CVE-2015-8011
> as well, this is fixed in unstable already.
> 
> For details and upstream commit see:
> https://security-tracker.debian.org/tracker/CVE-2015-8011
> 
> (while at it, please set urgency=high for consistency).
> 
> Can you repost a debdiff with the CVE-2015-8011 fix as well?
> 
> Can you test the package in production?

Actually about the DSA need of both issue I would like to clarify
first one aspect:

https://mail.openvswitch.org/pipermail/ovs-announce/2021-January/000268.html

We have found that Open vSwitch is subject to a remote code execution
exploit when LLDP processing is enabled on an interface.  By default,
interfaces are not configured to process LLDP messages.

(which probably reduces to denial of service with source
fortification)

https://mail.openvswitch.org/pipermail/ovs-announce/2021-January/000269.html

We have found that Open vSwitch is subject to a denial of service
exploit when LLDP processing is enabled on an interface.  By default,
interfaces are not configured to process LLDP messages.

What is your take here on the use of the LLDP processing beeing
enabled?

Regards,
Salvatore

Bug#960492: Any updates?

2021-01-15 Thread Wolfgang Karall-Ahlborn

Hi,

I just saw the mail on debian-devel-announce that the code freeze for
bullseye has begun, will this be reverted before?

Cheers
Wolfgang


signature.asc
Description: PGP signature

Bug#980190: GA release of open-vm-tools 11.2.5 available

2021-01-15 Thread John Wolfe

Package: open-vm-tools
Version 2:11.2.5

open-vm-tools 11.2.5 has been released.

See https://github.com/vmware/open-vm-tools/releases/tag/stable-11.2.5

This source update contains fixes for a couple of detected memory leaks, issues 
reported by Coverity and issues and pull requests submitted to 
https://github.com/vmware/open-vm-tools/

This release provides suggested vmtoolsd pam configuration files for major 
Linux vendors.  By default, the generic pam configuration settings will be used 
by "make install".  To select a Linux vendor specific pam configuration, the 
following line on "./services/vmtoolsd/Makefile"

 $(INSTALL) $(top_srcdir)/pam/generic 
$(DESTDIR)/$(PAM_PREFIX)/pam.d/vmtoolsd

should be edited - replacing "generic" with "debian".

A complete list of the granular changes that are in the open-vm-tools 11.2.5 
release is available at:


https://github.com/vmware/open-vm-tools/blob/stable-11.2.5/open-vm-tools/ChangeLog

VMware internal tracking #: https://jira.eng.vmware.com/browse/VMTOOLS-478

John Wolfe

Bug#980189: flask-security: CVE-2021-21241

On Fri, Jan 15, 2021 at 08:59:31PM +0100, Salvatore Bonaccorso wrote:
[...]
> Admitelly the CVE description currently on MITRE is quite confusing
> reffering to Flask-Security-Too package. But the other references
> pointed out and reviewing the changes seem to apply to the original
> project as well (I might miss something here).

I can answer this part myself "Flask-Security-Too" is the "upstream".

flask-security (3.4.2-1) unstable; urgency=medium
[...]
  * Switch upstream to Flask-Security-Too.
[...]

Regards,
Salvatore

Bug#980189: flask-security: CVE-2021-21241

Source: flask-security
Version: 3.4.2-2
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/Flask-Middleware/flask-security/issues/421
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for flask-security.

CVE-2021-21241[0]:
| The Python "Flask-Security-Too" package is used for adding security
| features to your Flask application. It is an is a independently
| maintained version of Flask-Security based on the 3.0.0 version of
| Flask-Security. In Flask-Security-Too from version 3.3.0 and before
| version 3.4.5, the /login and /change endpoints can return the
| authenticated user's authentication token in response to a GET
| request. Since GET requests aren't protected with a CSRF token, this
| could lead to a malicious 3rd party site acquiring the authentication
| token. Version 3.4.5 and version 4.0.0 are patched. As a workaround,
| if you aren't using authentication tokens - you can set the
| SECURITY_TOKEN_MAX_AGE to "0" (seconds) which should make the token
| unusable.

Admitelly the CVE description currently on MITRE is quite confusing
reffering to Flask-Security-Too package. But the other references
pointed out and reviewing the changes seem to apply to the original
project as well (I might miss something here).


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-21241
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21241
[1] 
https://github.com/Flask-Middleware/flask-security/security/advisories/GHSA-hh7m-rx4f-4vpv
[2] https://github.com/Flask-Middleware/flask-security/pull/422
[3] 
https://github.com/Flask-Middleware/flask-security/commit/61d313150b5f620d0b800896c4f2199005e84b1f
[4] https://github.com/Flask-Middleware/flask-security/issues/421

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#980188: fakeroot FTCBFS: uses AC_RUN_IFELSE

Source: fakeroot
Version: 1.25.3-1.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fakeroot fails to cross build from source, because it uses AC_RUN_IFELSE
without a separate argument for cross building. It's only one occasion.
Please consider applying the attached patch to preseed the test result
on linux at least.

Helmut
--- fakeroot-1.25.3.orig/configure.ac
+++ fakeroot-1.25.3/configure.ac
@@ -50,9 +50,17 @@
 return 0;
   }
 
-}], [ac_cv_use_ipc=sysv], [ac_cv_use_ipc=tcp])
+}], [ac_cv_use_ipc=sysv], [ac_cv_use_ipc=tcp], [ac_cv_use_ipc=cross])
 
-  if test $ac_cv_use_ipc = "tcp"; then
+  if test $ac_cv_use_ipc = cross; then
+if test "$host_os" = linux-gnu; then
+  ac_cv_use_ipc=sysv
+  AC_MSG_RESULT([cross, guessing yes])
+else
+  (set -o posix; set)
+  AC_MSG_ERROR([cross compiling, unknown result for $host_os])
+fi
+  elif test $ac_cv_use_ipc = "tcp"; then
 AC_MSG_RESULT([No, using TCP])
   else
 AC_MSG_RESULT([Yes])

Bug#980187: pmccabe FTCBFS: forces the build architecture compiler

Source: pmccabe
Version: 2.7b-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pmccabe still fails to cross build. It now uses dh_auto_build to pass a
cross compiler to make, but it also overrides the compiler passed by
dh_auto_build with the build architecture compiler as a make default of
debian/rules. A simple way to correctly initialize CC is including
dpkg's buildtools.mk. Please consider applying the attached patch.

Helmut
diff --minimal -Nru pmccabe-2.7b/debian/changelog pmccabe-2.7b/debian/changelog
--- pmccabe-2.7b/debian/changelog   2021-01-14 14:12:08.0 +0100
+++ pmccabe-2.7b/debian/changelog   2021-01-15 20:48:52.0 +0100
@@ -1,3 +1,10 @@
+pmccabe (2.7b-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk initialize CC. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 15 Jan 2021 20:48:52 +0100
+
 pmccabe (2.7b-1) unstable; urgency=low
 
   * New release from new upstream.
diff --minimal -Nru pmccabe-2.7b/debian/rules pmccabe-2.7b/debian/rules
--- pmccabe-2.7b/debian/rules   2020-12-25 19:43:11.0 +0100
+++ pmccabe-2.7b/debian/rules   2021-01-15 20:48:51.0 +0100
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+include /usr/share/dpkg/buildtools.mk
 
 %:
dh $@

Bug#975582: mypaint: MyPaint does not start

2021-01-15 Thread Boyuan Yang

Control: tags -1 +help

在 2021-01-15星期五的 18:58 +0100，Andreas Beckmann写道：
> Followup-For: Bug #975582
> Control: reopen -1
> Control: retitle -1 mypaint: insufficient python dependency
> 
> mypaint ships /usr/lib/mypaint/lib/_mypaintlib.cpython-39-x86_64-
> linux-gnu.so
> but has only a dependency on python3:any - this may be a bug in
> dh_python3 or
> mypaint's usage of dh_python3, but I don't have enough experience
> with
> python packages to spot the error.
> 
> For example, ycmd ships /usr/lib/ycmd/ycm_core.cpython-39-x86_64-
> linux-gnu.so
> and has these python dependencies:
> libpython3.9 (>= 3.9.0~b4), python3 (<< 3.10), python3 (>= 3.9~),
> python3:any

I don't have a solution to it either. Any help would be appreciated.

Thanks,
Boyuan Yang


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

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

2021-01-15 Thread Vagrant Cascadian

On 2021-01-10, harr...@gmx.ph wrote:
> For 32-bit Allwinner boards, the u-boot-sunxi package provides the image
> u-boot-sunxi-with-spl.bin (as well as the standard uboot.elf), but for
> 64-bit boards it provides instead several components such as sunxi-spl.bin,
> u-boot.bin and u-boot-nodtb.bin.  This is because originally ARM Trusted
> Firmware wasn't available in Debian (according to commit 59a1bb4f) and so
> a full bootable image had to be made later on the target system using the
> u-boot-install-sunxi64 script.
...
> arm64 sunxi   orangepi_one_plus   
> /usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot.bin spl/sunxi-spl.bin 
> u-boot-nodtb.bin arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb 
> u-boot-sunxi-with-spl.fit.itb
>
> to:
>
> arm64 sunxi   orangepi_one_plus   
> /usr/lib/arm-trusted-firmware/sun50i_h6/bl31.bin u-boot-sunxi-with-spl.bin
>
> and similarly so could all the other arm64 sunxi entries.

This is fairly new in u-boot, but yes, it's probably possible in most
cases with recent u-boot versions.


> That would mean we could further simplify the u-boot-install-sunxi script.

This part is already done in the 2021.01~rc version experimental.


> Below is a suggested patch to the latest version (commit 81c17086) which
> includes some other suggested small improvements such as eliminating
> temporary files.

Please compare against the u-boot-install-sunxi script in the
2021.01~rc+ versions in experimental.


> Out of interest, what's the reason for including uboot.elf?  It was
> originally added for all boards in commit d22b2e11, removed in c769484b
> then reinstated in 128e7344, but I'm not sure where it gets used.

I tried removing it at some point, but some platforms require it
(e.g. p2371-2180 in u-boot-tegra).


Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#980185: sensible-utils: Errors in man page

2021-01-15 Thread Helge Kreutzmann

Package: sensible-utils
Version: 0.0.14
Severity: minor


A few minutes ago I reported an updated German translation of the man
pages (see #980183). While preparing the update, we noticed the
following errors.

If you fix them, either unfuzzy the German translation or, if you feel
uncomfortable doing so (which is fine, if in doubt, do not unfuzzy
yourself), please provide me de.po (after update of the template) and
I will send  you the updated de.po back. I usually respond within 24
hours.

Now to the errors:

"B make sensible decisions on which editor to call.  "
"Programs in Debian can use these scripts as their default editor."

1. make → makes
2. these scripts → this script

##

"B make sensible decisions on which web browser to call.  "
"Programs in Debian can use this script as their default web browser or "
"emulate their behavior."

make → makes

##

"sensible-pager, sensible paging"

Komma → Dash (i.e. s/, / - /)

##

"B make sensible decisions on which pager to call.  Programs "
"in Debian can use this script as their default pager, or emulate their "
"behavior."

make → makes

##

"B provides a coherent mechanism for selecting and storing a "
"preferred sensible-editor on a per-user basis.  It lists the available "
"editors on a system and interactively prompts the user to select one.  The "
"results are stored as SELECTED_EDITOR in ~/.selected_editor, which is "
"sourced and used by sensible-editor.  SELECTED_EDITOR is overridden by the "   
   <-- here
"VISUAL and EDITOR environment variables."

by sensible-editor → by B(1)

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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#980184: time: should be renamed

2021-01-15 Thread Antonio


Package: time
Version: 1.9-0.1
Severity: normal

Dear Maintainer,
as indicated in the object, "/usr/bin/time" should be renamed as it is covered by the 
"time" command integrated into the bash shell, so this executable is never called, unless 
it is run complete with path or through a specific alias.


Thanks,
Antonio

Bug#980119: libgnutls30: "An unexpected TLS packet was received" when connecting to FTPS (FTP/TLS) servers

2021-01-15 Thread cacatoes

No success on my side, it times out, or doesn't seem to send/process the
USER/PASS if I input them, maybe I was late this time.
The server has IP blacklisting so it doesn't help...

~~~
$ gnutls-cli --starttls-proto=ftp myftphost -V
Processed 126 CA certificate(s).
Resolving 'myftphost:ftp'...
Connecting to 'ip.ip.ip.ip:21'...
Negotiating FTP STARTTLS
starttls: sending: FEAT

starttls: waiting for: "211 "
starttls: received: 220 Some Welcome Message

starttls: received: 521 Not logged in - Secure authentication required

USER myuser
PASS error receiving '211 ': Timeout
~~~

With the same host but with Filezilla it was able to receive the
certificate before trying to Login.

With some other host (the one used by OP) I receive the certificate and
go into simple client mode, so it could have worked.

Le vendredi 15 janvier 2021 à 07:02:35, Andreas Metzler a écrit :
> On 2021-01-14 "Boyd Stephen Smith Jr."  wrote:
> > Package: libgnutls30
> > Version: 3.7.0-5
> > Severity: normal
> 
> > Dear Maintainer,
> 
> > Trying to upload some files to a game hosting provider that only allows FTPS
> > (not SFTP) access.  Provider is akliz.net.
> 
> > Each customer gets a private virtual (vsftp?) instance.  I'm connecting to
> > bos-sr-2-36.akliz.net
> 
> > In both FileZilla 3.51.0-1 and lftp 4.8.4-2+b1 I get an error _after_ a
> > successful login when trying to list the contents of the current directory.
> [...]
> 
> Is this reproducible with gnutls-cli?
> 
> -
> gnutls-cli  --starttls-proto=ftp bos-sr-2-36.akliz.net
> ...
> USER _loginhere_
> PASS _passwordhere_
> PWD
> -
> 
> cu Andreas
> -- 
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'

Bug#976811: transition: php8.0

2021-01-15 Thread Ondřej Surý

Thinking about it, security-wise it might be better. Microsoft will support the 
security backports to EOL versions of PHP 7.x, but they announced they won’t do 
it for PHP 8.x, so we are (maybe) bit more covered with PHP 7.4.

Ondrej
--
Ondřej Surý  (He/Him)

> On 15. 1. 2021, at 19:45, Moritz Mühlenhoff  wrote:
> 
> Am Thu, Jan 14, 2021 at 10:28:41AM +0100 schrieb Sebastian Ramacher:
>> I'm also CCing the security team for their input in case the have a
>> strong opinion on this transition.
> 
> It's fine. PHP 8 would have been great, but it is what it is.
> 
> Cheers,
>Moritz

Bug#980183: sensible-utils: [INTL:de] updated German man page translation

2021-01-15 Thread Helge Kreutzmann

Package: sensible-utils
Version: 0.0.14
Severity: wishlist
Tags: patch l10n

Please find the updated German man page translation for sensible-utils
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of sensible-utils man page template to German
# Copyright (C) Helge Kreutzmann , 2011, 2017, 2021.
# This file is distributed under the same license as the sensible-utils package.
#
msgid ""
msgstr ""
"Project-Id-Version: sensible-utils man page 0.0.14\n"
"POT-Creation-Date: 2021-01-12 22:34+\n"
"PO-Revision-Date: 2021-01-15 19:56+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: utf-8\n"

#. type: TH
#: sensible-editor.man sensible-browser.man
#, no-wrap
msgid "SENSIBLE-EDITOR"
msgstr "SENSIBLE-EDITOR"

#. type: TH
#: sensible-editor.man
#, no-wrap
msgid "14 Nov 2018"
msgstr "14. Nov. 2018"

#. type: TH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "Debian"
msgstr "Debian"

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "NAME"
msgstr "NAME"

#. type: Plain text
#: sensible-editor.man
msgid "sensible-editor - sensible editing"
msgstr "sensible-editor - vernünftiges Bearbeiten"

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "SYNOPSIS"
msgstr "ÜBERSICHT"

#. type: Plain text
#: sensible-editor.man
msgid "B [OPTIONS...]"
msgstr "B [OPTIONEN …]"

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

# FIXME make → makes
# FIXME these scripts → this script
#. type: Plain text
#: sensible-editor.man
msgid ""
"B make sensible decisions on which editor to call.  "
"Programs in Debian can use these scripts as their default editor."
msgstr ""
"B trifft vernünftige Entscheidungen, welcher Editor "
"aufgerufen wird. Programme in Debian können dieses Skript als ihren Standard-"
"Editor benutzen."

#. type: Plain text
#: sensible-editor.man
msgid "B try to do in the following order:"
msgstr "B versucht Folgendes in nachfolgender Reihenfolge:"

#. type: IP
#: sensible-editor.man
#, no-wrap
msgid "\\n[step]"
msgstr "\\n[step]"

#. type: Plain text
#: sensible-editor.man
msgid "if B environment variable exists, execute B"
msgstr ""
"Falls die Umgebungsvariable B existiert, führt es B aus."

#. type: IP
#: sensible-editor.man
#, no-wrap
msgid "\\n+[step]"
msgstr "\\n+[step]"

#. type: Plain text
#: sensible-editor.man
msgid "if B environment variable exists, execute B"
msgstr ""
"Falls die Umgebungsvariable B existiert, führt es B aus."

#. type: Plain text
#: sensible-editor.man
msgid ""
"source the contents of file I<~/.selected_editor> and, if B "
"environment variable exists execute B"
msgstr ""
"Es liest den Inhalt der Datei I<~/.selected_editor> ein und führt, falls die "
"Umgebungsvariable B existiert, B aus."

#. type: Plain text
#: sensible-editor.man
msgid "run B command"
msgstr "Es führt B aus."

#. type: Plain text
#: sensible-editor.man
msgid "finally run B command"
msgstr "Schließlich wird B ausgeführt."

#. type: SH
#: sensible-editor.man sensible-pager.man select-editor.man
#, no-wrap
msgid "SEE ALSO"
msgstr "SIEHE AUCH"

#. type: Plain text
#: sensible-editor.man
msgid "B(7)  for documentation of the EDITOR, VISUAL variables"
msgstr "B(7) für die Dokumentation der Variablen EDITOR, VISUAL"

#. type: Plain text
#: sensible-editor.man
msgid "B(1)  for changing a user's default editor."
msgstr "B(1) zum Ändern des Standards-Editors des Benutzers."

#. type: Plain text
#: sensible-editor.man
msgid "B(1)  for default system wide editor."
msgstr "B(1) für den systemweiten Vorgabe-Editor."

#. type: SH
#: sensible-editor.man
#, no-wrap
msgid "BUGS"
msgstr "FEHLER"

#. type: Plain text
#: sensible-editor.man
msgid ""
"This command is protected against trivial fork bomb, when user set "
"B wider loops are still possible."
msgstr ""
"Dieser Befehl ist gegen triviale Fork-Bomben geschützt. Wenn der Benutzer "
"B setzt, sind weitere Schleifen noch möglich."

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#, no-wrap
msgid "STANDARD"
msgstr "STANDARD"

#. type: Plain text
#: sensible-editor.man sensible-browser.man sensible-pager.man
msgid ""
"Documentation of behavior of sensible-utils under a debian system is "
"available under section 11.4 of debian-policy usually installed under /usr/"
"share/doc/debian-policy (you might need to install debian-policy)"
msgstr ""
"Die Beschreibung des Verhaltens der Sensible-Utils in einem Debian-System "
"ist unter Abschnitt 11.4 der

Bug#928661: UnicodeDecodeError for pyzor -s mbox

2021-01-15 Thread Timo van Roermund


I believe this bug was fixed in version 1:1.0.0-6.

Cheers,

Timo

Bug#979984: breaks on check with "NameError: name 'get_binary_stdin' is not defined"

2021-01-15 Thread Timo van Roermund


This bug was fixed in version 1:1.0.0-6.

Cheers,

Timo

Bug#976811: transition: php8.0

2021-01-15 Thread Moritz Mühlenhoff

Am Thu, Jan 14, 2021 at 10:28:41AM +0100 schrieb Sebastian Ramacher:
> I'm also CCing the security team for their input in case the have a
> strong opinion on this transition.

It's fine. PHP 8 would have been great, but it is what it is.

Cheers,
Moritz

Bug#980181: libssw: please mark one symbol as optional

2021-01-15 Thread Gianfranco Costamagna

Source: libssw
Version: 1.1-11
tags: patch

When built with -O3 optimization level, on s390x a symbol disappears.

Marking it as optional fixes the issue.

- 
_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
 1.1
+ 
(optional)_ZNSt6vectorIjSaIjEE17_M_realloc_insertIJRKjEEEvN9__gnu_cxx17__normal_iteratorIPjS1_EEDpOT_@Base
 1.1

thanks for considering it

Gianfranco

Bug#980180: Missing support for Intel Elkhart Lake Ethernet

2021-01-15 Thread Jan Kiszka

Package: linux-image-amd64
Version: 5.10.4-1

In order to support the Ethernet controller found on Intel Elkhart Lake
SOCs which are STMMAC-based, CONFIG_DWMAC_INTEL and dependencies are
needed. Please enable.

Bug#980119: libgnutls30: "An unexpected TLS packet was received" when connecting to FTPS (FTP/TLS) servers

2021-01-15 Thread Andreas Metzler

On 2021-01-14 "Boyd Stephen Smith Jr."  wrote:
> Package: libgnutls30
> Version: 3.7.0-5
> Severity: normal

> Dear Maintainer,

> Trying to upload some files to a game hosting provider that only allows FTPS
> (not SFTP) access.  Provider is akliz.net.

> Each customer gets a private virtual (vsftp?) instance.  I'm connecting to
> bos-sr-2-36.akliz.net

> In both FileZilla 3.51.0-1 and lftp 4.8.4-2+b1 I get an error _after_ a
> successful login when trying to list the contents of the current directory.
[...]

Is this reproducible with gnutls-cli?

-
gnutls-cli  --starttls-proto=ftp bos-sr-2-36.akliz.net
...
USER _loginhere_
PASS _passwordhere_
PWD
-

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#916692: ITA: cuyo

2021-01-15 Thread Emmanuel Arias

Hi,

sorry for the delay.

Please see #980178. Could you review/sponsor it, please?

Cheers

El dom, 3 de ene. de 2021 a la(s) 08:03, Jean-Michel Vourgère (
nir...@debian.org) escribió:

> Hello Emmanuel
>
> Do you still plan to adopt cuyo?

Bug#694101: closed by Bernhard Schmidt (Closing bugs opened for old Gtk client)

2021-01-15 Thread Tomas Pospisek


Thanks a lot Bernhard that makes sense!
*t

On Fri, 15 Jan 2021, Debian Bug Tracking System wrote:


This is an automatic notification regarding your Bug report
which was filed against the linphone package:

#694101: immediate segfault without config file

It has been closed by Bernhard Schmidt .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Bernhard Schmidt 
 by
replying to this email.


--
694101: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694101
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#975582: mypaint: MyPaint does not start

Followup-For: Bug #975582
Control: reopen -1
Control: retitle -1 mypaint: insufficient python dependency

mypaint ships /usr/lib/mypaint/lib/_mypaintlib.cpython-39-x86_64-linux-gnu.so
but has only a dependency on python3:any - this may be a bug in dh_python3 or
mypaint's usage of dh_python3, but I don't have enough experience with
python packages to spot the error.

For example, ycmd ships /usr/lib/ycmd/ycm_core.cpython-39-x86_64-linux-gnu.so
and has these python dependencies:
libpython3.9 (>= 3.9.0~b4), python3 (<< 3.10), python3 (>= 3.9~), python3:any


Andreas

Bug#973934: RFS: c-evo/285+dfsg.5-5 [ITP 968495] -- Empire Building Game

2021-01-15 Thread Peter

I have uploaded a new version of C-evo to Mentors.

Download link is now
dget -x 
https://mentors.debian.net/debian/pool/main/c/c-evo/c-evo_285+dfsg.5-5.dsc


Peter

Bug#971953: linux-image-5.8: Intel Bay Trail PMIC, laptop screen backlight cannot be adjusted

2021-01-15 Thread William Sones

Hi Everyone

I've recompiled the Debian Backports kernel 5.9.6 (with config changes
documented above by dev...@inventati.org) on the Asus T100TA along with an
i915 driver (in the firmware-misc-nonfree package) from Debian
buster-backports. I can confirm screen backlight can be adjusted and power
consumption is reduced. I also ran dmesg after triggering hibernation
(closing the laptop). It suggests the laptop is now moving into idle
without a problem, but can't enter into hibernation. It still seems to be
unable to find crystalcove, but now can control backlight with PWM.

Hope this helps!

Will

$sudo dmesg
...
[0.00] DMI: ASUSTeK COMPUTER INC. T100TAM/T100TAM, BIOS T100TAM.205
07/25/2014
...
[3.972360] i915 :00:02.0: vgaarb: deactivate vga console
[3.973773] i915 :00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[3.974167] i915 :00:02.0: cannot find GPIO chip gpio_crystalcove,
deferring
[3.974169] i915 :00:02.0: [drm] *ERROR* Failed to own gpio for
panel control
[3.974697] i915 :00:02.0: [drm] Using PMIC PWM for LCD backlight
control
[3.981676] [drm] Initialized i915 1.6.0 20200715 for :00:02.0 on
minor 0
...
[ 3196.039364] PM: suspend entry (s2idle)
[ 3196.058281] Filesystems sync: 0.018 seconds
[ 3196.061135] (NULL device *): firmware: direct-loading firmware
regulatory.db
[ 3196.068645] (NULL device *): firmware: direct-loading firmware
brcm/brcmfmac43241b4-sdio.txt
[ 3196.068741] (NULL device *): firmware: direct-loading firmware
brcm/brcmfmac43241b4-sdio.bin
[ 3196.070542] (NULL device *): firmware: direct-loading firmware
intel/fw_sst_0f28.bin
[ 3196.071389] (NULL device *): firmware: direct-loading firmware
regulatory.db.p7s
[ 3196.071466] Freezing user space processes ... (elapsed 0.031 seconds)
done.
[ 3196.103199] OOM killer disabled.
[ 3196.103201] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 3196.105184] printk: Suspending console(s) (use no_console_suspend to
debug)
[ 3196.154980] i2c_hid i2c-SIS0817:00: failed to change power setting.
[ 3200.390971] OOM killer enabled.
[ 3200.390973] Restarting tasks ... done.
[ 3200.421981] PM: suspend exit
[ 3217.236676] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

$ apt show firmware-misc-nonfree
Package: firmware-misc-nonfree
Version: 20200918-1~bpo10+1
...

Bug#980179: ITP: kubecolor -- colorizes kubectl output

2021-01-15 Thread Stephen Gelman

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: kubecolor
  Version : 0.0.9-1
  Upstream Author : Hidetatsu Yaginuma
* URL : https://github.com/dty1er/kubecolor
* License : Expat
  Programming Lang: Go
  Description : colorizes kubectl output

 kubecolor is a wrapper for the kubernetes kubectl command that colorizes its
 output

This package will be group maintained by the golang team

Bug#980178: RFS: cuyo/2.1.0-1 [ITA] -- Tetris-like game with very impressive effects

2021-01-15 Thread Emmanuel Arias

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "cuyo":

 * Package name: cuyo
   Version : 2.1.0-1
   Upstream Author : Immanuel Halupczok 
 * URL : http://www.karimmi.de/cuyo/
 * License : GPL2.0+
 * Vcs : https://salsa.debian.org/games-team/cuyo
   Section : games

It builds those binary packages:

  cuyo-data - data files for the game cuyo
  cuyo - Tetris-like game with very impressive effects

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/cuyo/

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/c/cuyo/cuyo_2.1.0-1.dsc

Changes since the last upload:

 cuyo (2.1.0-1) unstable; urgency=medium
 .
   * New upstream release
   * New maintainer (Closes: #916692).
 - Add myself to Maintainer field on d/control file.
   * Modify d/control field:
 - Bump Standards-Version to 4.5.1.
 - Add debhelper-compat = 13 to Build-Depends field.
 - Delete d/compat file.
   * Update Vcs-* on d/control files:
 - I create the project on salsa.
   * wrap-and-sort.
   * Bump d/watch version.

Regards,
-- 
  Emmanuel Arias

Bug#979072: Bug#979047: RM: pepperflashplugin-nonfree -- RoQA; No longer work; upstream eol