from:"Vincent"

commit: d025b3934177f8d333de0b5402e478383120bb36
Author: Vincent Phan  gmail  com>
AuthorDate: Sat Jun  8 00:58:53 2024 +
Commit:     Vincent Phan  gmail  com>
CommitDate: Sat Jun  8 00:58:53 2024 +
URL:https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=d025b393

gui-apps/aylurs-gtk-shell: update HOMEPAGE

Signed-off-by: Vincent Phan  gmail.com>

 gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild 
b/gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild
index 503e0c7b7..9dec5874f 100644
--- a/gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild
+++ b/gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild
@@ -16,7 +16,7 @@ KEYWORDS="~amd64"
 S="${WORKDIR}/${MY_PN}"
 
 DESCRIPTION="Aylurs's Gtk Shell (AGS), An eww inspired gtk widget system."
-HOMEPAGE="https://github.com/Alyur/ags;
+HOMEPAGE="https://github.com/Aylur/ags;
 
 LICENSE="GPL-3"
 SLOT="0"

[gentoo-commits] repo/proj/guru:dev commit in: media-sound/openutau/

commit: b0dccb95b039bc953e1ab8b318321ae4071a6834
Author: Vincent Phan  gmail  com>
AuthorDate: Sat Jun  8 00:04:47 2024 +
Commit:     Vincent Phan  gmail  com>
CommitDate: Sat Jun  8 00:04:47 2024 +
URL:https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=b0dccb95

media-sound/openutau: Add missing dependency in ebuilds

Signed-off-by: Vincent Phan  gmail.com>

 media-sound/openutau/openutau-0.1.327.ebuild | 1 +
 media-sound/openutau/openutau-0.1.463.ebuild | 1 +
 media-sound/openutau/openutau-.ebuild| 1 +
 3 files changed, 3 insertions(+)

diff --git a/media-sound/openutau/openutau-0.1.327.ebuild 
b/media-sound/openutau/openutau-0.1.327.ebuild
index 21df89703..275602592 100644
--- a/media-sound/openutau/openutau-0.1.327.ebuild
+++ b/media-sound/openutau/openutau-0.1.327.ebuild
@@ -272,6 +272,7 @@ RDEPEND="
dev-dotnet/dotnet-sdk-bin
sys-fs/fuse-common
media-libs/alsa-lib
+   media-libs/fontconfig
 "
 
 DEPEND="${RDEPEND}

diff --git a/media-sound/openutau/openutau-0.1.463.ebuild 
b/media-sound/openutau/openutau-0.1.463.ebuild
index 984a3641c..018543b42 100644
--- a/media-sound/openutau/openutau-0.1.463.ebuild
+++ b/media-sound/openutau/openutau-0.1.463.ebuild
@@ -274,6 +274,7 @@ RDEPEND="
dev-dotnet/dotnet-sdk-bin
sys-fs/fuse-common
media-libs/alsa-lib
+   media-libs/fontconfig
 "
 
 DEPEND="${RDEPEND}

diff --git a/media-sound/openutau/openutau-.ebuild 
b/media-sound/openutau/openutau-.ebuild
index 984a3641c..018543b42 100644
--- a/media-sound/openutau/openutau-.ebuild
+++ b/media-sound/openutau/openutau-.ebuild
@@ -274,6 +274,7 @@ RDEPEND="
dev-dotnet/dotnet-sdk-bin
sys-fs/fuse-common
media-libs/alsa-lib
+   media-libs/fontconfig
 "
 
 DEPEND="${RDEPEND}

[gentoo-commits] repo/proj/guru:dev commit in: gui-apps/aylurs-gtk-shell/

commit: 96dfd2cbe510fcbedb3fd78a06c09c5e6ec5a98f
Author: Vincent Phan  gmail  com>
AuthorDate: Sat Jun  8 00:06:14 2024 +
Commit:     Vincent Phan  gmail  com>
CommitDate: Sat Jun  8 00:06:14 2024 +
URL:https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=96dfd2cb

gui-apps/aylurs-gtk-shell: new package, add 1.8.2

Signed-off-by: Vincent Phan  gmail.com>

 gui-apps/aylurs-gtk-shell/Manifest |  2 +
 .../aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild | 67 ++
 gui-apps/aylurs-gtk-shell/metadata.xml | 14 +
 3 files changed, 83 insertions(+)

diff --git a/gui-apps/aylurs-gtk-shell/Manifest 
b/gui-apps/aylurs-gtk-shell/Manifest
new file mode 100644
index 0..5c9b96def
--- /dev/null
+++ b/gui-apps/aylurs-gtk-shell/Manifest
@@ -0,0 +1,2 @@
+DIST aylurs-gtk-shell-1.8.2.tar.gz 435232 BLAKE2B 
9b7c7cbe652df76282d9dc11dd49d09ab1fb962e45fec3f3a849b161abd3e8f287f14a72cb7ac85df7f65fea748e4b1546568684eb830ce0382f2f4977d57564
 SHA512 
4ed3f4b4da9c8bbd045ab3cd455b24768bc8807fa9a215a5b788b6319edd72c76cb9fe6d3e3cf82068e43bf3463d5025cfb86eba78b93bc481d95e2e4ed4552d
+DIST node-modules.tar.gz 1810 BLAKE2B 
bf118c47e08c5075502c01cbdcb68189c4964ec32413a298fa9abaaf5634ccf3cc94251de5dc38c1913c66ba3346cd60f4d0a1179dfec571b6ceb269f0a6acc2
 SHA512 
814acad890be748d04f7e28ea6c7a8321edac907c2729c7f4966a8bb24bccad69684d570bc4b9f6148361f8ce5d1ef8306677ef781598467c6a06b765ac974ca

diff --git a/gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild 
b/gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild
new file mode 100644
index 0..503e0c7b7
--- /dev/null
+++ b/gui-apps/aylurs-gtk-shell/aylurs-gtk-shell-1.8.2.ebuild
@@ -0,0 +1,67 @@
+# Copyright 2022 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+MY_PV="v${PV}"
+MY_PN="ags"
+
+inherit meson
+
+SRC_URI="
+   
https://github.com/Aylur/${MY_PN}/releases/download/${MY_PV}/${MY_PN}-${MY_PV}.tar.gz
 -> ${P}.tar.gz
+   
https://github.com/Aylur/${MY_PN}/releases/download/${MY_PV}/node_modules-${MY_PV}.tar.gz
 -> node-modules.tar.gz
+"
+KEYWORDS="~amd64"
+S="${WORKDIR}/${MY_PN}"
+
+DESCRIPTION="Aylurs's Gtk Shell (AGS), An eww inspired gtk widget system."
+HOMEPAGE="https://github.com/Alyur/ags;
+
+LICENSE="GPL-3"
+SLOT="0"
+IUSE="upower bluetooth networkmanager tray"
+
+DEPEND="
+   ${RDEPEND}
+"
+BDEPEND="
+   dev-build/meson
+   dev-lang/typescript
+   net-libs/nodejs[npm]
+"
+RDEPEND="
+   dev-libs/gjs
+   x11-libs/gtk+
+   gui-libs/gtk-layer-shell[introspection]
+   dev-libs/gobject-introspection
+   upower? ( sys-power/upower )
+   bluetooth? ( net-wireless/gnome-bluetooth )
+   networkmanager? ( net-misc/networkmanager )
+   tray? ( dev-libs/libdbusmenu[gtk3] )
+"
+
+BUILD_DIR="${S}/build"
+
+src_prepare() {
+   default
+   mv "${WORKDIR}/node_modules" "${S}"
+}
+
+src_configure() {
+   default
+   local emesonargs=(
+   -Dbuild_types="true"
+   )
+   meson_src_configure || die
+}
+
+src_install() {
+   default
+   meson_src_install --destdir "${D}"
+}
+
+pkg_postinst() {
+   elog "ags wont run without a config file (usually in ~/.config/ags)."
+   elog "For example configs visit https://aylur.github.io/ags-docs/;
+}

diff --git a/gui-apps/aylurs-gtk-shell/metadata.xml 
b/gui-apps/aylurs-gtk-shell/metadata.xml
new file mode 100644
index 00000..2c3699583
--- /dev/null
+++ b/gui-apps/aylurs-gtk-shell/metadata.xml
@@ -0,0 +1,14 @@
+
+https://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   chinh4the...@gmail.com
+   Vincent Phan
+   
+   
+   Enable support for tray
+   
+   
+   Aylur/ags
+   
+

[gentoo-commits] repo/proj/guru:dev commit in: net-im/vesktop-bin/

commit: 7c39fd470a4cbe050bc05279750fa177216f816e
Author: Vincent Phan  gmail  com>
AuthorDate: Sat Jun  8 00:03:09 2024 +
Commit:     Vincent Phan  gmail  com>
CommitDate: Sat Jun  8 00:03:42 2024 +
URL:https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=7c39fd47

net-im/vesktop-bin: update SRC_URI

Signed-off-by: Vincent Phan  gmail.com>

 net-im/vesktop-bin/Manifest |  2 +-
 net-im/vesktop-bin/vesktop-bin-1.5.2.ebuild | 14 ++
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/net-im/vesktop-bin/Manifest b/net-im/vesktop-bin/Manifest
index 3799c272d..d7f4f0f94 100644
--- a/net-im/vesktop-bin/Manifest
+++ b/net-im/vesktop-bin/Manifest
@@ -1 +1 @@
-DIST vesktop-1.5.2.tar.gz 102634262 BLAKE2B 
d81967889f80ad8e92c8b8a3fba9be64635653b387a9e53ab29a50fde8672879be9011923aaa2c81bf4e23789ca54691bb97412f6e370cd8eca5052a537328f8
 SHA512 
5cab70ece26fefc5a573279b12101f3327f377661aa9e4aec153bf2bbf2d2f1e92753c0ea4ec3b424c6c5af60ea47866abe612b407220881c34b5ac1321b7a76
+DIST vesktop.tar.gz 104972407 BLAKE2B 
0c19c024611e87438347c3de87ce0688a14498290f639e29ad4b5488b34a2aaa765a2ef1f12d5b43522a1feb3ba3e71c1dfedb3a35b89d4e5340c8f3f002d53b
 SHA512 
9440e7ec349e88aa42c3cff6579e0e915447e5713d419f8e4fd8b93261fd55a3b78122de4088554ad93632c5e1f2b9661e9b9ebb31646be18054ef8acb7aacc8

diff --git a/net-im/vesktop-bin/vesktop-bin-1.5.2.ebuild 
b/net-im/vesktop-bin/vesktop-bin-1.5.2.ebuild
index 37818325e..b0a362f3f 100644
--- a/net-im/vesktop-bin/vesktop-bin-1.5.2.ebuild
+++ b/net-im/vesktop-bin/vesktop-bin-1.5.2.ebuild
@@ -15,7 +15,7 @@ inherit chromium-2 desktop linux-info unpacker xdg
 
 DESCRIPTION="All-in-one voice and text chat for gamers with Vencord 
Preinstalled"
 HOMEPAGE="https://github.com/Vencord/Vesktop/;
-SRC_URI="https://github.com/Vencord/Vesktop/releases/download/v${PV}/${MY_PN}-${PV}.tar.gz;
+SRC_URI="https://github.com/Vencord/Vesktop/releases/download/v${PV}/${MY_PN}-${PV}.tar.gz
 -> ${MY_PN}.tar.gz"
 S="${WORKDIR}/${MY_PN}-${PV}"
 
 LICENSE="GPL-3+"
@@ -29,7 +29,7 @@ DEPEND="
app-crypt/libsecret
app-accessibility/at-spi2-core
dev-libs/expat
-   dev-libs/glib:2
+   dev-libs/glib
dev-libs/nspr
dev-libs/nss
media-libs/alsa-lib
@@ -42,20 +42,18 @@ DEPEND="
x11-libs/libdrm
x11-libs/gdk-pixbuf:2
x11-libs/gtk+:3
-   x11-libs/libxkbcommon
x11-libs/libXcomposite
x11-libs/libXdamage
+   x11-libs/libXext
x11-libs/libXfixes
-   x11-libs/libX11
x11-libs/libXrandr
+   x11-libs/libdrm
+   x11-libs/libxcb
+   x11-libs/libxkbcommon
x11-libs/pango
x11-misc/xdg-utils
 "
 
-BDEPEND="
-   dev-vcs/git
-"
-
 DESTDIR="/opt/${PN}"
 
 QA_PREBUILT="*"

Bug#1055945: linux-image-6.1.0-13-amd64: touchpad buttons sometimes stop working for several seconds/minutes

2024-06-07 Thread Vincent Lefevre

Control: found -1 6.8.12-1

This still occurs with the current kernel.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1055945: linux-image-6.1.0-13-amd64: touchpad buttons sometimes stop working for several seconds/minutes

2024-06-07 Thread Vincent Lefevre

Control: found -1 6.8.12-1

This still occurs with the current kernel.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[R-pkg-devel] debugging R CMD build

2024-06-07 Thread Vincent Carey

https://bioconductor.org/checkResults/3.20/bioc-LATEST/velociraptor/nebbiolo2-buildsrc.html

shows an error arising in R CMD build that cannot be reproduced
in manual attempts with the vignette code that is triggering the
error.  "It works fine except in CMD build" (on linux).

I have tried debugging tools::buildVignettes by setting a debug
call in .Rprofile but it won't step through during R CMD build.  I want
to find out how CMD build manipulates environment to inhibit
resolution of symbols that can be resolved during ordinary interactive
use.

I haven't dug hard into the buildVignettes function.  Before doing so,
I wanted to know if anyone has a way of stepping through in a CMD
build task.

-- 
The information in this email is intended only for the p...{{dropped:12}}

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[INDOLOGY] PDF request

2024-06-06 Thread Vincent Tournier via INDOLOGY

Dear Colleagues, 

I am looking for the following two references, which I could not trace neither 
in German libraries (at least not in Munich) nor on Archive.org: 

- N. Venkataramanayya, Inscriptions of Andhra Pradesh, Warangal District, 
Hyderabad, 1974. I need, in particular, the few pages pertaining to the 
Bekkallu grant of Vikramāditya VI, occurring pp. 45-50.
- Journal of the Andhra Historical Research Society 29, 3/4 (1963), p. 24. I am 
afraid my reference on this, derived from Subrahmanyam’s Vajrayāna Buddhist 
Centres in South India, is incomplete, but this concerns the Korni plates of 
Anantavarman. 

Any help in tracking down these few pages would be greatly appreciated. 

Best wishes, 

Vincent
___
Prof. Dr. Vincent Tournier
Lehrstuhl für Klassische Indologie
Ludwig-Maximilians-Universität München
Department für Asienstudien, Institut für Indologie und Tibetologie
Geschwister-Scholl-Platz 1 | 80539 München | Deutschland
Tel.: +49 (0)89 2180-5501


___
INDOLOGY mailing list
INDOLOGY@list.indology.info
https://list.indology.info/mailman/listinfo/indology

Re: [e-users] EFL compile problem

On Thu, Jun 6, 2024 at 2:17 PM daniel antoine  wrote:
>
> do you mean just that
>
> diff --git a/src/lib/eina/meson.build b/src/lib/eina/meson.build
> index 4ab37d2112..c50a06b59b 100644
> --- a/src/lib/eina/meson.build
>  +++ b/src/lib/eina/meson.build
>  @@ -371,17 +371,17 @@ eina_ext_deps += [iconv]
> execinfo = cc.find_library('execinfo', required: false)
> eina_ext_deps += [execinfo]
> -  c_args : [package_c_args, '-DEINA_BUILD', iconv_c_args],
> +  c_args : eina_c_args,

yes


___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Bug#1069449: firejail: FTBFS on armhf: ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined

2024-06-06 Thread Vincent Lefevre

On 2024-04-20 14:51:12 +0200, Lucas Nussbaum wrote:
> > /tmp/ccnMX2lv.s: Assembler messages:
> > /tmp/ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined
> > /tmp/ccnMX2lv.s:2079: Error: symbol `freopen64' is already defined
> > /tmp/ccnMX2lv.s:3164: Error: symbol `__stat64_time64' is already defined
> > /tmp/ccnMX2lv.s:3474: Error: symbol `__lstat64_time64' is already defined
> > make[2]: *** [../../src/so.mk:23: libtrace.o] Error 1

firejail has been removed from testing due to this bug. Any news?

I think that the buggy patch for musl

https://github.com/netblue30/firejail/commit/a86c4fe93f130752a862ff0a5ee75f073c3586b1

mentioned in the upstream bug

  https://github.com/netblue30/firejail/issues/5906

should be reverted.

BTW, for architectures without -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
(such as amd64), though the code compiles and linking succeeds too,
I'm wondering whether the behavior is correct, because there are 2
definitions of some functions (like fopen64): one from libtrace and
one from the glibc.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1069449: firejail: FTBFS on armhf: ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined

2024-06-06 Thread Vincent Lefevre

On 2024-04-20 14:51:12 +0200, Lucas Nussbaum wrote:
> > /tmp/ccnMX2lv.s: Assembler messages:
> > /tmp/ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined
> > /tmp/ccnMX2lv.s:2079: Error: symbol `freopen64' is already defined
> > /tmp/ccnMX2lv.s:3164: Error: symbol `__stat64_time64' is already defined
> > /tmp/ccnMX2lv.s:3474: Error: symbol `__lstat64_time64' is already defined
> > make[2]: *** [../../src/so.mk:23: libtrace.o] Error 1

firejail has been removed from testing due to this bug. Any news?

I think that the buggy patch for musl

https://github.com/netblue30/firejail/commit/a86c4fe93f130752a862ff0a5ee75f073c3586b1

mentioned in the upstream bug

  https://github.com/netblue30/firejail/issues/5906

should be reverted.

BTW, for architectures without -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64
(such as amd64), though the code compiles and linking succeeds too,
I'm wondering whether the behavior is correct, because there are 2
definitions of some functions (like fopen64): one from libtrace and
one from the glibc.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [e-users] EFL compile problem

On Thu, Jun 6, 2024 at 11:22 AM daniel antoine  wrote:
>
> Hi Vincent
>
> I run in the compile error with commit
> 1cd130ac096bd2148d4c0f6e54864413284e0963 , you talk about a patch, if
> you want I can try it

please try it. don't forget the missing colon that i have mentioned.
I'm waiting for someone  to tell me that the patch is fixing this
issue

Vincent

