Bug#969057: libreswan make opportunistic and cavp autopkgtest skippable

[Daniel Kahn Gillmor]

On Tue 2021-01-12 18:33:55 +0100, Eduardo Barretto wrote:
> Feel free to correct me at any point, but here is what I've experienced.
>
> It seems like this issue appeared after Launchpad builders started to
> recognize the needs-internet restriction, and it seems that
> needs-internet is not enough. Here is what the test was returning
> before:
> opportunisticSKIP unknown restriction needs-internet
> And after, when I was applying some fixes:
> opportunisticFAIL non-zero exit status 1
>
> That's why we added the skippable and exit 77.

ok, but what does "recognize the needs-internet restriction" mean?  the
definition of "needs-internet" [0] is:

The test needs unrestricted internet access, e.g. to download test
data that's not shipped as a package, or to test a protocol
implementation against a test server. Please also see the note about
Network access later in this document.

[0] 
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst


The "Network access" section also says:

[…] In Ubuntu's infrastructure access to sites other than
*.ubuntu.com and *.launchpad.net happens via a proxy (limited to DNS
and http/https).

The patches you've proposed, if i'm understanding them correctly, cause
the test to be skipped because the test really does use unrestricted
Internet -- not only DNS and HTTP/HTTPS.

This makes me think that either Ubuntu's infrastructure shouldn't
consider itself as offering "unrestricted internet access" (meaning, it
should automatically skip any test with a "needs-internet" restriction),
or it should run any test that has a "needs-internet" restriction
outside of the proxied filter.

If there's a need for a different constraint (like
"needs-only-dns-and-http") to match what ubuntu's infrastructure offers,
that might be a separate question.  But either the documentation of what
"needs-internet" means needs to change, or Ubuntu's infrastructure
should not claim to support it, if i'm reading the docs correctly.

thanks for raising this issue!  I'm happy to talk about it more if
you've got a different interpretation.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#980030: vim-gtk3: gvim Could not load pixbuf defaults to vim with no gui

[P V Mathew]

Package: vim-gtk3
Version: 2:8.2.1913-1+b2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   After latest system update gvim does not load gui.It shows following
error messages.
* 
   (gvim:1792): Gtk-WARNING **: 12:28:53.889: Could not load a
pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png.
This may indicate that pixbuf loaders or the mime database could not be
found.
**
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
assertion failed (error == NULL): Failed to load
/org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image
file format (gdk-pixbuf-error-quark, 3)
Bail out!
Gtk:ERROR:../../../../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon:
assertion failed (error == NULL): Failed to load
/org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognized image
file format (gdk-pixbuf-error-quark, 3)
Vim: Caught deadly signal ABRT
Vim: Finished.
E852: The child process failed to start the GUI
Press ENTER or type command to continue
*
   Tried update-mime-database /usr/share/mime and also
   /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders 
--update-cache
   Also tried after removing .vimrc.
-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk3
/usr/bin/vim is /usr/bin/vim.gtk3
/usr/bin/gvim is /usr/bin/vim.gtk3

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=ml_IN.UTF-8@pvm, LC_CTYPE=ml_IN.UTF-8@pvm (charmap=UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim-gtk3 depends on:
ii  libacl1  2.2.53-9
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libcanberra0 0.30-7
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.4-1
ii  libgpm2  1.20.7-6
ii  libgtk-3-0   3.24.24-1
ii  libice6  2:1.0.10-1
ii  liblua5.2-0  5.2.4-1.1+b3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libperl5.32  5.32.0-6
ii  libpython3.9 3.9.1-1
ii  libruby2.7   2.7.2-3
ii  libselinux1  3.1-2+b2
ii  libsm6   2:1.2.3-1
ii  libtcl8.68.6.11+dfsg-1
ii  libtinfo66.2+20201114-2
ii  libx11-6 2:1.6.12-1
ii  libxt6   1:1.2.0-1
ii  vim-common   2:8.2.1913-1
ii  vim-gui-common   2:8.2.1913-1
ii  vim-runtime  2:8.2.1913-1

vim-gtk3 recommends no packages.

Versions of packages vim-gtk3 suggests:
pn  cscope
ii  fonts-dejavu  2.37-2
ii  gnome-icon-theme  3.12.0-3
pn  vim-doc   

-- no debconf information

Bug#777291: gpm should provides systemd services

[Moritz Muehlenhoff]

On Wed, Jan 13, 2021 at 05:37:27AM +0100, Axel Beckert wrote:
> Control: tag -1 + pending
> 
> Hi Moritz,
> 
> Moritz Mühlenhoff wrote:
> > > Moritz Mühlenhoff wrote:
> > > > Attached is a patch against current sid which adds a systemd unit
> > > > for gpm. I've been using it for a few days on my system without
> > > > any issues.
> > > 
> > > Thanks! Committed to git and pushed.
> > > 
> > > Will probably do an upload tomorrow. To tired now and still some other
> > > things to fix.
> > 
> > Mmhh, actually, please hold back an upload. I just ran into an issue where 
> > it
> > failed to start, I need to poke at this some more and see if I can reproduce
> > this. I'll update the bug with more information.
> 
> I nevertheless based my current solution on your initial .service
> file.
> 
> Mind trying to build a package off https://salsa.debian.org/debian/gpm
> and see if works for you? Would like to upload soon-ish, latest this
> weekend.

Sure, I'll start testing it this evening!

Cheers,
Moritz

Bug#980013: libreoffice fails throwing com::sun::star::uno::RuntimeException

[Rene Engelhard]

tag 980013 + moreinfo

tag 980013 + unreproducible

thanks


Hi,

Am 12.01.21 um 22:54 schrieb Nick Bailey:
> access("/tmp", W_OK)= 0
> getuid()= 1000
> socket(AF_UNIX, SOCK_STREAM, 0) = 3
> fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
> connect(3, {sa_family=AF_UNIX, 
> sun_path="/tmp/OSL_PIPE_1000_SingleOfficeIPC_e68685edcbca78b5debcd31a7a395fac"},
>  110) = -1 ECONNREFUSED (Connection refused)
> close(3)= 0
> stat("/proc/version", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> stat("/usr/lib/libreoffice/program/", {st_mode=S_IFDIR|0755, st_size=20480, 
> ...}) = 0
> openat(AT_FDCWD, "/sys/dev/block/254:0/queue/rotational", O_RDONLY) = 3
> close(3)= 0
Which is normal tht
> The named OSL_PIPE is left in /tmp after the program fails.
>
> This behaviour has arisen after (but not immediately after) upgrading
> the installation from Buster to Bullseye. 
But?
> I cannot find any left-over packages
> from the old installation.

I can find brokeness in your installation.


Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE


Nvidia crap?


> Versions of packages libreoffice-core recommends:
> ii  gstreamer1.0-libav 1:1.14.4-dmo3
[...]
> ii  gstreamer1.0-plugins-ugly  1:1.14.4-dmo2

Sigh, dmo.



> Versions of packages libreoffice-writer depends on:
> ii  libabw-0.1-1 0.1.3-1
> ii  libc62.31-9
> ii  libe-book-0.1-1  0.1.3-2
> ii  libepubgen-0.1-1 0.1.1-1
> ii  libetonyek-0.1-1 0.1.9-4
> ii  libgcc-s110.2.1-3
> ii  libicu67 67.1-5
> ii  libmwaw-0.3-30.3.17-1
> ii  libodfgen-0.1-1  0.1.7-1
> ii  libreoffice-base-core1:7.0.4-3
> ii  libreoffice-common   1:7.0.4-3
> ii  libreoffice-core 1:7.0.4-3
> pn  librevenge-0.0-0 
[...]
> pn  libwpd-0.10-10   
> pn  libwpg-0.3-3 

How on earth did you get into a situation where a dependency is not
there? Did you force it's removal of what?


Anyways, just works for me, and for gazillions of other people since if
it was a real problem a report would have been there far earlier.


Regards,


Rene

Bug#980028: sudoedit runs editor as root

[James McCoy]

Package: sudo
Version: 1.9.5-1
Severity: important
Tags: upstream

This is fixed in 1.9.5p1:

 * Fixed a regression introduced in sudo 1.9.5 where the editor run
   by sudoedit was set-user-ID root unless SELinux RBAC was in use.
   The editor is now run with the user's real and effective user-IDs.

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

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

Versions of packages sudo depends on:
ii  libaudit1   1:3.0-2
ii  libc6   2.31-9
ii  libpam-modules  1.4.0-2
ii  libpam0g1.4.0-2
ii  libselinux1 3.1-2+b2
ii  lsb-base11.1.0
ii  zlib1g  1:1.2.11.dfsg-2

Bug#980027: artikulate: conffile not removed: /etc/xdg/artikulate.knsrc

[Paul Wise]

Package: artikulate
Version: 4:20.12.1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

   $ p=artikulate ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete
   artikulate: obsolete-conffile /etc/xdg/artikulate.knsrc
    /etc/xdg/artikulate.knsrc 99c112e353852d9da575d13d84e9d7ed obsolete
   
-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages artikulate depends on:
ii  kio  5.77.0-3
ii  libc6    2.31-9
ii  libgcc-s1    10.2.1-3
ii  libkf5archive5   5.77.0-2
ii  libkf5configcore5    5.77.0-2
ii  libkf5configgui5 5.77.0-2
ii  libkf5coreaddons5    5.77.0-2
ii  libkf5crash5 5.77.0-2
ii  libkf5i18n5  5.77.0-2
ii  libqt5core5a 5.15.2+dfsg-2
ii  libqt5gui5   5.15.2+dfsg-2
ii  libqt5multimedia5    5.15.2-2
ii  libqt5multimedia5-plugins    5.15.2-2
ii  libqt5qml5   5.15.2+dfsg-2
ii  libqt5quick5 5.15.2+dfsg-2
ii  libqt5sql5   5.15.2+dfsg-2
ii  libqt5widgets5   5.15.2+dfsg-2
ii  libqt5xml5   5.15.2+dfsg-2
ii  libqt5xmlpatterns5   5.15.2-2
ii  libstdc++6   10.2.1-3
ii  qml-module-org-kde-kirigami2 5.77.0-2
ii  qml-module-org-kde-kquickcontrolsaddons  5.77.0-2
ii  qml-module-org-kde-newstuff  5.77.0-3
ii  qml-module-qtqml-models2 5.15.2+dfsg-2
ii  qml-module-qtquick-controls  5.15.2-2
ii  qml-module-qtquick-controls2 5.15.2+dfsg-2
ii  qml-module-qtquick-dialogs   5.15.2-2
ii  qml-module-qtquick-layouts   5.15.2+dfsg-2
ii  qml-module-qtquick-shapes    5.15.2+dfsg-2
ii  qml-module-qtquick2  5.15.2+dfsg-2

artikulate recommends no packages.

artikulate suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#980026: blueman-applet will sometimes be duplicated in the panel

[Neil]

Package: blueman
Version: 2.1.4-1+b1
Severity: minor

Hello,
I'll attach two screenshots where we can see 2 blueman-applets,  I don't know
what causes this,  or how to reproduce it,  it will simply happen sometimes
after powering on or rebooting.
(I'm using Xfce in sid, this happened also with Xfce 4.14,  I'm not sure if
this is related to Xfce, so if does sorry
I can also reproduce this in debian testing)).



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

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

Versions of packages blueman depends on:
ii  adwaita-icon-theme3.38.0-1
ii  bluez 5.55-3
ii  bluez-obexd   5.55-3
ii  dbus  1.12.20-1
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-1
ii  gir1.2-ayatanaappindicator3-0.1   0.5.5-2
ii  gir1.2-gdkpixbuf-2.0  2.42.2+dfsg-1
ii  gir1.2-glib-2.0   1.66.1-1+b1
ii  gir1.2-gtk-3.03.24.24-1
ii  gir1.2-nm-1.0 1.28.0-2+b1
ii  gir1.2-pango-1.0  1.46.2-3
ii  libbluetooth3 5.55-3
ii  libc6 2.31-9
ii  libglib2.0-0  2.66.4-1
ii  libpulse-mainloop-glib0   14.0-2
ii  librsvg2-common   2.50.2+dfsg-1
ii  policykit-1   0.105-29
ii  python3   3.9.1-1
ii  python3-cairo 1.16.2-4+b2
ii  python3-gi3.38.0-1+b2
ii  python3-gi-cairo  3.38.0-1+b2
ii  xfce4-notifyd [notification-daemon]   0.6.2-1

Versions of packages blueman recommends:
ii  pulseaudio-module-bluetooth  14.0-2

blueman suggests no packages.

-- no debconf information

Bug#960564: usbauth: autopkgtest fails on Ubuntu

[Logan Rosen]

Hi,

On Mon, 10 Aug 2020 11:41:08 +0800 Alvin Chen  wrote:
> Could you please check if this patch works on your environment?
>
> https://salsa.debian.org/debian/usbauth/-/merge_requests/24/diffs

I synced 1.0.3-1 (which contains that patch) to Ubuntu, and the
autopkgtest succeeded [1]. You can feel free to close this out
accordingly.

Thanks,
Logan

[1] https://autopkgtest.ubuntu.com/packages/u/usbauth/hirsute/amd64

Bug#957610: nn: ftbfs with GCC-10

[Logan Rosen]

Source: nn
Version: 6.7.3-12
Followup-For: Bug #957610
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/07-gcc-10.diff: Fix FTBFS with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru nn-6.7.3/debian/patches/07-gcc-10.diff 
nn-6.7.3/debian/patches/07-gcc-10.diff
--- nn-6.7.3/debian/patches/07-gcc-10.diff  1969-12-31 19:00:00.0 
-0500
+++ nn-6.7.3/debian/patches/07-gcc-10.diff  2021-01-12 23:33:20.0 
-0500
@@ -0,0 +1,114 @@
+--- a/global.h
 b/global.h
+@@ -172,7 +172,7 @@
+ extern group_header *current_group, *group_sequence, *rc_sequence;
+ 
+ 
+-int l_g_index, s_g_first;
++extern int l_g_index, s_g_first;
+ 
+ #define   Loop_Groups_Number(num) \
+ for (num = 0; num < master.number_of_groups; num++)
+--- a/db.c
 b/db.c
+@@ -130,6 +130,8 @@
+ static char*group_position = NULL;
+ static article_number current_digest_article = 0;
+ 
++int l_g_index, s_g_first;
++
+ int
+ init_group(register group_header * gh)
+ {
+--- a/nn_term.h
 b/nn_term.h
+@@ -48,7 +48,7 @@
+  */
+ 
+ 
+-int prompt_line;  /* prompt line */
++extern int prompt_line;   /* prompt line */
+ 
+ #define   P_MOVE  (char *)1
+ #define P_REDRAW  (char *)5
+--- a/term.c
 b/term.c
+@@ -140,6 +140,7 @@
+ int show_current_time = 1;
+ int conf_dont_sleep = 0;
+ int prompt_length;
++int prompt_line;
+ int terminal_speed = 0;
+ int slow_speed = 1200;
+ int any_message = 0;
+--- a/articles.c
 b/articles.c
+@@ -33,6 +33,9 @@
+ int body_search_header = 0;
+ int cross_post_limit = 0;
+ 
++article_number  n_articles;
++article_header **articles;
++
+ extern int  ignore_fancy_select;
+ extern int  killed_articles;
+ 
+--- a/articles.h
 b/articles.h
+@@ -10,8 +10,8 @@
+ 
+ /* article headers */
+ 
+-article_number  n_articles;
+-article_header **articles;
++extern article_number  n_articles;
++extern article_header **articles;
+ 
+ 
+ typedef struct thunk {
+--- a/news.h
 b/news.h
+@@ -44,7 +44,9 @@
+ char   *ng_xlines;/* lines (from header)   */
+ int ng_lines; /* lines (decoded)   */
+ char   *ng_comment;   /* comment-to (rfmail)   */
+-}   news;
++};
++
++extern struct news_header news;
+ 
+ 
+ /*
+@@ -62,7 +64,9 @@
+ char   *dg_to;/* to*/
+ 
+ int dg_lines; /* lines (pseudo field)  */
+-}   digest;
++};
++
++extern struct digest_header digest;
+ 
+ 
+ #define   NEWS_HEADER_BUFFER  4096
+--- a/digest.c
 b/digest.c
+@@ -23,6 +23,8 @@
+ 
+ /* digest.c */
+ 
++struct digest_header digest;
++
+ static char   **dg_hdr_field(register char *lp, int all);
+ 
+ int strict_from_parse = 2;
+--- a/news.c
 b/news.c
+@@ -22,6 +22,8 @@
+ 
+ /* news.c */
+ 
++struct news_header news;
++
+ static char   **art_hdr_field(register char *lp, int all);
+ 
+ 
diff -Nru nn-6.7.3/debian/patches/series nn-6.7.3/debian/patches/series
--- nn-6.7.3/debian/patches/series  2020-04-04 05:57:39.0 -0400
+++ nn-6.7.3/debian/patches/series  2021-01-12 23:25:33.0 -0500
@@ -5,3 +5,4 @@
 04-spelling.diff
 05-fix-compile.diff
 06-maintainers-additions.diff
+07-gcc-10.diff

Bug#972344: bash automatically selects the copied text

[王昊然]

I also found this feature causes confusing in some terminals. However
disabling bracketed paste for BASH worked good enough for me: just
adding 'bind "set enable-bracketed-paste off"' into /etc/bash.bashrc.

Bug#979978: lime-forensics-dkms: unable to make or make install due to error set_fs

[Eriberto Mota]

Thanks a lot Gregory and Paul.

I will use a PR from upstream site[1]. I tested this patch and it works fine.

The patch used in Ubuntu seems a bit wrong[2].

[1] https://github.com/504ensicsLabs/LiME/pull/85
[2] https://github.com/504ensicsLabs/LiME/pull/83

Cheers,

Eriberto

Em ter., 12 de jan. de 2021 às 11:26, Paul Wise  escreveu:
>
> Control: severity -1 serious
> Control: tags -1 - ftbfs
> Control: tags -1 + patch
>
> On Tue, 12 Jan 2021 09:00:57 -0500 Gregory Lamarche wrote:
>
> >* What was the outcome of this action? instead of building the modules 
> > it just errors out and gives error
>
> It looks like Ubuntu have a patch for this:
>
> https://patches.ubuntu.com/l/lime-forensics/lime-forensics_1.9.1-1ubuntu1.patch
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

Bug#777291: gpm should provides systemd services

[Axel Beckert]

Control: tag -1 + pending

Hi Moritz,

Moritz Mühlenhoff wrote:
> > Moritz Mühlenhoff wrote:
> > > Attached is a patch against current sid which adds a systemd unit
> > > for gpm. I've been using it for a few days on my system without
> > > any issues.
> > 
> > Thanks! Committed to git and pushed.
> > 
> > Will probably do an upload tomorrow. To tired now and still some other
> > things to fix.
> 
> Mmhh, actually, please hold back an upload. I just ran into an issue where it
> failed to start, I need to poke at this some more and see if I can reproduce
> this. I'll update the bug with more information.

I nevertheless based my current solution on your initial .service
file.

Mind trying to build a package off https://salsa.debian.org/debian/gpm
and see if works for you? Would like to upload soon-ish, latest this
weekend.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

[Ryutaroh Matsumoto]

Control: tags -1 + moreinfo

Hi Nicholas, thanks again for your response.

In my new year holidays, I built the upstream (not Debian)
5.10.6 kernel and saw what happend. The situation got better,
* booting always succeeded (at least I did not observe it)
* tpm error persisted
* I did "systemctl poweroff" immediately after I got "login:".
  The shutdown behavior was very strange, many systemd services cannot be
  stopped cleanly and timeouts occurred many times. I cut the power line
  after waiting 5 minutes or so.

I'd like to see the situation again after the upstream version gets 5.10.10 or
so, because, for I now have very little (or no) trust on the upstream (not 
Debian)
kernel as

* arm64 kernel does not boot at all on raspberry pi 4B on USB MSD
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694
* arm64 kernel did not boot on raspberry pi 4B on SD card,
  (all usual booting devices did not work). It seems fixed in upstream 5.10.6
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977645
* wireless network does not work on raspberry pi 4B
  (this has not been reported as booting on my raspi has not been confirmed
  on any Debian kernel).

Simply, I am tired of seeing if 5.10.? kernel works normally or not on my 
machines.
I have seen little problem in Debian 5.9.* series.
Since 5.10 is LTS, maybe 5.10.10 or 5.10.20 will gets as good as 5.9.15.
I will stick to Debian 5.9.15 kernel on my amd64 notebook and raspi4b
for a while...

Best regards, Ryutaroh Matsumoto

Bug#980024: pdmenu: FTBFS with GCC 10

[Logan Rosen]

Source: pdmenu
Version: 1.3.4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

pdmenu currently FTBFS in unstable with GCC 10 as default. There is a
patch in the linked VCS repo from September that has not been uploaded -
can you please consider uploading it? We applied it successfully in
Ubuntu but would prefer not to carry a delta.

Thanks,
Logan

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Guilhem Moulin]

Had a closer look at this with the help of your links from msg#27.  With
both foo.css.gz and foo.css.br present in a directory, .gz and .br
respectively mapping to gzip and br encoding (and .br to the breton
language too), as Kevin wrote the request fails:

HEAD /foo.css HTTP/1.1
Accept: */*
Accept-Encoding: br
Accept-Language: en

HTTP/1.1 406 Not Acceptable
Date: Wed, 13 Jan 2021 03:06:33 GMT
Server: Apache/2.4.46 (Debian)
Alternates: {"foo.css.br" 1 {type text/css} {language br} {encoding br} 
{length 3}}, {"foo.css.gz" 1 {type text/css} {encoding gzip} {length 32}}
Vary: negotiate,accept-language,accept-encoding
TCN: list
Content-Type: text/html; charset=iso-8859-1

However I still don't understand why this is a blocker.  With the
MultiViews method one accepts to use ‘RemoveType .gz’, why is it not OK
to use ‘RemoveLanguage .br’?

Also, the MultiViews method won't work with /usr/share/javascript/jquery
anyway because jquery.min.js exists, so apache2 won't honor Content-
{Language,Encoding} negotiation and serve that file instead (ie never
pick the compress files from the file system), right?

The mod_brotli configuration snippet you linked to in #972632 works well
on the other hand.  Using mod_rewrite one can emulate negotiation and
point the HTTPd to the uncompressed / gzipped / brotli-compressed file
depending on the value of the ‘Accept-Encoding’ header.  When using .br
suffixes the file is served with ‘Content-Language: br’ header, which I
guess is why you changed the extension?  IMHO adding ‘RemoveLanguage
.br’ in the  of a system-provided snippet would be an OK
workaround, but whatever, I guess using .brotli suffixes for apache2 is
fine too :-)

On Tue, 12 Jan 2021 at 23:32:29 +0100, Guilhem Moulin wrote:
> Keeping the above snippet, would apache complain about the mere presence
> of a jquery.min.js.br file alongside the jquery.min.js.brotli?

Given Content-{Language,Encoding,Type,…} is unusable here (because the
uncompressed file is present as well), I was unable to find any downside
of doing that (aside from the fact that symlink resolution now needs to
be enabled).

> If not, then how about shipping both?

:-]
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#980023: petri-foo: FTBFS with GCC 10

[Logan Rosen]

Source: petri-foo
Version: 0.1.87-4
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com

Hi,

petri-foo currently FTBFS on rebuild in unstable with GCC 10 as default
because of a variable being defined multiple times.

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 petri-foo-0.1.87/debian/control petri-foo-0.1.87/debian/control
--- petri-foo-0.1.87/debian/control 2018-02-05 11:51:44.0 -0500
+++ petri-foo-0.1.87/debian/control 2021-01-12 22:37:28.0 -0500
@@ -1,8 +1,7 @@
 Source: petri-foo
 Section: sound
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Multimedia Maintainers 

+Maintainer: Debian Multimedia Maintainers 

 Uploaders:
  Alessio Treglia ,
  Jaromír Mikeš 
diff -Nru petri-foo-0.1.87/debian/patches/gcc-10.patch 
petri-foo-0.1.87/debian/patches/gcc-10.patch
--- petri-foo-0.1.87/debian/patches/gcc-10.patch1969-12-31 
19:00:00.0 -0500
+++ petri-foo-0.1.87/debian/patches/gcc-10.patch2021-01-12 
22:37:27.0 -0500
@@ -0,0 +1,21 @@
+--- a/gui/gui.c
 b/gui/gui.c
+@@ -93,6 +93,8 @@
+ /* current patch, makes passing patch id to sample editor easier */
+ static int cur_patch = -1;
+ 
++GtkRecentManager *recent_manager;
++
+ 
+ GtkWidget* gui_title_new(const char* msg)
+ {
+--- a/gui/gui.h
 b/gui/gui.h
+@@ -107,6 +107,6 @@
+ 
+ void gui_set_session_mode(void);
+ 
+-GtkRecentManager *recent_manager;
++extern GtkRecentManager *recent_manager;
+  
+ #endif /* __GUI_H__ */
diff -Nru petri-foo-0.1.87/debian/patches/series 
petri-foo-0.1.87/debian/patches/series
--- petri-foo-0.1.87/debian/patches/series  2016-12-23 10:09:46.0 
-0500
+++ petri-foo-0.1.87/debian/patches/series  2021-01-12 22:36:12.0 
-0500
@@ -1,2 +1,3 @@
 0003-desktop_file_fix.patch
 0005-spelling.patch
+gcc-10.patch

Bug#980022: ITP: blur-effect -- offscreen image blurring tool

[stan clay]

Package: wnpp
Severity: wishlist
Owner: clay stan 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: blur-effect
  Version : 1.1.3
  Upstream Author : linuxdeepin
* URL : https://github.com/linuxdeepin/blur-effect
  License : GPL-3+
  Programming Lang:  CPP
  Description : offscreen image blurring tool

Blur-effect is based on efficient Gaussian blur with linear sampling.
This is a part of DDE.

Bug#980021: initramfs-tools: Upgrading a LVM2 system with separate /usr to buster breaks booting

[Ryan Underwood]

Package: initramfs-tools
Version: 0.139
Severity: important

Dear Maintainer,

I understand that separate /usr is deprecated, but many users do not
have the luxury of wiping and reinstalling their entire system.  Rather,
a simple dist-upgrade procedure is expected to produce a working system,
making a best effort to migrate previously supported configurations.

Given that, upgrading a system to buster will break booting if the
following two conditions are true:
* /usr is a mount for a separate block device
* The block device containing the /usr filesystem is a LVM volume.

The reason is because the script
/usr/share/initramfs-tools/scripts/local-top/lvm2 only attempts to
activate the root and resume devices, and no other devices.
Unfortunately, systemd which has been introduced with buster introduces
a new boot dependency on /usr.

I have created the following workaround:
# DEV=$(lsblk -p -f -l | grep '\/usr' | awk '{print $1}' | sed 's/\//\\\//g'); 
cat /usr/share/initramfs-tools/scripts/local-top/lvm2 | sed 's/^exit 
0$/activate "'${DEV}'"; exit 0/' > /etc/initramfs-tools/scripts/local-top/lvm2

This produces the following diff:
# diff -u /usr/share/initramfs-tools/scripts/local-top/lvm2
/etc/initramfs-tools/scripts/local-top/lvm2
--- /usr/share/initramfs-tools/scripts/local-top/lvm2   2019-06-21
02:59:13.0 -0500
+++ /etc/initramfs-tools/scripts/local-top/lvm2 2021-01-12
21:20:36.0 -0600
@@ -62,4 +62,4 @@
 activate "$ROOT"
 activate "$resume"

-exit 0
+activate "/dev/mapper/debian--lenny--i386-usr"; exit 0

Another part of the initramfs scripts mounts a separate /usr filesystem
if the block device exists; this workaround is strictly to ensure the
LVM device is activated so that the later code can actually mount it.

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 26M Jan 12 20:49 /boot/initrd.img-5.4.0-2-686-pae
-rw-r--r-- 1 root root 27M Jan 12 20:49 /boot/initrd.img-5.8.0-0.bpo.2-686-pae
-rw-r--r-- 1 root root 27M Jan 12 20:48 /boot/initrd.img-5.9.0-0.bpo.2-686-pae
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.9.0-0.bpo.2-686-pae 
root=/dev/mapper/debian--lenny--i386-root ro elevator=noop quiet

-- /proc/filesystems
ext3
ext2
ext4
fuseblk

-- lsmod
Module  Size  Used by
openafs  1720320  2
cirrus 16384  0
sg 28672  0
drm_kms_helper151552  3 cirrus
cec40960  1 drm_kms_helper
virtio_balloon 24576  0
joydev 24576  0
evdev  20480  4
serio_raw  20480  0
pcspkr 16384  0
button 20480  0
drm   372736  3 cirrus,drm_kms_helper
fuse  102400  1
configfs   32768  1
ip_tables  24576  0
x_tables   28672  1 ip_tables
autofs440960  2
ext4  565248  5
crc16  16384  1 ext4
mbcache16384  1 ext4
jbd2   90112  1 ext4
crc32c_generic 16384  5
dm_mod106496  26
sd_mod 49152  3
sr_mod 24576  0
t10_pi 16384  1 sd_mod
crc_t10dif 20480  1 t10_pi
crct10dif_generic  16384  1
cdrom  53248  1 sr_mod
crct10dif_common   16384  2 crct10dif_generic,crc_t10dif
ata_generic16384  0
virtio_net 45056  0
net_failover   20480  1 virtio_net
failover   16384  1 net_failover
ata_piix   32768  2
uhci_hcd   45056  0
libata188416  2 ata_piix,ata_generic
ehci_hcd   65536  0
scsi_mod  176128  4 sd_mod,libata,sr_mod,sg
psmouse   131072  0
virtio_pci 24576  0
virtio_ring28672  3 virtio_net,virtio_balloon,virtio_pci
virtio 16384  3 virtio_net,virtio_balloon,virtio_pci
i2c_piix4  28672  0
usbcore   196608  2 ehci_hcd,uhci_hcd
usb_common 16384  3 ehci_hcd,uhci_hcd,usbcore
floppy 57344  0

-- /etc/initramfs-tools/modules

-- /etc/kernel-img.conf
# This is a sample /etc/kernel-img.conf file
# See kernel-img.conf(5) for details

# If you want the symbolic link (or image, if move_image is set) to be
# stored elsewhere than / set this variable to the dir where you
# want the symbolic link.  Please note that this is not a Boolean
# variable.  This may be of help to loadlin users, who may set both
# this and move_image. Defaults to /. This can be used in conjunction
# with all above options except link_in_boot, which would not make
# sense.  (If both image_dest and link_in_boot are set, link_in_boot
# overrides).
image_dest = /

# This option manipulates the build link created by recent kernels. If
# the link is a dangling link, and if a the corresponding kernel
# headers appear to have been installed on the system, a new symlink
# shall be created to point to them.

Bug#979965: milter-greylist exits after running for a few minutes

[Michael Grant]

On Tue, Jan 12, 2021 at 10:02:19PM +, Sudip Mukherjee wrote:
> On Tue, Jan 12, 2021 at 9:36 PM Michael Grant  wrote:
> >
> > I have made this change:
> >
> >
> >
> > [Service]
> >
> > Type=forking
> >
> > ExecStart=/usr/sbin/milter-greylist
> >
> > Restart=on-failure
> >
> > PrivateTmp=true
> >
> >
> >
> > And it’s still restarting every few minutes:
> >
> >
> >
> > Jan 12 16:09:43 strange milter-greylist[255358]: racl 277 greylist [delay 
> > 300] [aw 3888000] [maxpeek -1] default
> >
> > Jan 12 16:09:43 strange systemd[1]: Started Greylist Mail Filter Daemon.
> >
> > Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Main process 
> > exited, code=exited, status=71/OSERR
> >
> > Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Failed with 
> > result 'exit-code'.
> >
> > Jan 12 16:30:44 strange systemd[1]: milter-greylist.service: Scheduled 
> > restart job, restart counter is at 2.
> >
> > Jan 12 16:30:44 strange systemd[1]: Stopped Greylist Mail Filter Daemon.
> >
> > Jan 12 16:30:44 strange systemd[1]: Starting Greylist Mail Filter Daemon...
> >
> >
> >
> > I just noticed it says ‘Scheduled restart job’, is that because it exits? 
> > Or is that because some timer is killing it?
> 
> I think its restarting because the service file has
> "Restart=on-failure". and since the main process is exiting with error
> systemd thinks the service has failed and so it restarts.
> To reproduce the error, do I just run milter-greylist with a
> greylist.conf and Sendmail/Postfix or do I need to have real mails to
> see the issue?

I could probably send you my config files.  I do have a fairly large database 
of grey listed hosts. I probably don't want to post that in the bug tracking 
database!

For me, it runs for a while in side sendmail as a milter, I get a few messages, 
then it restarts.

The journalctl is huge, I will forward it to you after.  It doesn't seem to 
have any extra info.  


signature.asc
Description: PGP signature

Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

[Nicholas D Steeves]

Hi,

Ryutaroh Matsumoto  writes:

> Hi Nicholas,
> Thank you very much for your attention!
>

You're welcome :-)

[snip]
> Boot failures themselves are unreliable...
>

This is the key to the most important issue.  To solve this bug, we will
need to figure out the steps to reproduce it, and it's not clear what
needs to be fixed (or how to fix it!) if no one can reproduce it.

>> If that's not possible,
>> see if you can get a copy from /var/log after rebooting with a working
>> kernel or when using a network disk.
>
> /var/log/kern.log does not have information of 5.10.1...
>
>> If that's not possible, and you
>> have good reflexes, you could try ctr+s or scroll-lock to pause the
>> kernel output at just the right moment,
>
> I found that once in ten times, booting succeeds and I got dmesg and 
> /proc/mounts
> of 5.10.1 as attached...
>

Thank you.  The backtrace is from a crashing tpm driver, and not btrfs.
If you want to eliminate this as a possible factor, the tpm, tpm_tis,
and tpm_tis_core drivers can be blacklisted.

It's encouraging to hear that it fails 10% of the time, because that
means you'll be able to reproduce it without much trouble ;-) Please
finish reading this email, then enable network logging using the
document linked to in my previous email, because it sounds like your
system is probably hard locking before the logs are written to disk,
which means sending them to another computer is the most reliable way to
capture them.  For your convenience, here is the link again:
  https://wiki.debian.org/Rsyslog

>> Finally, what btrfs features (profiles, compression, layers of storage,
>> etc) are being used?
>
> Please have a look at attached file. Less usual one is compress-force=lzo.
> If I remember it correctly, all files are lzo-compressed.
>

P.S. I believe that btrfs compression is not yet ready for general use.
There's still at least one major bug per year that only occurs when it
is enabled.  If I remember correctly, Zygo on the linux-btrfs mailing
list is tracking its state, and he periodically posts "year in review"
and "current outstanding issues" reports.

At this point my two hypotheses are:

1. It's hardware specific, and the TPM crash is more significant than it
appears to be.
2. It may be that your btrfs volume has errors which 5.10 detects and
halts for, but which 5.9 is not aware of.  If you'd like to explore this
possibility, run "btrfs check" against the unmounted volume.  If it
finds errors *DO NOT* run "btrfs check --repair"; instead, send a copy
of the output to linux-btrfs asking for advice about what to do next,
and request to be CCed on replies.
3. Something else.

There's not really any substitute for logs, so I wish you success in
configuring network logging :-)

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#934327: libreswan: addconn crash on ipsec.conf

[Daniel Kahn Gillmor]

Version: 4.1-1
Control: tags 934327 + moreinfo

On Fri 2019-09-27 20:50:33 +, Ray Klassen wrote:
> Further on this. It seems to relate to having esp= in the default
> 'conn' and overriding it with phase2alg= in a specific 'conn.' I had
> that crash again on another router and after using phase2alg in both
> stanzas the problem went away.

I'm not sure how to replicate this bug report, and perhaps it has been
fixed in 4.1-1.  I'm closing this while also asking for more
information.  If you can replicate it with 4.1-1, please provide a
sample configuration snippet that we can use to replicate the problem,
and reopen the bug report (i'm happy to reopen it for you if you aren't
sure how to do that).

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#980019: ITP: deepin-turbo -- ​A deepin project that derives from Applauncherd

[Hu Feng]

Package: wnpp
Severity: wishlist
Owner: Hu Feng 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name    : deepin-turbo
  Version : 0.0.5
  Upstream Author : zccrs 