> Best regards
>
> Daniel
>
> Le jeu. 6 juin 2024 à 10:36, Vincent Torri  a écrit :
> >
> > On Thu, Jun 6, 2024 at 10:30 AM Masaru Nomiya  wrote:
> > >
> > > Hello,
> > >
> > > Sorry, forgot to attach the error message.
> > >
> > > In the Message;
> > >
> > >   Subject: Re: [e-users] EFL compile problem
> > >   Message-ID : <87v82mqyhu.wl-nom...@lake.dti.ne.jp>
> > >   Date & Time:
> > >
> > > [MN] == Masaru Nomiya  has written:
> > >
> > > MN> Hello,
> > >
> > > MN> In the Message;
> > >
> > > MN>   Subject: Re: [e-users] EFL compile problem
> > > MN>   Message-ID : 
> > > 
> > > MN>   Date & Time: Thu, 6 Jun 2024 09:24:51 +0200
> > >
> > > MN> [VT] == Vincent Torri  has written:
> > >
> > > VT>  try that patch
> > >
> > > VT>  diff --git a/src/lib/eina/meson.build b/src/lib/eina/meson.build
> > > VT>  index 4ab37d2112..c50a06b59b 100644
> > > VT>  --- a/src/lib/eina/meson.build
> > > VT>  +++ b/src/lib/eina/meson.build
> > > VT>  @@ -371,17 +371,17 @@ eina_ext_deps += [iconv]
> > > VT>   execinfo = cc.find_library('execinfo', required: false)
> > > VT>   eina_ext_deps += [execinfo]
> > > MN> [...]
> > > VT>  -  c_args : [package_c_args, '-DEINA_BUILD', iconv_c_args],
> > > VT>  +  c_args : eina_c_args
> >
> > see my last msg : missing comma at the end above (I did the diff
> > before saving file...)
> >
> > Vincent
> >
> >
> > ___
> > enlightenment-users mailing list
> > enlightenment-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
>
> ___
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users


___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] EFL compile problem

On Thu, Jun 6, 2024 at 10:30 AM Masaru Nomiya  wrote:
>
> Hello,
>
> Sorry, forgot to attach the error message.
>
> In the Message;
>
>   Subject: Re: [e-users] EFL compile problem
>   Message-ID : <87v82mqyhu.wl-nom...@lake.dti.ne.jp>
>   Date & Time:
>
> [MN] == Masaru Nomiya  has written:
>
> MN> Hello,
>
> MN> In the Message;
>
> MN>   Subject: Re: [e-users] EFL compile problem
> MN>   Message-ID : 
> 
> MN>   Date & Time: Thu, 6 Jun 2024 09:24:51 +0200
>
> MN> [VT] == Vincent Torri  has written:
>
> VT>  try that patch
>
> VT>  diff --git a/src/lib/eina/meson.build b/src/lib/eina/meson.build
> VT>  index 4ab37d2112..c50a06b59b 100644
> VT>  --- a/src/lib/eina/meson.build
> VT>  +++ b/src/lib/eina/meson.build
> VT>  @@ -371,17 +371,17 @@ eina_ext_deps += [iconv]
> VT>   execinfo = cc.find_library('execinfo', required: false)
> VT>   eina_ext_deps += [execinfo]
> MN> [...]
> VT>  -  c_args : [package_c_args, '-DEINA_BUILD', iconv_c_args],
> VT>  +  c_args : eina_c_args

see my last msg : missing comma at the end above (I did the diff
before saving file...)

Vincent


___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] EFL compile problem

On Thu, Jun 6, 2024 at 9:24 AM Vincent Torri  wrote:
>
> try that patch
>
>
> diff --git a/src/lib/eina/meson.build b/src/lib/eina/meson.build
> index 4ab37d2112..c50a06b59b 100644
> --- a/src/lib/eina/meson.build
> +++ b/src/lib/eina/meson.build
> @@ -371,17 +371,17 @@ eina_ext_deps += [iconv]
>  execinfo = cc.find_library('execinfo', required: false)
>  eina_ext_deps += [execinfo]
>
> -iconv_c_args = ''
> +eina_c_args = [package_c_args, '-DEINA_BUILD']
>  if sys_windows == true
> bcrypt = cc.find_library('bcrypt', required: true)
> eina_ext_deps += [bcrypt]
> if iconv.found()
> - iconv_c_args = '-DWINICONV_CONST='
> + eina_c_args += '-DWINICONV_CONST='
> endif
>  endif
>
>  eina_lib = library('eina', eina_src,
> -  c_args : [package_c_args, '-DEINA_BUILD', iconv_c_args],
> +  c_args : eina_c_args

missing  comma at the end of the previous line

>include_directories : config_dir,
>dependencies: eina_ext_deps + [eina_deps, evil],
>install: true,
>
>
>
> On Thu, Jun 6, 2024 at 8:47 AM Philippe Jean Guillaumie  wrote:
> >
> > I update the Enlightenment ecosystem on a daily basis.
> > Everything was okay before commit 1cd130ac09.
> >
> > This commit is the obvious culprit.
> >
> > Le 06/06/2024 à 08:23, Vincent Torri a écrit :
> > > On Thu, Jun 6, 2024 at 7:59 AM Philippe Jean Guillaumie  
> > > wrote:
> > >>
> > >> EFL fails to build on all my Ubuntu systems (22.04 LTS and 24.04 LTS)
> > >>
> > >> Same errors:
> > >>
> > >> gcc: warning: : linker input file unused because linking not done
> > >> gcc: error: : linker input file not found: No such file or directory
> > >> ninja: build stopped: subcommand failed.
> > >
> > > and if you revert my patch,it works ?
> > >
> > > Vincent
> > >
> > >>
> > >> Le 06/06/2024 à 06:35, Vincent Torri a écrit :
> > >>> hello
> > >>>
> > >>> i have no clue about this error (except maybe a problem with ccache),
> > >>> but the commit about constness is only for Windows
> > >>>
> > >>> Vincent
> > >>>
> > >>> On Thu, Jun 6, 2024 at 1:19 AM Conrad Knight  
> > >>> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> I just did the usual updates on my system today and that included
> > >>>> pulling the latest efl sources using AUR (the efl-git package). But i
> > >>>> quickly ran into a problem... meson ran fine, but as soon as ninja
> > >>>> started the compile process i got errors:
> > >>>>
> > >>>> ninja: Entering directory `build'
> > >>>> [1/2065] Compiling C object 
> > >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> > >>>> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> > >>>> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> > >>>> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> > >>>> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> > >>>> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> > >>>> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> > >>>> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> > >>>> -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> > >>>> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
> > >>>> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
> > >>>> -mno-omit-leaf-frame-pointer -g
> > >>>> -ffile-prefix-map=/usr/src/aur/efl-git/src=/usr/src/debug/efl-git
> > >>>> -flto=auto -fvisibility=hidden -fPIC -pthread
> > >>>> '-DPACKAGE_DATA_DIR="/usr/share/eina"' -DNEED_RUN_IN_TREE=1
> > >>>> -DEFL_BUILD=1 -DEINA_BUILD '' -MD -MQ
> > >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -MF
> > >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o.d -o
> > >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -c
> > >>>> ../src/lib/eina/eina_abi.c
> > >>>> cc: warning: : linker input file unused because linking not done
> > >>>> cc: error: : linker input file not found: No such file or directory
> > >>>> [2/2065] Compiling C object 
> &g

Re: [e-users] EFL compile problem

try that patch


diff --git a/src/lib/eina/meson.build b/src/lib/eina/meson.build
index 4ab37d2112..c50a06b59b 100644
--- a/src/lib/eina/meson.build
+++ b/src/lib/eina/meson.build
@@ -371,17 +371,17 @@ eina_ext_deps += [iconv]
 execinfo = cc.find_library('execinfo', required: false)
 eina_ext_deps += [execinfo]

-iconv_c_args = ''
+eina_c_args = [package_c_args, '-DEINA_BUILD']
 if sys_windows == true
bcrypt = cc.find_library('bcrypt', required: true)
eina_ext_deps += [bcrypt]
if iconv.found()
- iconv_c_args = '-DWINICONV_CONST='
+ eina_c_args += '-DWINICONV_CONST='
endif
 endif

 eina_lib = library('eina', eina_src,
-  c_args : [package_c_args, '-DEINA_BUILD', iconv_c_args],
+  c_args : eina_c_args
   include_directories : config_dir,
   dependencies: eina_ext_deps + [eina_deps, evil],
   install: true,



On Thu, Jun 6, 2024 at 8:47 AM Philippe Jean Guillaumie  wrote:
>
> I update the Enlightenment ecosystem on a daily basis.
> Everything was okay before commit 1cd130ac09.
>
> This commit is the obvious culprit.
>
> Le 06/06/2024 à 08:23, Vincent Torri a écrit :
> > On Thu, Jun 6, 2024 at 7:59 AM Philippe Jean Guillaumie  
> > wrote:
> >>
> >> EFL fails to build on all my Ubuntu systems (22.04 LTS and 24.04 LTS)
> >>
> >> Same errors:
> >>
> >> gcc: warning: : linker input file unused because linking not done
> >> gcc: error: : linker input file not found: No such file or directory
> >> ninja: build stopped: subcommand failed.
> >
> > and if you revert my patch,it works ?
> >
> > Vincent
> >
> >>
> >> Le 06/06/2024 à 06:35, Vincent Torri a écrit :
> >>> hello
> >>>
> >>> i have no clue about this error (except maybe a problem with ccache),
> >>> but the commit about constness is only for Windows
> >>>
> >>> Vincent
> >>>
> >>> On Thu, Jun 6, 2024 at 1:19 AM Conrad Knight  
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I just did the usual updates on my system today and that included
> >>>> pulling the latest efl sources using AUR (the efl-git package). But i
> >>>> quickly ran into a problem... meson ran fine, but as soon as ninja
> >>>> started the compile process i got errors:
> >>>>
> >>>> ninja: Entering directory `build'
> >>>> [1/2065] Compiling C object 
> >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> >>>> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> >>>> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> >>>> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> >>>> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> >>>> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> >>>> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> >>>> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> >>>> -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> >>>> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
> >>>> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
> >>>> -mno-omit-leaf-frame-pointer -g
> >>>> -ffile-prefix-map=/usr/src/aur/efl-git/src=/usr/src/debug/efl-git
> >>>> -flto=auto -fvisibility=hidden -fPIC -pthread
> >>>> '-DPACKAGE_DATA_DIR="/usr/share/eina"' -DNEED_RUN_IN_TREE=1
> >>>> -DEFL_BUILD=1 -DEINA_BUILD '' -MD -MQ
> >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -MF
> >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o.d -o
> >>>> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -c
> >>>> ../src/lib/eina/eina_abi.c
> >>>> cc: warning: : linker input file unused because linking not done
> >>>> cc: error: : linker input file not found: No such file or directory
> >>>> [2/2065] Compiling C object 
> >>>> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o
> >>>> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o
> >>>> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> >>>> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> >>>> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> >>>> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> >>>> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> >>

Re: [e-users] EFL compile problem

On Thu, Jun 6, 2024 at 7:59 AM Philippe Jean Guillaumie  wrote:
>
> EFL fails to build on all my Ubuntu systems (22.04 LTS and 24.04 LTS)
>
> Same errors:
>
> gcc: warning: : linker input file unused because linking not done
> gcc: error: : linker input file not found: No such file or directory
> ninja: build stopped: subcommand failed.

and if you revert my patch,it works ?

Vincent

>
> Le 06/06/2024 à 06:35, Vincent Torri a écrit :
> > hello
> >
> > i have no clue about this error (except maybe a problem with ccache),
> > but the commit about constness is only for Windows
> >
> > Vincent
> >
> > On Thu, Jun 6, 2024 at 1:19 AM Conrad Knight  wrote:
> >>
> >> Hi,
> >>
> >> I just did the usual updates on my system today and that included
> >> pulling the latest efl sources using AUR (the efl-git package). But i
> >> quickly ran into a problem... meson ran fine, but as soon as ninja
> >> started the compile process i got errors:
> >>
> >> ninja: Entering directory `build'
> >> [1/2065] Compiling C object src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> >> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> >> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> >> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> >> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> >> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> >> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> >> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> >> -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> >> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
> >> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
> >> -mno-omit-leaf-frame-pointer -g
> >> -ffile-prefix-map=/usr/src/aur/efl-git/src=/usr/src/debug/efl-git
> >> -flto=auto -fvisibility=hidden -fPIC -pthread
> >> '-DPACKAGE_DATA_DIR="/usr/share/eina"' -DNEED_RUN_IN_TREE=1
> >> -DEFL_BUILD=1 -DEINA_BUILD '' -MD -MQ
> >> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -MF
> >> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o.d -o
> >> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -c
> >> ../src/lib/eina/eina_abi.c
> >> cc: warning: : linker input file unused because linking not done
> >> cc: error: : linker input file not found: No such file or directory
> >> [2/2065] Compiling C object 
> >> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o
> >> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o
> >> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> >> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> >> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> >> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> >> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> >> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> >> -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> >> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
> >> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
> >> -mno-omit-leaf-frame-pointer -g
> >> -ffile-prefix-map=/usr/src/aur/efl-git/src=/usr/src/debug/efl-git
> >> -flto=auto -fvisibility=hidden -fPIC -pthread
> >> '-DPACKAGE_DATA_DIR="/usr/share/eina"' -DNEED_RUN_IN_TREE=1
> >> -DEFL_BUILD=1 -DEINA_BUILD '' -MD -MQ
> >> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o -MF
> >> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o.d -o
> >> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o -c
> >> ../src/lib/eina/eina_accessor.c
> >> cc: warning: : linker input file unused because linking not done
> >> cc: error: : linker input file not found: No such file or directory
> >> [3/2065] Compiling C object 
> >> src/lib/eina/libeina.so.1.27.99.p/eina_binshare.c.o
> >> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_binshare.c.o
> >> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> >> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> >> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> >> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> >> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> >> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> >> -march=x86-64 -mtune=g

Re: [e-users] EFL compile problem

2024-06-05 Thread Vincent Torri

hello

i have no clue about this error (except maybe a problem with ccache),
but the commit about constness is only for Windows

Vincent

On Thu, Jun 6, 2024 at 1:19 AM Conrad Knight  wrote:
>
> Hi,
>
> I just did the usual updates on my system today and that included
> pulling the latest efl sources using AUR (the efl-git package). But i
> quickly ran into a problem... meson ran fine, but as soon as ninja
> started the compile process i got errors:
>
> ninja: Entering directory `build'
> [1/2065] Compiling C object src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o
> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer -g
> -ffile-prefix-map=/usr/src/aur/efl-git/src=/usr/src/debug/efl-git
> -flto=auto -fvisibility=hidden -fPIC -pthread
> '-DPACKAGE_DATA_DIR="/usr/share/eina"' -DNEED_RUN_IN_TREE=1
> -DEFL_BUILD=1 -DEINA_BUILD '' -MD -MQ
> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -MF
> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o.d -o
> src/lib/eina/libeina.so.1.27.99.p/eina_abi.c.o -c
> ../src/lib/eina/eina_abi.c
> cc: warning: : linker input file unused because linking not done
> cc: error: : linker input file not found: No such file or directory
> [2/2065] Compiling C object 
> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o
> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o
> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer -g
> -ffile-prefix-map=/usr/src/aur/efl-git/src=/usr/src/debug/efl-git
> -flto=auto -fvisibility=hidden -fPIC -pthread
> '-DPACKAGE_DATA_DIR="/usr/share/eina"' -DNEED_RUN_IN_TREE=1
> -DEFL_BUILD=1 -DEINA_BUILD '' -MD -MQ
> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o -MF
> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o.d -o
> src/lib/eina/libeina.so.1.27.99.p/eina_accessor.c.o -c
> ../src/lib/eina/eina_accessor.c
> cc: warning: : linker input file unused because linking not done
> cc: error: : linker input file not found: No such file or directory
> [3/2065] Compiling C object 
> src/lib/eina/libeina.so.1.27.99.p/eina_binshare.c.o
> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_binshare.c.o
> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -fvisibility=hidden -Wpointer-arith -Wunused-parameter -Wsign-compare
> -Wno-missing-field-initializers -DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1
> -DEFL_BETA_API_SUPPORT=1 -DELM_INTERNAL_API_ARGESFSDFEFC=1
> -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
> -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
> -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer -g
> -ffile-prefix-map=/usr/src/aur/efl-git/src=/usr/src/debug/efl-git
> -flto=auto -fvisibility=hidden -fPIC -pthread
> '-DPACKAGE_DATA_DIR="/usr/share/eina"' -DNEED_RUN_IN_TREE=1
> -DEFL_BUILD=1 -DEINA_BUILD '' -MD -MQ
> src/lib/eina/libeina.so.1.27.99.p/eina_binshare.c.o -MF
> src/lib/eina/libeina.so.1.27.99.p/eina_binshare.c.o.d -o
> src/lib/eina/libeina.so.1.27.99.p/eina_binshare.c.o -c
> ../src/lib/eina/eina_binshare.c
> cc: warning: : linker input file unused because linking not done
> cc: error: : linker input file not found: No such file or directory
> [4/2065] Compiling C object 
> src/lib/eina/libeina.so.1.27.99.p/eina_benchmark.c.o
> FAILED: src/lib/eina/libeina.so.1.27.99.p/eina_benchmark.c.o
> ccache cc -Isrc/lib/eina/libeina.so.1.27.99.p -Isrc/lib/eina
> -I../src/lib/eina -I. -I.. -I/usr/include/valgrind
> -fdiagnostics-color=always

EBBR v2.2.0 has been released

2024-06-05 Thread Vincent Stehlé

Hi,

I am happy to announce that v2.2.0 of the EBBR specification has now been
released. [1]

The following people (listed in alphabetical order) have participated to this
EBBR release directly or indirectly, with patches, github issues, pull requests,
reviews, comments, suggestions, or by attending the zoom calls:

  Ilias Apalodimas
  Joakim Bech
  Ard Biesheuvel
  Etienne Carrière
  Wei Chen
  Patrick Delaunay
  Samuel Dionne-Riel
  Samer El-Haj-Mahmoud
  Andreas Färber
  Ahmad Fatoum
  Sughosh Ganu
  Simon Glass
  Alexander Graf
  Rob Herring
  Jon Humphreys
  Jan Kiszka
  Jan Lübbe
  Jose Marinho
  Loïc Minier
  Weizhao Ouyang
  François-Frédéric Ozog
  Stephen Paulger
  Tom Rini
  Peter Robinson
  Heinrich Schuchardt
  Michal Simek
  Vincent Stehlé
  Daniel Thompson
  Ivan T. Ivanov
  Stuart Yoder

A big thank you to all the EBBR contributors!

Best regards,

Vincent Stehlé
System Architect - Arm

[1]: https://github.com/ARM-software/ebbr/releases/tag/v2.2.0
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: [fr-users] Problème

2024-06-05 Thread Vincent Permaculture

Bonjour,
Ou bien tu as double-cliqué entre deux pages et les marges sont masquées... 
dans ce cas là, redouble-cliquer sur la limite entre deux pages.

Tout de bon,
Vincent

Envoyé avec la messagerie sécurisée Proton Mail.

Le mardi 4 juin 2024 à 21:56, FATTAL Joudy  a écrit :

>  dir="auto">Bonjour excusez moi jai un problème. Mon libre office fait 
> quelque-chose de bizarre, il écrit TOUT EN HAUT de ma page. Comment puis-je 
> régler ça?C'est vraiment une urgence en vue de mes examens la 
> semaine prochaine.
> 
> --
> Envoyez un mail à users+unsubscr...@fr.libreoffice.org pour vous désinscrire
> Les archives de la liste sont disponibles à 
> https://listarchives.libreoffice.org/fr/users/
> Privacy Policy: https://www.documentfoundation.org/privacy

-- 
Envoyez un mail à users+unsubscr...@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à 
https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Bug#1072620: aptitude: discrepancy between TUI and command line when not all packages of the same source can be upgraded

2024-06-05 Thread Vincent Lefevre

rror.so.0 
(0x7f27fbac2000)

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

Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-6
ii  libapt-pkg6.0t64  2.9.4
ii  libboost-iostreams1.83.0  1.83.0-3
ii  libc6 2.38-12
ii  libcwidget4   0.5.18-6+b1
ii  libgcc-s1 14.1.0-1
ii  libncursesw6  6.5-2
ii  libsigc++-2.0-0v5 2.12.1-2
ii  libsqlite3-0  3.46.0-1
ii  libstdc++614.1.0-1
ii  libtinfo6 6.5-2
ii  libxapian30   1.4.25-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.22.6
ii  sensible-utils  0.0.22

Versions of packages aptitude suggests:
pn  apt-xapian-index
ii  aptitude-doc-en [aptitude-doc]  0.8.13-6
pn  debtags     
ii  tasksel 3.75

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Aptitude-devel] Bug#1072620: aptitude: discrepancy between TUI and command line when not all packages of the same source can be upgraded

2024-06-05 Thread Vincent Lefevre

rror.so.0 
(0x7f27fbac2000)

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

Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-6
ii  libapt-pkg6.0t64  2.9.4
ii  libboost-iostreams1.83.0  1.83.0-3
ii  libc6 2.38-12
ii  libcwidget4   0.5.18-6+b1
ii  libgcc-s1 14.1.0-1
ii  libncursesw6  6.5-2
ii  libsigc++-2.0-0v5 2.12.1-2
ii  libsqlite3-0  3.46.0-1
ii  libstdc++614.1.0-1
ii  libtinfo6 6.5-2
ii  libxapian30   1.4.25-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.22.6
ii  sensible-utils  0.0.22

Versions of packages aptitude suggests:
pn  apt-xapian-index
ii  aptitude-doc-en [aptitude-doc]  0.8.13-6
pn  debtags     
ii  tasksel 3.75

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

Re: Pre-Draft for Opaque Objects

2024-06-04 Thread Vincent de Lau

On Tuesday, June 4, 2024 at 4:16:10 PM UTC+2 Grégory Planchat wrote:

Hello,

Hi Grégory,

I would like to make a proposal for Opaque and Ciphered objects. Both are
related to securing sensitive data such as passwords and keys while you
need to manipulate them in your code.

The need for Opaque Objects comes from securing sensitive data while they
are in clear in your system. Instead of manipulating passwords as strings,
we manipulate them through an Opaque object that can't leak its contents
through var_dump/var_export, trace dumping or serialization. The only way
of leaking the protected data would be by calling a `disclose()` method.

Are you aware of SensitiveParameterValue [1][2]? This class was introduced
as part of the 'Redacting parameters in back traces' RFC [3]. Is this
essentially what Opaque should be?

As the serialization feature would be blocked by Opaque Objects alone, the
Ciphered Objects and encrypt/decrypt functionalities are added to keep a
safe way of serialization of those sensitive data.

I have a specification I use as an ADR in some of my projects currently in
production that I would be happy to use as a PSR draft.

Would such proposal interest people from the FIG to transform it to a PSR?

As far as this being PSR worthy, I wonder how this problem space has impact
on interoperability. Maybe in the broader context of configuration and
service locator this might be an enhancement. What use cases do you see
that would require this to be a PSR and not just a library?

Kind regards,
Vincent

[1]: https://www.php.net/manual/en/class.sensitiveparametervalue.php
[2]: https://3v4l.org/Vso8g
[3]: https://wiki.php.net/rfc/redact_parameters_in_back_traces

--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/1319901b-5e5b-413e-bafe-9c15f995a635n%40googlegroups.com.

Re: timeout in shutdown, mutt killed by SIGKILL

2024-06-03 Thread Vincent Lefevre

On 2024-05-31 19:05:45 +0700, Max Nikulin wrote:
> Do you see an attempt to send SIGTERM to mutt before timeout and SIGKILL?

Unfortunately, there was no information from systemd. Some daemons
log a received SIGTERM, but mutt isn't a daemon.

> What other processes survived first step? Are there something suspicious
> before SIGKILL stage?

According to the journalctl output, only mutt survived (the only
process to receive a SIGKILL). And nothing suspicious.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

EBBR call today Jun 3

2024-06-03 Thread Vincent Stehlé

Hi,

We will have an EBBR call[1] today, Jun 3 at 15h BST (14h UTC; BST is active).
We have one topic on the agenda[2]:

- Decide if v2.2.0-pre1 is ok for release.

Feel free to add to the agenda, directly on the wiki page or by e-mail.
We can use this pad[3] for the meeting notes.

Best regards,

Vincent Stehlé
System Architect - Arm