* URL : https://github.com/linuxdeepin/deepin-turbo
  License : LGPL-2.1
  Programming Lang: C++
  Description : ​A deepin project that derives from Applauncherd


deepin-trubo is a deepin project that derives from Applauncherd.
.
Applauncherd is a daemon that helps to launch applications faster by 
preloading dynamically linked libraries and caching stuff. It also saves 
memory, because all launched applications share certain resources.

.
we built a booster type called dtkwidget-booster in this project to 
support launching dtk-based Apps faster.

.
I intend to co-maintain this package inside pkg-deepin group.

Bug#979986: Please, drop composer dependency

[Dmitry Smirnov]

On Wednesday, 13 January 2021 9:36:37 AM AEDT David Prévot wrote:
> > What would that be? I've thought that using phpab is the way to go.
> 
> Yes, it is! That’s why I’m surprised you need also
> 'Composer/Autoload/ClassLoader.php' on top of the other require (my
> guess is that some dependencies are not yet part of your current template).

So there must be a missing dependency - that's why composer is needed...
I see... Thank you very much for the hint. I'll try to comment composer
and include what's missing to phpab template. However this is a difficult
path - as I've mentioned, different errors are thrown here and there
depending on which CiviCRM feature is used and even though we use CiviCRM,
I can't check all the features especially in deactivated modules/plugins.

This situation feels fragile due to manual fiddling with phpab template
as merely forgetting a library breaks some functionality. Re-testing
everything on every new release makes maintenance slow and tedious.
Even then how can I be sure that nothing is missed? Perhaps some form of
translation of composer dependencies could be a solution, as you've said.


> My trial and errors first take at the issue would be to keep an eye on
> the webserver errors (e.g., “tail -f /var/log/apache2/error.log”) and
> take the following actions:
> - comment out the Composer autoload.php (l11);
> - hopefully get a meaningful error identifying a missing class;
> - try and include the missing classes, e.g. via
>   require_once 'Psr/Http/Client/autoload.php';
>if it can’t find some Psr\\Http\\Client\\… class;
> - go back to step 2 if it’s not enough…

Understood, thanks. I Will attempt that and I reckon this will help to
stabilise phpab template but I have a feeling that run-time dependency
discover is not a good way to populate list of dependencies...


> Optional dependencies should be loadable via @include_once or with
> something like:
>   if (stream_resolve_include_path('/autoload.php'))
>   include_once '/autoload.php';
> as we currently usually do.

Noted, thanks.


> I’ve no idea how to run civicrm right now (it doesn’t seem like a
> straight out of the box kind of thing at first sight), so I’m not
> proposing a patch, but will try harder if you need a hand for that.

If you are familiar with Wordpress then running CiviCRM should not be
too difficult. But leave the matters with me for now please. I'll
experiment, learn and maybe ask you for advise or review. 
I'll definitely need your help with autoload.php template generator
if we can use it with CiviCRM.

Thank you.

-- 
Kind regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The strongest argument for socialism is that it sounds good. The strongest
argument against socialism is that it doesn't work. But those who live by
words will always have a soft spot in their hearts for socialism because it
sounds so good.
-- Thomas Sowell

---

"Increased Risk of Noninfluenza Respiratory Virus Infections Associated
With Receipt of Inactivated Influenza Vaccine".
-- https://pubmed.ncbi.nlm.nih.gov/22423139/



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

Bug#979965: milter-greylist exits after running for a few minutes

[Michael Grant]

I have made this change:

[Service]
Type=forking
ExecStart=/usr/sbin/milter-greylist
Restart=on-failure
PrivateTmp=true

And it’s still restarting every few minutes:

Jan 12 16:09:43 strange milter-greylist[255358]: racl 277 greylist [delay 300] 
[aw 3888000] [maxpeek -1] default
Jan 12 16:09:43 strange systemd[1]: Started Greylist Mail Filter Daemon.
Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Main process 
exited, code=exited, status=71/OSERR
Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Failed with result 
'exit-code'.
Jan 12 16:30:44 strange systemd[1]: milter-greylist.service: Scheduled restart 
job, restart counter is at 2.
Jan 12 16:30:44 strange systemd[1]: Stopped Greylist Mail Filter Daemon.
Jan 12 16:30:44 strange systemd[1]: Starting Greylist Mail Filter Daemon...

I just noticed it says ‘Scheduled restart job’, is that because it exits? Or is 
that because some timer is killing it?

Bug#979965: milter-greylist exits after running for a few minutes

[Michael Grant]

Ok this is done, now we wait a bit. 

Thanks.

-Mike

From: Sudip Mukherjee
Sent: 12 January 2021 20:48
To: 979...@bugs.debian.org; Michael Grant
Cc: Vagrant Cascadian
Subject: Re: Bug#979965: milter-greylist exits after running for a few minutes

Hi Michael,

On Tue, Jan 12, 2021 at 5:54 PM Vagrant Cascadian  wrote:
>
> On 2021-01-12, Michael Grant wrote:
> > After update to 4.6.2-2, milter-greylist runs for a few minutes
> > processing greylist requests then exits.  No error in the daemon.log.
> > Daemon restarts with systemd over and over.
> >
> > Starting milter-greylist by hand using strace shows this just before
> > it dies:
> >
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 1 ([{fd=3,
> > revents=POLLIN}])
> > accept(3, {sa_family=AF_UNIX}, [2]) = 10
> > fcntl(10, F_GETFD)  = 0
> > fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
> > setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> > futex(0x7f0f22c221a4, FUTEX_WAKE_PRIVATE, 1) = 1
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000 ) = ?
> > +++ exited with 71 +++
> >
> > Previous version of milter-greylist on debian/testing was working fine
> > without this issue.
>
> Could you try running without the systemd .service file so that it falls
> back to the init script; there may be differences between how the
> .service file and the init script set up the environment to run it.

Can you also modify /lib/systemd/system/milter-greylist.service and
change the [Service] section to the following and test please..
[Service]
Type=forking
ExecStart=/usr/sbin/milter-greylist
Restart=on-failure
PrivateTmp=true


-- 
Regards
Sudip

Bug#979987: vorta: Cant find pyqt5

[Nicholas D Steeves]

Control: retitle -1 vorta: please resolve issues that are blocking a backport
Control: severity -1 minor
Control: tag -1 confirmed

Dear Ilya,

Installing packages from unstable/sid, or testing (bullseye right now)
onto Debian stable is not a supported configuration.  You are of course
free to experiment, but this is a case where if something breaks, you
get to keep the pieces and debug the state of your system on your own.
For more information, see:

  https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

Please don't use FrankenDebian on a production system unless you are
yourself ready to debug and fix any breakage.

That said, I do agree that users of stable (buster right now) should
have access to Vorta -- if at all possible :-) -- and to that end I have
started working on a backport.  While working on this I discovered
blocking various issues, but these issues do not affect Vorta for
unstable/sid and testing/bullseye.

What this bug actually seems to be requesting is access to Vorta on
Buster, and in a Debian context this should be achieved with a formal
backport.  Requests for backports should be sent to
debian-backpo...@lists.debian.org (I've CCed the list), should never be
filed on the BTS, and the priority of all such requests is "wishlist".
When requesting a backport it is useful to CC the package Maintainer and
Uploaders.

I chose to set this bug's priority to "minor" on the off-chance that
something in my packaging is not maximally correct.  For example, the
unversioned Paramiko dependency needs to be versioned, because a minimum
version is required.  I confess I ought to have noticed this sooner ^^

Please ping me for a progress update in two weeks.  I believe that I
have a functioning backport right now, but I need to take to take time
to test it, and also to investigate whether the changes are appropriate
for sid/testing.  If the changes are not appropriate, a no-change
backport will not be possible, but that's ok.  I'm optimistic that the
worst-case scenario is a delta between the source package in testing and
the future source package in buster-backports.

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#980017: argus-clients FTBFS due to missing link and includes for tirpc library

[Tiago Stürmer Daitx]

Source: argus-clients
Version: 3.0.8.2-6
Severity: important

Dear Maintainer,

This package failed to rebuild in Ubuntu with "fatal error: rpc/type.h".
Sun RPC used to be included in glibc and now it must be added from
TI-RPC library (libtirpc-dev).  

To fix it a simple change was needed:

configure.ac:
+AC_CHECK_LIB([tirpc],[rpc_call],,
+ [AC_MSG_ERROR([no tirpc library, exiting...!])])
+V_INCLS="$V_INCLS -I/usr/include/tirpc"
 AC_CHECK_FUNCS(xdrmem_create)

The full debdiff is available at:
https://launchpadlibrarian.net/516883019/argus-clients_1%3A3.0.8.2-6ubuntu1_1%3A3.0.8.2-6ubuntu2.diff.gz

Best regards,
Tiago


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(400, 'focal-proposed'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-36-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#980016: argus FTBFS due to missing link and includes for tirpc library

[Tiago Stürmer Daitx]

Source: argus
Version: 2:3.0.8.2-2
Severity: important

Dear Maintainer,

This package failed to rebuild in Ubuntu with "fatal error: rpc/type.h".
Sun RPC used to be included in glibc and now it must be added from
TI-RPC library (libtirpc-dev).

To fix it 3 changes were required:

configure.ac:
+AC_CHECK_LIB([tirpc],[rpc_call],,
+ [AC_MSG_ERROR([no tirpc library, exiting...!])])
 AC_CHECK_FUNCS(xdrmem_create)

reordering library inclusion in argus/Makefile.in:
-LIB = @LIBS@ @V_THREADS@ $(WRAPLIBS) $(SASLLIBS) $(COMPATLIB) 
../lib/argus_common.a -lm
+LIB = ../lib/argus_common.a -lm @LIBS@ @V_THREADS@ $(WRAPLIBS) $(SASLLIBS) 
$(COMPATLIB)

and finally the header include in debian/rules
+export DEB_CFLAGS_MAINT_APPEND  = -I/usr/include/tirpc

I tried the header inclusion through V_INCLS but it was being overriden
by the wrap macro, and this quick workaround was fine.

The full debdiff is available at:
https://launchpad.net/ubuntu/+archive/primary/+files/argus_2%3A3.0.8.2-2_2%3A3.0.8.2-2ubuntu1.diff.gz

Best regards,
Tiago

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(400, 'focal-proposed'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-36-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#980015: alberta: FTBFS due to missing link and include for tirpc library

[Tiago Stürmer Daitx]

Source: alberta
Version: 3.0.1-2
Severity: important

Dear Maintainer,

This package failed to rebuild in Ubuntu with "fatal error: rpc/type.h".
Sun RPC used to be included in glibc and now it must be added from
TI-RPC library (libtirpc-dev).

I was able to build it after adding a check lib in configure.ac right
before check headers for rpc/types.h
+AC_CHECK_LIB([tirpc],[rpc_call],,
+ [AC_MSG_ERROR([no tirpc library, exiting...!])])

and including the library in debian/rules
+export DEB_CFLAGS_MAINT_APPEND = -I/usr/include/tirpc

There might a better way to include that library directly in
configure.ac, but this is what worked for me.

Regards,
Tiago

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(400, 'focal-proposed'), (100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-36-generic (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#979993: [Pkg-javascript-devel] Bug#979993: libjs-jquery: Missing minified files

[Veiko Aasa]

On Tue, 2021-01-12 at 19:46 +0100, Jonas Smedegaard wrote:
> 
> Are you sure you have the latest package installed?
> 
> Please provide the output of this command:
> 
>   apt list libjs-jquery

I got same results.

# apt list libjs-jquery
Listing... Done
libjs-jquery/testing,now 3.5.1+dfsg+~3.5.5-5 all [installed]

However:
$ ls -l /usr/share/javascript/jquery
lrwxrwxrwx 1 root root 21 Dec  3 02:21 /usr/share/javascript/jquery ->
../nodejs/jquery/dist

$ dpkg -L node-jquery
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/node-jquery
/usr/share/doc/node-jquery/changelog.Debian.gz
/usr/share/doc/node-jquery/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/node-jquery
/usr/share/nodejs
/usr/share/nodejs/@types
/usr/share/nodejs/@types/jquery
/usr/share/nodejs/@types/jquery/JQuery.d.ts
/usr/share/nodejs/@types/jquery/JQueryStatic.d.ts
/usr/share/nodejs/@types/jquery/dist
/usr/share/nodejs/@types/jquery/dist/jquery.slim.d.ts
/usr/share/nodejs/@types/jquery/index.d.ts
/usr/share/nodejs/@types/jquery/legacy.d.ts
/usr/share/nodejs/@types/jquery/misc.d.ts
/usr/share/nodejs/@types/jquery/package.json
/usr/share/nodejs/jquery
/usr/share/nodejs/jquery/dist
/usr/share/nodejs/jquery/dist/jquery.js
/usr/share/nodejs/jquery/package.json




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

Bug#980005: lumpy-sv: lumpyexpress fails with no args

[Ken Yamaguchi]

On Wed, Jan 13, 2021 at 12:04:08AM +0200, Juhani Numminen wrote:
> It's a change made in debian/patches/lumpyexpress.config.patch.
> https://salsa.debian.org/med-team/lumpy-sv/-/commit/e64a65545fbf60c5c98965bc1d00d416b2f9582c#6864ced7557ec33a7ee70c7b0c75b076f84f4fac_24_30
> 
> -$PYTHON_TEST -c "import imp; imp.find_module('pysam')"
> -$PYTHON_TEST -c "import imp; imp.find_module('numpy')"
> +$PYTHON_TEST -c "import importlib; importlib.util.find_spec('pysam')"
> +$PYTHON_TEST -c "import importlib; importlib.util.find_spec('numpy')"
> 
> It's not entirely correct even if it worked: the original causes
> a visible error message to alert if one of the required modules does
> not exist. The current patch will not cause error messages or the
> python check to exit non-zero.
> 
> Because it's a Debian context we could rely on dpkg dependencies i.e.
> just don't perform this check and comment out the two lines.
> 
> --
> Juhani

There's a discussion of the issue at


https://stackoverflow.com/questions/39660934/error-when-using-importlib-util-to-check-for-library/39661116

To remove the error,

-$PYTHON_TEST -c "import imp; imp.find_module('pysam')"
-$PYTHON_TEST -c "import imp; imp.find_module('numpy')"
+$PYTHON_TEST -c "from importlib import util; util.find_spec('pysam')"
+$PYTHON_TEST -c "from importlib import util; util.find_spec('numpy')"

To print an error message, perhaps the awkward-looking

-$PYTHON_TEST -c "import imp; imp.find_module('pysam')"
-$PYTHON_TEST -c "import imp; imp.find_module('numpy')"
+$PYTHON_TEST -c "from importlib import util; print('pysam not found') if 
util.find_spec('pysam') is None else None"
+$PYTHON_TEST -c "from importlib import util; print('numpy not found') if 
util.find_spec('numpy') is None else None"

Ken

Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Yes, that works fine, using a netboot image, I am NOT asked to provide
> firmware for regulatory.db file, because it's already included in the d-i
> image.
> 
> However, that's only true for netboot images!
> 
> My wireless card (on an IBM Thinkpad T60) is also usable with DVD/CD netinst 
> images 
> (so related kernel modules seem to be included in those images; I have 
> explicitly
> tested that with said images on that T60), so probably wireless-regdb-udeb 
> should just 
> be added to all Linux d-i images?

I prepared a patch for this (includes removing it from the netboot/* files,
since it's now added generally in pkg-lists/base).
Will apply it, if noone objects.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/build/pkg-lists/base b/build/pkg-lists/base
index e5a6c6fba..bf6dc22b0 100644
--- a/build/pkg-lists/base
+++ b/build/pkg-lists/base
@@ -28,3 +28,7 @@ kldutils-udeb [kfreebsd]
 
 # Avoid entropy starvation issues (#923675):
 haveged-udeb [linux]
+
+# Needed, when nic-wireless kernel modules are included,
+# which seems to be the case on nearly all linux arch images
+wireless-regdb-udeb [linux]
diff --git a/build/pkg-lists/netboot/alpha.cfg b/build/pkg-lists/netboot/alpha.cfg
index 6395df6e2..db687ccc1 100644
--- a/build/pkg-lists/netboot/alpha.cfg
+++ b/build/pkg-lists/netboot/alpha.cfg
@@ -3,7 +3,6 @@ srm-modules-${kernel:Version}
 nic-shared-modules-${kernel:Version}
 nic-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 console-setup-pc-ekmap
 
 console-setup-udeb
diff --git a/build/pkg-lists/netboot/amd64.cfg b/build/pkg-lists/netboot/amd64.cfg
index 31e4d7b1a..82d663537 100644
--- a/build/pkg-lists/netboot/amd64.cfg
+++ b/build/pkg-lists/netboot/amd64.cfg
@@ -5,7 +5,6 @@ bogl-bterm-udeb
 nic-modules-${kernel:Version}
 nic-usb-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 virtio-modules-${kernel:Version} ?
 hyperv-modules-${kernel:Version} ?
 usb-modules-${kernel:Version}
diff --git a/build/pkg-lists/netboot/arm64.cfg b/build/pkg-lists/netboot/arm64.cfg
index 0af7b84e9..01fe2b0a5 100644
--- a/build/pkg-lists/netboot/arm64.cfg
+++ b/build/pkg-lists/netboot/arm64.cfg
@@ -10,7 +10,6 @@ netcfg
 nic-modules-${kernel:Version}
 nic-usb-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 virtio-modules-${kernel:Version} ?
 usb-modules-${kernel:Version}
 
diff --git a/build/pkg-lists/netboot/armhf.cfg b/build/pkg-lists/netboot/armhf.cfg
index 46ffac580..cd9ed4435 100644
--- a/build/pkg-lists/netboot/armhf.cfg
+++ b/build/pkg-lists/netboot/armhf.cfg
@@ -10,7 +10,6 @@ netcfg
 nic-modules-${kernel:Version}
 nic-usb-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 virtio-modules-${kernel:Version} ?
 
 fb-modules-${kernel:Version} ?
diff --git a/build/pkg-lists/netboot/i386.cfg b/build/pkg-lists/netboot/i386.cfg
index bf6ff7572..3d06ec1fc 100644
--- a/build/pkg-lists/netboot/i386.cfg
+++ b/build/pkg-lists/netboot/i386.cfg
@@ -5,7 +5,6 @@ bogl-bterm-udeb
 nic-modules-${kernel:Version}
 nic-usb-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 virtio-modules-${kernel:Version} ?
 hyperv-modules-${kernel:Version} ?
 usb-modules-${kernel:Version}
diff --git a/build/pkg-lists/netboot/mips.cfg b/build/pkg-lists/netboot/mips.cfg
index e5186cbeb..ad861e094 100644
--- a/build/pkg-lists/netboot/mips.cfg
+++ b/build/pkg-lists/netboot/mips.cfg
@@ -10,5 +10,4 @@ netcfg
 nic-modules-${kernel:Version}
 nic-usb-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 virtio-modules-${kernel:Version} ?
diff --git a/build/pkg-lists/netboot/mips64el.cfg b/build/pkg-lists/netboot/mips64el.cfg
index e5186cbeb..ad861e094 100644
--- a/build/pkg-lists/netboot/mips64el.cfg
+++ b/build/pkg-lists/netboot/mips64el.cfg
@@ -10,5 +10,4 @@ netcfg
 nic-modules-${kernel:Version}
 nic-usb-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 virtio-modules-${kernel:Version} ?
diff --git a/build/pkg-lists/netboot/mipsel.cfg b/build/pkg-lists/netboot/mipsel.cfg
index e5186cbeb..ad861e094 100644
--- a/build/pkg-lists/netboot/mipsel.cfg
+++ b/build/pkg-lists/netboot/mipsel.cfg
@@ -10,5 +10,4 @@ netcfg
 nic-modules-${kernel:Version}
 nic-usb-modules-${kernel:Version}
 nic-wireless-modules-${kernel:Version}
-wireless-regdb-udeb
 virtio-modules-${kernel:Version} ?
diff --git a/debian/changelog b/debian/changelog
index 43deab00b..ba86bb85f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,9 @@ debian-installer (20201203) UNRELEASED; urgency=medium
   [ Steve McIntyre ]
   * Bump Linux kernel ABI to 5.10.0-1
 
+  [ Holger Wansing ]
+  * Add wireless-regdb-udeb to all Linux arch images (#979104).
+
  -- Shawn Guo   Sat, 12 Dec 2020 12:11:26 +
 
 debian-installer (20201202) unstable; 

Bug#980014: RM: marionnet,ocamlbricks -- ROM; outdated upstream

[Lucas Nussbaum]

Package: ftp.debian.org
Severity: normal

Please remove marionnet and ocamlbricks from Debian.

marionnet is not very actively maintained upstream, and lacks a migration
from GTK2. Upstream recommends installing it should a script instead.

ocamlbricks is a CAML library that is only used by marionnet. Keeping it
in Debian is useless if marionnet is gone.

Thanks!

Lucas

Bug#979986: Please, drop composer dependency

[David Prévot]

Hi Dmitry,

Le 12/01/2021 à 17:26, Dmitry Smirnov a écrit :


On Wednesday, 13 January 2021 3:05:37 AM AEDT David Prévot wrote:

civicrm-common depends on composer, it seems like it is used as a
dynamic autoloader:

https://salsa.debian.org/debian/civicrm/-/blob/master/debian/autoload-vendo
r.php.tpl#L11

Please, do drop the dependency on composer


Thank you for your suggestion. Unfortunately, at the moment I can not do that
as CiviCRM just does not work without it (or I don't know _how_ to do it).


I’d need more information on the actual errors (or some time to dig it 
myself).



and use proper static autoloader(s) instead.


What would that be? I've thought that using phpab is the way to go.


Yes, it is! That’s why I’m surprised you need also 
'Composer/Autoload/ClassLoader.php' on top of the other require (my 
guess is that some dependencies are not yet part of your current template).


My trial and errors first take at the issue would be to keep an eye on 
the webserver errors (e.g., “tail -f /var/log/apache2/error.log”) and 
take the following actions:

- comment out the Composer autoload.php (l11);
- hopefully get a meaningful error identifying a missing class;
- try and include the missing classes, e.g. via
require_once 'Psr/Http/Client/autoload.php';
  if it can’t find some Psr\\Http\\Client\\… class;
- go back to step 2 if it’s not enough…

Optional dependencies should be loadable via @include_once or with
something like:
if (stream_resolve_include_path('/autoload.php'))
include_once '/autoload.php';
as we currently usually do.

I’ve no idea how to run civicrm right now (it doesn’t seem like a 
straight out of the box kind of thing at first sight), so I’m not 
proposing a patch, but will try harder if you need a hand for that.


Regards

David

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Guilhem Moulin]

On Tue, 12 Jan 2021 at 22:35:30 +0100, Jonas Smedegaard wrote:
> * rfc7932 refrain from recommending a suffix
>  (only talks about "HTTP Content Coding Registry")

That RFC is beyond my head but quick searches for “suffix” and
“extension” didn't lead to meaningful results.  The IANA registration is
only for Accept-Encoding HTTP request headers so irrelevant as far as
files are concerned, no?
 
>>> br is the ISO 639-1 code for the breton language but I guess that's 
>>> not what you mean (application/ecmascript, text/x-perl or video/gl 
>>> don't conflict with the language codes for Spanish, Polish or 
>>> Galician right)?  After quick search I was unable to find an 
>>> official registration for the .br file suffix.
>> 
>> As I recall, the "officiality" of it is tied to that ISO 639-1 and 
>> some W3C definitions (but might just be recommendations, and might 
>> just be Apache2 practise).
> 
> More specifically, Apache2 by default follows RFC 3066: 
> https://httpd.apache.org/docs/current/mod/mod_mime.html#addlanguage
> 
> ...and encourages using both language codes and media types (e.g. a 
> JavaScript file pre-compressed using brotli) and handlers (e.g. 
> on-the-fly request for brotli-compression when serving a JavaScript 
> file), and warns about clashes between those: 
> https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext

Oh I see, thanks for the links.  My Apache2-fu is a bit rusty :-P  So
what matters isn't the ISO 639-1 conflict per se, but rather the
presence of the AddLanguage with a suffix that's also used for a file
extension?  Then I note that a stock apache2/media-type comes with
conflicts for

#application/ecmascriptes
application/vnd.msa-disk-image msa
application/vnd.sigrok.session sr
application/vnd.snesdev-page-table ptrom pt
#text/trofft tr roff
text/vnd.wap.sisi
text/vnd.wap.slsl

(For es and tr the AddLanguage is preceded by a RemoveType with a
comment indicating it's precisely done to solve the conflict.)

> The debate I saw was Mozilla (referenced from above kevinlocke page): 
> https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147
> 
> ...but really that discussion ended without deciding on a file 
> extension, probably because Firefox does not need that at all.

Indeed.  In the end I don't care either which suffix is used, but would
like to have something that also works when ngx_brotli enters Debian (I
don't know what's the status of static compression with other HTTPd, and
if the file extension is configurable).

So I understand from #972632 that you're suggesting to ship a snippet
such as

RewriteRule "^(.*)\.js" "$1\.js\.brotli" [QSA]
RewriteRule "\.js\.brotli$" "-" [T=text/javascript,E=no-brotli:1]

Header append Content-Encoding br
[…]


This would not conflict with the ‘AddLanguage br .br’ directive, and
also play well with the .brotli suffix that jquery is now using.

Keeping the above snippet, would apache complain about the mere presence
of a jquery.min.js.br file alongside the jquery.min.js.brotli?  If not,
then how about shipping both?  That's what I meant by compatibility
symlink in my original message.  That setup would play well with
ngx_brotli also, if symlink resolution is enabled.  It might also be
helpful for those who copy configuration snippets mentioning .br not
.brotli.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#979554: please clarify case sensitiveness of mime.types

[Charles Plessy]

Le Fri, Jan 08, 2021 at 09:38:50AM +0100, Alexandre Duret-Lutz a écrit :
> 
> Recent versions of media-types (1.1.0 and 2.0.0) have introduced some
> lines with extension appearing in both lowercase and uppercase form:

Hi Alexandre, thank you for your report,

I was also wondering about case sensitivity when I worked on the 2.0.0
update.  One of my current problems is that there does not seem to be
a written specification for such details in /etc/mime.types.

> audio/AMR   amr AMR
> audio/AMR-WBawb AWB
> audio/EVRC-QCP  qcp QCP

The IANA assignment pages for these three types list both the lower- and
the uppercase suffixes, so I decided to stick to that.

> image/t38   t38 T38

When I merged the mime.types from Fedora in Debian's, Fedora had the
lowercase one and Debian the uppercase one.  The IANA assignment
declares no extension.  I decided to keep both.  Perhaps it is not
the best decision.

> image/vnd.globalgraphics.pgbPGB pgb

This type also declares both cases in IANA's assignment.

> Some tools will complain if some entries in mime.types have duplicate
> extensions (in some case-insensitive sense).  For instance the above
> lines are causing Bug#979232 for lighttpd.

I am glad that you could solve the bug easily on lighttpd's side.  By
the way I am preparing an update that reverts all case-sensitive
duplicates for this release cycle, and will surely do the same for
case-insensitive ones if it causes serious bugs elsewhere. 

> So the question is what is the intended semantics for the above lines?
> Is "audio/AMR amr AMR" really meant to achieve more than "audio/AMR amr"?

The problem here is that I have no comprehensive information on how
softwares use the mime.types files.  I can not rule out that some use
case sensitivity for their own good reasons, so if no other bug arise, I
would like to continue to stick to the information provided by the IANA.

> Also note that mime.types lists some extensions with only uppercase
> versions, or a mix of lower and upper case letters:
> 
> application/vnd.sar SAR
> application/vnd.ves.encrypted   VES

These two I imported from Fedora and I checked that they are consistent
with IANA.

> application/x-font-pcf  pcf pcf.Z

This one has been for a long time in Debian.

> Those entries will behave differently for "see" and Python's
> "mimetypes.guess_type()".   For instance "see" will consider "foo.sar"
> as application/vnd.sar, but "mimetypes.guess_type()" will not.

I can not tell which approach is wiser...  The mime.types file is not
comprehensive and is usually lagging.  What if there is another file
format around that uses the lowercase `sar` extension?

> It would be nice to clarify the semantics in the comments at the top of
> mime.types.

Definitely! I hope to do so or write a proper man page after I dig the
history of that file.

Bonne journée,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#979993: [Pkg-javascript-devel] Bug#979993: libjs-jquery: Missing minified files

[Veiko Aasa]

> Which specific paths are missing?
> 
>  - Jonas

In Debian stable:
$ ls -l /usr/share/javascript/jquery/
total 720
-rw-r--r-- 1 root root 271809 Apr 19  2019 jquery.js
-rw-r--r-- 1 root root 137549 Apr 19  2019 jquery.min.js
-rw-r--r-- 1 root root  34729 Apr 19  2019 jquery.min.js.br
-rw-r--r-- 1 root root  37419 Apr 19  2019 jquery.min.js.gz
-rw-r--r-- 1 root root 141854 Apr 19  2019 jquery.min.map
-rw-r--r-- 1 root root  49115 Apr 19  2019 jquery.min.map.br
-rw-r--r-- 1 root root  51207 Apr 19  2019 jquery.min.map.gz

In Debian testing:
$ ls -l /usr/share/javascript/jquery/
total 284
-rw-r--r-- 1 root root 287600 Jan  4 20:00 jquery.js



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

Bug#979965: milter-greylist exits after running for a few minutes

[Sudip Mukherjee]

On Tue, Jan 12, 2021 at 9:36 PM Michael Grant  wrote:
>
> I have made this change:
>
>
>
> [Service]
>
> Type=forking
>
> ExecStart=/usr/sbin/milter-greylist
>
> Restart=on-failure
>
> PrivateTmp=true
>
>
>
> And it’s still restarting every few minutes:
>
>
>
> Jan 12 16:09:43 strange milter-greylist[255358]: racl 277 greylist [delay 
> 300] [aw 3888000] [maxpeek -1] default
>
> Jan 12 16:09:43 strange systemd[1]: Started Greylist Mail Filter Daemon.
>
> Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Main process 
> exited, code=exited, status=71/OSERR
>
> Jan 12 16:30:43 strange systemd[1]: milter-greylist.service: Failed with 
> result 'exit-code'.
>
> Jan 12 16:30:44 strange systemd[1]: milter-greylist.service: Scheduled 
> restart job, restart counter is at 2.
>
> Jan 12 16:30:44 strange systemd[1]: Stopped Greylist Mail Filter Daemon.
>
> Jan 12 16:30:44 strange systemd[1]: Starting Greylist Mail Filter Daemon...
>
>
>
> I just noticed it says ‘Scheduled restart job’, is that because it exits? Or 
> is that because some timer is killing it?

I think its restarting because the service file has
"Restart=on-failure". and since the main process is exiting with error
systemd thinks the service has failed and so it restarts.
To reproduce the error, do I just run milter-greylist with a
greylist.conf and Sendmail/Postfix or do I need to have real mails to
see the issue?


-- 
Regards
Sudip

Bug#980005: lumpy-sv: lumpyexpress fails with no args

[Juhani Numminen]

Andreas Tille kirjoitti 12.1.2021 klo 23.08:
> Hi,
> 
> I confirm I can reproduce the issue in a minimal chroot while the
> lumpyexpress command prints the help screen as expected.  This smells
> like a missing dependency but I do not have any idea which one.  It
> seems there is a similar known issue here
> 
>
> https://stackoverflow.com/questions/65028261/attributeerror-module-importlib-has-no-attribute-util-ii
> 
> but there is no answer here.
> 
> Any idea how to fix this?
> 
> Kind regards
> 
>   Andreas.

It's a change made in debian/patches/lumpyexpress.config.patch.
https://salsa.debian.org/med-team/lumpy-sv/-/commit/e64a65545fbf60c5c98965bc1d00d416b2f9582c#6864ced7557ec33a7ee70c7b0c75b076f84f4fac_24_30

-$PYTHON_TEST -c "import imp; imp.find_module('pysam')"
-$PYTHON_TEST -c "import imp; imp.find_module('numpy')"
+$PYTHON_TEST -c "import importlib; importlib.util.find_spec('pysam')"
+$PYTHON_TEST -c "import importlib; importlib.util.find_spec('numpy')"

It's not entirely correct even if it worked: the original causes
a visible error message to alert if one of the required modules does
not exist. The current patch will not cause error messages or the
python check to exit non-zero.

Because it's a Debian context we could rely on dpkg dependencies i.e.
just don't perform this check and comment out the two lines.

--
Juhani

Bug#980013: libreoffice fails throwing com::sun::star::uno::RuntimeException

[Nick Bailey]

Package: libreoffice
Version: 1:7.0.4-3
Severity: normal
X-Debbugs-Cc: nicholas.bai...@glasgow.ac.uk

Dear Maintainer,

Starting libreoffice causes it to exit with

terminate called after throwing an instance of 
'com::sun::star::uno::RuntimeException'

and Signal 6.

I have tried moving the ~/.config/libreoffice directory temporarily: no change.

Running strace I see that there is a connection refused error:

access("/tmp", W_OK)= 0
getuid()= 1000
socket(AF_UNIX, SOCK_STREAM, 0) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
connect(3, {sa_family=AF_UNIX, 
sun_path="/tmp/OSL_PIPE_1000_SingleOfficeIPC_e68685edcbca78b5debcd31a7a395fac"},
 110) = -1 ECONNREFUSED (Connection refused)
close(3)= 0
stat("/proc/version", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
stat("/usr/lib/libreoffice/program/", {st_mode=S_IFDIR|0755, st_size=20480, 
...}) = 0
openat(AT_FDCWD, "/sys/dev/block/254:0/queue/rotational", O_RDONLY) = 3
close(3)= 0

The named OSL_PIPE is left in /tmp after the program fails.

This behaviour has arisen after (but not immediately after) upgrading
the installation from Buster to Bullseye. I cannot find any left-over packages
from the old installation.

The machine was rebooted to kernel 5.9 for to see if the problem was 
kernel-related,
but it occurs also under 5.10.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (550, 'stable'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libreoffice depends on:
ii  libreoffice-base1:7.0.4-3
ii  libreoffice-calc1:7.0.4-3
ii  libreoffice-core1:7.0.4-3
ii  libreoffice-draw1:7.0.4-3
ii  libreoffice-impress 1:7.0.4-3
ii  libreoffice-math1:7.0.4-3
ii  libreoffice-report-builder-bin  1:7.0.4-3
ii  libreoffice-writer  1:7.0.4-3
ii  python3-uno 1:7.0.4-3

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2.1
ii  fonts-crosextra-carlito 20130920-1.1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.2-1
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-core 20201225-1
ii  fonts-noto-extra20201225-1
ii  fonts-noto-mono 20201225-1
ii  fonts-noto-ui-core  20201225-1
ii  fonts-sil-gentium-basic 1.102-1.1
ii  libreoffice-java-common 1:7.0.4-3
ii  libreoffice-nlpsolver   0.9+LibO7.0.4-3
ii  libreoffice-report-builder  1:7.0.4-3
ii  libreoffice-script-provider-bsh 1:7.0.4-3
ii  libreoffice-script-provider-js  1:7.0.4-3
ii  libreoffice-script-provider-python  1:7.0.4-3
ii  libreoffice-sdbc-mysql  1:7.0.4-3
ii  libreoffice-sdbc-postgresql 1:7.0.4-3
ii  libreoffice-wiki-publisher  1.2.0+LibO7.0.4-3

Versions of packages libreoffice suggests:
ii  cups-bsd2.3.3op1-5
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox-esr 78.6.1esr-1~deb10u1
ii  ghostscript 9.53.3~dfsg-6
ii  gnupg   2.2.20-1
pn  gpa 
ii  gstreamer1.0-libav  1:1.14.4-dmo3
ii  gstreamer1.0-plugins-bad1.18.2-1~deb11u1
ii  gstreamer1.0-plugins-base   1.18.2-1
ii  gstreamer1.0-plugins-good   1.18.2-1
ii  gstreamer1.0-plugins-ugly   1:1.14.4-dmo2
ii  hunspell-en-gb [hunspell-dictionary]1:7.1.0~rc1-1
ii  hunspell-en-us [hunspell-dictionary]1:2019.10.06-1
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  imagemagick 8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.11.24+dfsg-1+b2
ii  libgl1  1.3.2-1
pn  libofficebean-java  
pn  libreoffice-gnome | libreoffice-plasma  
pn  libreoffice-grammarcheck
ii  libreoffice-help-en-us [libreoffice-help]   1:7.0.4-3
pn  libreoffice-l10n
pn  

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Guilhem Moulin]

On Tue, 12 Jan 2021 at 21:50:19 +0100, Jonas Smedegaard wrote:
>> br is the ISO 639-1 code for the breton language but I guess that's 
>> not what you mean (application/ecmascript, text/x-perl or video/gl 
>> don't conflict with the language codes for Spanish, Polish or Galician 
>> right)?  After quick search I was unable to find an official 
>> registration for the .br file suffix.
> 
> As I recall, the "officiality" of it is tied to that ISO 639-1 and some 
> W3C definitions (but might just be recommendations, and might just be 
> Apache2 practise).

I'm rather suprised by this, matching the 184 ISO 639-1 codes against a
stock mime.types from media-types 3.0.0 I find 23 conflicts (16 if we
exclude the /x- MIME types):

  cu Church Slavic| application/cu-seemecu
  es Spanish  | application/ecmascript  es
  nb Norwegian Bokmål | application/mathematica nb ma mb nbp
  ps Pushto   | application/postscript  ps ai eps 
epsi epsf eps2 eps3
  sc Sardinian| application/vnd.ibm.secure-containersc
  st Southern Sotho   | application/vnd.sailingtracker.trackst
  sr Serbian  | application/vnd.sigrok.session  sr
  pt Portuguese   | application/vnd.snesdev-page-table  ptrom pt
  fo Faroese  | application/vnd.software602.filler.form+xml fo
  sm Samoan   | application/vnd.stepmania.stepchart sm
  ms Malay| application/x-troff-ms  ms
  rm Romansh  | audio/x-pn-realaudiora rm ram
  sd Sindhi   | chemical/x-mdl-sdfile   sd sdf
  sw Swahili  | chemical/x-swissprotsw
  tr Turkish  | text/troff  t tr roff
  gv Manx | text/vnd.graphviz   gv dot
  ts Tsonga   | text/vnd.trolltech.linguist ts
  si Sinhala  | text/vnd.wap.si si
  sl Slovenian| text/vnd.wap.sl sl
  pl Polish   | text/x-perl pl pm
  tk Turkmen  | text/x-tcl  tcl tk
  dv Divehi   | video/dvdif dv
  gl Galician | video/glgl

HTTP daemons may ignore our /etc/mime.types, but as of nginx 1.18.0-6
from sid the default config has conflicts for

  ps Pushto | application/postscript ps ai eps epsi epsf eps2 eps3
  pl Polish | text/x-perlpl pm

AFAICT Debian's apache uses /etc/mime.types by default (so the above
applies), but docs/conf/mime.types from the source tree has conflicts
for

  cu Church Slavic| application/cu-seeme cu
  nb Norwegian Bokmål | application/mathematica  nb ma mb
  so Somali   | application/octet-stream bin dms lrf mar so 
dist distz pkg bpk dump elc deploy
  ps Pushto   | application/postscript   ai eps ps
  sc Sardinian| application/vnd.ibm.secure-container sc
  rm Romansh  | application/vnd.rn-realmedia rm
  st Southern Sotho   | application/vnd.sailingtracker.track st
  sm Samoan   | application/vnd.stepmania.stepchart  sm
  tr Turkish  | text/troff   t tr roff man me ms
  gv Manx | text/vnd.graphvizgv

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#845498: [Pkg-pascal-devel] Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Helmut Grohne]

Hi,

I'm coming late to the party and I only understand a fraction of what
you wrote, but the parts I do understand make a lot of sense.

On Mon, Nov 28, 2016 at 05:25:14PM -0800, Ben Longbons wrote:
> On Mon, Nov 28, 2016 at 12:19 AM, Abou Al Montacir
>  wrote:
> > For now you can use multi-arch to install fp-compiler
> 
> No, you can't (that was the first thing I thought of):
> fp-compiler:i386 depends on binutils:i386 rather than
> binutils-i586-linux-gnu, and binutils:i386 isn't multiarch
> installable. You'd have to do a full cross chroot, currently.

I've read the whole discussion and I'm getting the impression that there
are two distinct issues that are conflated inside this bug.

One one hand, it would be nice to be able to install a foreign
fp-compiler to be able to call an emulated (via qemu) compiler. On the
other hand it would be nice to be able to install a cross compiler. And
then there is a third issue not otherwise mentioned, which is cross
building the compiler itself.

All of them are nice and they interact somewhat with one another, but it
helps to tell these issues apart.

> But once the dependency part is fixed, /etc/fpc.cfg can `#INCLUDE
> /etc/fpc/$FPCTARGET.cfg` and put `-e/usr/i586-linux-gnu/bin
> -Fl/usr/lib/i386-linux-gnu -Fl/lib/i386-linux-gnu -Fl /usr/lib32
> -Fl/lib32` in there (each of those .cfg files will have to be manually
> written/installed based on the Debian arch (of the fp-compiler
> package), the Debian triple (subdir of /usr/lib), the legacy libdir
> (/lib32 - actually not sure if this is necessary or not anymore), the
> GNU triple (of binutils), and the FPC target (for choice of the
> filename)). Incidentally, managing /etc/fpc.cfg through
> update-alternatives is a waste since it could be implemented as just
> `#INCLUDE /etc/fpc-$fpcversion.cfg` (though since jessie has 2.6.4, an
> appropriate upgrade path would need to be written).

This is the part where I only understand very little. The thing I do
understand is that there is a fpc.cfg that influences how the compiler
behaves and given the "right" fpc.cfg it can mostly act as a cross
compiler.

As far as I understand though, there is a major piece missing in the
Debian package to make this reality. I've run fpc hello.pas under strace
and I observe that it calls out to ppcx64. If I were to cross compile
for armel, it would likely call into ppcarm, but there is no ppcarm
binary in any :amd64 package. So regardles how we configure it, we'll
need more binaries to make this happen. Please tell if you think this is
wrong.

> The above is fairly trivial and will get you a multiarch "cross"
> compiler, with /etc/ ready for real (non-multiarch fp-compiler (I
> *think* the libc6-*-cross packages are only needed because of ld.so
> conflicting. but fp-units-* are actually multiarch safe already,
> they're just not marked as such - they put all their files in
> /usr/lib/fpc/$fpcversion/{units,fpmkinst}/$FPCTARGET/ already)) ones.
> Then it's just a SMOC to actually build real cross-compilers binary
> packages from the Debian source package.

I'm not sure yet how you solve the missing binaries, but I'm all for
having cross compilers in the archive.

The initial point was switching the binutils dependency to
binutils-$triplet. Since binutils 2.30-6, we have binutils-for-host and
that means that we always have a binutils-$triplet:$arch where arch and
triplet match. So if you are ok with ignoring oldstable, you can now
depend on the triplet variant without issues.

However, I think that doing so is technically wrong. When I straced fpc,
I saw that it calls into ld.bfd. binutils-x86-64-linux-gnu does not
contain ld.bfd, so the dependency is too weak for what fpc uses. In
order for a binutils-$triplet to be a correct dependency, we'd have to
somehow tell fpc to always invoke triplet-prefixed tools such as
x86_64-linux-gnu-ld.bfd.

And given the pointer to fpc.cfg, I looked into it and stumbled into the
-XP option. It is conditional to cross compiling, but given Debian's
packaging of binutils, it is also relevant to foreign installation.
We'll need to teach fpc to always use the -XP option even natively. Once
that is done, we can replace the binutils dependency with
"binutils-$triplet" or if you require backwards compatibility with
stretch "binutils-$triplet | binutils". Once doing these two bits,
foreign installation should become possible.

The next part was fpc as a cross compiler. I think that one of the first
pieces to getting there is ensuring that all the compiler backend
binaries (e.g. ppcx86 or ppcarm) are built for all architectures. This
does not happen today. Any ideas on how to get there?

A separate problem (at least for me) is figuring out what the API to
cross building with fpc is. What is a builder expected to do to build
natively or to cross build?

How to build sources for some architecture that can be run (aka build
archtecture)?
 * fpc answer: Run plain fpc.
 * gcc answer: Run plain gcc. In future, this 

Bug#980012: FTBFS: TypeError: Cannot read property 'register' of undefined

[Xavier Guimard]

Package: coffeescript
Version: 1.12.8~dfsg-4
Severity: serious

coffeescript build seems broken. Logs:

 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building coffeescript using existing 
./coffeescript_1.12.8~dfsg.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building coffeescript in 
coffeescript_1.12.8~dfsg-5.debian.tar.xz
dpkg-source: info: building coffeescript in coffeescript_1.12.8~dfsg-5.dsc
 debian/rules binary
CDBS WARNING:  copyright-check disabled - licensecheck is missing.
test -x debian/rules
dh_testroot
dh_prep
dh_installdirs -A
mkdir -p "."

Scanning upstream source for new/changed copyright notices...

set -e; LC_ALL=C.UTF-8 /usr/bin/licensecheck --check '.*' --recursive 
--copyright --deb-fmt --ignore 
'^(debian/(changelog|copyright(|_hints|_newhints)))$' --lines 0 -- * | 
/usr/lib/cdbs/licensecheck2dep5 > debian/copyright_newhints
/bin/sh: 1: /usr/bin/licensecheck: not found
0 combinations of copyright and licensing found.
No new copyright notices found - assuming no news is good news...
touch debian/stamp-copyright-check
mkdir -p "debian/upstream-cruft"
cp -a "lib" "debian/upstream-cruft/lib";
touch debian/stamp-upstream-cruft
mkdir -p docs/v1/browser-compiler
chmod +x bin/cake
bin/cake build
bin/cake build
bin/cake build:browser
bin/cake test
(node:2439631) [DEP0005] DeprecationWarning: Buffer() is deprecated due to 
security and usability issues. Please use the Buffer.alloc(), 
Buffer.allocUnsafe(), or Buffer.from() methods instead.
(node:2439631) [DEP0124] DeprecationWarning: REPLServer.rli is deprecated
passed 856 tests in 1.66 seconds
bin/cake test:browser
/<>/Cakefile:450
CoffeeScript.register();
 ^

TypeError: Cannot read property 'register' of undefined
at runTests (/<>/Cakefile:450:18)
at Object.action (/<>/Cakefile:562:19)
at invoke (/<>/lib/coffee-script/cake.js:44:26)
at Object.exports.run (/<>/lib/coffee-script/cake.js:70:20)
at Object. (/<>/bin/cake:15:42)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Function.executeUserEntryPoint [as runMain] 
(internal/modules/run_main.js:60:12)
at internal/main/run_main_module.js:17:47

Bug#980011: src:r-cran-dbplyr: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: r-cran-dbplyr
Version: 1.4.4-1
Severity: serious
Control: close -1 2.0.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:r-cran-dbplyr
in its current version in unstable has been trying to migrate for 61
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=r-cran-dbplyr




OpenPGP_signature
Description: OpenPGP digital signature

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2021-01-12 21:50:19)
> Quoting Guilhem Moulin (2021-01-12 21:30:43)
> > On Tue, 12 Jan 2021 at 20:19:18 +0100, Jonas Smedegaard wrote:
> > > The officially registered meaning for file suffix .br is the 
> > > language breton.
> > 
> > Do you have a link for this?
> 
> Sorry, I found some evidence but don't recall if it was substantion 
> and failed at locating it again now :-)

Found now what convinced me to use .brotli instead of .br: 
https://kevinlocke.name/bits/2016/01/20/serving-pre-compressed-files-with-apache-multiviews/#adding-brotli

Boils down to...

  * Apache2 already by default use ISO 639-1 suffices
(so "just" a well-stablished default, no official standard)
  * rfc7932 refrain from recommending a suffix
(only talks about "HTTP Content Coding Registry")


> > br is the ISO 639-1 code for the breton language but I guess that's 
> > not what you mean (application/ecmascript, text/x-perl or video/gl 
> > don't conflict with the language codes for Spanish, Polish or 
> > Galician right)?  After quick search I was unable to find an 
> > official registration for the .br file suffix.
> 
> As I recall, the "officiality" of it is tied to that ISO 639-1 and 
> some W3C definitions (but might just be recommendations, and might 
> just be Apache2 practise).

More specifically, Apache2 by default follows RFC 3066: 
https://httpd.apache.org/docs/current/mod/mod_mime.html#addlanguage

...and encourages using both language codes and media types (e.g. a 
JavaScript file pre-compressed using brotli) and handlers (e.g. 
on-the-fly request for brotli-compression when serving a JavaScript 
file), and warns about clashes between those: 
https://httpd.apache.org/docs/current/mod/mod_mime.html#multipleext


> > It appears there was some debate upstream about the default 
> > extension (.br / .bro / .brotli) [0,1] but they now settled on .br 
> > and I think it's unfortunate to choose something else, especially 
> > given this not configurable everywhere.
> 
> I remember seeing such debate - but apparently another than the 
> toothless "debate" at [0] which does not mention ISO 639-1 at all.

The debate I saw was Mozilla (referenced from above kevinlocke page): 
https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147

...but really that discussion ended without deciding on a file 
extension, probably because Firefox does not need that at all.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#980010: Please create a debian-i...@lists.debian.org list

[Adrian Bunk]

Package: lists.debian.org
Severity: normal

Originally the list for discussing i386 specific issues
was debian-devel, since i386 was the main architecture
nearly everyone was using.

These days this main architecture nearly everyone is using
is amd64 (and the debian-amd64 list has become low/no-traffic).

Please create a debian-i386 list for discussing i386 specific issues.

Thanks in advance

Bug#979986: Please, drop composer dependency

[Dmitry Smirnov]

Hi David,

On Wednesday, 13 January 2021 3:05:37 AM AEDT David Prévot wrote:
> civicrm-common depends on composer, it seems like it is used as a
> dynamic autoloader:
> 
> https://salsa.debian.org/debian/civicrm/-/blob/master/debian/autoload-vendo
> r.php.tpl#L11
> 
> Please, do drop the dependency on composer

Thank you for your suggestion. Unfortunately, at the moment I can not do that
as CiviCRM just does not work without it (or I don't know _how_ to do it).


> and use proper static autoloader(s) instead.

What would that be? I've thought that using phpab is the way to go.
My knowledge is limited. How do you recommend to address the problem?


> There is work in progress to make that task
> mostly automatic in the future, but relying on composer to make every
> PHP library installed on the system available to civicrm seems like a
> very bad idea (maybe even a security issue).

I do not see that as a problem. For example, it is normal for Perl
applications to have access to all installed libraries.

For CiviCRM it make sense to use few vendored libraries and have
"/usr/share/php" as a last location in the include_path to expose
operating system libraries to be used as required.

Moreover, CiviCRM is a complex modular application. Some components can
be enabled/disabled by admin and that affects the list of used libraries.
I'm not sure how it affects use of composer...


> https://salsa.debian.org/php-team/pear/pkg-php-tools/-/merge_requests/6

Interesting approach. Thank you. I'm looking forward to try it once it
is incorporated into "pkg-php-tools" with detailed HOWTO instructions
and examples for beginners.

IMHO using composer is awkward and causes a lot of packaging inconvenience.
I would love to learn more about better ways to package apps depending
on composer. Thanks.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

"Government using COVID-19 to get rid of jury trials"
-- Kate Brunner QC, head barrister for Cornwall and Devon
   https://www.cornwalllive.com/news/government-using-covid-19-rid-4260447


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

Bug#751776: planning to NMU time 1.9

[Bob Proulx]

Matthias Klose wrote:
> I prepared the time 1.9 release, and I'd like to NMU the package, planning to
> upload on Tuesday to DELAYED/7.

Thank you for preparing this NMU.  I appreciate your help with this
package.  It is okay with me if you upload it to an earlier delayed
queue if you desire.

Bob


signature.asc
Description: PGP signature

Bug#980009: node-js-yaml frequently FTBFS: test timeout

[Adrian Bunk]

Source: node-js-yaml
Version: 3.14.1+dfsg+~3.12.6-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-js-yaml.html
https://buildd.debian.org/status/fetch.php?pkg=node-js-yaml=all=3.14.1%2Bdfsg%2B~3.12.6-1=1610381331=0

...
  254 passing (3s)
  1 failing

  1) Properties
   Load from dumped should be the original object:
 Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure 
"done()" is called; if returning a Promise, ensure it resolves. 
(/<>/test/25-dumper-fuzzy.js)
  at Test.Runnable._timeoutError 
(/usr/share/nodejs/mocha/lib/runnable.js:432:10)
  at done (/usr/share/nodejs/mocha/lib/runnable.js:306:18)
  at callFn (/usr/share/nodejs/mocha/lib/runnable.js:387:7)
  at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:352:5)
  at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:677:10)
  at /usr/share/nodejs/mocha/lib/runner.js:801:12
  at next (/usr/share/nodejs/mocha/lib/runner.js:594:14)
  at /usr/share/nodejs/mocha/lib/runner.js:604:7
  at next (/usr/share/nodejs/mocha/lib/runner.js:486:14)
  at Immediate._onImmediate (/usr/share/nodejs/mocha/lib/runner.js:572:5)
  at processImmediate (internal/timers.js:461:21)



dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1
make: *** [debian/rules:8: binary-indep] Error 25

Bug#980005: lumpy-sv: lumpyexpress fails with no args

[Andreas Tille]

Control: tags -1 confirmed
Control: tags -1 help

Hi,

I confirm I can reproduce the issue in a minimal chroot while the
lumpyexpress command prints the help screen as expected.  This smells
like a missing dependency but I do not have any idea which one.  It
seems there is a similar known issue here

   
https://stackoverflow.com/questions/65028261/attributeerror-module-importlib-has-no-attribute-util-ii

but there is no answer here.

Any idea how to fix this?

Kind regards

  Andreas.

On Tue, Jan 12, 2021 at 08:05:26PM +, Ken Yamaguchi wrote:
> Package: lumpy-sv
> Version: 0.3.1+dfsg-4
> Severity: important
> X-Debbugs-Cc: deb...@knowledgesynthesis.com
> 
> Dear Maintainer,
> 
> I built a lumpy-sv Docker image with the attached Dockerfile. Running a 
> container for the image produces the following error:
> 
> Sourcing executables from /etc/lumpy-sv/lumpyexpress.config ...
> 
> Checking for required python modules (/usr/bin/python3)...
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: module 'importlib' has no attribute 'util'
> 
> Thanks,
> Ken
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
> 
> Versions of packages lumpy-sv depends on:
> ii  bamkit0.0.1+git20170413.ccd079d-2
> ii  libbamtools2.5.1  2.5.1+dfsg-7+b1
> ii  libc6 2.31-9
> ii  libgcc-s1 10.2.1-3
> ii  libgzstream0  1.5+dfsg-5
> ii  libhts3   1.11-4
> ii  libstdc++610.2.1-3
> ii  python3   3.9.1-1
> ii  python3-numpy 1:1.19.4-1+b1
> ii  python3-pysam 0.15.4+ds-3+b2
> ii  samblaster0.1.26-1
> ii  samtools  1.11-1
> 
> Versions of packages lumpy-sv recommends:
> pn  sambamba  
> 
> lumpy-sv suggests no packages.
> 
> -- no debconf information

> FROM debian:bullseye-slim
> 
> RUN apt-get update && \
> apt-get -y --no-install-recommends full-upgrade && \
> apt-get -y --no-install-recommends install \
> lumpy-sv \
> && \
> rm -rf /var/lib/apt/lists/*
> 
> RUN useradd -ms /bin/bash lumpy
> 
> USER lumpy
> 
> WORKDIR /home/lumpy
> 
> CMD ["lumpyexpress"]

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#976097: python3-django-postorius cannot be installed in testing

[Adrian Bunk]

Control: retitle -1 postorius: autopkgtest failure

On Sun, Nov 29, 2020 at 06:42:17PM +0100, Matthias Klose wrote:
> Package: src:postorius
> Version: 1.3.2-2.1
> Severity: serious
> Tags: sid bullseye
> 
> python3-django-postorius cannot be installed in testing. The autopkg tests 
> pass
> in unstable but fail in testing.
> 
> see https://ci.debian.net/packages/p/postorius/testing/amd64/
> 
> [...]
> Updating certificates in /etc/ssl/certs...
> 126 added, 0 removed; done.
> Setting up libpython3.8-stdlib:amd64 (3.8.6-1) ...
> Setting up python3.8 (3.8.6-1) ...
> Processing triggers for ca-certificates (20200601) ...
> Updating certificates in /etc/ssl/certs...
> 0 added, 0 removed; done.
> Running hooks in /etc/ca-certificates/update.d...
> done.
> autopkgtest: WARNING: package python3-django-postorius is not installed though
> it should be
>...

This looks like temporary breakagge during the python3 transition.

Current failures are:
https://ci.debian.net/packages/p/postorius/

...Creating test database for alias 'default'...
.x.x..F..E.E..EEE.E..EEE.EEE...autopkgtest
 
[17:25:11]: ERROR: timed out on command "su -s /bin/bash root -c set -e; 
export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  . 
~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/build.ZWo/src"; mkdir 
-p -m 1777 -- 
"/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/python3-django-postorius-artifacts"; 
export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/python3-django-postorius-artifacts";
 
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/autopkgtest_tmp"; 
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; 
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=48; unset 
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY 
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT 
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo 
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f 
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export 
AUTOPKGTEST_NORMAL_USER=debci; export ADT_NORMAL_USER=debci; chmod +x 
/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/build.ZWo/src/debian/tests/python3-django-postorius;
 
touch 
/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/python3-django-postorius-stdout 
/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/python3-django-postorius-stderr; 
/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/build.ZWo/src/debian/tests/python3-django-postorius
 
2> >(tee -a 
/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/python3-django-postorius-stderr 
>&2) > >(tee -a 
/tmp/autopkgtest-lxc.8k_pq1u2/downtmp/python3-django-postorius-stdout);" 
(kind: test)
autopkgtest [17:25:11]: test python3-django-postorius: 
---]
autopkgtest [17:25:11]: test python3-django-postorius:  - - - - - - - - 
- - results - - - - - - - - - -
python3-django-postorius FAIL timed out


cu
Adrian

Bug#962203: NMU

[Calum McConnell]

Of course I would be willing to help out on package maintenance: I won't
be able to do much this week, but in coming weeks I should be more helpful


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

Bug#979942: [Pkg-javascript-devel] Bug#979942: Bug#979942: Bug#979942: embedding dead code is no fix to bug for removing that same dead code

[Jonas Smedegaard]

Quoting Bastien ROUCARIES (2021-01-12 21:17:36)
> Fixed it was a little bit hard to test options of compression one by
> one but it work now.

Great!  Thanks!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#979993: libjs-jquery: Missing minified files

[Veiko Aasa]

Package: libjs-jquery
Version: 3.5.1+dfsg+~3.5.5-5
Severity: important
X-Debbugs-Cc: veik...@disroot.org

Dear Maintainer,

Version 3.5.1+dfsg+~3.5.5-5 is missing the minified version of jquery. This 
breaks web apps that use the minified version. 

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

Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

libjs-jquery depends on no packages.

Versions of packages libjs-jquery recommends:
ii  javascript-common  11+nmu1

libjs-jquery suggests no packages.

-- no debconf information

Bug#980008: RFS: clikit/0.6.2-1 [ITP] -- utilities to build beautiful command lines interfaces

[Emmanuel Arias]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear mentors,

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

 * Package name: clikit
   Version : 0.6.2-1
   Upstream Author : Sébastien Eustace 
 * URL : https://github.com/sdispater/clikit
 * License : expat
 * Vcs : https://salsa.debian.org/python-team/packages/clikit
   Section : python

It builds those binary packages:

  python3-clikit - utilities to build beautiful command lines interfaces

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/c/clikit/clikit_0.6.2-1.dsc

Changes for the initial release:

 clikit (0.6.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #977675)

Regards,
-- 
  Emmanuel Arias

Bug#979992: RFS: uwebsockets/18.19.0-1 [ITP] -- simple, secure & standards compliant web server

[Aisha Tammy]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: uwebsockets
   Version : 18.19.0-1
   Upstream Author : Alex Hultman 
 * URL : https://github.com/uNetworking/uWebSockets
 * License : Apache-2.0
 * Vcs : https://github.com/uNetworking/uWebSockets
   Section : libs

It builds those binary packages:

  uwebsockets-dev - simple, secure & standards compliant web server

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/uwebsockets/uwebsockets_18.19.0-1.dsc

Changes for the initial release:

 uwebsockets (18.19.0-1) unstable; urgency=medium
 .
   * Initial release (closes: #979861)

Regards,
Aisha

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Jonas Smedegaard]

Quoting Guilhem Moulin (2021-01-12 21:30:43)
> On Tue, 12 Jan 2021 at 20:19:18 +0100, Jonas Smedegaard wrote:
> > I think you (and nginx?) are mistaken:
> 
> FWIW ngx_brotli is a third-party nginx module developed by the folks 
> (Google) behind the brotli(1) utility and the brotli data format 
> [RFC7932].

Heh - developed by Google I am not surprised they have their own agenda.


> > The officially registered meaning for file suffix .br is the 
> > language breton.
> 
> Do you have a link for this?

Sorry, I found some evidence but don't recall if it was substantion and 
failed at locating it again now :-)


> br is the ISO 639-1 code for the breton language but I guess that's 
> not what you mean (application/ecmascript, text/x-perl or video/gl 
> don't conflict with the language codes for Spanish, Polish or Galician 
> right)?  After quick search I was unable to find an official 
> registration for the .br file suffix.

As I recall, the "officiality" of it is tied to that ISO 639-1 and some 
W3C definitions (but might just be recommendations, and might just be 
Apache2 practise).


> It appears there was some debate upstream about the default extension 
> (.br / .bro / .brotli) [0,1] but they now settled on .br and I think 
> it's unfortunate to choose something else, especially given this not 
> configurable everywhere.

I remember seeing such debate - but apparently another than the 
toothless "debate" at [0] which does not mention ISO 639-1 at all.


> > Until that clash with language code is resolved (if ever) I think it 
> > is wrong to change back, and I therefore flag this as wontfix.
> 
> Please at least document the extension change in the NEWS files, as 
> the change might require a manual configuration update on the HTTPd.

Ah, I thought it was introduced recently, even with the old suffix, but 
I see now that it was in buster.  Yes, makes sense to add a NEWS entry 
for that.  Thanks!


 - Jonas


> [0] https://github.com/google/brotli/issues/299 
> [1] https://news.ycombinator.com/item?id=11336756

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#979965: milter-greylist exits after running for a few minutes

[Sudip Mukherjee]

Hi Michael,

On Tue, Jan 12, 2021 at 5:54 PM Vagrant Cascadian  wrote:
>
> On 2021-01-12, Michael Grant wrote:
> > After update to 4.6.2-2, milter-greylist runs for a few minutes
> > processing greylist requests then exits.  No error in the daemon.log.
> > Daemon restarts with systemd over and over.
> >
> > Starting milter-greylist by hand using strace shows this just before
> > it dies:
> >
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 1 ([{fd=3,
> > revents=POLLIN}])
> > accept(3, {sa_family=AF_UNIX}, [2]) = 10
> > fcntl(10, F_GETFD)  = 0
> > fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
> > setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> > futex(0x7f0f22c221a4, FUTEX_WAKE_PRIVATE, 1) = 1
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> > poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000 ) = ?
> > +++ exited with 71 +++
> >
> > Previous version of milter-greylist on debian/testing was working fine
> > without this issue.
>
> Could you try running without the systemd .service file so that it falls
> back to the init script; there may be differences between how the
> .service file and the init script set up the environment to run it.

Can you also modify /lib/systemd/system/milter-greylist.service and
change the [Service] section to the following and test please..
[Service]
Type=forking
ExecStart=/usr/sbin/milter-greylist
Restart=on-failure
PrivateTmp=true


-- 
Regards
Sudip

Bug#963887:

[Masum Khan]

Bug#979991: RFS: purritobin/0.3.3-1 [ITP] -- ultra fast, minimalistic, encrypted command line paste-bin

[Aisha Tammy]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: purritobin
   Version : 0.3.3-1
   Upstream Author : Aisha Tammy 
 * URL : https://bsd.ac/
 * License : ISC
 * Vcs : https://github.com/PurritoBin/PurritoBin
   Section : web

It builds those binary packages:

  purritobin - ultra fast, minimalistic, encrypted command line paste-bin

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/purritobin/purritobin_0.3.3-1.dsc

Changes for the initial release:

 purritobin (0.3.3-1) unstable; urgency=medium
 .
   * Initial release (Closes: #979860)

Regards,
Aisha

Bug#979990: RFS: uwebsockets/18.19.0-1 [ITP] -- simple, secure & standards compliant web server

[Aisha Tammy]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: uwebsockets
   Version : 18.19.0-1
   Upstream Author : Alex Hultman 
 * URL : https://github.com/uNetworking/uWebSockets
 * License : Apache-2.0
 * Vcs : https://github.com/uNetworking/uWebSockets
   Section : libs

It builds those binary packages:

  uwebsockets-dev - simple, secure & standards compliant web server

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/uwebsockets/uwebsockets_18.19.0-1.dsc

Changes for the initial release:

 uwebsockets (18.19.0-1) unstable; urgency=medium
 .
   * Initial release (closes: #979861)

Regards,
Aisha

Bug#932461: src:libfm: archivers.list fix xarchiver command

[Amy Kos]

Control: tags -1 patch upstream
Control: reassign -1 src:libfm


Hi,

patch available on salsa, commit: 103c4695

Cheers,
Amy

Bug#930334: src:libfm-qt: archivers.list fix xarchiver command

[Amy Kos]

Control: tags -1 patch upstream
Control: reassign -1 src:libfm-qt


Hi,

patch available on salsa, commit: a30ef507

Cheers,
Amy

Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso

[Ben Hutchings]

On Tue, 2021-01-12 at 19:50 +0100, Holger Wansing wrote:
> Hi,
> 
> Holger Wansing  wrote:
> > Yes, that works fine, using a netboot image, I am NOT asked to
> > provide
> > firmware for regulatory.db file, because it's already included in
> > the d-i
> > image.
> > 
> > However, that's only true for netboot images!
> > 
> > My wireless card (on an IBM Thinkpad T60) is also usable with
> > DVD/CD netinst images 
> > (so related kernel modules seem to be included in those images; I
> > have explicitly
> > tested that with said images on that T60), so probably wireless-
> > regdb-udeb should just 
> > be added to all Linux d-i images?
> 
> I prepared a patch for this (includes removing it from the netboot/* files,
> since it's now added generally in pkg-lists/base).
> Will apply it, if noone objects.

Oh, I see.  What I did was to add it to every list that includes nic-
wireless-modules, forgetting that for "CD" images that's not present in
the initramfs and will get installed later.

I think the cleanest solution, that I originally intended to implement,
is to make it a dependency of nic-wireless-modules, but that was going
to require changing kernel-wedge.  But I don't have time to do that
now, so I'm happy with your change.  The size increase will be
negligible.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Guilhem Moulin]

On Tue, 12 Jan 2021 at 20:19:18 +0100, Jonas Smedegaard wrote:
> I think you (and nginx?) are mistaken:

FWIW ngx_brotli is a third-party nginx module developed by the folks
(Google) behind the brotli(1) utility and the brotli data format
[RFC7932].

> The officially registered meaning for file suffix .br is the language
> breton.

Do you have a link for this?  br is the ISO 639-1 code for the breton
language but I guess that's not what you mean (application/ecmascript,
text/x-perl or video/gl don't conflict with the language codes for
Spanish, Polish or Galician right)?  After quick search I was unable to
find an official registration for the .br file suffix.

It appears there was some debate upstream about the default extension
(.br / .bro / .brotli) [0,1] but they now settled on .br and I think
it's unfortunate to choose something else, especially given this not
configurable everywhere.

> Until that clash with language code is resolved (if ever) I think it is
> wrong to change back, and I therefore flag this as wontfix.

Please at least document the extension change in the NEWS files, as the
change might require a manual configuration update on the HTTPd.

-- 
Guilhem.

[0] https://github.com/google/brotli/issues/299 
[1] https://news.ycombinator.com/item?id=11336756


signature.asc
Description: PGP signature

Bug#979989: RFS: usockets/0.6.0-1 [ITP] -- miniscule async eventing, networking & crypto library

[Aisha Tammy]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: usockets
   Version : 0.6.0-1
   Upstream Author : Alex Hultman 
 * URL : https://github.com/uNetworking/uSockets
 * License : Apache-2.0
 * Vcs : https://github.com/uNetworking/uSockets
   Section : libs

It builds those binary packages:

  libusockets0.6.0 - miniscule async eventing, networking & crypto library
  libusockets-dev - usockets - development files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/usockets/usockets_0.6.0-1.dsc

Changes for the initial release:

 usockets (0.6.0-1) unstable; urgency=medium
 .
   * Initial release (closes: #979844)

Regards,
Aisha

Bug#979942: [Pkg-javascript-devel] Bug#979942: Bug#979942: embedding dead code is no fix to bug for removing that same dead code

[Bastien ROUCARIES]

Hi,

Fixed it was a little bit hard to test options of compression one by
one but it work now.


Le mar. 12 janv. 2021 à 17:48, Xavier  a écrit :
>
> Control: tags -1 reopen
> Control: severity -1 serious
>
> Le 12/01/2021 à 18:17, Jonas Smedegaard a écrit :
> > Quoting Debian FTP Masters (2021-01-12 18:06:40)
> >>  node-browser-pack (6.1.0+ds-7) unstable; urgency=medium
> >>  .
> >>* Team upload
> >>* Bump debhelper compatibility level to 13
> >>* Declare compliance with policy 4.5.1
> >>* Use dh-sequence-nodejs
> >>* Remove dependency to node-uglify but embed node-uglify in 
> >> build_modules
> >>  else build file is wrong (Closes: #979942)
> >
> > Do I read the above correctly that node-browser-pack "fixes" node-uglify
> > going away by embedding it, hidden?
> >
> > I disagree that that is a fix.
>
> OK, but I didn't succeed to fix that, let's reopen, upgrade severity and
> wait for someone else to fix it
>
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#980007: tcmu: CVE-2020-28374

[Salvatore Bonaccorso]

Source: tcmu
Version: 1.5.2-5
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 tcmu.

CVE-2020-28374[0]:
| Linux SCSI target (LIO) unrestricted copy offload

A patch was provided in [1] but at time of writing it does not apper
to be yet in the upstream repository.

Further information in [2].

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-28374
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28374
[1] https://bugzilla.suse.com/show_bug.cgi?id=1180676
[2] https://www.openwall.com/lists/oss-security/2021/01/12/12

Regards,
Salvatore

Bug#980006: pulseaudio: fails to prompt Gnome for headphone/headset selection (regression in 14.x)

[Harlan Lieberman-Berg]

Package: pulseaudio
Version: 14.0-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: hlieber...@debian.org, 
pkg-gnome-maintain...@lists.alioth.debian.org

Hello maintainers,

Not entirely sure whether this is a GNOME issue or a pulseaudio issue, but since
the breakage occured due to a change in the pulseaudio API, I'm putting it here
for now. Feel free to move it if appropriate.

Since upgrading from the 13.x branch, GNOME no longer prompts whether a device
is a headphone or headset on plug insertion. After talking with i-garrison on
freenode/#pulseaudio, our guess is that this is related to the creation of
availability groups in 13.99.2 and the changes made to module
switch-on-port-available.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1028 is related,
though not specifically covering the breakage between GNOME and PA, but rather
mistakes in the way PA did selection from g-s-d.

Sincerely,

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-6
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-1
ii  libgcc-s110.2.1-3
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-14
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.0-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-8
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-3
ii  libsystemd0  247.2-4
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.2-4
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.6.12-1
ii  libx11-xcb1  2:1.6.12-1
ii  libxcb1  1.14-2.1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.0-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-1
ii  libpam-systemd [logind]  247.2-4
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  4.0-2
pn  pavumeter
ii  udev 247.2-4

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; 

Bug#980005: lumpy-sv: lumpyexpress fails with no args

[Ken Yamaguchi]

Package: lumpy-sv
Version: 0.3.1+dfsg-4
Severity: important
X-Debbugs-Cc: deb...@knowledgesynthesis.com

Dear Maintainer,

I built a lumpy-sv Docker image with the attached Dockerfile. Running a 
container for the image produces the following error:

Sourcing executables from /etc/lumpy-sv/lumpyexpress.config ...

Checking for required python modules (/usr/bin/python3)...
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: module 'importlib' has no attribute 'util'

Thanks,
Ken

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages lumpy-sv depends on:
ii  bamkit0.0.1+git20170413.ccd079d-2
ii  libbamtools2.5.1  2.5.1+dfsg-7+b1
ii  libc6 2.31-9
ii  libgcc-s1 10.2.1-3
ii  libgzstream0  1.5+dfsg-5
ii  libhts3   1.11-4
ii  libstdc++610.2.1-3
ii  python3   3.9.1-1
ii  python3-numpy 1:1.19.4-1+b1
ii  python3-pysam 0.15.4+ds-3+b2
ii  samblaster0.1.26-1
ii  samtools  1.11-1

Versions of packages lumpy-sv recommends:
pn  sambamba  

lumpy-sv suggests no packages.

-- no debconf information
FROM debian:bullseye-slim

RUN apt-get update && \
apt-get -y --no-install-recommends full-upgrade && \
apt-get -y --no-install-recommends install \
lumpy-sv \
&& \
rm -rf /var/lib/apt/lists/*

RUN useradd -ms /bin/bash lumpy

USER lumpy

WORKDIR /home/lumpy

CMD ["lumpyexpress"]

Bug#979843: python-django: autopkgtest regression in testing: 'image/vnd.mozilla.apng' != 'image/png'

[Paul Gevers]

Control: reopen -1

Hi Chris,

On 12-01-2021 13:57, Chris Lamb wrote:
> This appears to be returning the correct result. Has another mimetype-
> related package been updated recently? I can't seem to locate one.

Did you see
https://lists.debian.org/msgid-search/20210108232226.gb23...@bubu.plessy.net

And, please don't close the bug until the regression in testing is
really solved. https://ci.debian.net/packages/p/python-django/ shows
your package fails it's autopkgtest since a couple of days on all
architectures it got tested.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979392: RFS: libfilezilla/0.26.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Gianfranco Costamagna]

Hello,

On Thu, 07 Jan 2021 03:21:51 + Philip Wyett  
wrote:
> On Wed, 2021-01-06 at 13:27 +0100, Adam Borowski wrote:
> > On Wed, Jan 06, 2021 at 04:15:28AM +, Philip Wyett wrote:
> > >  * Package name: libfilezilla
> > >Version : 0.26.0-1
> > > 
> > > It builds those binary packages:
> > > 
> > >   libfilezilla0 - build high-performing platform-independent
> > > programs
> > > (runtime lib)
> > >   libfilezilla-dev - build high-performing platform-independent
> > > programs (development)
> > 
> > The soname has changed, you'd need to rename the runtime package to
> > libfilezilla1.
> > 
> > 

Looks like the SONAME is currently set to 11

objdump -p ../libfilezilla.so.11.0.0  |grep -i SONAME
  SONAME   libfilezilla.so.11


I fixed the number and uploaded to binNEW queue, will follow up with filezilla 
once accepted!

G.

Bug#979993: [Pkg-javascript-devel] Bug#979993: libjs-jquery: Missing minified files

[Jonas Smedegaard]

Quoting Veiko Aasa (2021-01-12 20:18:17)
> On Tue, 2021-01-12 at 19:46 +0100, Jonas Smedegaard wrote:
> > 
> > Are you sure you have the latest package installed?
> > 
> > Please provide the output of this command:
> > 
> >   apt list libjs-jquery
> 
> I got same results.
> 
> # apt list libjs-jquery
> Listing... Done
> libjs-jquery/testing,now 3.5.1+dfsg+~3.5.5-5 all [installed]
> 
> However:
> $ ls -l /usr/share/javascript/jquery
> lrwxrwxrwx 1 root root 21 Dec  3 02:21 /usr/share/javascript/jquery ->
> ../nodejs/jquery/dist

Ouch!  There should be no symlink there!

Seems you might be affected by bug#977960 which was supposed to be 
solved by now :-(


> $ dpkg -L node-jquery

That's a different package!

Package node-jquery contains code for use with nodejs.

Package libjs-jquery contains code for browser use.

(in the past one of those packages depended on the other for internal 
reasons, but that's no longer the case)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#980004: python3-etcd3gw: consume from upstream source change (opendev), consider version bump from 0.2.1-3 to 2.6.0 (latest)

[Heather Lemon]

Package: python3-etcd3gw
Version: 0.2.1-3
Severity: normal
X-Debbugs-Cc: heather.le...@canonical.com

Dear Maintainer,

   * What led up to the situation?
 - python-etcd3gw library has changed repos from github to opendev 
(https://opendev.org/openstack/etcd3gw/src/branch/master/etcd3gw)
 - requesting a version update from 0.2.1-3 to 2.6.0 

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

Kernel: Linux debian-lxc 5.4.0-60-generic (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-etcd3gw depends on:
ii  python3   3.9.1-1
ii  python3-futurist  2.3.0-2
ii  python3-pbr   5.5.0-2
ii  python3-requests  2.25.1+dfsg-2
ii  python3-six   1.15.0-2
ii  python3-urllib3   1.26.2-1

python3-etcd3gw recommends no packages.

Versions of packages python3-etcd3gw suggests:
pn  python-etcd3gw-doc  

-- no debconf information

Bug#979996: libjs-jquery: please use the default extension for precompressed brotli files

[Jonas Smedegaard]

Control: tags -1 +wontfix

Hi Guilhem,

Quoting Guilhem Moulin (2021-01-12 18:42:39)
> Package: libjs-jquery
> Version: 3.5.1+dfsg+~3.5.5-5
> Severity: normal
> 
> Dear Maintainer,
> 
> The brotli suffix was changed from .br to .brotli in
> 3.5.1+dfsg+~3.5.4-3:
> 
> 
> https://salsa.debian.org/js-team/node-jquery/-/commit/2c27f2b80e89dc4fb051cb7081ad464643316a9d
> 
> The .br suffix is hardcoded in ngx_http_brotli_static_module (granted 
> ngx_brotli is not in Debian at the moment, #919320) — just like .gz is 
> hardcoded in ngx_http_gzip_static_module — so the precompressed 
> .brotli resources aren't usable by Nginx.
> 
> Given .br is the default suffix for brotli files, please consider 
> reverting the above change, or at least providing compatibility 
> symlinks.

I think you (and nginx?) are mistaken: The officially registered meaning 
for file suffix .br is the language breton.

The confusion probably stems from the (officially registered, I guess) 
content-encoding type 'br' which indeed is brotli.


I introduced the brotli-compressed files with extension .br but changed 
that when I realized my mistake.

Until that clash with language code is resolved (if ever) I think it is 
wrong to change back, and I therefore flag this as wontfix.


See also related bug#972632 from when I realized my mistake.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#979609:

[Sudip Mukherjee]

I had been testing little more and I can see the same problem with
other packages (syndie and stegosuite) which are using
libswt-cairo-gtk-4-jni.
So, all the three packages using libswt-cairo-gtk-4-jni triggers the
segfault in ppc64el.


-- 
Regards
Sudip

Bug#980003: gcl-doc: describe fails because gcl-si.info does not exist

[Leo Butler]

Package: gcl-doc
Version: 2.6.12-100
Severity: normal
X-Debbugs-Cc: leo.but...@member.fsf.org

Dear Camm,

gcl-doc installs gcl-si.info.gz in the correct spot, but when one
attempts to use DESCRIBE in gcl, one gets:

$ gcl
GCL (GNU Common Lisp)  2.6.12 CLtL1Fri Apr 22 15:51:11 UTC 2016
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files:
/tmp/

>(describe 'compile)

COMPILE - external symbol in COMMON-LISP package
-
COMPILE[Function]

Error: FILE-ERROR :PATHNAME "/usr/share/info/gcl-si.info" "Pathname does not 
exist"
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by DESCRIBE.
FILE-ERROR :PATHNAME "/usr/share/info/gcl-si.info" "Pathname does not exist"

Broken at DESCRIBE.  Type :H for Help.
1  Return to top level. 
>>



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 gcl-doc depends on:
ii  dpkg  1.20.5
ii  install-info  6.7.0.dfsg.2-5+b1

gcl-doc recommends no packages.

gcl-doc suggests no packages.

-- no debconf information

Bug#979246: src:fonts-ddc-uchen: invalid maintainer address

[Baptiste Beauplat]

Hi Sruthi,

On Mon, 04 Jan 2021 17:52:01 +0100 Ansgar  wrote:
> Source: fonts-ddc-uchen
> Version: 1.0-1
> Severity: serious
> X-Debbugs-Cc: fonts-ddc-uchen
> 
> The maintainer address is invalid, see below.
> 
> Ansgar
> 
>  Start of forwarded message 
> From: Mail Delivery System 
> Subject: Mail delivery failed: returning message to sender
> Date: Mon, 04 Jan 2021 14:33:44 +

I'm Cc'ing you manually on this bug since you are the maintainer but the
email is incorrect (s...@openmailbox.org).

Let me know if you don't have time to attend to it, I'll do an NMU with
your address fixed.

Note: this also affects ruby-fog-cloudatcost

Best,
-- 
Baptiste Beauplat - lyknode



OpenPGP_signature
Description: OpenPGP digital signature

Bug#959100: Upstream concerns

[Alexandre Franke]

Hi,

One of the upstream development team member here. Make of that what
you will, but know that we’d rather you don’t offer a Fractal package.
We recommend people get the application as we publish it ourselves as
a flatpak on flathub.org. There are various reasons and I won’t try to
sell flatpak to you, but the main points for us are that:
* the application is built exactly how we intend it to be built (no
broken feature or hard to reproduce issues because package maintainers
decide to disable options)
* we get sandboxing

Now I’m not here to debate or say that Debian packagers are not
competent. I’m here to make you aware of our preference. As I said,
make of it what you will.

-- 
Alexandre Franke
GNOME Hacker

Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

[Ryan Tandy]

Control: tag -1 moreinfo

Hello,

On Tue, Jan 12, 2021 at 07:04:41PM +0100, Andreas Metzler wrote:

On 2021-01-12 Andras Korn  wrote:

I think I shouldn't need to specify `ldap_tls_cacert =
/etc/ssl/certs/ca-certificates.crt` when using a Debian package, since
this is the default location of trusted CA certificates in Debian.
Configuration should only be necessary for non-default setups.


The libldap-common package ships a default /etc/ldap/ldap.conf which 
contains exactly this default TLS_CACERT value. It should be picked up 
automatically by programs using the library. If sssd does something to 
override that, I don't think libldap can be blamed.



GnuTLS offers a sane compile default for the trust store (See
gnutls_x509_trust_list_add_system_trust()), which can be used by the
application. - I have therefore retitled the bug.

From the upstream bug report:
2021-01-12 17:52:00.657730500 [be[ldap]] [sss_ldap_debug] (0x4000): libldap: 
TLS: warning: cacertdir not implemented for gnutls

GnuTLS has supported using a directory instead of a file since version
3.3.6 (released 2014-07-23), so it looks like a missing thing in libldap.


There are two things here:

1. libldap 2.4.x indeed does not support TLS_CACERTDIR when linked with 
GnuTLS. This is fixed in the 2.5 branch. (ITS#8155)


2. It is intentional by upstream that *no* CA certificates are used when 
there is no explicit TLS_CACERT or TLS_CACERTDIR configured. There's 
some discussion about this in ITS#5582. (Bearing in mind that in Debian 
we *do* configure a default TLS_CACERT in ldap.conf).




Is there still something you think needs to be changed or fixed in the 
libldap package?


thanks,
Ryan

Bug#979993: [Pkg-javascript-devel] Bug#979993: libjs-jquery: Missing minified files

[Jonas Smedegaard]

Quoting Veiko Aasa (2021-01-12 19:05:32)
> 
> > Which specific paths are missing?
> > 
> >  - Jonas
> 
> In Debian stable:
> $ ls -l /usr/share/javascript/jquery/
> total 720
> -rw-r--r-- 1 root root 271809 Apr 19  2019 jquery.js
> -rw-r--r-- 1 root root 137549 Apr 19  2019 jquery.min.js
> -rw-r--r-- 1 root root  34729 Apr 19  2019 jquery.min.js.br
> -rw-r--r-- 1 root root  37419 Apr 19  2019 jquery.min.js.gz
> -rw-r--r-- 1 root root 141854 Apr 19  2019 jquery.min.map
> -rw-r--r-- 1 root root  49115 Apr 19  2019 jquery.min.map.br
> -rw-r--r-- 1 root root  51207 Apr 19  2019 jquery.min.map.gz
> 
> In Debian testing:
> $ ls -l /usr/share/javascript/jquery/
> total 284
> -rw-r--r-- 1 root root 287600 Jan  4 20:00 jquery.js


That's interesting - here what I see:

$ dget libjs-jquery
dget: retrieving 
http://deb.debian.org/debian/pool/main/n/node-jquery/libjs-jquery_3.5.1+dfsg+~3.5.5-5_all.deb
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  307k  100  307k0 0  1296k  0 --:--:-- --:--:-- --:--:-- 1296k
$ dpkg-deb --contents libjs-jquery_3.5.1+dfsg+~3.5.5-5_all.deb
drwxr-xr-x root/root 0 2021-01-04 19:00 ./
drwxr-xr-x root/root 0 2021-01-04 19:00 ./usr/
drwxr-xr-x root/root 0 2021-01-04 19:00 ./usr/share/
drwxr-xr-x root/root 0 2021-01-04 19:00 ./usr/share/doc/
drwxr-xr-x root/root 0 2021-01-04 19:00 ./usr/share/doc/libjs-jquery/
-rw-r--r-- root/root  1924 2021-01-04 19:00 
./usr/share/doc/libjs-jquery/changelog.Debian.gz
-rw-r--r-- root/root  1671 2020-12-22 08:25 
./usr/share/doc/libjs-jquery/copyright
drwxr-xr-x root/root 0 2021-01-04 19:00 ./usr/share/javascript/
drwxr-xr-x root/root 0 2021-01-04 19:00 ./usr/share/javascript/jquery/
-rw-r--r-- root/root287600 2021-01-04 19:00 
./usr/share/javascript/jquery/jquery.js
-rw-r--r-- root/root 89204 2021-01-04 19:00 
./usr/share/javascript/jquery/jquery.min.js
-rw-r--r-- root/root 28057 2021-01-04 19:00 
./usr/share/javascript/jquery/jquery.min.js.brotli
-rw-r--r-- root/root 29899 2021-01-04 19:00 
./usr/share/javascript/jquery/jquery.min.js.gz
-rw-r--r-- root/root137391 2021-01-04 19:00 
./usr/share/javascript/jquery/jquery.min.map
-rw-r--r-- root/root 49787 2021-01-04 19:00 
./usr/share/javascript/jquery/jquery.min.map.brotli
-rw-r--r-- root/root 52072 2021-01-04 19:00 
./usr/share/javascript/jquery/jquery.min.map.gz


...which also (on my sid system) matches this:

$ apt-file list libjs-jquery
libjs-jquery: /usr/share/doc/libjs-jquery/changelog.Debian.gz
libjs-jquery: /usr/share/doc/libjs-jquery/copyright
libjs-jquery: /usr/share/javascript/jquery/jquery.js
libjs-jquery: /usr/share/javascript/jquery/jquery.min.js
libjs-jquery: /usr/share/javascript/jquery/jquery.min.js.brotli
libjs-jquery: /usr/share/javascript/jquery/jquery.min.js.gz
libjs-jquery: /usr/share/javascript/jquery/jquery.min.map
libjs-jquery: /usr/share/javascript/jquery/jquery.min.map.brotli
libjs-jquery: /usr/share/javascript/jquery/jquery.min.map.gz


...and this:

$ dpkg -L libjs-jquery
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libjs-jquery
/usr/share/doc/libjs-jquery/changelog.Debian.gz
/usr/share/doc/libjs-jquery/copyright
/usr/share/javascript
/usr/share/javascript/jquery
/usr/share/javascript/jquery/jquery.js
/usr/share/javascript/jquery/jquery.min.js
/usr/share/javascript/jquery/jquery.min.js.brotli
/usr/share/javascript/jquery/jquery.min.js.gz
/usr/share/javascript/jquery/jquery.min.map
/usr/share/javascript/jquery/jquery.min.map.brotli
/usr/share/javascript/jquery/jquery.min.map.gz



Are you sure you have the latest package installed?

Please provide the output of this command:

  apt list libjs-jquery


Regardless of the outcome, thanks for reporting this!

Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#979845: Bug #979845: mustache-java: Please drop the Build-Depends on jruby

[Louis-Philippe Véronneau]

noowner -1
thanks

I've had a good look at this package and what it would take to upgrade
it to the latest upstream version, and I am afraid it would be quite a
large change from the current version.

Since we're currently in the soft-freeze and I'm not exactly fluent in
Java, I don't think it's a good idea for me to try and update the
package to 0.9.7, as it might create breakage I wouldn't be equipped to fix.

I'm thus removing myself as owner for this bug and I'll ask for help on
the Java Team mailing list instead.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#968626: Patch is not working

[Leopold Palomo-Avellaneda]

El 7/1/21 a les 16:54, Maximilian Stein ha escrit:
>>I have used the patch from Maximilian Stein, but I got the same error.
> 
> Have you tried to debug the exact cause of the failure in your case? In
> my message above I outlined how I debugged the issue — maybe that helps
> to investigate your situation.

First of all, I'm sorry because I couldn't test what did you say. In any
case, after upgrade to 13.5.6 artifacts are working again.

So, my recommendation is to solve first #977701 and after check is this
is solved.


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Leopold Palomo-Avellaneda]

Just to put some info in the bug:

I have upgraded my gitlab installation to 13.5.6-1~fto10+2.

I have follow wiki instructions but there are missing dependencies:

ruby-charlock-holmes ruby-mini-magick

node-katex must be backported if not, there are error because
katex.min.css is missing. A possible workaround is to drop the
references in the directory /usr/share/gitlab/app/assets/javascripts
the files:

behaviors/markdown/render_math.js:   // import(/* webpackChunkName:
'katex' */ 'katex/dist/katex.min.css'),

notebook/cells/markdown.vue:/* @import '~katex/dist/katex.min.css'; */

After that seem that gitlab is working ... I hope.

-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Bug#979717: seconded!

[Gürkan Myczko]

seconded!

maybe even integrate its stuff into vrms? and the same for flatpak?

Bug#979653: xfsprogs: Incomplete debian/copyright

[Bastian Germann]

Am 12.01.21 um 18:46 schrieb Darrick J. Wong:

On Sun, Jan 10, 2021 at 01:23:58AM +0100, Bastian Germann wrote:

Files: *
Copyright:
  1995-2013 Silicon Graphics, Inc.
  2010-2018 Red Hat, Inc.
  2016-2020 Oracle.  All Rights Reserved.


/me notes that a lot of the Oracle-copyright files are actually GPL-2+,
not GPL-2.  That might not be obvious because I bungled some of the SPDX
tags when spdx deprecated the "GPL-2.0+" tag and we had to replace them
all with "GPL-2.0-or-later", though it looks like they've all been
cleaned up at this point.


Yes, I have noticed that there are some GPL-2.0-or-later and GPL-2.0+ 
licensed files. Simplifying them as GPL-2.0-only in debian/copyright 
does not harm in my opinion as the whole work including the GPL-2.0-only 
files is not usable under GPL-2.0-or-later. And someone who is 
interested in using specific files would look at their individual SPDX 
lines anyway.




Question: How can we autogenerate debian/copyright from the source files
in the git repo?  In the long run I think it best that this becomes
something we can automate when tagging a new upstream release.


I do not know of any SPDX to DEP-5 converter. Implementing a generic 
converter would be beneficial to more projects but is a bigger task. The 
need for it is mentioned at https://wiki.debian.org/SPDX.
Just writing a converter for xfsprogs would be doable easily from what I 
have seen.

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

[Sean Whitton]

Hello,

On Tue 12 Jan 2021 at 01:53PM +02, Wouter Verhelst wrote:

> Maybe talk to debian-policy to come up with some wording to be added to
> either the developer's reference or policy that discourages dropping
> init scripts, but encourages talking to the maintainers of
> orphan-sysvinit-scripts if for whatever reason it ends up being
> necessary?

Once the package has cleared NEW, we should definitely mention it in
Policy; whether we say anything to discourage dropping init scripts is
trickier however.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#980002: golang-golang-x-text: CVE-2020-28852

[Salvatore Bonaccorso]

Source: golang-golang-x-text
Version: 0.3.4-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/golang/go/issues/42536
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-golang-x-text.

CVE-2020-28852[0]:
| In x/text in Go 1.15.4, a "slice bounds out of range" panic occurs in
| language.ParseAcceptLanguage while processing a BCP 47 tag.
| (x/text/language is supposed to be able to parse an HTTP Accept-
| Language header.)


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-28852
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28852
[1] https://github.com/golang/go/issues/42536

Regards,
Salvatore

Bug#980001: golang-golang-x-text: CVE-2020-28851

[Salvatore Bonaccorso]

Source: golang-golang-x-text
Version: 0.3.4-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/golang/go/issues/42535
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-golang-x-text.

CVE-2020-28851[0]:
| In x/text in Go 1.15.4, an "index out of range" panic occurs in
| language.ParseAcceptLanguage while parsing the -u- extension.
| (x/text/language is supposed to be able to parse an HTTP Accept-
| Language header.)


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-28851
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28851
[1] https://github.com/golang/go/issues/42535

Regards,
Salvatore

Bug#980000: ffmpeg: CVE-2020-35964

[Salvatore Bonaccorso]

Source: ffmpeg
Version: 7:4.3.1-5
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ffmpeg.

CVE-2020-35964[0]:
| track_header in libavformat/vividas.c in FFmpeg 4.3.1 has an out-of-
| bounds write because of incorrect extradata packing.


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-35964
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35964
[1] 
https://github.com/FFmpeg/FFmpeg/commit/27a99e2c7d450fef15594671eef4465c8a166bd7
[2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26622

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#979999: ffmpeg: CVE-2020-35965

[Salvatore Bonaccorso]

Source: ffmpeg
Version: 7:4.3.1-5
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ffmpeg.

CVE-2020-35965[0]:
| decode_frame in libavcodec/exr.c in FFmpeg 4.3.1 has an out-of-bounds
| write because of errors in calculations of when to perform memset zero
| operations.


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-35965
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35965
[1] 
https://github.com/FFmpeg/FFmpeg/commit/3e5959b3457f7f1856d997261e6ac672bba49e8b
[2] 
https://github.com/FFmpeg/FFmpeg/commit/b0a8b40294ea212c1938348ff112ef1b9bf16bb3
[3] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26532

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#979997: dpkg: Please fall back to rename if making back-up link fails

[Sven Joachim]

Control: tags -1 - patch

On 2021-01-12 18:46 +0100, наб wrote:

> Package: dpkg
> Version: 1.20.7.1
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> When upgrading the kernel on one of my machines I got hit with
>   Preparing to unpack .../linux-image-5.10.0-1-amd64_5.10.5-1_amd64.deb ...
>   Unpacking linux-image-5.10.0-1-amd64:amd64 (5.10.5-1) over (5.10.4-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/linux-image-5.10.0-1-amd64_5.10.5-1_amd64.deb 
> (--unpack):
>unable to make backup link of './boot/System.map-5.10.0-1-amd64' before 
> installing new version: Operation not permitted
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>   Errors were encountered while processing:
>/var/cache/apt/archives/linux-image-5.10.0-1-amd64_5.10.5-1_amd64.deb
>   E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> I have /boot on FAT, which does not support more than one link per file;

Don't do that.

> please consider the attached patch,
> based on b0c80a72a9a32e17953483e1fb6b66dcfd8d0096,
> that falls back to rename(2).

That risks rendering your system unbootable if it crashes at the wrong
moment.  For further reading, I recommend the links below.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825945
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_the_filesystem_requirements_by_dpkg.3F

Cheers,
   Sven

Bug#979995: There should be a sensible compile time default for the location of the file that contains trusted CA certificates

[Andreas Metzler]

Control: retitle -1 cacertdir not implemented for gnutls
Control: reassign -1 libldap-2.4-2 2.4.56+dfsg-1

On 2021-01-12 Andras Korn  wrote:
> Package: libgnutls30
> Version: 3.7.0-3
> Severity: wishlist

> Hi,

> I was just bitten by https://github.com/SSSD/sssd/issues/5444.

> Briefly:

>  * sssd relies on libldap to query LDAP servers.
>  * libldap can be linked against libssl (openssl) or gnutls for SSL/TLS 
> support.
>  * libssl supports an ldap_tls_cacertdir option; you can point it to 
> /etc/ssl/certs and it'll trust all CA certificates that are in this directory.
>  * gnutls doesn't have this cacertdir mechanism and needs `ldap_tls_cacert = 
> /etc/ssl/certs/ca-certificates.crt` instead.
>  * my sssd.conf only had ldap_tls_cacertdir, not ldap_tls_cacert; thus, 
> gnutls didn't know which CA certificates to trust and failed to validate my 
> LDAP server certificates.
>  * The root cause of the problem only became visible after enabling LDAP 
> library debugging in sssd.conf. 

> I think I shouldn't need to specify `ldap_tls_cacert =
> /etc/ssl/certs/ca-certificates.crt` when using a Debian package, since
> this is the default location of trusted CA certificates in Debian.
> Configuration should only be necessary for non-default setups.

Hello,
GnuTLS offers a sane compile default for the trust store (See
gnutls_x509_trust_list_add_system_trust()), which can be used by the
application. - I have therefore retitled the bug.

>From the upstream bug report:
2021-01-12 17:52:00.657730500 [be[ldap]] [sss_ldap_debug] (0x4000): libldap: 
TLS: warning: cacertdir not implemented for gnutls

GnuTLS has supported using a directory instead of a file since version
3.3.6 (released 2014-07-23), so it looks like a missing thing in libldap.

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#979998: cacti: CVE-2020-35701

[Salvatore Bonaccorso]

Source: cacti
Version: 1.2.16+ds1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/Cacti/cacti/issues/4022
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cacti.

CVE-2020-35701[0]:
| An issue was discovered in Cacti 1.2.x through 1.2.16. A SQL injection
| vulnerability in data_debug.php allows remote authenticated attackers
| to execute arbitrary SQL commands via the site_id parameter. This can
| lead to remote code execution.


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-35701
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35701
[1] https://github.com/Cacti/cacti/issues/4022

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#979880: kodi: FTBFS because of mount_getexports_timeout and struct hdr_output_metadata

[Laurent Bonnaud]

On 1/12/21 1:02 PM, Vasyl Gello wrote:


This is probably a regression due to ABI change in libnfs. Let me
check if upstream has a fix for it.


Thanks a lot for looking at this bug!


Do you use NFS shares with Kodi in your HTPC setup?


Not at all.  I am just trying to rebuild kodi before doing a backport for older 
systems...

Thanks again,

--
Laurent.

Bug#979992: RFS: uwebsockets/18.19.0-1 [ITP] -- simple, secure & standards compliant web server

[Hilmar Preuße]

Control: merge -1 979990

Am 12.01.2021 um 17:44 teilte Aisha Tammy mit:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,




--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#979965: milter-greylist exits after running for a few minutes

[Vagrant Cascadian]

On 2021-01-12, Michael Grant wrote:
> After update to 4.6.2-2, milter-greylist runs for a few minutes
> processing greylist requests then exits.  No error in the daemon.log.
> Daemon restarts with systemd over and over.
>
> Starting milter-greylist by hand using strace shows this just before
> it dies:
>
> poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 1 ([{fd=3,
> revents=POLLIN}])
> accept(3, {sa_family=AF_UNIX}, [2]) = 10
> fcntl(10, F_GETFD)  = 0
> fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
> setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> futex(0x7f0f22c221a4, FUTEX_WAKE_PRIVATE, 1) = 1
> poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000) = 0 (Timeout)
> poll([{fd=3, events=POLLIN|POLLPRI}], 1, 5000 ) = ?
> +++ exited with 71 +++
>
> Previous version of milter-greylist on debian/testing was working fine
> without this issue.

Could you try running without the systemd .service file so that it falls
back to the init script; there may be differences between how the
.service file and the init script set up the environment to run it.

If that doesn't help, could you try rebuilding the previous version with
a current sid build environment and seeing if that is still affected?
There aren't many changes to the actual code or packaging, and my fear
is it might be changes in the toolchain used to build it since the
previous version.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#979653: xfsprogs: Incomplete debian/copyright

[Darrick J. Wong]

On Sun, Jan 10, 2021 at 01:23:58AM +0100, Bastian Germann wrote:
> Am 09.01.21 um 23:53 schrieb Eric Sandeen:
> > On 1/9/21 2:42 PM, Bastian Germann wrote:
> > > On Sat, 9 Jan 2021 19:31:50 +0100 Bastian Germann 
> > >  wrote:
> > > > xfsprogs' debian/copyright only mentions Silicon Graphics, Inc.'s 
> > > > copyright. There are other copyright holders, e.g. Oracle, Red Hat, 
> > > > Google LLC, and several individuals. Please provide a complete 
> > > > copyright file and convert it to the machine-readable format.
> > > 
> > > Please find a copyright file enclosed.
> > 
> > Hi Bastian -
> > 
> > I'll take an update to this file, but what are the /minimum/ requirements
> > per Debian policy?
> 
> https://www.debian.org/doc/debian-policy/ch-archive.html#copyright-considerations
> 
> The minimum requirements are that you include the license info.
> The copyright info also has to be included in some cases, essentially for
> each file that is included in compiled form in a binary package you have to
> reproduce its copyright info if the license requires the copyright to be
> retained in binary distributions.
> 
> > 
> > Tracking everything by file+name(s)+year seems rather pointless - it's all
> > present in the accompanying source, and keeping it up to date at this
> > granularity seems like make-work doomed to be perpetually out of sync.
> 
> You can get rid of all the file names. The license info has to be included
> (GPL-2, LGPL-2.1, GPL-3+ with autoconf exception). One can argue that the
> FSF unlimited permission license text (m4/*) also has to be included by
> Policy.
> 
> The (L)GPL requires the copyright statements to be included.
> 
> I have reduced the given copyright file to a more maintainable version. It
> still keeps some file names (not required) so that one can identify the
> primary copyright holders and the LGPL parts easily.
> 
> > I'd prefer to populate it with the minimum required information in
> > order to minimize churn and maximize ongoing correctness if possible.
> > 
> > Thanks,
> > -Eric
> > 

> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Upstream-Name: xfsprogs
> Comment: This package was debianized by Nathan Scott 
> Source: https://www.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/
> 
> Files: *
> Copyright:
>  1995-2013 Silicon Graphics, Inc.
>  2010-2018 Red Hat, Inc.
>  2016-2020 Oracle.  All Rights Reserved.

/me notes that a lot of the Oracle-copyright files are actually GPL-2+,
not GPL-2.  That might not be obvious because I bungled some of the SPDX
tags when spdx deprecated the "GPL-2.0+" tag and we had to replace them
all with "GPL-2.0-or-later", though it looks like they've all been
cleaned up at this point.

Question: How can we autogenerate debian/copyright from the source files
in the git repo?  In the long run I think it best that this becomes
something we can automate when tagging a new upstream release.

--D

> Comment: For most files, only one of the copyrights applies.
> License: GPL-2
> 
> Files:
>  libhandle/*.c
> Copyright: 1995, 2001-2002, 2005 Silicon Graphics, Inc.
> Comment: This also applies to some header files.
> License: LGPL-2.1
>  This library is free software; you can redistribute it and/or modify it
>  under the terms of the GNU Lesser General Public License as published by
>  the Free Software Foundation; version 2.1 of the License.
>  .
>  This library is distributed in the hope that it will be useful, but WITHOUT
>  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
>  for more details.
>  .
>  On Debian systems, refer to /usr/share/common-licenses/LGPL-2.1
>  for the complete text of the GNU Lesser General Public License.
> 
> Files: config.*
> Copyright: 1992-2013 Free Software Foundation, Inc.
> License: GPL-3+ with autoconf exception
>  This file is free software; you can redistribute it and/or modify it
>  under the terms of the GNU General Public License as published by
>  the Free Software Foundation; either version 3 of the License, or
>  (at your option) any later version.
>  .
>  This program is distributed in the hope that it will be useful, but
>  WITHOUT ANY WARRANTY; without even the implied warranty of
>  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>  General Public License for more details.
>  .
>  You should have received a copy of the GNU General Public License
>  along with this program; if not, see .
>  .
>  As a special exception to the GNU General Public License, if you
>  distribute this file as part of a program that contains a
>  configuration script generated by Autoconf, you may include it under
>  the same distribution terms that you use for the rest of that
>  program.  This Exception is an additional permission under section 7
>  of the GNU General Public License, version 3 ("GPLv3").
>  .
>  On Debian systems, the full text of the GNU 

Bug#979997: dpkg: Please fall back to rename if making back-up link fails

[наб]

Package: dpkg
Version: 1.20.7.1
Severity: normal
Tags: patch

Dear Maintainer,

When upgrading the kernel on one of my machines I got hit with
  Preparing to unpack .../linux-image-5.10.0-1-amd64_5.10.5-1_amd64.deb ...
  Unpacking linux-image-5.10.0-1-amd64:amd64 (5.10.5-1) over (5.10.4-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/linux-image-5.10.0-1-amd64_5.10.5-1_amd64.deb 
(--unpack):
   unable to make backup link of './boot/System.map-5.10.0-1-amd64' before 
installing new version: Operation not permitted
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/linux-image-5.10.0-1-amd64_5.10.5-1_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

I have /boot on FAT, which does not support more than one link per file;
please consider the attached patch,
based on b0c80a72a9a32e17953483e1fb6b66dcfd8d0096,
that falls back to rename(2).

Best,
наб

-- Package-specific info:
System tainted due to merged-usr-via-symlinks.

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  liblzma5 5.2.4-1
ii  libselinux1  2.8-1+b1
ii  tar  1.30+dfsg-6
ii  zlib1g   1:1.2.11.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.2.2
pn  debsig-verify  

-- Configuration Files:
/etc/logrotate.d/alternatives changed [not included]
/etc/logrotate.d/dpkg changed [not included]

-- no debconf information
From b0c80a72a9a32e17953483e1fb6b66dcfd8d0096 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Tue, 12 Jan 2021 18:28:26 +0100
Subject: [PATCH] Fall back from link(2) to rename(2) if the underlying
 filesystem does not support it
X-Mutt-PGP: OS

Most notably, this likely fixes kernel upgrades with /boot on FAT
---
 src/archives.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/archives.c b/src/archives.c
index 96079ab1f..f38deee0a 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -1061,9 +1061,16 @@ tarobject(struct tar_archive *tar, struct tar_entry *ti)
   tarobject_set_se_context(fnamevb.buf, fnametmpvb.buf, stab.st_mode);
 } else {
   debug(dbg_eachfiledetail, "tarobject nondirectory, 'link' backup");
-  if (link(fnamevb.buf,fnametmpvb.buf))
-ohshite(_("unable to make backup link of '%.255s' before installing new version"),
-ti->name);
+  if (link(fnamevb.buf,fnametmpvb.buf)) {
+if (errno == EPERM) {
+  debug(dbg_eachfiledetail, "unable to link, falling back to nonatomic");
+  if (rename(fnamevb.buf,fnametmpvb.buf))
+ohshite(_("unable to move aside '%.255s' to install new version"),
+ti->name);
+} else
+  ohshite(_("unable to make backup link of '%.255s' before installing new version"),
+  ti->name);
+  }
 }
   }
 
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#979942: [Pkg-javascript-devel] Bug#979942: embedding dead code is no fix to bug for removing that same dead code

[Xavier]

Control: tags -1 reopen
Control: severity -1 serious

Le 12/01/2021 à 18:17, Jonas Smedegaard a écrit :
> Quoting Debian FTP Masters (2021-01-12 18:06:40)
>>  node-browser-pack (6.1.0+ds-7) unstable; urgency=medium
>>  .
>>* Team upload
>>* Bump debhelper compatibility level to 13
>>* Declare compliance with policy 4.5.1
>>* Use dh-sequence-nodejs
>>* Remove dependency to node-uglify but embed node-uglify in build_modules
>>  else build file is wrong (Closes: #979942)
> 
> Do I read the above correctly that node-browser-pack "fixes" node-uglify 
> going away by embedding it, hidden?
> 
> I disagree that that is a fix.

OK, but I didn't succeed to fix that, let's reopen, upgrade severity and
wait for someone else to fix it