[1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09
[2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings
[3]: https://mensuel.framapad.org/p/ebbr-call-of-jun-3-a83j
___
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Bug#1072504: lynx: does not discard output from mailcap test

2024-06-02 Thread Vincent Lefevre

Package: lynx
Version: 2.9.2-1
Severity: important

lynx does not discard output from mailcap test, so that "lynx -dump"
generates incorrect output.

With mailcap 3.71:

$ lynx -dump /dev/null
/bin/atril
/usr/bin/emacs
/usr/bin/emacs
/bin/gimp-2.10
/bin/baobab
/bin/eog
/bin/evince
/bin/inkscape
/bin/wireshark

because /etc/mailcap now has lines like

application/pdf; atril %s; test=command -v atril && test -n "$DISPLAY"

where "command -v atril" outputs "/bin/atril".

I can see from strace output that lynx executes

434913 execve("/bin/sh", ["sh", "-c", "--", "command -v atril && test -n 
\"$DISPLAY\""], 0x55b606914990 /* 137 vars */ 

and so on.

As a comparison, run-mailcap discards stdout and stderr:

if ($match =~ m/;\s*test=(.*?)\s*($|;)/) {
my $test;
print STDERR " - running test: $1 " if $debug;
$test   = system "$1 >/dev/null 2>&1";

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

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 lynx depends on:
ii  libbrotli1  1.1.0-2+b3
ii  libbsd0 0.12.2-1
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.38-12
ii  libgnutls30t64  3.8.5-4
ii  libidn2-0   2.3.7-2
ii  libncursesw66.5-2
ii  libtinfo6   6.5-2
ii  lynx-common 2.9.2-1
ii  zlib1g      1:1.3.dfsg-3.1

Versions of packages lynx recommends:
ii  mailcap  3.71

lynx suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

2024-06-02 Thread Vincent Lefevre

Hi,

On 2024-06-03 00:38:01 +0200, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2024-04-29 at 04:37:18 +0200, Vincent Lefevre wrote:
> > On 2024-04-29 03:05:50 +0200, Guillem Jover wrote:
> > > I don't think dpkg is at fault here, I assume something else is either
> > > getting activated in the middle of the transaction while the package
> > > manager frontend driving dpkg has released the lock (which it should
> > > not), or the package manager frontend driving dpkg is performing the
> > > locking dance incorrectly.
> > 
> > Isn't dpkg able to install/uninstall a set of packages in an atomic
> > way (where dpkg itself would set a lock at the beginning and release
> > the lock once every install/uninstall has been done, so that a lock
> > failure would not be possible in the middle of the installation)?
> 
> Sure, but that's not how apt-based frontends do it, as they call
> dpkg multiples times over an upgrade process.

Why do they do that while it is possible to give dpkg several packages
to install (upgrade)?

And why doesn't the frontend log the different calls
in/var/log/apt/history.log?

I'm talking specifically about

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070027#19

> Checking around I see that the systemd apt-daily.timer triggered at just
> the same time, so that seems like the most likely culprit. So I guess it
> makes sense for this report to be cloned and reassigned or so.

Hmm... That was also the case for me. Let's recall:

Start-Date: 2024-04-28  22:05:30
[...]
Error: Sub-process /usr/bin/dpkg returned an error code (2)
End-Date: 2024-04-28  22:05:34

and in the journalctl output at this time:

Apr 28 22:05:33 disset systemd[1]: Reloading requested from client PID 58469 
('systemctl') (unit session-796.scope)...
Apr 28 22:05:33 disset systemd[1]: Reloading...
Apr 28 22:05:34 disset systemd[1]: Reloading finished in 102 ms.
Apr 28 22:05:34 disset systemd[1]: Starting apt-daily.service - Daily apt 
download activities...
Apr 28 22:05:34 disset systemd[1]: fstrim.timer: Deactivated successfully.
Apr 28 22:05:34 disset systemd[1]: Stopped fstrim.timer - Discard unused 
filesystem blocks once a week.
Apr 28 22:05:34 disset systemd[1]: Stopping fstrim.timer - Discard unused 
filesystem blocks once a week...
Apr 28 22:05:34 disset systemd[1]: Started fstrim.timer - Discard unused 
filesystem blocks once a week.
Apr 28 22:05:34 disset systemd[1]: Reloading requested from client PID 58516 
('systemctl') (unit session-796.scope)...
Apr 28 22:05:34 disset systemd[1]: Reloading...
Apr 28 22:05:34 disset systemd[1]: Reloading finished in 110 ms.
Apr 28 22:05:34 disset systemd[1]: apt-daily.service: Deactivated successfully.
Apr 28 22:05:34 disset systemd[1]: Finished apt-daily.service - Daily apt 
download activities.

But I've never requested a reloading at this time!
So there's something broken related to systemd.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

2024-06-02 Thread Vincent Lefevre

Hi,

On 2024-06-03 00:38:01 +0200, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2024-04-29 at 04:37:18 +0200, Vincent Lefevre wrote:
> > On 2024-04-29 03:05:50 +0200, Guillem Jover wrote:
> > > I don't think dpkg is at fault here, I assume something else is either
> > > getting activated in the middle of the transaction while the package
> > > manager frontend driving dpkg has released the lock (which it should
> > > not), or the package manager frontend driving dpkg is performing the
> > > locking dance incorrectly.
> > 
> > Isn't dpkg able to install/uninstall a set of packages in an atomic
> > way (where dpkg itself would set a lock at the beginning and release
> > the lock once every install/uninstall has been done, so that a lock
> > failure would not be possible in the middle of the installation)?
> 
> Sure, but that's not how apt-based frontends do it, as they call
> dpkg multiples times over an upgrade process.

Why do they do that while it is possible to give dpkg several packages
to install (upgrade)?

And why doesn't the frontend log the different calls
in/var/log/apt/history.log?

I'm talking specifically about

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070027#19

> Checking around I see that the systemd apt-daily.timer triggered at just
> the same time, so that seems like the most likely culprit. So I guess it
> makes sense for this report to be cloned and reassigned or so.

Hmm... That was also the case for me. Let's recall:

Start-Date: 2024-04-28  22:05:30
[...]
Error: Sub-process /usr/bin/dpkg returned an error code (2)
End-Date: 2024-04-28  22:05:34

and in the journalctl output at this time:

Apr 28 22:05:33 disset systemd[1]: Reloading requested from client PID 58469 
('systemctl') (unit session-796.scope)...
Apr 28 22:05:33 disset systemd[1]: Reloading...
Apr 28 22:05:34 disset systemd[1]: Reloading finished in 102 ms.
Apr 28 22:05:34 disset systemd[1]: Starting apt-daily.service - Daily apt 
download activities...
Apr 28 22:05:34 disset systemd[1]: fstrim.timer: Deactivated successfully.
Apr 28 22:05:34 disset systemd[1]: Stopped fstrim.timer - Discard unused 
filesystem blocks once a week.
Apr 28 22:05:34 disset systemd[1]: Stopping fstrim.timer - Discard unused 
filesystem blocks once a week...
Apr 28 22:05:34 disset systemd[1]: Started fstrim.timer - Discard unused 
filesystem blocks once a week.
Apr 28 22:05:34 disset systemd[1]: Reloading requested from client PID 58516 
('systemctl') (unit session-796.scope)...
Apr 28 22:05:34 disset systemd[1]: Reloading...
Apr 28 22:05:34 disset systemd[1]: Reloading finished in 110 ms.
Apr 28 22:05:34 disset systemd[1]: apt-daily.service: Deactivated successfully.
Apr 28 22:05:34 disset systemd[1]: Finished apt-daily.service - Daily apt 
download activities.

But I've never requested a reloading at this time!
So there's something broken related to systemd.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [DISCUSS] indexes for API calls

2024-05-31 Thread Vincent Beck

Interesting thread.

I think what makes this discussion complex is that Airflow makes a lot of 
different queries (API, Scheduler, ...). I think it is even harder to keep 
track of all the different queries Airflow makes and thus, hard to figure if 
such index is needed. Also, Airflow evolves (and rightfully so), therefore, one 
index might have been useful in the past but not anymore due to some 
modifications in the code.

What would help us is a clear contract between the database and Airflow, 
meaning what are all the operations/queries Airflow needs. I know it had been 
mentioned during the last community sync and some folks are against but I 
wanted to reiterate this idea of having an API/interface for any DB operation. 
I dont know the consequences in terms of performance (especially for the 
scheduler) of even feasibility, but I think it might be worth to think about 
it? Especially because that would open some doors such as using NoSQL DB 
engines to run Airflow.

(Sorry if I deviated the conversation a bit).

On 2024/05/31 12:10:11 Andrey Anshin wrote:
> IMHO, blindy adding new indexes into the `dag_run` and `task_instance`
> tables will cause additional maintenance costs.
> 
> There are 8 indexes already exists per each of this tables
> 
> SELECT
> pi.schemaname schema_name,
> pi.tablename table_name,
> count(*) num
> FROM pg_indexes pi
> WHERE pi.schemaname = 'public'
> GROUP BY 1, 2
> ORDER BY 3 DESC, 2;
> 
> And maintenance indexes overall it is not something cheap, every time when
> the row changed/added (INSERT/UPDATE/DELETE/MERGE/COPY) there is a check
> whether or not it is required to rebalance index tree (B-Tree indexes).
> 
> If we would like to add individual indexes for one field we bump into the
> problem that this are less effective when it comes to a filter/sorting over
> multiple different fields (include PK), just because this action required
> to create Bitmap Scan into the memory (Working Memory in postgres, default
> something like 10 MiB), and in the end COB (Cost Base Optimisation)
> mechanism more like decide to do sequential scan, as result indexes become
> useless, and just use additional disc space and CPU for maintenance.
> 
> Rather than add these indexes (and every other "performance optimisation"
> measures) we should prove that this action gains benefits, rather than the
> opposite. That might be achieved by enable on some prod-like environment
> logs collection and analyze logs by pgBadger (
> https://github.com/darold/pgbadger), that might shows different metrics
> before changes and after the changes
> 
> This all valid for Postgres, and I have no idea how to calculate measures
> for MySQL, I hope we will reach an agreement to drop MySQL in Airflow 3.
> 
> On Fri, 31 May 2024 at 12:10, Pierre Jeambrun  wrote:
> 
> > Indeed Jarek I feel like this is another point in favor of stick to
> > "Postgres"
> >
> > As mentioned, maybe we were a little reckless when adding all these kinds
> > of filters. If they are not often used and we rarely / never see
> > performance github issues on those, marking them as 'non optimised but here
> > for convenience' could be a good short term solution. (And maybe removing
> > those filters at some point)
> >
> > What people use the API for (replicating the DB, building an UI, etc...) do
> > not really matter I think, Ideally I just think that the API should have a
> > sort of SLA and guarantee a reasonable response time for all endpoints
> > (through pagination, indexes, etc...). We can still document that some
> > endpoints are known to be slower for some reason and leave them out of this
> > performance constraint. (Having performance tests could be great otherwise
> > it will be very hard to track).
> >
> > Also just to be sure, the slowness you observe for listing task instances
> > only appears with a certain combination of filters, while some other
> > combinations, yielding a comparable result set in terms of 'size' are much
> > quicker ? (Just trying to understand if the slowness comes from missing
> > index, or also possibly from missing loading options that would cause lazy
> > loading at serialization time slowing everything down, I don't see a lot of
> > eager loading to prevent those, but maybe the few that we have are enough).
> >
> > Le ven. 31 mai 2024 à 09:38, Jarek Potiuk  a écrit :
> >
> > > And to be perfectly honest -  if people (like me) hesitate on settling on
> > > architectural decisions because they are afraid that their changes might
> > > have unintended consequences, because we want to support all the
> > different
> > > kinds of databases - this is one more reason we should stick to "Postgres
> > > only".  This is a very good example where we have real slow-downs that
> > > impact the speed the decisions are made (which impacts speed of feature
> > > development).
> > >
> > > On Fri, May 31, 2024 at 9:13 AM Jarek Potiuk  wrote:
> > >
> > > > Using UUIDS was the proposal how we can bypass the

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-31 01:05:51 +0800, Jun MO wrote:
> And if I understood correctly, wtmpdb require program use PAM to update
> wtmpdb, thus program not use PAM will still write /var/log/wtmp. For
> example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux
> depends on pam.

GNU Screen and xterm also write to /var/log/wtmp via libutempter0. So
this is libutempter0 that should actually be fixed. There is no need
to change the interface, as utempter_add_record uses neither the time
nor a specific structure to write to the file:

int
utempter_add_record(int fd, const char *host);

utempter_add_record() function adds a login record  to  the  database
for  the  TTY belonging to the pseudo-terminal master file descriptor
fd, using the username corresponding with the real  user  ID  of  the
calling process and the optional hostname host.  This function spawns
a privileged process to perform the actual logging.

> $ cat /var/log/wtmp.1 /var/log/wtmp >> wtmp-combined
> $ last -f wtmp-combined
> 
> The output will show when a user logout for those previously
> "gone - no logout" lines. I just realize this about a month ago.

Thanks. I didn't know that.

> I know there is a utmpdump(1) in the util-linux package, that is still
> available in 2.40.1-3 version. The command will dump more information
> than last(1); but it is for every single records, one may need to
> manually match login with logout, boot with shutdown, etc. Still it
> seems to me some information, e.g. exit_status, are still missing.

The host names are also dropped.

I've never seen an exit status. But the wtmp(5) man page says
"not used by Linux init(1)".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-31 01:05:51 +0800, Jun MO wrote:
> And if I understood correctly, wtmpdb require program use PAM to update
> wtmpdb, thus program not use PAM will still write /var/log/wtmp. For
> example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux
> depends on pam.

GNU Screen and xterm also write to /var/log/wtmp via libutempter0. So
this is libutempter0 that should actually be fixed. There is no need
to change the interface, as utempter_add_record uses neither the time
nor a specific structure to write to the file:

int
utempter_add_record(int fd, const char *host);

utempter_add_record() function adds a login record  to  the  database
for  the  TTY belonging to the pseudo-terminal master file descriptor
fd, using the username corresponding with the real  user  ID  of  the
calling process and the optional hostname host.  This function spawns
a privileged process to perform the actual logging.

> $ cat /var/log/wtmp.1 /var/log/wtmp >> wtmp-combined
> $ last -f wtmp-combined
> 
> The output will show when a user logout for those previously
> "gone - no logout" lines. I just realize this about a month ago.

Thanks. I didn't know that.

> I know there is a utmpdump(1) in the util-linux package, that is still
> available in 2.40.1-3 version. The command will dump more information
> than last(1); but it is for every single records, one may need to
> manually match login with logout, boot with shutdown, etc. Still it
> seems to me some information, e.g. exit_status, are still missing.

The host names are also dropped.

I've never seen an exit status. But the wtmp(5) man page says
"not used by Linux init(1)".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-31 01:05:51 +0800, Jun MO wrote:
> And if I understood correctly, wtmpdb require program use PAM to update
> wtmpdb, thus program not use PAM will still write /var/log/wtmp. For
> example, tmux write /var/log/wtmp via libutempter0 and I do not see tmux
> depends on pam.

GNU Screen and xterm also write to /var/log/wtmp via libutempter0. So
this is libutempter0 that should actually be fixed. There is no need
to change the interface, as utempter_add_record uses neither the time
nor a specific structure to write to the file:

int
utempter_add_record(int fd, const char *host);

utempter_add_record() function adds a login record  to  the  database
for  the  TTY belonging to the pseudo-terminal master file descriptor
fd, using the username corresponding with the real  user  ID  of  the
calling process and the optional hostname host.  This function spawns
a privileged process to perform the actual logging.

> $ cat /var/log/wtmp.1 /var/log/wtmp >> wtmp-combined
> $ last -f wtmp-combined
> 
> The output will show when a user logout for those previously
> "gone - no logout" lines. I just realize this about a month ago.

Thanks. I didn't know that.

> I know there is a utmpdump(1) in the util-linux package, that is still
> available in 2.40.1-3 version. The command will dump more information
> than last(1); but it is for every single records, one may need to
> manually match login with logout, boot with shutdown, etc. Still it
> seems to me some information, e.g. exit_status, are still missing.

The host names are also dropped.

I've never seen an exit status. But the wtmp(5) man page says
"not used by Linux init(1)".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-30 18:41:51 +0200, Chris Hofstaedtler wrote:
> wtmpdb takes over the "last" name. Unfortunately without support for
> reading the old files. Nobody wrote tooling to import them or so.

In the new versions of the package, "last" could have been installed
under another name (e.g. last-legacy) instead of dropping it entirely,
in particular because some programs still write to the old wtmp
(which has no issues until 2038).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-30 18:41:51 +0200, Chris Hofstaedtler wrote:
> wtmpdb takes over the "last" name. Unfortunately without support for
> reading the old files. Nobody wrote tooling to import them or so.

In the new versions of the package, "last" could have been installed
under another name (e.g. last-legacy) instead of dropping it entirely,
in particular because some programs still write to the old wtmp
(which has no issues until 2038).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-30 18:41:51 +0200, Chris Hofstaedtler wrote:
> wtmpdb takes over the "last" name. Unfortunately without support for
> reading the old files. Nobody wrote tooling to import them or so.

In the new versions of the package, "last" could have been installed
under another name (e.g. last-legacy) instead of dropping it entirely,
in particular because some programs still write to the old wtmp
(which has no issues until 2038).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [Qgis-user] [QGIS-Developer] lack of conflation tools

2024-05-31 Thread Vincent Picavet via QGIS-User


Hi,

Geospatial data conflation is not an easy task, and usually depends on :

- the input data

- desired output

- semantics

- conflation based mainly on semantics( / attribute data ), topology or purely 
geometric

Note that semantic and topology-based methods are much more robusts than 
geometry-based ones.

In any case, there is no magic workflow and the method has to be adapted to the 
specific context.

I contributed to an implementation based on PostGIS quite a long time ago :

https://docplayer.fr/8718145-Appariement-de-graphes-de-reseau-avec-postgis.html 
( in french ).

There could be some generic algorithms which could be made available in QGIS 
processing to ease creation of workflows for conflation ( e.g. node 
fingerprints, geometry local correspondance search  ).

Get in touch if you are interested in developing some.

Vincent


On 30/05/2024 11:46, PIERRE Sylvain via QGIS-Developer wrote:


Hi devs and  qgis power users,

After investigating I can arg that there’s a lack of conflation tools in QGIS 
like such existing for Esri  :

https://proceedings.esri.com/library/userconf/proc17/tech-workshops/tw_513-105.pdf

Is there some plan or something I miss for doing such task in QGIS ?

Thanks

**



Sylvain PIERRE**

Chef de projet système d’information

Direction des Systèmes d’Information et du Développement Numérique

Service Projets et Ingénierie Numérique

*Collectivité européenne d’Alsace*

Tél : 03 88 76 68 88

sylvain.pie...@alsace.eu <mailto:sylvain.pie...@alsace.eu>

www.alsace.eu <http://www.alsace.eu>

facebook <http://www.facebook.com/toutelalsace>twitter 
<http://www.twitter.com/toutelalsace>insta <http://www.instagram.com/toutelalsace>


___
QGIS-Developer mailing list
qgis-develo...@lists.osgeo.org
List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-User mailing list
QGIS-User@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [QGIS-Developer] lack of conflation tools

2024-05-31 Thread Vincent Picavet via QGIS-Developer


Hi,

Geospatial data conflation is not an easy task, and usually depends on :

- the input data

- desired output

- semantics

- conflation based mainly on semantics( / attribute data ), topology or purely 
geometric

Note that semantic and topology-based methods are much more robusts than 
geometry-based ones.

In any case, there is no magic workflow and the method has to be adapted to the 
specific context.

I contributed to an implementation based on PostGIS quite a long time ago :

https://docplayer.fr/8718145-Appariement-de-graphes-de-reseau-avec-postgis.html 
( in french ).

There could be some generic algorithms which could be made available in QGIS 
processing to ease creation of workflows for conflation ( e.g. node 
fingerprints, geometry local correspondance search  ).

Get in touch if you are interested in developing some.

Vincent


On 30/05/2024 11:46, PIERRE Sylvain via QGIS-Developer wrote:


Hi devs and  qgis power users,

After investigating I can arg that there’s a lack of conflation tools in QGIS 
like such existing for Esri  :

https://proceedings.esri.com/library/userconf/proc17/tech-workshops/tw_513-105.pdf

Is there some plan or something I miss for doing such task in QGIS ?

Thanks

**



Sylvain PIERRE**

Chef de projet système d’information

Direction des Systèmes d’Information et du Développement Numérique

Service Projets et Ingénierie Numérique

*Collectivité européenne d’Alsace*

Tél : 03 88 76 68 88

sylvain.pie...@alsace.eu <mailto:sylvain.pie...@alsace.eu>

www.alsace.eu <http://www.alsace.eu>

facebook <http://www.facebook.com/toutelalsace>twitter 
<http://www.twitter.com/toutelalsace>insta <http://www.instagram.com/toutelalsace>


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: timeout in shutdown, mutt killed by SIGKILL

On 2024-05-31 10:10:32 +0200, Vincent Lefevre wrote:
> On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> > Do you mean that mutt properly exits unless it receives SIGTERM in the
> > course of shutdown process?
> 
> I think that this was not the first time I did a shutdown while Mutt
> was still running. But this was the first time it did not exit.

I've tried a shutdown with Mutt still running in GNU Screen
a couple of times, and I got no timeout, i.e. Mutt exited as
expected.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: timeout in shutdown, mutt killed by SIGKILL

On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> Do you mean that mutt properly exits unless it receives SIGTERM in the
> course of shutdown process?

I think that this was not the first time I did a shutdown while Mutt
was still running. But this was the first time it did not exit.

> I would try to enable debug log in mutt. There is a chance that
> networking is already disabled (or some other system unit important
> for mutt is already stopped) when systemd tries to kill mutt first
> time.

No, according to the logs, the network was stopped after SIGKILL
was sent to Mutt:

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
[...]
May 29 01:55:26 qaa systemd[1]: Stopping NetworkManager.service - Network 
Manager...
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2966] caught 
SIGTERM, shutting down normally.
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2975] dhcp4 
(eth0): canceled DHCP transaction

Note that mutt is not the only case of timeout at shutdown. There's
also

May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: State 
'stop-sigterm' timed out. Killing.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116031 (xdg-document-po) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116037 (fusermount3) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Main process 
exited, code=killed, status=9/KILL
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Failed with 
result 'timeout'.

This one is a known issue:

https://github.com/flatpak/xdg-desktop-portal/issues/999

I'm wondering whether there could be a same cause.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [j-nsp] ACX EVO - funky auto complete

2024-05-30 Thread Vincent Bernat via juniper-nsp

On 2024-05-30 11:52, Ola Thoresen via juniper-nsp wrote:

This is fun...

 > show version
(...)
Model: acx7348
Junos: 23.4R1-S1.11-EVO

 > show lldp neighbors*//*
^
'neighbors ' is ambiguous.
Possible completions:
   neighbors    Show LLDP neighbor information
   neighbors-vlan-name-tlv-list  Show list of Vlan-Name in the LLDPDU of 
the interface

Exact same version, same hardware, I don't get this bug.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[jira] [Closed] (IMPALA-13118) Removing explicit ascii encoding of kerberos_host_fqdn when -b/--kerberos_host_fqdn is used



 [ 
https://issues.apache.org/jira/browse/IMPALA-13118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Tran closed IMPALA-13118.
-
Resolution: Duplicate

> Removing explicit ascii encoding of kerberos_host_fqdn when 
> -b/--kerberos_host_fqdn is used
> ---
>
> Key: IMPALA-13118
> URL: https://issues.apache.org/jira/browse/IMPALA-13118
> Project: IMPALA
>  Issue Type: Improvement
>  Components: Clients
>Affects Versions: Impala 4.4.0
>Reporter: Vincent Tran
>Assignee: Vincent Tran
>Priority: Major
>  Labels: Python3, impala-shell
>
> IMPALA-651 added an explicit encoding for sasl_host to ascii before passing 
> it to sasl_client.setAttr(). This is no longer required after sasl was 
> upgraded to 0.2.1 in IMPALA-9719.  This explicit encoding also causes an 
> error in Python 3 when -b is used:
> {noformat}
> Starting Impala Shell with Kerberos authentication using Python 3.6.8
> Using service name 'impala'
> SSL is enabled. Impala server certificates will NOT be verified (set 
> --ca_cert to change)
> Error connecting: TTransportException, Could not start SASL: b'Error in 
> sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Failure: no 
> serverFQDN'
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org

[jira] [Closed] (IMPALA-13118) Removing explicit ascii encoding of kerberos_host_fqdn when -b/--kerberos_host_fqdn is used



 [ 
https://issues.apache.org/jira/browse/IMPALA-13118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vincent Tran closed IMPALA-13118.
-
Resolution: Duplicate

> Removing explicit ascii encoding of kerberos_host_fqdn when 
> -b/--kerberos_host_fqdn is used
> ---
>
> Key: IMPALA-13118
> URL: https://issues.apache.org/jira/browse/IMPALA-13118
> Project: IMPALA
>  Issue Type: Improvement
>  Components: Clients
>Affects Versions: Impala 4.4.0
>Reporter: Vincent Tran
>Assignee: Vincent Tran
>Priority: Major
>  Labels: Python3, impala-shell
>
> IMPALA-651 added an explicit encoding for sasl_host to ascii before passing 
> it to sasl_client.setAttr(). This is no longer required after sasl was 
> upgraded to 0.2.1 in IMPALA-9719.  This explicit encoding also causes an 
> error in Python 3 when -b is used:
> {noformat}
> Starting Impala Shell with Kerberos authentication using Python 3.6.8
> Using service name 'impala'
> SSL is enabled. Impala server certificates will NOT be verified (set 
> --ca_cert to change)
> Error connecting: TTransportException, Could not start SASL: b'Error in 
> sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Failure: no 
> serverFQDN'
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IMPALA-13118) Removing explicit ascii encoding of kerberos_host_fqdn when -b/--kerberos_host_fqdn is used



[ 
https://issues.apache.org/jira/browse/IMPALA-13118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850796#comment-17850796
 ] 

Vincent Tran commented on IMPALA-13118:
---

This duplicates IMPALA-12552.

> Removing explicit ascii encoding of kerberos_host_fqdn when 
> -b/--kerberos_host_fqdn is used
> ---
>
> Key: IMPALA-13118
> URL: https://issues.apache.org/jira/browse/IMPALA-13118
> Project: IMPALA
>  Issue Type: Improvement
>  Components: Clients
>Affects Versions: Impala 4.4.0
>Reporter: Vincent Tran
>Assignee: Vincent Tran
>Priority: Major
>  Labels: Python3, impala-shell
>
> IMPALA-651 added an explicit encoding for sasl_host to ascii before passing 
> it to sasl_client.setAttr(). This is no longer required after sasl was 
> upgraded to 0.2.1 in IMPALA-9719.  This explicit encoding also causes an 
> error in Python 3 when -b is used:
> {noformat}
> Starting Impala Shell with Kerberos authentication using Python 3.6.8
> Using service name 'impala'
> SSL is enabled. Impala server certificates will NOT be verified (set 
> --ca_cert to change)
> Error connecting: TTransportException, Could not start SASL: b'Error in 
> sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Failure: no 
> serverFQDN'
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org

Re: timeout in shutdown, mutt killed by SIGKILL

On 2024-05-30 00:19:30 +0700, Max Nikulin wrote:
> On 29/05/2024 07:44, Vincent Lefevre wrote:
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> 
> Have you tried to send SIGTERM to mutt?

I didn't. AFAIK, systemd sends a SIGTERM to all the processes of the
session: that's the

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...

but this timed out, apparently due to the mutt process, which was
still running, so that systemd sent a SIGKILL (which succeeded).

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.

> If it ignores this signal or the reaction is some prompt then you
> need to find another way to stop mutt and to configure systemd user
> session to do it on logout (shutdown).

A SIGTERM normally kills mutt. In signal.c, signals are blocked
"while doing critical ops", namely for compressing/decompressing
(which I don't use) and when locking a mailbox (but I don't see
why this would have happened). Otherwise the signal handler just
does that:

static void exit_handler (int sig)
{
  curs_set (1);
  endwin (); /* just to be safe */

  exit_print_string (Caught_Signal_L10N ? Caught_Signal_L10N : "Caught signal 
");
#if SYS_SIGLIST_DECLARED
  exit_print_string (sys_siglist[sig]);
#else
#if (__sun__ && __svr4__)
  exit_print_string (_sys_siglist[sig]);
#else
#if (__alpha && __osf__)
  exit_print_string (__sys_siglist[sig]);
#else
  exit_print_int (sig);
#endif
#endif
#endif
  exit_print_string (Exiting_L10N ? Exiting_L10N : "...  Exiting.\n");
  exit (0);
}

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[jira] [Created] (IMPALA-13118) Removing explicit ascii encoding of kerberos_host_fqdn when -b/--kerberos_host_fqdn is used

Vincent Tran created IMPALA-13118:
-

 Summary: Removing explicit ascii encoding of kerberos_host_fqdn 
when -b/--kerberos_host_fqdn is used
 Key: IMPALA-13118
 URL: https://issues.apache.org/jira/browse/IMPALA-13118
 Project: IMPALA
  Issue Type: Improvement
  Components: Clients
Affects Versions: Impala 4.4.0
Reporter: Vincent Tran
Assignee: Vincent Tran


IMPALA-651 added an explicit encoding for sasl_host to ascii before passing it 
to sasl_client.setAttr(). This is no longer required after sasl was upgraded to 
0.2.1 in IMPALA-9719.  This explicit encoding also causes an error in Python 3 
when -b is used:

{noformat}
Starting Impala Shell with Kerberos authentication using Python 3.6.8
Using service name 'impala'
SSL is enabled. Impala server certificates will NOT be verified (set --ca_cert 
to change)
Error connecting: TTransportException, Could not start SASL: b'Error in 
sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Failure: no serverFQDN'
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org

[jira] [Created] (IMPALA-13118) Removing explicit ascii encoding of kerberos_host_fqdn when -b/--kerberos_host_fqdn is used

Vincent Tran created IMPALA-13118:
-

 Summary: Removing explicit ascii encoding of kerberos_host_fqdn 
when -b/--kerberos_host_fqdn is used
 Key: IMPALA-13118
 URL: https://issues.apache.org/jira/browse/IMPALA-13118
 Project: IMPALA
  Issue Type: Improvement
  Components: Clients
Affects Versions: Impala 4.4.0
Reporter: Vincent Tran
Assignee: Vincent Tran


IMPALA-651 added an explicit encoding for sasl_host to ascii before passing it 
to sasl_client.setAttr(). This is no longer required after sasl was upgraded to 
0.2.1 in IMPALA-9719.  This explicit encoding also causes an error in Python 3 
when -b is used:

{noformat}
Starting Impala Shell with Kerberos authentication using Python 3.6.8
Using service name 'impala'
SSL is enabled. Impala server certificates will NOT be verified (set --ca_cert 
to change)
Error connecting: TTransportException, Could not start SASL: b'Error in 
sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Failure: no serverFQDN'
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: timeout in shutdown, mutt killed by SIGKILL

On 2024-05-29 16:13:05 -, Curt wrote:
> On 2024-05-29, Vincent Lefevre  wrote:
> > During the latest shutdown:
> >
> > May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of 
> > User vinc17...
> > [...]
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. 
> > Killing.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 
> > (mutt) with signal SIGKILL.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 
> > 'timeout'.
> > May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
> > vinc17.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s 
> > CPU time.
> > May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User 
> > Login Management...
> > May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager 
> > for UID 1000...
> > [...]
> >
> > Note: I had set DefaultTimeoutStopSec=20s because then is normally
> > sufficient.
> >
> > The mutt process was running in GNU Screen. The current mailbox
> > was just a local one. Mutt does no network connections (I do not
> > use IMAP). I general, I quit it before logging out, but this time,
> > it seems that I forgot.
> >
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> >
> 
> sudo journalctl -b-1?

See above. There's nothing else about mutt in the journal.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[jenkinsci/aws-java-sdk-plugin] 34d042: Bump revision from 1.12.696 to 1.12.730

2024-05-30 Thread 'Vincent Latombe' via Jenkins Commits

  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/aws-java-sdk-plugin
  Commit: 34d042df94d7131f61f9d2689afd123cf5e4f7bd
  
https://github.com/jenkinsci/aws-java-sdk-plugin/commit/34d042df94d7131f61f9d2689afd123cf5e4f7bd
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2024-05-27 (Mon, 27 May 2024)

  Changed paths:
M pom.xml

  Log Message:
  ---
  Bump revision from 1.12.696 to 1.12.730

Bumps `revision` from 1.12.696 to 1.12.730.

Updates `com.amazonaws:aws-java-sdk-bom` from 1.12.696 to 1.12.730
- [Changelog](https://github.com/aws/aws-sdk-java/blob/master/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-java/compare/1.12.696...1.12.730)

Updates `com.amazonaws:aws-java-sdk` from 1.12.696 to 1.12.730
- [Changelog](https://github.com/aws/aws-sdk-java/blob/master/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-java/compare/1.12.696...1.12.730)

Updates `com.amazonaws:aws-java-sdk-s3` from 1.12.696 to 1.12.730
- [Changelog](https://github.com/aws/aws-sdk-java/blob/master/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-java/compare/1.12.696...1.12.730)

Updates `com.amazonaws:aws-java-sdk-sts` from 1.12.696 to 1.12.730
- [Changelog](https://github.com/aws/aws-sdk-java/blob/master/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-java/compare/1.12.696...1.12.730)

---
updated-dependencies:
- dependency-name: com.amazonaws:aws-java-sdk-bom
  dependency-type: direct:production
  update-type: version-update:semver-patch
- dependency-name: com.amazonaws:aws-java-sdk
  dependency-type: direct:production
  update-type: version-update:semver-patch
- dependency-name: com.amazonaws:aws-java-sdk-s3
  dependency-type: direct:production
  update-type: version-update:semver-patch
- dependency-name: com.amazonaws:aws-java-sdk-sts
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] 


  Commit: 3403b37d21706d95866019e16e0dc2749be5431e
  
https://github.com/jenkinsci/aws-java-sdk-plugin/commit/3403b37d21706d95866019e16e0dc2749be5431e
  Author: Vincent Latombe 
  Date:   2024-05-30 (Thu, 30 May 2024)

  Changed paths:
M pom.xml

  Log Message:
  ---
  Merge pull request #1248 from jenkinsci/dependabot/maven/revision-1.12.730


Compare: 
https://github.com/jenkinsci/aws-java-sdk-plugin/compare/c95c8a8145d8...3403b37d2170

To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/aws-java-sdk-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/aws-java-sdk-plugin/push/refs/heads/master/c95c8a-3403b3%40github.com.

[jenkinsci/aws-java-sdk-plugin] cb2ac3: Bump io.jenkins.tools.incrementals:git-changelist-...

2024-05-30 Thread 'Vincent Latombe' via Jenkins Commits

  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/aws-java-sdk-plugin
  Commit: cb2ac347d61169e98d8f0af04bbf3b24d946056c
  
https://github.com/jenkinsci/aws-java-sdk-plugin/commit/cb2ac347d61169e98d8f0af04bbf3b24d946056c
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2024-05-30 (Thu, 30 May 2024)

  Changed paths:
M .mvn/extensions.xml

  Log Message:
  ---
  Bump io.jenkins.tools.incrementals:git-changelist-maven-extension

Bumps 
[io.jenkins.tools.incrementals:git-changelist-maven-extension](https://github.com/jenkinsci/incrementals-tools)
 from 1.7 to 1.8.
- [Release notes](https://github.com/jenkinsci/incrementals-tools/releases)
- 
[Commits](https://github.com/jenkinsci/incrementals-tools/compare/parent-1.7...parent-1.8)

---
updated-dependencies:
- dependency-name: io.jenkins.tools.incrementals:git-changelist-maven-extension
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] 


  Commit: c95c8a8145d890e7b13d035024abba7a500e1a67
  
https://github.com/jenkinsci/aws-java-sdk-plugin/commit/c95c8a8145d890e7b13d035024abba7a500e1a67
  Author: Vincent Latombe 
  Date:   2024-05-30 (Thu, 30 May 2024)

  Changed paths:
M .mvn/extensions.xml

  Log Message:
  ---
  Merge pull request #1239 from 
jenkinsci/dependabot/maven/io.jenkins.tools.incrementals-git-changelist-maven-extension-1.8


Compare: 
https://github.com/jenkinsci/aws-java-sdk-plugin/compare/3e1146bcdd26...c95c8a8145d8

To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/aws-java-sdk-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/aws-java-sdk-plugin/push/refs/heads/master/3e1146-c95c8a%40github.com.

[jenkinsci/aws-java-sdk-plugin] 735e0e: Bump org.jenkins-ci.plugins:plugin from 4.80 to 4.82

2024-05-30 Thread 'Vincent Latombe' via Jenkins Commits

  Branch: refs/heads/master
  Home:   https://github.com/jenkinsci/aws-java-sdk-plugin
  Commit: 735e0e29e17f52964093e3edeab5931126767653
  
https://github.com/jenkinsci/aws-java-sdk-plugin/commit/735e0e29e17f52964093e3edeab5931126767653
  Author: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
  Date:   2024-05-06 (Mon, 06 May 2024)

  Changed paths:
M pom.xml

  Log Message:
  ---
  Bump org.jenkins-ci.plugins:plugin from 4.80 to 4.82

Bumps [org.jenkins-ci.plugins:plugin](https://github.com/jenkinsci/plugin-pom) 
from 4.80 to 4.82.
- [Release notes](https://github.com/jenkinsci/plugin-pom/releases)
- [Changelog](https://github.com/jenkinsci/plugin-pom/blob/master/CHANGELOG.md)
- 
[Commits](https://github.com/jenkinsci/plugin-pom/compare/plugin-4.80...plugin-4.82)

---
updated-dependencies:
- dependency-name: org.jenkins-ci.plugins:plugin
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] 


  Commit: 3e1146bcdd2699be98bcb57310589e3cc95c69cf
  
https://github.com/jenkinsci/aws-java-sdk-plugin/commit/3e1146bcdd2699be98bcb57310589e3cc95c69cf
  Author: Vincent Latombe 
  Date:   2024-05-30 (Thu, 30 May 2024)

  Changed paths:
M pom.xml

  Log Message:
  ---
  Merge pull request #1244 from 
jenkinsci/dependabot/maven/org.jenkins-ci.plugins-plugin-4.82


Compare: 
https://github.com/jenkinsci/aws-java-sdk-plugin/compare/0651ada9caec...3e1146bcdd26

To unsubscribe from these emails, change your notification settings at 
https://github.com/jenkinsci/aws-java-sdk-plugin/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/aws-java-sdk-plugin/push/refs/heads/master/0651ad-3e1146%40github.com.

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> For last(1) my concern is that it will be helped to keep the original
> last(1) for back-compatibility to read old wtmp files.

I agree, this may be useful. Unfortunately, the current status is
that one cannot have both: installing wtmpdb forces the upgrade of
util-linux to 2.40.1-3 (at least), where "last" is no longer installed.

However, I think that it is better to archive human-readable text files
(generated by "last" in the past) rather than the wtmp files.

I've used the attached script to get both the IP addresses and the
host names with "last" (I don't know whether there's a better way to
get full information).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
#!/usr/bin/env perl

# Output wtmp logs, based on command 'last' from util-linux.
# This command is called twice:
#   1. without the -d option;
#   2. with the -d option to get the host names.

use strict;

my ($proc) = '$Id: lastf 103313 2017-11-06 01:47:30Z vinc17/joooj $'
  =~ /^.Id: (\S+) \d+ / or die;

@ARGV == 1 or $! = 1, die "Usage: $proc \n";
-f $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a regular file\n";
-r $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a readable file\n";

sub rdlog ($@)
  {
my $file = shift;
open LAST, '-|', 'last', @_, '-axf', $file
  or die "$proc: can't exec 'last': $!";
my @t = ;
close LAST, or die "$proc: 'last' failed: $!";
$t[-1] =~ / begins / && $t[-2] eq "\n"
  or $! = 2, die "$proc: bad format";
return @t;
  }

my @t1 = rdlog $ARGV[0];
my @t2 = rdlog $ARGV[0], '-d';
$#t1 == $#t2 or $! = 1, die "$proc: bad length ($#t1 vs $#t2)\n";
$t1[-1] eq $t2[-1] or die $! = 1, die "$proc: inconsistent last line\n";

foreach my $i (0..$#t1-2)
  {
$_ = $t1[$i];
chomp;
my ($u1) = /^(.){60}/
  or $! = 2, die "$proc: bad format";
my ($u2,$v2) = $t2[$i] =~ /^(.){60}(.*)$/
  or $! = 2, die "$proc: bad format";
$u1 eq $u2 or $! = 2, die "$proc: bad format";
$v2 eq '0.0.0.0' or $_ .= " ($v2)";
print "$_\n";
  }

print "\n$t1[-1]";

Bug#1068017: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> For last(1) my concern is that it will be helped to keep the original
> last(1) for back-compatibility to read old wtmp files.

I agree, this may be useful. Unfortunately, the current status is
that one cannot have both: installing wtmpdb forces the upgrade of
util-linux to 2.40.1-3 (at least), where "last" is no longer installed.

However, I think that it is better to archive human-readable text files
(generated by "last" in the past) rather than the wtmp files.

I've used the attached script to get both the IP addresses and the
host names with "last" (I don't know whether there's a better way to
get full information).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
#!/usr/bin/env perl

# Output wtmp logs, based on command 'last' from util-linux.
# This command is called twice:
#   1. without the -d option;
#   2. with the -d option to get the host names.

use strict;

my ($proc) = '$Id: lastf 103313 2017-11-06 01:47:30Z vinc17/joooj $'
  =~ /^.Id: (\S+) \d+ / or die;

@ARGV == 1 or $! = 1, die "Usage: $proc \n";
-f $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a regular file\n";
-r $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a readable file\n";

sub rdlog ($@)
  {
my $file = shift;
open LAST, '-|', 'last', @_, '-axf', $file
  or die "$proc: can't exec 'last': $!";
my @t = ;
close LAST, or die "$proc: 'last' failed: $!";
$t[-1] =~ / begins / && $t[-2] eq "\n"
  or $! = 2, die "$proc: bad format";
return @t;
  }

my @t1 = rdlog $ARGV[0];
my @t2 = rdlog $ARGV[0], '-d';
$#t1 == $#t2 or $! = 1, die "$proc: bad length ($#t1 vs $#t2)\n";
$t1[-1] eq $t2[-1] or die $! = 1, die "$proc: inconsistent last line\n";

foreach my $i (0..$#t1-2)
  {
$_ = $t1[$i];
chomp;
my ($u1) = /^(.){60}/
  or $! = 2, die "$proc: bad format";
my ($u2,$v2) = $t2[$i] =~ /^(.){60}(.*)$/
  or $! = 2, die "$proc: bad format";
$u1 eq $u2 or $! = 2, die "$proc: bad format";
$v2 eq '0.0.0.0' or $_ .= " ($v2)";
print "$_\n";
  }

print "\n$t1[-1]";

Re: Y2038-safe replacements for utmp/wtmp and lastlog

On 2024-05-08 16:53:53 +0800, Jun MO wrote:
> For last(1) my concern is that it will be helped to keep the original
> last(1) for back-compatibility to read old wtmp files.

I agree, this may be useful. Unfortunately, the current status is
that one cannot have both: installing wtmpdb forces the upgrade of
util-linux to 2.40.1-3 (at least), where "last" is no longer installed.

However, I think that it is better to archive human-readable text files
(generated by "last" in the past) rather than the wtmp files.

I've used the attached script to get both the IP addresses and the
host names with "last" (I don't know whether there's a better way to
get full information).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
#!/usr/bin/env perl

# Output wtmp logs, based on command 'last' from util-linux.
# This command is called twice:
#   1. without the -d option;
#   2. with the -d option to get the host names.

use strict;

my ($proc) = '$Id: lastf 103313 2017-11-06 01:47:30Z vinc17/joooj $'
  =~ /^.Id: (\S+) \d+ / or die;

@ARGV == 1 or $! = 1, die "Usage: $proc \n";
-f $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a regular file\n";
-r $ARGV[0] or $! = 1, die "$proc: $ARGV[0] is not a readable file\n";

sub rdlog ($@)
  {
my $file = shift;
open LAST, '-|', 'last', @_, '-axf', $file
  or die "$proc: can't exec 'last': $!";
my @t = ;
close LAST, or die "$proc: 'last' failed: $!";
$t[-1] =~ / begins / && $t[-2] eq "\n"
  or $! = 2, die "$proc: bad format";
return @t;
  }

my @t1 = rdlog $ARGV[0];
my @t2 = rdlog $ARGV[0], '-d';
$#t1 == $#t2 or $! = 1, die "$proc: bad length ($#t1 vs $#t2)\n";
$t1[-1] eq $t2[-1] or die $! = 1, die "$proc: inconsistent last line\n";

foreach my $i (0..$#t1-2)
  {
$_ = $t1[$i];
chomp;
my ($u1) = /^(.){60}/
  or $! = 2, die "$proc: bad format";
my ($u2,$v2) = $t2[$i] =~ /^(.){60}(.*)$/
  or $! = 2, die "$proc: bad format";
$u1 eq $u2 or $! = 2, die "$proc: bad format";
$v2 eq '0.0.0.0' or $_ .= " ($v2)";
print "$_\n";
  }

print "\n$t1[-1]";

RE: [PHP-DEV] [RFC] Asymmetric Visibility, v2

2024-05-30 Thread Vincent de Lau

> -Original Message-
> From: Larry Garfield 
> Sent: Wednesday, May 29, 2024 10:03 PM
> 
> On Wed, May 29, 2024, at 7:53 PM, Andreas Hennings wrote:
> > Hello Larry,
> > just a quick thought.
> > Is there a reason why we cannot just make it "public private string
> > $x" instead of "public private(set) string $x"?
> > We would define that the second visibility specifier is for write.
> >
> > The current proposal with "public private(set)" is less ambiguous, and
> > it is immediately obvious that this is something new, and not just
> > somebody accidentally added two modifiers.
> > At the same time, it feels a bit alien and cluttered.
> >
> > Other options could be something like "public:private" or "public-
> private".
> >
> > A consequence of such options would be that you always need to specify
> > the read visibility along with the write visibility.
> > But this seems ok to me.
> >
> > This is not a final opinion, just a thought.

> We went through a bunch of syntax variations last year, including "public
> private", "public:private", and "public private:set", plus a few others.
> In an RCV poll, public private(set) was the favorite. (See link at the end
> of the RFC.)  It also allows for extension to other operations and scopes,
> and for the short-hand syntax.  Many of the other options did not support
> those.  Thus we stuck with the known syntax that had the most flexibility
> and most support.

Would it make sense to do another RCV poll now that hooks are accepted, after 
lengthy discussion over its syntax? 

Personally, I would prefer the HookEmbeddedStyle form. I don't think the 
argument that the visibility would potentially be separated from the hook 
definition is very strong, as you would have to scan for the existence of the 
hook anyway. For me, asymmetric visibility and property hooks are mentally more 
related than the RFC technically defines them to be.

Furthermore, I see a lot of reasoning in favour of the prefix syntax in 
relation to limitations of other language constructs like property promotion. 
While I don't think it is fair to expect this RFC should fix those, to me it 
feels we are compounding 'errors'.

Thanks to both you and Ilija for all the hard work on these RFC's, it is much 
appreciated!

--
Vincent de Lau

Re: [oe] [PATCH 18/23] mongodb: skip until python 3.12 fixes are available.

2024-05-30 Thread Vincent Prince

Hello

It seems to compile with this patch

diff --git a/buildscripts/moduleconfig.py b/buildscripts/moduleconfig.py
index b4d0bba0490..73c0f1a03fa 100644
--- a/buildscripts/moduleconfig.py
+++ b/buildscripts/moduleconfig.py
@@ -27,7 +27,7 @@ MongoDB SConscript files do.
__all__ = ('discover_modules', 'discover_module_directories', 
'configure_modules',
'register_module_test')  # pylint: disable=undefined-all-variable

-import imp
+import importlib
import inspect
import os

@@ -71,7 +71,7 @@ def discover_modules(module_root, allowed_modules):
print("adding module: %s" % (name))
fp = open(build_py, "r")
try:
-                module = imp.load_module("module_" + name, fp, build_py,
+                module = importlib.import_module("module_" + name, fp, 
build_py,
(".py", "r", imp.PY_SOURCE))
if getattr(module, "name", None) is None:
module.name = name
--
2.34.1

I'm not that confident about it but if it helps :)

Best regards,

Vincent

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#110624): 
https://lists.openembedded.org/g/openembedded-devel/message/110624
Mute This Topic: https://lists.openembedded.org/mt/103445578/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Uninstalling a package and its entourage

On 2024-05-27 18:42:48 +0300, mindaugascelies...@gmail.com wrote:
> On Monday, May 27, 2024 5:59:55 PM EEST Nicolas George wrote:
> > Eben King (12024-05-27):
> > > Is there an easier way to uninstall a package and everything it brought in
> > > at one swell foop?  Thanks.
> > 
> > The packages you did not choose to install but were installed as a
> > consequence are shown by apt-get when you do almost anything:
> > 
> > The following packages were automatically installed and are no longer
> > required: 
> > 
> > Regards,
> Hello.
> 
> You can use one simple command: sudo apt autoremove --purge

For various reasons, this may leave automatically installed packages
behind.

First, for symmetry with "apt install", you would need

APT::AutoRemove::SuggestsImportant "false";

Still, a package could have been automatically installed due to a
dependency, but it may be in another OR dependency, in which case
apt will not propose its removal, even though the OR dependency
would still be satisfied.

So, you should either look at the logs or keep trace of the packages
that are installed before installation of new packages.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

timeout in shutdown, mutt killed by SIGKILL

During the latest shutdown:

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...
[...]
May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager for 
UID 1000...
[...]

Note: I had set DefaultTimeoutStopSec=20s because then is normally
sufficient.

The mutt process was running in GNU Screen. The current mailbox
was just a local one. Mutt does no network connections (I do not
use IMAP). I general, I quit it before logging out, but this time,
it seems that I forgot.

But I don't understand why there was a timeout. Does this mean that
mutt didn't react to SIGTERM? Any reason?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[RE-wrenches] Discover AES explosion

2024-05-28 Thread Vincent Jolissaint via RE-wrenches

Michael, it is super scary to hear these stories and they are a good
reminder that Li-ion technology still has risks. I am glad the manufacturer
is taking care of you, but it is concerning to see that the battery safety
systems allowed the thermal runaway event.

Hopefully, the fire department coded the incident response correctly, so
the powers that be can understand this was a li-ion thermal event from a
home energy storage system.

As more and more ESS systems enter the market, getting a recent UL 9540
listing is important. The earlier versions of the standard were less
robust, but the current edition of 9540 requires UL 9540A testing to be
performed for indoor installations to establish minimum room size based on
25% LFL.

It looks like there will soon be a UL 9540B requirement, and the outline of
investigation is just circulating. I see one Discover datasheet shows UL
9540 listing, but I didn't do research into what edition they tested to, or
if this was the same unit that exploded.

The issue with the 9540A thermal runaway testing is it might not have
tested for this failure mode, but the conditions you describe are very
similar to what 9540B intends to test.

I know many feel LFP is a safer battery than NMC or other li-ion
chemistries, but these events show that the LFP batteries do fail, and when
they do, they can cause large sudden deflagration events without other
warning. An NMC battery pack buy contrast will usually fail by burning
until it is consumed, which might at least set off a smoke or heat
detector.

Were there any fire detection measures in the shed such as a heat or smoke
detector?


*Vince Jolissaint |* *Director of CAD Services*

2557 Wyandotte Street | Mountain View, CA  94043
Office: 650.938.9574 | Email: vince...@cobaltpower.com






>
> Date: Mon, 27 May 2024 20:40:00 -0700
> From: Michael Morningstar 
> To: RE-wrenches 
> Subject: [RE-wrenches] Discover AES exposion
> Message-ID:
> <
> capwhfaegnz5vjmkflffea6my+cdjqde-uuabg1_mdyuilob...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey Everybody,
>
> I wanted to circle back on the Discover AES explosion that I reported a few
> weeks ago. As far as we know, there was a thermal runaway situation. Gas
> from the battery filled the power room and then ignited causing an
> explosion. It was hot enough that anything plastic melted. The steel man
> door blew off its hinges. Beyond that, we are still trying to figure out
> why it happened.
>
> For now, what I want to say is that Discover has been awesome. The VP, CEO
> and crew responded immediately. They are paying for the cleanup of the
> building by a specialized remediation company, offered to pay to have the
> building rebuilt, 2nd day shipped new rack mount batteries and a pre-built
> Schneider system to the site. Are paying a plumbing contractor to replace
> all of the plumbing (booster pump, pressure tank and significant treatment
> equipment. Flying Mike Wight (ace off-grid installer and
> applications engineer for Discover) to the site for the rebuild. And
> reimbursing me for my involvement. This with no coercion or dawdling about.
> As soon as they found out, they were on it. I spoke with the VP and CEO and
> they genuinely care about my clients and want to do right for the sake of
> doing right, not to avoid litigation. Tell me of another RE company, or any
> company for that matter that would respond this way.
>
> --
>
> Michael Morningstar
>
>
> Morningstar Electric Inc
>
> PO Box 1494
>
> Mount Shasta, CA 96067
>
> 530-921-0560
>
> CSLB 1116835
>
> mjmornings...@gmail.com
>
>
___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try the other:
https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org

Bug#978607: Please drop empty /etc/udev/udev.conf

On 2020-12-28 23:29:12 -0800, Josh Triplett wrote:
> The systemd family of packages has generally tried to minimize the
> number of files in /etc, in favor of files in /usr.
> 
> /etc/udev/udev.conf contains nothing but comments. Please consider
> dropping it (when unmodified).

I've always found such files useful for the user who wishes to
change the default configuration. This may be more visible than
the man page.

BTW, this file also provides documentation that is not present
in the man page:

# udevd is also started in the initrd.  When this file is modified you might
# also want to rebuild the initrd, so that it will include the modified 
configuration.

while there's nothing about initrd in the udev.conf(5) man page.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#978607: Please drop empty /etc/udev/udev.conf

On 2020-12-28 23:29:12 -0800, Josh Triplett wrote:
> The systemd family of packages has generally tried to minimize the
> number of files in /etc, in favor of files in /usr.
> 
> /etc/udev/udev.conf contains nothing but comments. Please consider
> dropping it (when unmodified).

I've always found such files useful for the user who wishes to
change the default configuration. This may be more visible than
the man page.

BTW, this file also provides documentation that is not present
in the man page:

# udevd is also started in the initrd.  When this file is modified you might
# also want to rebuild the initrd, so that it will include the modified 
configuration.

while there's nothing about initrd in the udev.conf(5) man page.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1072063: linux-image-6.8.11-amd64: one of the external monitors randomly blank for 2-3 seconds with 6.8 kernels

2024-05-27 Thread Vincent Lefevre

ll dock
Bus 001 Device 012: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO)
Bus 001 Device 013: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 8087:0b40 Intel Corp. USB3.0 Hub
Bus 004 Device 003: ID 0bda:0487 Realtek Semiconductor Corp. Dell dock
Bus 004 Device 004: ID 0bda:0413 Realtek Semiconductor Corp. Dell dock
Bus 004 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit 
Ethernet Adapter


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

Kernel: Linux 6.8.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 linux-image-6.8.11-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod32+20240327-1
ii  linux-base  4.9

Versions of packages linux-image-6.8.11-amd64 recommends:
ii  apparmor  3.0.13-2

Versions of packages linux-image-6.8.11-amd64 suggests:
pn  debian-kernel-handbook  
ii  firmware-linux-free 20200122-4
ii  grub-efi-amd64  2.12-2
ii  linux-doc-6.8   6.8.11-1

Versions of packages linux-image-6.8.11-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20230625-2
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20230625-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano        
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1072063: linux-image-6.8.11-amd64: one of the external monitors randomly blank for 2-3 seconds with 6.8 kernels

2024-05-27 Thread Vincent Lefevre

ll dock
Bus 001 Device 012: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO)
Bus 001 Device 013: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 8087:0b40 Intel Corp. USB3.0 Hub
Bus 004 Device 003: ID 0bda:0487 Realtek Semiconductor Corp. Dell dock
Bus 004 Device 004: ID 0bda:0413 Realtek Semiconductor Corp. Dell dock
Bus 004 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit 
Ethernet Adapter


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

Kernel: Linux 6.8.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 linux-image-6.8.11-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod32+20240327-1
ii  linux-base  4.9

Versions of packages linux-image-6.8.11-amd64 recommends:
ii  apparmor  3.0.13-2

Versions of packages linux-image-6.8.11-amd64 suggests:
pn  debian-kernel-handbook  
ii  firmware-linux-free 20200122-4
ii  grub-efi-amd64  2.12-2
ii  linux-doc-6.8   6.8.11-1

Versions of packages linux-image-6.8.11-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20230625-2
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20230625-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano        
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[graoulug-libre] Convocation Assemblée Générale du Graoulug

2024-05-27 Thread Vincent MERLET via libre


Bonjour,

Nous avons le plaisir de vous convoquer à la prochaine assemblée 
générale du Graoulug :


Date : Samedi 29 juin 2024 à partir de 9h30
Lieu : "Oui, vivre en Outre-Seille !"
60 rue des Allemands
57000 METZ

Voici l'ordre du jour :

Assemblée Générale Ordinaire (AGO)
- approbation du rapport moral
- modification du bureau
- approbation du rapport financier
- proposition/approbation du nouveau règlement intérieur
- événements à venir

Assemblée Générale Extraordinaire (AGE)
- modification de l'adresse légale du siège
- modifications des statuts

Tout membre à jour de cotisation, peut demander à ajouter un sujet à 
l'ordre du jour jusqu'au 22 juin 2024.


Suivant les statuts actuels, chaque membre à jour de cotisation et qui 
serait absent, peut donner procuration à un autre membre à jour de 
cotisation. Chaque membre ne peut détenir plus de quatre procurations 
(mandats).


À l’issue des assemblées générales, nous continuerons par une permanence 
habituelle.


À bientôt.

Librement,

--
Vincent MERLET
Président du GRAOULUG
___
libre mailing list
libre@graoulug.org
https://brassens.heberge.info/cgi-bin/mailman/listinfo/libre

Re: [VOTE] Airflow Providers prepared on May 26, 2024

2024-05-27 Thread Vincent Beck

+1 non binding. All AWS system tests are running successfully against 
apache-airflow-providers-amazon==8.23.0rc1. You can see the results here: 
https://aws-mwaa.github.io/#/open-source/system-tests/version/98c5a3a2c6d1df722d56bb3748dfbc810d5952aa_8.23.0rc1.html

On 2024/05/27 14:01:48 Rahul Vats wrote:
> -1 (non-binding) for cncf-kubernetes-provider. Our example DAGs are failing
> due to an unexpected argument 'pod' in the read_namespaced_pod_log call.
> Thanks to Wei for raising the fix PR
> .
> 
> Regards,
> Rahul Vats
> 9953794332
> 
> 
> On Mon, 27 May 2024 at 01:31, Jarek Potiuk  wrote:
> 
> > +1 (binding) - checked reproducibility, checksums, licences. signatures.
> > Checked my changes.
> >
> > On Sun, May 26, 2024 at 11:03 AM Elad Kalif  wrote:
> >
> > > Hey all,
> > >
> > > I have just cut the new wave Airflow Providers packages. This email is
> > > calling a vote on the release, which will last for 72 hours - which means
> > > that it will end on May 29, 2024 09:00 AM UTC and until 3 binding +1
> > votes
> > > have been received.
> > >
> > > Consider this my (binding) +1.
> > >
> > > Airflow Providers are available at:
> > > https://dist.apache.org/repos/dist/dev/airflow/providers/
> > >
> > > *apache-airflow-providers--*.tar.gz* are the binary
> > >  Python "sdist" release - they are also official "sources" for the
> > provider
> > > packages.
> > >
> > > *apache_airflow_providers_-*.whl are the binary
> > >  Python "wheel" release.
> > >
> > > The test procedure for PMC members is described in
> > >
> > >
> > https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-candidate-by-pmc-members
> > >
> > > The test procedure for and Contributors who would like to test this RC is
> > > described in:
> > >
> > >
> > https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-candidate-by-contributors
> > >
> > >
> > > Public keys are available at:
> > > https://dist.apache.org/repos/dist/release/airflow/KEYS
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > Only votes from PMC members are binding, but members of the community are
> > > encouraged to test the release and vote with "(non-binding)".
> > >
> > > Please note that the version number excludes the 'rcX' string.
> > > This will allow us to rename the artifact without modifying
> > > the artifact checksums when we actually release.
> > >
> > > The status of testing the providers by the community is kept here:
> > > https://github.com/apache/airflow/issues/39842
> > >
> > > The issue is also the easiest way to see important PRs included in the RC
> > > candidates.
> > > Detailed changelog for the providers will be published in the
> > documentation
> > > after the
> > > RC candidates are released.
> > >
> > > You can find the RC packages in PyPI following these links:
> > >
> > > https://pypi.org/project/apache-airflow-providers-airbyte/3.8.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-alibaba/2.8.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-amazon/8.23.0rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-beam/5.7.1rc1/
> > >
> > >
> > https://pypi.org/project/apache-airflow-providers-apache-cassandra/3.5.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-drill/2.7.1rc1/
> > >
> > https://pypi.org/project/apache-airflow-providers-apache-druid/3.10.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-flink/1.4.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-hdfs/4.4.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-hive/8.1.1rc1/
> > >
> > https://pypi.org/project/apache-airflow-providers-apache-impala/1.4.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-kafka/1.4.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-kylin/3.6.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-livy/3.8.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-pig/4.4.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-pinot/4.4.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apache-spark/4.8.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-apprise/1.3.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-arangodb/2.5.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-asana/2.5.1rc1/
> > >
> > https://pypi.org/project/apache-airflow-providers-atlassian-jira/2.6.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-celery/3.7.1rc1/
> > > https://pypi.org/project/apache-airflow-providers-cloudant/3.5.1rc1/
> > >
> > https://pypi.org/project/apache-airflow-providers-cncf-kubernetes/8.3.0rc1/
> > > https://pypi.org/project/apache-airflow-providers-cohere/1.2.1rc1/
> > >

[PATCH 0/2] block: allow commit to unmap zero blocks

This patch series adds support for zero blocks in non-active commits.
The first patch in the series contains the actual changes to the commit
code, the second patch adds a test for the new functionality.

Vincent Vanlaer (2):
  block: allow commit to unmap zero blocks
  block: add test non-active commit with zeroed data

 block/commit.c | 71 ++--
 tests/qemu-iotests/315 | 95 ++
 tests/qemu-iotests/315.out | 54 ++
 3 files changed, 207 insertions(+), 13 deletions(-)
 create mode 100755 tests/qemu-iotests/315
 create mode 100644 tests/qemu-iotests/315.out

-- 
2.42.0

[PATCH 1/2] block: allow commit to unmap zero blocks

Non-active block commits do not discard blocks only containing zeros,
causing images to lose sparseness after the commit. This commit fixes
that by writing zero blocks using blk_co_pwrite_zeroes rather than
writing them out as any oother arbitrary data.

Signed-off-by: Vincent Vanlaer 
---
 block/commit.c | 71 +-
 1 file changed, 58 insertions(+), 13 deletions(-)

diff --git a/block/commit.c b/block/commit.c
index 7c3fdcb0ca..5bd97b5a74 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -12,9 +12,13 @@
  *
  */
 
+#include "bits/time.h"
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
+#include "time.h"
 #include "trace.h"
+#include "block/block-common.h"
+#include "block/coroutines.h"
 #include "block/block_int.h"
 #include "block/blockjob_int.h"
 #include "qapi/error.h"
@@ -126,6 +130,12 @@ static void commit_clean(Job *job)
 blk_unref(s->top);
 }
 
+typedef enum CommitMethod {
+COMMIT_METHOD_COPY,
+COMMIT_METHOD_ZERO,
+COMMIT_METHOD_IGNORE,
+} CommitMethod;
+
 static int coroutine_fn commit_run(Job *job, Error **errp)
 {
 CommitBlockJob *s = container_of(job, CommitBlockJob, common.job);
@@ -156,8 +166,9 @@ static int coroutine_fn commit_run(Job *job, Error **errp)
 buf = blk_blockalign(s->top, COMMIT_BUFFER_SIZE);
 
 for (offset = 0; offset < len; offset += n) {
-bool copy;
 bool error_in_source = true;
+CommitMethod commit_method = COMMIT_METHOD_COPY;
+
 
 /* Note that even when no rate limit is applied we need to yield
  * with no pending I/O here so that bdrv_drain_all() returns.
@@ -167,21 +178,54 @@ static int coroutine_fn commit_run(Job *job, Error **errp)
 break;
 }
 /* Copy if allocated above the base */
-ret = blk_co_is_allocated_above(s->top, s->base_overlay, true,
-offset, COMMIT_BUFFER_SIZE, );
-copy = (ret > 0);
+WITH_GRAPH_RDLOCK_GUARD() {
+ret = bdrv_co_common_block_status_above(blk_bs(s->top),
+s->base_overlay, true, true, offset, COMMIT_BUFFER_SIZE,
+, NULL, NULL, NULL);
+}
+
 trace_commit_one_iteration(s, offset, n, ret);
-if (copy) {
-assert(n < SIZE_MAX);
-
-ret = blk_co_pread(s->top, offset, n, buf, 0);
-if (ret >= 0) {
-ret = blk_co_pwrite(s->base, offset, n, buf, 0);
-if (ret < 0) {
-error_in_source = false;
+
+if (ret >= 0 && !(ret & BDRV_BLOCK_ALLOCATED)) {
+commit_method = COMMIT_METHOD_IGNORE;
+} else if (ret >= 0 && ret & BDRV_BLOCK_ZERO) {
+int64_t target_offset;
+int64_t target_bytes;
+WITH_GRAPH_RDLOCK_GUARD() {
+bdrv_round_to_subclusters(s->base_bs, offset, n,
+   _offset, _bytes);
+}
+
+if (target_offset == offset &&
+target_bytes == n) {
+commit_method = COMMIT_METHOD_ZERO;
+}
+}
+
+if (ret >= 0) {
+switch (commit_method) {
+case COMMIT_METHOD_COPY:
+assert(n < SIZE_MAX);
+ret = blk_co_pread(s->top, offset, n, buf, 0);
+if (ret >= 0) {
+ret = blk_co_pwrite(s->base, offset, n, buf, 0);
+if (ret < 0) {
+error_in_source = false;
+}
 }
+break;
+case COMMIT_METHOD_ZERO:
+ret = blk_co_pwrite_zeroes(s->base, offset, n,
+BDRV_REQ_MAY_UNMAP);
+error_in_source = false;
+break;
+case COMMIT_METHOD_IGNORE:
+break;
+default:
+abort();
 }
 }
+
 if (ret < 0) {
 BlockErrorAction action =
 block_job_error_action(>common, s->on_error,
@@ -193,10 +237,11 @@ static int coroutine_fn commit_run(Job *job, Error **errp)
 continue;
 }
 }
+
 /* Publish progress */
 job_progress_update(>common.job, n);
 
-if (copy) {
+if (commit_method == COMMIT_METHOD_COPY) {
 block_job_ratelimit_processed_bytes(>common, n);
 }
 }
-- 
2.42.0

[PATCH 2/2] block: add test non-active commit with zeroed data

Signed-off-by: Vincent Vanlaer 
---
 tests/qemu-iotests/315 | 95 ++
 tests/qemu-iotests/315.out | 54 ++
 2 files changed, 149 insertions(+)
 create mode 100755 tests/qemu-iotests/315
 create mode 100644 tests/qemu-iotests/315.out

diff --git a/tests/qemu-iotests/315 b/tests/qemu-iotests/315
new file mode 100755
index 00..84865f8001
--- /dev/null
+++ b/tests/qemu-iotests/315
@@ -0,0 +1,95 @@
+#!/usr/bin/env bash
+# group: rw quick
+#
+# Test for commit of discarded blocks
+#
+# This tests committing a live snapshot where some of the blocks that
+# are present in the base image are discarded in the intermediate image.
+# This intends to check that these blocks are also discarded in the base
+# image after the commit.
+#
+# Copyright (C) 2024 Vincent Vanlaer.
+#
+# This program 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 2 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 <http://www.gnu.org/licenses/>.
+#
+# creator
+owner=libvirt-e6954...@volkihar.be
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+_cleanup_qemu
+_rm_test_img "${TEST_IMG}.base"
+_rm_test_img "${TEST_IMG}.mid"
+_cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+. ./common.qemu
+
+_supported_fmt qcow2
+_supported_proto file
+
+size="1M"
+
+TEST_IMG="$TEST_IMG.base" _make_test_img $size
+TEST_IMG="$TEST_IMG.mid" _make_test_img -b "$TEST_IMG.base" -F $IMGFMT $size
+_make_test_img -b "${TEST_IMG}.mid" -F $IMGFMT $size
+
+$QEMU_IO -c "write -P 0x01 64k 128k" "$TEST_IMG.base" | _filter_qemu_io
+$QEMU_IO -c "discard 64k 64k" "$TEST_IMG.mid" | _filter_qemu_io
+
+echo
+echo "=== Base image info before commit ==="
+TEST_IMG="${TEST_IMG}.base" _img_info | _filter_img_info
+$QEMU_IMG map --output=json "$TEST_IMG.base" | _filter_qemu_img_map
+
+echo
+echo "=== Middle image info before commit ==="
+TEST_IMG="${TEST_IMG}.mid" _img_info | _filter_img_info
+$QEMU_IMG map --output=json "$TEST_IMG.mid" | _filter_qemu_img_map
+
+echo
+echo === Running QEMU Live Commit Test ===
+echo
+
+qemu_comm_method="qmp"
+_launch_qemu -drive file="${TEST_IMG}",if=virtio,id=test
+h=$QEMU_HANDLE
+
+_send_qemu_cmd $h "{ 'execute': 'qmp_capabilities' }" "return"
+
+_send_qemu_cmd $h "{ 'execute': 'block-commit',
+ 'arguments': { 'device': 'test',
+ 'top': '"${TEST_IMG}.mid"',
+ 'base': '"${TEST_IMG}.base"'} }" '"status": 
"null"'
+
+_cleanup_qemu
+
+echo
+echo "=== Base image info after commit ==="
+TEST_IMG="${TEST_IMG}.base" _img_info | _filter_img_info
+$QEMU_IMG map --output=json "$TEST_IMG.base" | _filter_qemu_img_map
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/315.out b/tests/qemu-iotests/315.out
new file mode 100644
index 00..146ec117fb
--- /dev/null
+++ b/tests/qemu-iotests/315.out
@@ -0,0 +1,54 @@
+QA output created by 315
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=1048576
+Formatting 'TEST_DIR/t.IMGFMT.mid', fmt=IMGFMT size=1048576 
backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 
backing_file=TEST_DIR/t.IMGFMT.mid backing_fmt=IMGFMT
+wrote 131072/131072 bytes at offset 65536
+128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+discard 65536/65536 bytes at offset 65536
+64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+=== Base image info before commit ===
+image: TEST_DIR/t.IMGFMT.base
+file format: IMGFMT
+virtual size: 1 MiB (1048576 bytes)
+[{ "start": 0, "length": 65536, "depth": 0, "present": false, "zero": true, 
"data": false, "compressed": false},
+{ "start": 65536, "length": 131072, "depth": 0, "present": true, "zero": 
false, "data": true, "compressed": false, "offset": OFFSET},
+{ "start": 19660

[PATCH 2/2] block: add test non-active commit with zeroed data

Signed-off-by: Vincent Vanlaer 
---
 tests/qemu-iotests/315 | 95 ++
 tests/qemu-iotests/315.out | 54 ++
 2 files changed, 149 insertions(+)
 create mode 100755 tests/qemu-iotests/315
 create mode 100644 tests/qemu-iotests/315.out

diff --git a/tests/qemu-iotests/315 b/tests/qemu-iotests/315
new file mode 100755
index 00..84865f8001
--- /dev/null
+++ b/tests/qemu-iotests/315
@@ -0,0 +1,95 @@
+#!/usr/bin/env bash
+# group: rw quick
+#
+# Test for commit of discarded blocks
+#
+# This tests committing a live snapshot where some of the blocks that
+# are present in the base image are discarded in the intermediate image.
+# This intends to check that these blocks are also discarded in the base
+# image after the commit.
+#
+# Copyright (C) 2024 Vincent Vanlaer.
+#
+# This program 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 2 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 <http://www.gnu.org/licenses/>.
+#
+# creator
+owner=libvirt-e6954...@volkihar.be
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+_cleanup_qemu
+_rm_test_img "${TEST_IMG}.base"
+_rm_test_img "${TEST_IMG}.mid"
+_cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+. ./common.qemu
+
+_supported_fmt qcow2
+_supported_proto file
+
+size="1M"
+
+TEST_IMG="$TEST_IMG.base" _make_test_img $size
+TEST_IMG="$TEST_IMG.mid" _make_test_img -b "$TEST_IMG.base" -F $IMGFMT $size
+_make_test_img -b "${TEST_IMG}.mid" -F $IMGFMT $size
+
+$QEMU_IO -c "write -P 0x01 64k 128k" "$TEST_IMG.base" | _filter_qemu_io
+$QEMU_IO -c "discard 64k 64k" "$TEST_IMG.mid" | _filter_qemu_io
+
+echo
+echo "=== Base image info before commit ==="
+TEST_IMG="${TEST_IMG}.base" _img_info | _filter_img_info
+$QEMU_IMG map --output=json "$TEST_IMG.base" | _filter_qemu_img_map
+
+echo
+echo "=== Middle image info before commit ==="
+TEST_IMG="${TEST_IMG}.mid" _img_info | _filter_img_info
+$QEMU_IMG map --output=json "$TEST_IMG.mid" | _filter_qemu_img_map
+
+echo
+echo === Running QEMU Live Commit Test ===
+echo
+
+qemu_comm_method="qmp"
+_launch_qemu -drive file="${TEST_IMG}",if=virtio,id=test
+h=$QEMU_HANDLE
+
+_send_qemu_cmd $h "{ 'execute': 'qmp_capabilities' }" "return"
+
+_send_qemu_cmd $h "{ 'execute': 'block-commit',
+ 'arguments': { 'device': 'test',
+ 'top': '"${TEST_IMG}.mid"',
+ 'base': '"${TEST_IMG}.base"'} }" '"status": 
"null"'
+
+_cleanup_qemu
+
+echo
+echo "=== Base image info after commit ==="
+TEST_IMG="${TEST_IMG}.base" _img_info | _filter_img_info
+$QEMU_IMG map --output=json "$TEST_IMG.base" | _filter_qemu_img_map
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/315.out b/tests/qemu-iotests/315.out
new file mode 100644
index 00..146ec117fb
--- /dev/null
+++ b/tests/qemu-iotests/315.out
@@ -0,0 +1,54 @@
+QA output created by 315
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=1048576
+Formatting 'TEST_DIR/t.IMGFMT.mid', fmt=IMGFMT size=1048576 
backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 
backing_file=TEST_DIR/t.IMGFMT.mid backing_fmt=IMGFMT
+wrote 131072/131072 bytes at offset 65536
+128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+discard 65536/65536 bytes at offset 65536
+64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+=== Base image info before commit ===
+image: TEST_DIR/t.IMGFMT.base
+file format: IMGFMT
+virtual size: 1 MiB (1048576 bytes)
+[{ "start": 0, "length": 65536, "depth": 0, "present": false, "zero": true, 
"data": false, "compressed": false},
+{ "start": 65536, "length": 131072, "depth": 0, "present": true, "zero": 
false, "data": true, "compressed": false, "offset": OFFSET},
+{ "start": 19660

[PATCH 0/2] block: allow commit to unmap zero blocks

This patch series adds support for zero blocks in non-active commits.
The first patch in the series contains the actual changes to the commit
code, the second patch adds a test for the new functionality.

Vincent Vanlaer (2):
  block: allow commit to unmap zero blocks
  block: add test non-active commit with zeroed data

 block/commit.c | 71 ++--
 tests/qemu-iotests/315 | 95 ++
 tests/qemu-iotests/315.out | 54 ++
 3 files changed, 207 insertions(+), 13 deletions(-)
 create mode 100755 tests/qemu-iotests/315
 create mode 100644 tests/qemu-iotests/315.out

-- 
2.42.0

[PATCH 1/2] block: allow commit to unmap zero blocks

Non-active block commits do not discard blocks only containing zeros,
causing images to lose sparseness after the commit. This commit fixes
that by writing zero blocks using blk_co_pwrite_zeroes rather than
writing them out as any oother arbitrary data.

Signed-off-by: Vincent Vanlaer 
---
 block/commit.c | 71 +-
 1 file changed, 58 insertions(+), 13 deletions(-)

diff --git a/block/commit.c b/block/commit.c
index 7c3fdcb0ca..5bd97b5a74 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -12,9 +12,13 @@
  *
  */
 
+#include "bits/time.h"
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
+#include "time.h"
 #include "trace.h"
+#include "block/block-common.h"
+#include "block/coroutines.h"
 #include "block/block_int.h"
 #include "block/blockjob_int.h"
 #include "qapi/error.h"
@@ -126,6 +130,12 @@ static void commit_clean(Job *job)
 blk_unref(s->top);
 }
 
+typedef enum CommitMethod {
+COMMIT_METHOD_COPY,
+COMMIT_METHOD_ZERO,
+COMMIT_METHOD_IGNORE,
+} CommitMethod;
+
 static int coroutine_fn commit_run(Job *job, Error **errp)
 {
 CommitBlockJob *s = container_of(job, CommitBlockJob, common.job);
@@ -156,8 +166,9 @@ static int coroutine_fn commit_run(Job *job, Error **errp)
 buf = blk_blockalign(s->top, COMMIT_BUFFER_SIZE);
 
 for (offset = 0; offset < len; offset += n) {
-bool copy;
 bool error_in_source = true;
+CommitMethod commit_method = COMMIT_METHOD_COPY;
+
 
 /* Note that even when no rate limit is applied we need to yield
  * with no pending I/O here so that bdrv_drain_all() returns.
@@ -167,21 +178,54 @@ static int coroutine_fn commit_run(Job *job, Error **errp)
 break;
 }
 /* Copy if allocated above the base */
-ret = blk_co_is_allocated_above(s->top, s->base_overlay, true,
-offset, COMMIT_BUFFER_SIZE, );
-copy = (ret > 0);
+WITH_GRAPH_RDLOCK_GUARD() {
+ret = bdrv_co_common_block_status_above(blk_bs(s->top),
+s->base_overlay, true, true, offset, COMMIT_BUFFER_SIZE,
+, NULL, NULL, NULL);
+}
+
 trace_commit_one_iteration(s, offset, n, ret);
-if (copy) {
-assert(n < SIZE_MAX);
-
-ret = blk_co_pread(s->top, offset, n, buf, 0);
-if (ret >= 0) {
-ret = blk_co_pwrite(s->base, offset, n, buf, 0);
-if (ret < 0) {
-error_in_source = false;
+
+if (ret >= 0 && !(ret & BDRV_BLOCK_ALLOCATED)) {
+commit_method = COMMIT_METHOD_IGNORE;
+} else if (ret >= 0 && ret & BDRV_BLOCK_ZERO) {
+int64_t target_offset;
+int64_t target_bytes;
+WITH_GRAPH_RDLOCK_GUARD() {
+bdrv_round_to_subclusters(s->base_bs, offset, n,
+   _offset, _bytes);
+}
+
+if (target_offset == offset &&
+target_bytes == n) {
+commit_method = COMMIT_METHOD_ZERO;
+}
+}
+
+if (ret >= 0) {
+switch (commit_method) {
+case COMMIT_METHOD_COPY:
+assert(n < SIZE_MAX);
+ret = blk_co_pread(s->top, offset, n, buf, 0);
+if (ret >= 0) {
+ret = blk_co_pwrite(s->base, offset, n, buf, 0);
+if (ret < 0) {
+error_in_source = false;
+}
 }
+break;
+case COMMIT_METHOD_ZERO:
+ret = blk_co_pwrite_zeroes(s->base, offset, n,
+BDRV_REQ_MAY_UNMAP);
+error_in_source = false;
+break;
+case COMMIT_METHOD_IGNORE:
+break;
+default:
+abort();
 }
 }
+
 if (ret < 0) {
 BlockErrorAction action =
 block_job_error_action(>common, s->on_error,
@@ -193,10 +237,11 @@ static int coroutine_fn commit_run(Job *job, Error **errp)
 continue;
 }
 }
+
 /* Publish progress */
 job_progress_update(>common.job, n);
 
-if (copy) {
+if (commit_method == COMMIT_METHOD_COPY) {
 block_job_ratelimit_processed_bytes(>common, n);
 }
 }
-- 
2.42.0

Bug#1071919: xdg-document-portal.service: timeout during shutdown

On 2024-05-25 23:26:43 +0200, Vincent Lefevre wrote:
> I logged out, so that I was back to the lightdm display manager.
> I did a restart, but it took a long time due to a timeout for
> xdg-document-portal.service. This was the first time I got this
> issue.

I don't know whether this is related, but there's an upstream bug
about this timeout:

  https://github.com/flatpak/xdg-desktop-portal/issues/999

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Pkg-utopia-maintainers] Bug#1071919: xdg-document-portal.service: timeout during shutdown

On 2024-05-25 23:26:43 +0200, Vincent Lefevre wrote:
> I logged out, so that I was back to the lightdm display manager.
> I did a restart, but it took a long time due to a timeout for
> xdg-document-portal.service. This was the first time I got this
> issue.

I don't know whether this is related, but there's an upstream bug
about this timeout:

  https://github.com/flatpak/xdg-desktop-portal/issues/999

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Pkg-utopia-maintainers mailing list
Pkg-utopia-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers

Bug#1071919: xdg-document-portal.service: timeout during shutdown

Package: xdg-desktop-portal
Version: 1.18.4-1
Severity: normal

I logged out, so that I was back to the lightdm display manager.
I did a restart, but it took a long time due to a timeout for
xdg-document-portal.service. This was the first time I got this
issue.

I've attached the journalctl output, starting at the logout.

On screen, there were various kernel errors, but they actually
occurred just after booting: firmware that failed to load (this
has always happened) and an issue that seems to be due to
"Lockdown: Xorg: raw io port access is restricted; see man
kernel_lockdown.7" (which was occurring with the 6.7.12-amd64
kernel too).

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

Kernel: Linux 6.8.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 xdg-desktop-portal depends on:
ii  bubblewrap0.9.0-1
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  dbus-x11 [dbus-session-bus]   1.14.10-4+b1
ii  fuse3 3.14.0-5
ii  init-system-helpers   1.66
ii  libc6 2.38-11
ii  libfuse3-33.14.0-5
ii  libgdk-pixbuf-2.0-0   2.42.12+dfsg-1
ii  libglib2.0-0t64   2.80.2-2
ii  libjson-glib-1.0-01.8.0-2+b1
ii  libpipewire-0.3-0t64  1.0.6-1
ii  libsystemd0   255.5-1

xdg-desktop-portal recommends no packages.

xdg-desktop-portal suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
May 25 22:51:52 qaa lightdm[1826]: pam_unix(lightdm:session): session closed 
for user vinc17
May 25 22:51:52 qaa systemd-logind[1422]: Session 2 logged out. Waiting for 
processes to exit.
May 25 22:51:52 qaa at-spi-bus-launcher[116055]: X connection to :0 broken 
(explicit kill or server shutdown).
May 25 22:51:52 qaa systemd[2230]: xdg-desktop-portal-gtk.service: Main process 
exited, code=exited, status=1/FAILURE
May 25 22:51:52 qaa systemd[2230]: xdg-desktop-portal-gtk.service: Failed with 
result 'exit-code'.
May 25 22:51:52 qaa systemd[2230]: xdg-desktop-portal-gtk.service: Consumed 
1.127s CPU time.
May 25 22:51:54 qaa kernel: Lockdown: Xorg: raw io port access is restricted; 
see man kernel_lockdown.7
May 25 22:51:56 qaa accounts-daemon[1395]: Language 'C.utf8' set for user 
vinc17 is invalid
May 25 22:51:56 qaa lightdm[220879]: pam_unix(lightdm-greeter:session): session 
opened for user lightdm(uid=118) by (uid=0)
May 25 22:51:56 qaa systemd[1]: Created slice user-118.slice - User Slice of 
UID 118.
May 25 22:51:56 qaa systemd[1]: Starting user-runtime-dir@118.service - User 
Runtime Directory /run/user/118...
May 25 22:51:56 qaa systemd-logind[1422]: New session c2 of user lightdm.
May 25 22:51:56 qaa systemd[1]: Finished user-runtime-dir@118.service - User 
Runtime Directory /run/user/118.
May 25 22:51:56 qaa systemd[1]: Starting user@118.service - User Manager for 
UID 118...
May 25 22:51:56 qaa (systemd)[220885]: pam_unix(systemd-user:session): session 
opened for user lightdm(uid=118) by lightdm(uid=0)
May 25 22:51:56 qaa systemd[220885]: Queued start job for default target 
default.target.
May 25 22:51:56 qaa systemd[220885]: Created slice app.slice - User Application 
Slice.
May 25 22:51:56 qaa systemd[220885]: Created slice session.slice - User Core 
Session Slice.
May 25 22:51:56 qaa systemd[220885]: Reached target paths.target - Paths.
May 25 22:51:56 qaa systemd[220885]: Reached target timers.target - Timers.
May 25 22:51:56 qaa systemd[220885]: Starting dbus.socket - D-Bus User Message 
Bus Socket...
May 25 22:51:56 qaa systemd[220885]: Listening on dirmngr.socket - GnuPG 
network certificate management daemon.
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent-browser.socket - 
GnuPG cryptographic agent and passphrase cache (access for web browsers).
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent-extra.socket - 
GnuPG cryptographic agent and passphrase cache (restricted).
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent-ssh.socket - GnuPG 
cryptographic agent (ssh-agent emulation).
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent.socket - GnuP

[Pkg-utopia-maintainers] Bug#1071919: xdg-document-portal.service: timeout during shutdown

Package: xdg-desktop-portal
Version: 1.18.4-1
Severity: normal

I logged out, so that I was back to the lightdm display manager.
I did a restart, but it took a long time due to a timeout for
xdg-document-portal.service. This was the first time I got this
issue.

I've attached the journalctl output, starting at the logout.

On screen, there were various kernel errors, but they actually
occurred just after booting: firmware that failed to load (this
has always happened) and an issue that seems to be due to
"Lockdown: Xorg: raw io port access is restricted; see man
kernel_lockdown.7" (which was occurring with the 6.7.12-amd64
kernel too).

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

Kernel: Linux 6.8.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 xdg-desktop-portal depends on:
ii  bubblewrap0.9.0-1
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4+b1
ii  dbus-x11 [dbus-session-bus]   1.14.10-4+b1
ii  fuse3 3.14.0-5
ii  init-system-helpers   1.66
ii  libc6 2.38-11
ii  libfuse3-33.14.0-5
ii  libgdk-pixbuf-2.0-0   2.42.12+dfsg-1
ii  libglib2.0-0t64   2.80.2-2
ii  libjson-glib-1.0-01.8.0-2+b1
ii  libpipewire-0.3-0t64  1.0.6-1
ii  libsystemd0   255.5-1

xdg-desktop-portal recommends no packages.

xdg-desktop-portal suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
May 25 22:51:52 qaa lightdm[1826]: pam_unix(lightdm:session): session closed 
for user vinc17
May 25 22:51:52 qaa systemd-logind[1422]: Session 2 logged out. Waiting for 
processes to exit.
May 25 22:51:52 qaa at-spi-bus-launcher[116055]: X connection to :0 broken 
(explicit kill or server shutdown).
May 25 22:51:52 qaa systemd[2230]: xdg-desktop-portal-gtk.service: Main process 
exited, code=exited, status=1/FAILURE
May 25 22:51:52 qaa systemd[2230]: xdg-desktop-portal-gtk.service: Failed with 
result 'exit-code'.
May 25 22:51:52 qaa systemd[2230]: xdg-desktop-portal-gtk.service: Consumed 
1.127s CPU time.
May 25 22:51:54 qaa kernel: Lockdown: Xorg: raw io port access is restricted; 
see man kernel_lockdown.7
May 25 22:51:56 qaa accounts-daemon[1395]: Language 'C.utf8' set for user 
vinc17 is invalid
May 25 22:51:56 qaa lightdm[220879]: pam_unix(lightdm-greeter:session): session 
opened for user lightdm(uid=118) by (uid=0)
May 25 22:51:56 qaa systemd[1]: Created slice user-118.slice - User Slice of 
UID 118.
May 25 22:51:56 qaa systemd[1]: Starting user-runtime-dir@118.service - User 
Runtime Directory /run/user/118...
May 25 22:51:56 qaa systemd-logind[1422]: New session c2 of user lightdm.
May 25 22:51:56 qaa systemd[1]: Finished user-runtime-dir@118.service - User 
Runtime Directory /run/user/118.
May 25 22:51:56 qaa systemd[1]: Starting user@118.service - User Manager for 
UID 118...
May 25 22:51:56 qaa (systemd)[220885]: pam_unix(systemd-user:session): session 
opened for user lightdm(uid=118) by lightdm(uid=0)
May 25 22:51:56 qaa systemd[220885]: Queued start job for default target 
default.target.
May 25 22:51:56 qaa systemd[220885]: Created slice app.slice - User Application 
Slice.
May 25 22:51:56 qaa systemd[220885]: Created slice session.slice - User Core 
Session Slice.
May 25 22:51:56 qaa systemd[220885]: Reached target paths.target - Paths.
May 25 22:51:56 qaa systemd[220885]: Reached target timers.target - Timers.
May 25 22:51:56 qaa systemd[220885]: Starting dbus.socket - D-Bus User Message 
Bus Socket...
May 25 22:51:56 qaa systemd[220885]: Listening on dirmngr.socket - GnuPG 
network certificate management daemon.
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent-browser.socket - 
GnuPG cryptographic agent and passphrase cache (access for web browsers).
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent-extra.socket - 
GnuPG cryptographic agent and passphrase cache (restricted).
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent-ssh.socket - GnuPG 
cryptographic agent (ssh-agent emulation).
May 25 22:51:56 qaa systemd[220885]: Listening on gpg-agent.socket - GnuP

Bug#1071829: fail2ban: spurious ">" character in paths-debian.conf

Package: fail2ban
Version: 1.1.0-3
Severity: grave
Justification: renders package unusable

The /etc/fail2ban/paths-debian.conf file starts with

># Debian

which yields an error:

May 25 10:39:45 qaa systemd[1]: Started fail2ban.service - Fail2Ban Service.
May 25 10:39:45 qaa fail2ban-server[172274]: 2024-05-25 10:39:45,628 fail2ban   
 [172274]: ERROR   Failed during configuration: File contains no 
section headers.
May 25 10:39:45 qaa fail2ban-server[172274]: file: 
'/etc/fail2ban/paths-debian.conf', line: 1
May 25 10:39:45 qaa fail2ban-server[172274]: '># Debian\n'
May 25 10:39:45 qaa fail2ban-server[172274]: 2024-05-25 10:39:45,630 fail2ban   
 [172274]: ERROR   Async configuration of server failed
May 25 10:39:45 qaa systemd[1]: fail2ban.service: Main process exited, 
code=exited, status=255/EXCEPTION
May 25 10:39:45 qaa systemd[1]: fail2ban.service: Failed with result 
'exit-code'.

The first hunk in debian/patches/update_backend_system.diff, which
adds this character, should be removed:

Index: fail2ban/config/paths-debian.conf
===
--- fail2ban.orig/config/paths-debian.conf
+++ fail2ban/config/paths-debian.conf
@@ -1,4 +1,4 @@
-# Debian
+># Debian
 
 [INCLUDES]
 

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

Kernel: Linux 6.8.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 fail2ban depends on:
ii  python3  3.11.8-1
ii  python3-systemd  235-1+b3

Versions of packages fail2ban recommends:
ii  iptables   1.8.10-3
ii  nftables   1.0.9-2
ii  python3-pyinotify  0.9.6-2
ii  whois  5.5.23

Versions of packages fail2ban suggests:
ii  mailutils [mailx]  1:3.17-1.1+b2
pn  monit  
ii  sqlite33.45.3-1
pn  system-log-daemon  

-- Configuration Files:
/etc/fail2ban/action.d/mikrotik.conf [Errno 2] No such file or directory: 
'/etc/fail2ban/action.d/mikrotik.conf'
/etc/fail2ban/filter.d/dante.conf [Errno 2] No such file or directory: 
'/etc/fail2ban/filter.d/dante.conf'
/etc/fail2ban/filter.d/nginx-error-common.conf [Errno 2] No such file or 
directory: '/etc/fail2ban/filter.d/nginx-error-common.conf'
/etc/fail2ban/filter.d/nginx-forbidden.conf [Errno 2] No such file or 
directory: '/etc/fail2ban/filter.d/nginx-forbidden.conf'
/etc/fail2ban/filter.d/routeros-auth.conf [Errno 2] No such file or directory: 
'/etc/fail2ban/filter.d/routeros-auth.conf'

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1071829: fail2ban: spurious ">" character in paths-debian.conf

Package: fail2ban
Version: 1.1.0-3
Severity: grave
Justification: renders package unusable

The /etc/fail2ban/paths-debian.conf file starts with

># Debian

which yields an error:

May 25 10:39:45 qaa systemd[1]: Started fail2ban.service - Fail2Ban Service.
May 25 10:39:45 qaa fail2ban-server[172274]: 2024-05-25 10:39:45,628 fail2ban   
 [172274]: ERROR   Failed during configuration: File contains no 
section headers.
May 25 10:39:45 qaa fail2ban-server[172274]: file: 
'/etc/fail2ban/paths-debian.conf', line: 1
May 25 10:39:45 qaa fail2ban-server[172274]: '># Debian\n'
May 25 10:39:45 qaa fail2ban-server[172274]: 2024-05-25 10:39:45,630 fail2ban   
 [172274]: ERROR   Async configuration of server failed
May 25 10:39:45 qaa systemd[1]: fail2ban.service: Main process exited, 
code=exited, status=255/EXCEPTION
May 25 10:39:45 qaa systemd[1]: fail2ban.service: Failed with result 
'exit-code'.

The first hunk in debian/patches/update_backend_system.diff, which
adds this character, should be removed:

Index: fail2ban/config/paths-debian.conf
===
--- fail2ban.orig/config/paths-debian.conf
+++ fail2ban/config/paths-debian.conf
@@ -1,4 +1,4 @@
-# Debian
+># Debian
 
 [INCLUDES]
 

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

Kernel: Linux 6.8.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 fail2ban depends on:
ii  python3  3.11.8-1
ii  python3-systemd  235-1+b3

Versions of packages fail2ban recommends:
ii  iptables   1.8.10-3
ii  nftables   1.0.9-2
ii  python3-pyinotify  0.9.6-2
ii  whois  5.5.23

Versions of packages fail2ban suggests:
ii  mailutils [mailx]  1:3.17-1.1+b2
pn  monit  
ii  sqlite33.45.3-1
pn  system-log-daemon  

-- Configuration Files:
/etc/fail2ban/action.d/mikrotik.conf [Errno 2] No such file or directory: 
'/etc/fail2ban/action.d/mikrotik.conf'
/etc/fail2ban/filter.d/dante.conf [Errno 2] No such file or directory: 
'/etc/fail2ban/filter.d/dante.conf'
/etc/fail2ban/filter.d/nginx-error-common.conf [Errno 2] No such file or 
directory: '/etc/fail2ban/filter.d/nginx-error-common.conf'
/etc/fail2ban/filter.d/nginx-forbidden.conf [Errno 2] No such file or 
directory: '/etc/fail2ban/filter.d/nginx-forbidden.conf'
/etc/fail2ban/filter.d/routeros-auth.conf [Errno 2] No such file or directory: 
'/etc/fail2ban/filter.d/routeros-auth.conf'

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Pce] Re: IPR poll for draft-li-pce-controlled-id-space

2024-05-25 Thread Shihang(Vincent)

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thanks,
Hang

From: Andrew Stone (Nokia) 
Sent: Saturday, May 18, 2024 3:19 AM
To: Dhruv Dhody ; Mach Chen ; 
Lizhenbin ; Dongjie (Jimmy) ; Cheng 
Li ; Shihang(Vincent) ; 
wang...@chinatelecom.cn; chengweiqi...@chinamobile.com; chaozhou...@yahoo.com; 
pce@ietf.org; pce-cha...@ietf.org
Subject: IPR poll for draft-li-pce-controlled-id-space

Hi Authors,

In preparation for WG adoption on this draft, we'd like all authors and 
contributors to confirm on the list that they are in compliance with IETF IPR 
rules.

Please respond (copying the mailing list) to say one of:

- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules.

- I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.

- I am aware of IPR applicable to this draft, but that has not yet been 
disclosed to the IETF. I will work to ensure that it will be disclosed in a 
timely manner.

Thanks,
Andrew
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[graoulug-libre] Linuxfr suggestions dons aux associations

2024-05-25 Thread Vincent MERLET via libre


Bonjour,

Comme discuté ce matin à la permanence du Graoulug, voici la page de 
suggestions de dons aux associations publiée sur le site linuxfr :


https://linuxfr.org/news/dons-aux-associations-episode-12

A+

--
Vincent
___
libre mailing list
libre@graoulug.org
https://brassens.heberge.info/cgi-bin/mailman/listinfo/libre

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-24 14:52:08 +0200, Sylvestre Ledru wrote:
> Could you please propose a PR ? I didn't find the time to fix this lately
> (and i don't use fail2ban anymore).

https://salsa.debian.org/python-team/packages/fail2ban/-/merge_requests/9

This restores the use of nftables and selects the systemd backend
for the same set of jails as Fedora and Arch (openSUSE also has
mysql, but this is probably a mistake because Fedora and Arch had
it initially but it got removed because "mysqld does not log login
attempts to the journal" -- I did not check whether this is still
the case or the Fedora and Arch settings are out-of-date).

Note that the setting for sshd is necessary. For the other jails,
this may also be needed if the user has enabled other jails but has
not set the backend explicitly (not needed with fail2ban 1.0.2-3 in
testing). For instance, in my case, I had enabled the postfix jail,
and without this setting, after the upgrade from testing, fail2ban
was failing for the same reason as with sshd.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-24 14:52:08 +0200, Sylvestre Ledru wrote:
> Could you please propose a PR ? I didn't find the time to fix this lately
> (and i don't use fail2ban anymore).

https://salsa.debian.org/python-team/packages/fail2ban/-/merge_requests/9

This restores the use of nftables and selects the systemd backend
for the same set of jails as Fedora and Arch (openSUSE also has
mysql, but this is probably a mistake because Fedora and Arch had
it initially but it got removed because "mysqld does not log login
attempts to the journal" -- I did not check whether this is still
the case or the Fedora and Arch settings are out-of-date).

Note that the setting for sshd is necessary. For the other jails,
this may also be needed if the user has enabled other jails but has
not set the backend explicitly (not needed with fail2ban 1.0.2-3 in
testing). For instance, in my case, I had enabled the postfix jail,
and without this setting, after the upgrade from testing, fail2ban
was failing for the same reason as with sshd.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-07 08:35:28 +0200, Sylvestre Ledru wrote:
> 
> Le 07/05/2024 à 03:57, Vincent Lefevre a écrit :
> > On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote:
> > > May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 
> > > fail2ban[557228]: ERROR   Failed during configuration: 
> > > Have not found any log file for sshd jail
> > I suppose that this is because sshd no longer uses the systemd
> > backend. This is wrong. If I understand correctly, the point of
> > 
> > https://github.com/fail2ban/fail2ban/issues/3292#issuecomment-2078361360
> > 
> > is to no longer use the systemd backend for all jails, but for
> > sshd only. So "backend = systemd" has been removed from DEFAULT,
> > but the above comment also points to
> > 
> > https://github.com/fail2ban/fail2ban/commit/85a4881a9a818b6a746109f74980919296eedad0
> > 
> > which adds for DEFAULT in paths-debian.conf:
> > 
> > 
> > banaction = nftables
> > banaction_allports = nftables[type=allports]
> > 
> > sshd_backend = systemd
> > 
> > 
> > But paths-debian.conf has not changed in the fail2ban 1.1.0-1 package.
> > 
> ok, thanks.
> 
> Any idea what the fix should be? I am a bit lost in this conversation :/

For the sshd issue (mainly this bug), upstream changed 2 visible
things in the above commit:

* It changed default's "backend = systemd" to "sshd_backend = systemd"
  with the reason:

remove default backend (systemd) - too dangerous for all jails,
because it's hardly to find an error if some jail mistakenly start
to monitor journal instead of logfile (even if it exists), but will
silently find nothing

  Indeed, using systemd as the backend for all jails by default may
  yield silent breakage for services that do not use syslog for logging
  (this is not like this had already been the default backend).

* It disabled the sshd jail by default.

What you did in

https://salsa.debian.org/python-team/packages/fail2ban/-/commit/c03b1a832132f8033a6c698650daba9c48e22c62

is that the following lines are removed.

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

(leaving the sshd jail enabled, contrary to upstream's Debian files).

Since the sshd jail is still enabled but its backend is now the
default backend, it will use a syslog log file (/var/log/auth.log
if this has not changed), which doesn't exist if rsyslog is not
installed. Said otherwise, the following bugs are back:

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

(you fixed them in

https://salsa.debian.org/python-team/packages/fail2ban/-/commit/e634fa863e2d8035181e9e03476ae6dd56044fe6

on 2024-01-02 by the "backend = systemd", but reverted them
in c03b1a832132f8033a6c698650daba9c48e22c62).

There are several (non-exclusive) solutions:

1. Do not enable the sshd jail by default, following upstream's
decision, and let the user decide whether he should change the
backend for sshd when he enables the sshd jail.

The side effects after an upgrade:
  * The sshd jail may no longer be enabled (i.e. if the user hasn't
explicitly enabled it in jail.local). So this will need to be
announced.
  * If it is still enabled (due to jail.local), this solution alone
(without (2) or (3)) will not fix the problem.

2. Add "sshd_backend = systemd" like upstream, so that the sshd jail
will use the systemd backend.

A possible side effect after an upgrade from stable: this will
break for users who do not use systemd (but contrary to the default
"backend = systemd" issue, this should not be a silent breakage,
because fail2ban should be able to detect that the systemd logs
are not available at all - not tested, though).

3. Recommend the rsyslog package (or "rsyslog | system-log-daemon").
This would ensure that any backend will work, but would add another
daemon and additional log files (note that rsyslog is OK, but I don't
know whether the other log daemons are compatible with fail2ban's
default rules).

Moreover, I don't know why you removed the

banaction = nftables
banaction_allports = nftables[type=allports]

from [DEFAULT]. This was about a "switch from iptables to nftables"
as said at

  https://github.com/fail2ban/fail2ban/discussions/3575

Indeed, iptables is not always installed by default, while nftables
seems to be installed by the Debian installer (in any case, iptables
recommends nftables). So, I suppose that these lines would still be
necessary.

About the other services that log to the journal via syslog, things
like "postfix_backend = system

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-07 08:35:28 +0200, Sylvestre Ledru wrote:
> 
> Le 07/05/2024 à 03:57, Vincent Lefevre a écrit :
> > On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote:
> > > May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 
> > > fail2ban[557228]: ERROR   Failed during configuration: 
> > > Have not found any log file for sshd jail
> > I suppose that this is because sshd no longer uses the systemd
> > backend. This is wrong. If I understand correctly, the point of
> > 
> > https://github.com/fail2ban/fail2ban/issues/3292#issuecomment-2078361360
> > 
> > is to no longer use the systemd backend for all jails, but for
> > sshd only. So "backend = systemd" has been removed from DEFAULT,
> > but the above comment also points to
> > 
> > https://github.com/fail2ban/fail2ban/commit/85a4881a9a818b6a746109f74980919296eedad0
> > 
> > which adds for DEFAULT in paths-debian.conf:
> > 
> > 
> > banaction = nftables
> > banaction_allports = nftables[type=allports]
> > 
> > sshd_backend = systemd
> > 
> > 
> > But paths-debian.conf has not changed in the fail2ban 1.1.0-1 package.
> > 
> ok, thanks.
> 
> Any idea what the fix should be? I am a bit lost in this conversation :/

For the sshd issue (mainly this bug), upstream changed 2 visible
things in the above commit:

* It changed default's "backend = systemd" to "sshd_backend = systemd"
  with the reason:

remove default backend (systemd) - too dangerous for all jails,
because it's hardly to find an error if some jail mistakenly start
to monitor journal instead of logfile (even if it exists), but will
silently find nothing

  Indeed, using systemd as the backend for all jails by default may
  yield silent breakage for services that do not use syslog for logging
  (this is not like this had already been the default backend).

* It disabled the sshd jail by default.

What you did in

https://salsa.debian.org/python-team/packages/fail2ban/-/commit/c03b1a832132f8033a6c698650daba9c48e22c62

is that the following lines are removed.

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

(leaving the sshd jail enabled, contrary to upstream's Debian files).

Since the sshd jail is still enabled but its backend is now the
default backend, it will use a syslog log file (/var/log/auth.log
if this has not changed), which doesn't exist if rsyslog is not
installed. Said otherwise, the following bugs are back:

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

(you fixed them in

https://salsa.debian.org/python-team/packages/fail2ban/-/commit/e634fa863e2d8035181e9e03476ae6dd56044fe6

on 2024-01-02 by the "backend = systemd", but reverted them
in c03b1a832132f8033a6c698650daba9c48e22c62).

There are several (non-exclusive) solutions:

1. Do not enable the sshd jail by default, following upstream's
decision, and let the user decide whether he should change the
backend for sshd when he enables the sshd jail.

The side effects after an upgrade:
  * The sshd jail may no longer be enabled (i.e. if the user hasn't
explicitly enabled it in jail.local). So this will need to be
announced.
  * If it is still enabled (due to jail.local), this solution alone
(without (2) or (3)) will not fix the problem.

2. Add "sshd_backend = systemd" like upstream, so that the sshd jail
will use the systemd backend.

A possible side effect after an upgrade from stable: this will
break for users who do not use systemd (but contrary to the default
"backend = systemd" issue, this should not be a silent breakage,
because fail2ban should be able to detect that the systemd logs
are not available at all - not tested, though).

3. Recommend the rsyslog package (or "rsyslog | system-log-daemon").
This would ensure that any backend will work, but would add another
daemon and additional log files (note that rsyslog is OK, but I don't
know whether the other log daemons are compatible with fail2ban's
default rules).

Moreover, I don't know why you removed the

banaction = nftables
banaction_allports = nftables[type=allports]

from [DEFAULT]. This was about a "switch from iptables to nftables"
as said at

  https://github.com/fail2ban/fail2ban/discussions/3575

Indeed, iptables is not always installed by default, while nftables
seems to be installed by the Debian installer (in any case, iptables
recommends nftables). So, I suppose that these lines would still be
necessary.

About the other services that log to the journal via syslog, things
like "postfix_backend = system

Re: salsa web server broken?

On 2024-05-24 11:51:15 +0200, Alexander Wirt wrote:
> Am Fri, May 24, 2024 at 11:23:44AM +0200 schrieb Vincent Lefevre:
> > Is the salsa web server broken?
> > 
> > The display of https://salsa.debian.org/python-team/packages/fail2ban
> > is completely wrong, and https://salsa.debian.org/ gives an
> >
> We are in maintenance. 

OK. A mail is usually sent to debian-infrastructure-announce, but
this time, there was no such mail.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

salsa web server broken?