from:"Valerio"


I removed the file:
/etc/network/interfaces.d/enp5s0

then:
$ sudo service networking restart

$ sudo nmcli device set enp5s0 managed yes


but:
$ nmcli device

still say unmanaged and no ethernet conection in the Network manager icon

--
Valerio

[Pkg-utopia-maintainers] Bug#1070974: network-manager-gnome: do not show local ethernet connection


I removed the file:
/etc/network/interfaces.d/enp5s0

then:
$ sudo service networking restart

$ sudo nmcli device set enp5s0 managed yes


but:
$ nmcli device

still say unmanaged and no ethernet conection in the Network manager icon

--
Valerio

___
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#1070974: network-manager-gnome: do not show local ethernet connection


On 5/12/24 11:05 AM, Marco Moock wrote:

Most likely the connection is not manages by NM.

Run
nmcli device


I got:

efa@08i7-2500:~$ nmcli device
DEVICE  TYPE  STATE   CONNECTION
lo  loopback  connected (externally)  lo
wlp4s0  wifi  disconnected--
p2p-dev-wlp4s0  wifi-p2p  disconnected--
enp5s0  ethernet  unmanaged   --



> If it is configured in /etc/network/interfaces, NM won't manage it, so
> comment the config out for that interface if you want to use it in NM.


/etc/network/interfaces
---
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback



but:

/etc/network/interfaces.d/enp5s0

auto enp5s0
iface enp5s0 inet dhcp
ethernet-wol g



Probably was when I activated the WOL


So I had to remove the file: /etc/network/interfaces.d/enp5s0
and set everything from the NetworkManager, WOL too ?


In case, ethernet-wol g is equivalent to Wake on LAN:
Phy
Unicast
Multicast
Broadcast
Arp
Magic
?


THANK YOU for support
--
Valerio

[Pkg-utopia-maintainers] Bug#1070974: network-manager-gnome: do not show local ethernet connection


On 5/12/24 11:05 AM, Marco Moock wrote:

Most likely the connection is not manages by NM.

Run
nmcli device


I got:

efa@08i7-2500:~$ nmcli device
DEVICE  TYPE  STATE   CONNECTION
lo  loopback  connected (externally)  lo
wlp4s0  wifi  disconnected--
p2p-dev-wlp4s0  wifi-p2p  disconnected--
enp5s0  ethernet  unmanaged   --



> If it is configured in /etc/network/interfaces, NM won't manage it, so
> comment the config out for that interface if you want to use it in NM.


/etc/network/interfaces
---
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback



but:

/etc/network/interfaces.d/enp5s0

auto enp5s0
iface enp5s0 inet dhcp
ethernet-wol g



Probably was when I activated the WOL


So I had to remove the file: /etc/network/interfaces.d/enp5s0
and set everything from the NetworkManager, WOL too ?


In case, ethernet-wol g is equivalent to Wake on LAN:
Phy
Unicast
Multicast
Broadcast
Arp
Magic
?


THANK YOU for support
--
Valerio

___
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#1070974: network-manager-gnome: do not show local ethernet connection

2024-05-12 Thread Valerio

Package: network-manager-gnome
Version: 1.30.0-2
Severity: normal
X-Debbugs-Cc: e...@iol.it

Dear Maintainer,

ifconfig in the console show regular 'enp5s0' device with its IP 192.168.1.11 
and all computer communication work as expected

clicking on Network Manager icon, show only Wireless networks
right clicking the icon, Network and WiFi are enabled.
right clicking the icon and choosing Network information, show only 'lo' 
network with its IPv4 127.0.0.1 and IPv6 ::1/128
right clicking the icon and choosing Change connections, the list include 
Ethernet and WiFi, but Ethernet has indication of 3 months ago last connection
also adding a new Ethernet with right 'enp5s0' device, DHCP and so on, and 
saving, the new connection appear but say never connected, and doesn't appear 
in the applet icon

In the past I remember I can connect and disconnect from ethernet connection

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

Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-1~deb12u1
ii  dbus-x11 [dbus-session-bus]   1.14.10-1~deb12u1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gnome-shell [polkit-1-auth-agent] 43.9-0+deb12u2
ii  libatk1.0-0   2.46.0-5
ii  libayatana-appindicator3-10.5.92-1
ii  libc6 2.36-9+deb12u7
ii  libcairo2 1.16.0-7
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2+deb12u2
ii  libgtk-3-03.24.38-2~deb12u1
ii  libjansson4   2.14-2
ii  libmm-glib0   1.20.4-1
ii  libnm01.42.4-1
ii  libnma0   1.10.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libsecret-1-0 0.20.5-3
ii  libselinux1   3.4-1+b6
ii  mate-polkit [polkit-1-auth-agent] 1.26.1-3
ii  network-manager   1.42.4-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-8
ii  polkit-kde-agent-1 [polkit-1-auth-agent]  4:5.27.5-2

Versions of packages network-manager-gnome recommends:
ii  cinnamon [notification-daemon]  5.6.8-1
ii  gnome-icon-theme3.12.0-5
ii  gnome-keyring   42.1-1+b2
ii  gnome-shell [notification-daemon]   43.9-0+deb12u2
ii  iso-codes   4.15.0-1
ii  mate-notification-daemon [notification-daemon]  1.26.0-1+deb12u1
ii  mobile-broadband-provider-info  20230416-1
ii  plasma-workspace [notification-daemon]  4:5.27.5-2+deb12u1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
ii  network-manager-openvpn-gnome  1.10.2-2
ii  network-manager-pptp-gnome 1.2.12-1
pn  network-manager-vpnc-gnome 

-- no debconf information

[Pkg-utopia-maintainers] Bug#1070974: network-manager-gnome: do not show local ethernet connection

2024-05-12 Thread Valerio

Package: network-manager-gnome
Version: 1.30.0-2
Severity: normal
X-Debbugs-Cc: e...@iol.it

Dear Maintainer,

ifconfig in the console show regular 'enp5s0' device with its IP 192.168.1.11 
and all computer communication work as expected

clicking on Network Manager icon, show only Wireless networks
right clicking the icon, Network and WiFi are enabled.
right clicking the icon and choosing Network information, show only 'lo' 
network with its IPv4 127.0.0.1 and IPv6 ::1/128
right clicking the icon and choosing Change connections, the list include 
Ethernet and WiFi, but Ethernet has indication of 3 months ago last connection
also adding a new Ethernet with right 'enp5s0' device, DHCP and so on, and 
saving, the new connection appear but say never connected, and doesn't appear 
in the applet icon

In the past I remember I can connect and disconnect from ethernet connection

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

Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-1~deb12u1
ii  dbus-x11 [dbus-session-bus]   1.14.10-1~deb12u1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gnome-shell [polkit-1-auth-agent] 43.9-0+deb12u2
ii  libatk1.0-0   2.46.0-5
ii  libayatana-appindicator3-10.5.92-1
ii  libc6 2.36-9+deb12u7
ii  libcairo2 1.16.0-7
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2+deb12u2
ii  libgtk-3-03.24.38-2~deb12u1
ii  libjansson4   2.14-2
ii  libmm-glib0   1.20.4-1
ii  libnm01.42.4-1
ii  libnma0   1.10.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libsecret-1-0 0.20.5-3
ii  libselinux1   3.4-1+b6
ii  mate-polkit [polkit-1-auth-agent] 1.26.1-3
ii  network-manager   1.42.4-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-8
ii  polkit-kde-agent-1 [polkit-1-auth-agent]  4:5.27.5-2

Versions of packages network-manager-gnome recommends:
ii  cinnamon [notification-daemon]  5.6.8-1
ii  gnome-icon-theme3.12.0-5
ii  gnome-keyring   42.1-1+b2
ii  gnome-shell [notification-daemon]   43.9-0+deb12u2
ii  iso-codes   4.15.0-1
ii  mate-notification-daemon [notification-daemon]  1.26.0-1+deb12u1
ii  mobile-broadband-provider-info  20230416-1
ii  plasma-workspace [notification-daemon]  4:5.27.5-2+deb12u1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
ii  network-manager-openvpn-gnome  1.10.2-2
ii  network-manager-pptp-gnome 1.2.12-1
pn  network-manager-vpnc-gnome 

-- no debconf information

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

[ovs-dev] [PATCH v2] conntrack: Fully initialize conn struct before insertion.

2024-05-10 Thread Paolo Valerio

From: Mike Pattrick 

In case packets are concurrently received in both directions, there's
a chance that the ones in the reverse direction get received right
after the connection gets added to the connection tracker but before
some of the connection's fields are fully initialized.
This could cause OVS to access potentially invalid, as the lookup may
end up retrieving the wrong offsets during CONTAINER_OF(), or
uninitialized memory.

This may happen in case of regular NAT or all-zero SNAT.

Fix it by initializing early the connections fields.

Fixes: 1116459b3ba8 ("conntrack: Remove nat_conn introducing key 
directionality.")
Reported-at: https://issues.redhat.com/browse/FDP-616
Signed-off-by: Mike Pattrick 
Co-authored-by: Paolo Valerio 
Signed-off-by: Paolo Valerio 
---
 lib/conntrack.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index 16e1c8bb5..5fdfe98de 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -947,6 +947,18 @@ conn_not_found(struct conntrack *ct, struct dp_packet *pkt,
 nc->parent_key = alg_exp->parent_key;
 }
 
+ovs_mutex_init_adaptive(>lock);
+atomic_flag_clear(>reclaimed);
+fwd_key_node->dir = CT_DIR_FWD;
+rev_key_node->dir = CT_DIR_REV;
+
+if (zl) {
+nc->admit_zone = zl->czl.zone;
+nc->zone_limit_seq = zl->czl.zone_limit_seq;
+} else {
+nc->admit_zone = INVALID_ZONE;
+}
+
 if (nat_action_info) {
 nc->nat_action = nat_action_info->nat_action;
 
@@ -972,22 +984,16 @@ conn_not_found(struct conntrack *ct, struct dp_packet 
*pkt,
 _key_node->cm_node, rev_hash);
 }
 
-ovs_mutex_init_adaptive(>lock);
-atomic_flag_clear(>reclaimed);
-fwd_key_node->dir = CT_DIR_FWD;
-rev_key_node->dir = CT_DIR_REV;
 cmap_insert(>conns[ctx->key.zone],
 _key_node->cm_node, ctx->hash);
 conn_expire_push_front(ct, nc);
 atomic_count_inc(>n_conn);
-ctx->conn = nc; /* For completeness. */
+
 if (zl) {
-nc->admit_zone = zl->czl.zone;
-nc->zone_limit_seq = zl->czl.zone_limit_seq;
 atomic_count_inc(>czl.count);
-} else {
-nc->admit_zone = INVALID_ZONE;
 }
+
+ctx->conn = nc; /* For completeness. */
 }
 
 return nc;
-- 
2.45.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Subject: conntrack: Fully initialize conn struct before insertion.

2024-05-10 Thread Paolo Valerio

From: Mike Pattrick 

In case packets are concurrently received in both directions, there's
a chance that the ones in the reverse direction get received right
after the connection gets added to the connection tracker but before
some of the connection's fields are fully initialized.
This could cause OVS to access potentially invalid, as the lookup may
end up retrieving the wrong offsets during CONTAINER_OF(), or
uninitialized memory.

This may happen in case of regular NAT or all-zero SNAT.

Fix it by initializing early the connections fields.

Fixes: 1116459b3ba8 ("conntrack: Remove nat_conn introducing key 
directionality.")
Reported-at: https://issues.redhat.com/browse/FDP-616
Signed-off-by: Mike Pattrick 
Co-authored-by: Paolo Valerio 
Signed-off-by: Paolo Valerio 
---
 lib/conntrack.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index 16e1c8bb5..5fdfe98de 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -947,6 +947,18 @@ conn_not_found(struct conntrack *ct, struct dp_packet *pkt,
 nc->parent_key = alg_exp->parent_key;
 }
 
+ovs_mutex_init_adaptive(>lock);
+atomic_flag_clear(>reclaimed);
+fwd_key_node->dir = CT_DIR_FWD;
+rev_key_node->dir = CT_DIR_REV;
+
+if (zl) {
+nc->admit_zone = zl->czl.zone;
+nc->zone_limit_seq = zl->czl.zone_limit_seq;
+} else {
+nc->admit_zone = INVALID_ZONE;
+}
+
 if (nat_action_info) {
 nc->nat_action = nat_action_info->nat_action;
 
@@ -972,22 +984,16 @@ conn_not_found(struct conntrack *ct, struct dp_packet 
*pkt,
 _key_node->cm_node, rev_hash);
 }
 
-ovs_mutex_init_adaptive(>lock);
-atomic_flag_clear(>reclaimed);
-fwd_key_node->dir = CT_DIR_FWD;
-rev_key_node->dir = CT_DIR_REV;
 cmap_insert(>conns[ctx->key.zone],
 _key_node->cm_node, ctx->hash);
 conn_expire_push_front(ct, nc);
 atomic_count_inc(>n_conn);
-ctx->conn = nc; /* For completeness. */
+
 if (zl) {
-nc->admit_zone = zl->czl.zone;
-nc->zone_limit_seq = zl->czl.zone_limit_seq;
 atomic_count_inc(>czl.count);
-} else {
-nc->admit_zone = INVALID_ZONE;
 }
+
+ctx->conn = nc; /* For completeness. */
 }
 
 return nc;
-- 
2.45.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] conntrack: Do not use {0} to initialize unions.

2024-05-09 Thread Paolo Valerio

Xavier Simonart  writes:

> In the following case:
> union ct_addr {
> unsigned int ipv4;
> struct in6_addr ipv6;
> };
> union ct_addr zero_ip = {0};
>
> The ipv6 field might not be properly initialized.
> For instance, clang 18.1.1 does not initialize the ipv6 field.
>
> Reported-at: https://issues.redhat.com/browse/FDP-608
> Signed-off-by: Xavier Simonart 
> ---
> v2: updated based on nit from Paolo.
> ---

Thanks Xavier.

Acked-by: Paolo Valerio 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] conntrack: Do not use {0} to initialize unions.

2024-05-08 Thread Paolo Valerio

Hello Xavier,

just curious, based on your tests, is clang 18.1.1 the only
compiler/version known so far to lead to the problem, right?

Anyways, only a small cosmetic nit below. Other than that:

Acked-by: Paolo Valerio 

Xavier Simonart  writes:

> In the following case:
> union ct_addr {
> unsigned int ipv4;
> struct in6_addr ipv6;
> };
> union ct_addr zero_ip = {0};
>
> The ipv6 field might not be properly initialized.
> For instance, clang 18.1.1 does not initialize the ipv6 field.
>
> Reported-at: https://issues.redhat.com/browse/FDP-608
> Signed-off-by: Xavier Simonart 
> ---
>  lib/conntrack.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index 16e1c8bb5..ff4a17abc 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -2302,7 +2302,8 @@ find_addr(const struct conn_key *key, union ct_addr 
> *min,
>uint32_t hash, bool ipv4,
>const struct nat_action_info_t *nat_info)
>  {
> -const union ct_addr zero_ip = {0};
> +union ct_addr zero_ip;
> +memset(_ip, 0, sizeof zero_ip);
>  
>  /* All-zero case. */
>  if (!memcmp(min, _ip, sizeof *min)) {
> @@ -2394,7 +2395,7 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
> *conn,
>  {
>  struct conn_key *fwd_key = >key_node[CT_DIR_FWD].key;
>  struct conn_key *rev_key = >key_node[CT_DIR_REV].key;
> -union ct_addr min_addr = {0}, max_addr = {0}, addr = {0};
> +union ct_addr min_addr, max_addr, addr;

nit: please keep the reverse xmas tree

>  bool pat_proto = fwd_key->nw_proto == IPPROTO_TCP ||
>   fwd_key->nw_proto == IPPROTO_UDP ||
>   fwd_key->nw_proto == IPPROTO_SCTP;
> @@ -2402,6 +2403,10 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
> *conn,
>  uint16_t min_sport, max_sport, curr_sport;
>  uint32_t hash, port_off, basis;
>  
> +memset(_addr, 0, sizeof min_addr);
> +memset(_addr, 0, sizeof max_addr);
> +memset(, 0, sizeof addr);
> +
>  basis = (nat_info->nat_flags & NAT_PERSISTENT) ? 0 : ct->hash_basis;
>  hash = nat_range_hash(fwd_key, basis, nat_info);
>  
> -- 
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Bug#1070245: dicomnifti 2.33.1-5: ROM; Obsolete

2024-05-02 Thread Valerio Luccio


Package: dicomnifti
Version: 2.33.1-5

Software not compatible with most recent DICOM image version and will 
not be updated.


--
Valerio Luccio  
High Performance Computing  10 Astor Place, 4th Floor
New York University New York, NY 10003

   "In an open world, who needs windows or gates ?"

Bug#1070243: dicomnifti 2.33.1-5: ROM; Obsolete

2024-05-02 Thread Valerio Luccio


Package: dicomnifti 2.33.1-5

Software not compatible with most recent DICOM image version and will 
not be updated.


--
Valerio Luccio  
High Performance Computing  10 Astor Place, 4th Floor
New York University New York, NY 10003

   "In an open world, who needs windows or gates ?"

`notmuch-message-headers` interpreted case-sensitively

2024-04-24 Thread Herbert Valerio Riedel

Hello!

Not sure if this is a bug or intentional behaviour but it did surprise me:

When I added "Message-Id" to `notmuch-message-headers` I noticed that
sometimes the header would be shown and sometimes not. It turns out that
some MUAs generate the header as "Message-Id" and others as "Message-ID"
with a slightly different capitalization.

Only when I included both, "Message-Id" and "Message-ID", in
`notmuch-message-headers` I was able to workaround this issue.

the culprit seems to be the function below which does no attempt to
retrieve the respective header case-insensitively via `plist-get` as it
constructs a symbol :Message-Id or :Message-id respectively which are
not equal as the `eq` comparison is used by default:

--8<---cut here---start->8---
(defun notmuch-show-insert-headers (headers)
  "Insert the headers of the current message."
  (let ((start (point)))
(mapc (lambda (header)
(let* ((header-symbol (intern (concat ":" header)))
   (header-value (plist-get headers header-symbol)))
  (when (and header-value
 (not (string-equal "" header-value)))
(notmuch-show-insert-header header header-value
  notmuch-message-headers)
(save-excursion
  (save-restriction
(narrow-to-region start (point-max))
(run-hooks 'notmuch-show-markup-headers-hook)
--8<---cut here---end--->8---
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[Corpora-List] Two postdoc positions at University of Turin (HARMONIA)

2024-04-23 Thread Valerio Basile via Corpora

The Content-Centered Computing
<https://www.cs.unito.it/do/gruppi.pl/Show?_id=453y> group at the
University of Turin, Italy, offers *two 14-month postdoc positions* in the
context of HARMONIA (Harmony in Hybrid Decision-Making: Knowledge-enhanced
Perspective-taking LLMs for Inclusive Decision-Making), funded by the
European Union under the NextGenerationEU program within the larger project
FAIR (Future Artificial Intelligence) Spoke 2 "Integrative AI"
<https://fair.fbk.eu/>. The project aims at developing methods for the
adoption of knowledge-enhanced Large Language Models (LLMs) in supporting
informed and inclusive political decisions within public decision-making
processes.

The topics of the postdoc fellowships are:
- Computational linguistics methods for knowledge-enhanced
perspective-taking LLMs to support Inclusive Decision-Making
- Perspective-taking LLMs for supporting Inclusive Decision-Making
(full descriptions below)

The team includes members of the Computer Science Department and Economics
and Statistics Department of the University of Turin.
A PhD in Computer Science, Computational Linguistics, or related areas is
highly recommended. Knowledge of Italian is not mandatory.
The deadline for application is *May 13th 2024*.

The gross salary is €25.328 (about €1,860/month net salary). Turin
<https://www.turismotorino.org/en/territory/torino-metropoli/torino> is a
vibrant and liveable city in Northern Italy, close to the beautiful Italian
Alps and with a manageable cost of living
<https://en.unito.it/living-turin/when-you-arrive/cost-living-turin>.

Link to the call
<https://www.turismotorino.org/en/territory/torino-metropoli/torino> (in
Italian). Link to the application platform
<https://pica.cineca.it/unito/assegni-di-ricerca-unito-2024-i-pnrr/>.
Please write to  or  for
further information on how to apply.

Best regards,
Valerio Basile

--

*Computational linguistics methods for knowledge-enhanced
perspective-taking LLMs to support Inclusive Decision-Making*
The activity will focus on a) design of a semantic model to represent
interactions between urban services and citizens and integrate multi-source
hybrid data; b) data annotation by citizens with different socio-cultural
backgrounds to collect different perspectives on social issues. Data will
be collected and organized in a Knowledge Graph. The activity will be
supported by an interdisciplinary team of experts in KR, behavioral
economics and LLMs (link with the design of knowledge-enhanced LLMs).

*Perspective-taking LLMs for supporting Inclusive Decision-Making*
The activity will focus on a) exploring techniques for integrating
multi-source hybrid citizen data into LLMs (RAG and Knowledge Injection);
b) developing methods for training and evaluating perspective-taking LLMs,
which explicitly encode multiple perspectives, embodying the point of view
of different citizen communities on a topic. Planned activities include:
benchmark creation, error analysis, and evaluation of the efficiency and
reliability of the developed technologies.
___
Corpora mailing list -- corpora@list.elra.info
https://list.elra.info/mailman3/postorius/lists/corpora.list.elra.info/
To unsubscribe send an email to corpora-le...@list.elra.info

[ovs-dev] [PATCH] dpctl: fix segfault on ct-{set,del}-limits

2024-04-22 Thread Paolo Valerio

When no parameters other than the datapath are specified a segfault
occurs.

Fix it by checking the argument access is inside the bounds.

Signed-off-by: Paolo Valerio 
---
 lib/dpctl.c | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/lib/dpctl.c b/lib/dpctl.c
index 34ee7d0e2..3c555a559 100644
--- a/lib/dpctl.c
+++ b/lib/dpctl.c
@@ -2168,13 +2168,20 @@ static int
 dpctl_ct_set_limits(int argc, const char *argv[],
 struct dpctl_params *dpctl_p)
 {
-struct dpif *dpif;
-struct ds ds = DS_EMPTY_INITIALIZER;
+struct ovs_list zone_limits = OVS_LIST_INITIALIZER(_limits);
 int i =  dp_arg_exists(argc, argv) ? 2 : 1;
+struct ds ds = DS_EMPTY_INITIALIZER;
+struct dpif *dpif = NULL;
 uint32_t default_limit;
-struct ovs_list zone_limits = OVS_LIST_INITIALIZER(_limits);
+int error;
+
+if (i >= argc) {
+ds_put_cstr(, "too few arguments");
+error = EINVAL;
+goto error;
+}
 
-int error = opt_dpif_open(argc, argv, dpctl_p, INT_MAX, );
+error = opt_dpif_open(argc, argv, dpctl_p, INT_MAX, );
 if (error) {
 return error;
 }
@@ -2261,11 +2268,17 @@ static int
 dpctl_ct_del_limits(int argc, const char *argv[],
 struct dpctl_params *dpctl_p)
 {
-struct dpif *dpif;
+struct ovs_list zone_limits = OVS_LIST_INITIALIZER(_limits);
+int i =  dp_arg_exists(argc, argv) ? 2 : 1;
 struct ds ds = DS_EMPTY_INITIALIZER;
+struct dpif *dpif = NULL;
 int error;
-int i =  dp_arg_exists(argc, argv) ? 2 : 1;
-struct ovs_list zone_limits = OVS_LIST_INITIALIZER(_limits);
+
+if (i >= argc) {
+ds_put_cstr(, "too few arguments");
+error = EINVAL;
+goto error;
+}
 
 error = opt_dpif_open(argc, argv, dpctl_p, 4, );
 if (error) {
-- 
2.44.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [BUG] Custom headers in `notmuch-message-headers` are broken

2024-04-20 Thread Herbert Valerio Riedel



>> The end result is that `notmuch-message-headers` variable has no effect.

> Not sure if you are still interested, but this should be fixed in
> notmuch 0.35 (see show.extra_headers in notmuch-config(1)).

I just stumbled over this issue when trying to add "Message-Id" to the
list of shown messages as the docstring of the custom variable
definition in 'notmuch-show.el' didn't mention that I needed to tweak my
config or that only a small subset of headers might be supported:

--8<---cut here---start->8---
(defcustom notmuch-message-headers '("Subject" "To" "Cc" "Date")
  "Headers that should be shown in a message, in this order.

For an open message, all of these headers will be made visible
according to `notmuch-message-headers-visible' or can be toggled
with `notmuch-show-toggle-visibility-headers'. For a closed message,
only the first header in the list will be visible."
  :type '(repeat string)
  :group 'notmuch-show)
--8<---cut here---end--->8---

I suggest adding a hint there that tweaking 'show.extra_headers' might
be necessary.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [ovs-discuss] Urgent Help needed: OVS 3.2.2 Strange TC DROPs

2024-04-18 Thread Paolo Valerio via discuss

Paolo Valerio  writes:

> Adrian Moreno via discuss  writes:
>
>> Hi Gavin
>>
>> On 4/18/24 02:38, Gavin McKee via discuss wrote:
>>> This is an example.
>>> 
>>> Again the TCP 3 handshake completes , but the next packet fails to NAT
>>> and goes out onto the physical network using the private address .  An
>>> example of this is in the packet trace I provided.
>>> 
>>
>> Given you were using retis in your initial troubleshooting, you can use it 
>> with 
>> the additional "ct" collector to see if the kernel datapath is retrieving 
>> the 
>> right conntrack entry and what's its state. If that shows some unexpected 
>> conntrack entry change, it can be confirmed by monitoring "conntrack -E".
>>
>> Additionally, a dp flow dump (ovs-appctl dpctl/dump-flows -m) when the 
>> problem 
>> is happening might be also useful.
>>
>
> one thing to add on top of the above is a check for invalid logs (nf-log
> can be used as well):
>
> # modprobe nf_log_ipv4
> ## set logger for AF_INET (should be already set)
> # sysctl -w net.netfilter.nf_log.2=nf_log_ipv4
> ## enable invalid logs for TCP
> # sysctl net.netfilter.nf_conntrack_log_invalid=6
>

there's C/P mistake here:

sysctl -w net.netfilter.nf_conntrack_log_invalid=6

and soon after the invalid example message below in the clean up.
Should be:

sysctl -w net.netfilter.nf_conntrack_log_invalid=0

> in the case an invalid packet gets logged, you should see in dmesg
> something like:
>
> [312352.460843] nf_ct_proto_6: invalid new IN=eno1 ...
>
> once done:
>
> # sysctl net.netfilter.nf_conntrack_log_invalid=6
> # rmmod nf_log_syslog
>
> Paolo
>
>> --
>> Adrián
>>
>>
>>> ovs-appctl ofproto/trace br-int
>>> in_port=7753,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,tcp,nw_src=172.27.18.244,nw_dst=104.18.3.35,nw_ttl=32,tcp_src=52776,tcp_dst=443,tcp_flags=2
>>> Flow: 
>>> tcp,in_port=7753,vlan_tci=0x,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,nw_src=172.27.18.244,nw_dst=104.18.3.35,nw_tos=0,nw_ecn=0,nw_ttl=32,nw_frag=no,tp_src=52776,tp_dst=443,tcp_flags=syn
>>> 
>>> bridge("br-int")
>>> 
>>>   0. in_port=7753, priority 100, cookie 0xc33f39c4
>>>  set_field:0x16d->reg13
>>>  set_field:0x155->reg11
>>>  set_field:0x1cf->reg12
>>>  set_field:0x12->metadata
>>>  set_field:0xca->reg14
>>>  resubmit(,8)
>>>   8. metadata=0x12, priority 50, cookie 0x1645d3f2
>>>  set_field:0/0x1000->reg10
>>>  resubmit(,73)
>>>  73. 
>>> ip,reg14=0xca,metadata=0x12,dl_src=4e:42:14:a1:2a:fb,nw_src=172.27.18.244,
>>> priority 90, cookie 0xc33f39c4
>>>  set_field:0/0x1000->reg10
>>>  move:NXM_NX_REG10[12]->NXM_NX_XXREG0[111]
>>>   -> NXM_NX_XXREG0[111] is now 0
>>>  resubmit(,9)
>>>   9. metadata=0x12, priority 0, cookie 0xcc4fd106
>>>  resubmit(,10)
>>> 10. metadata=0x12, priority 0, cookie 0x9e10ad0e
>>>  resubmit(,11)
>>> 11. metadata=0x12, priority 0, cookie 0x557f3249
>>>  resubmit(,12)
>>> 12. ip,metadata=0x12, priority 100, cookie 0x14131a67
>>>  
>>> set_field:0x1/0x1->xxreg0
>>>  resubmit(,13)
>>> 13. metadata=0x12, priority 0, cookie 0x85f9ed4f
>>>  resubmit(,14)
>>> 14. ip,reg0=0x1/0x1,metadata=0x12, priority 100, cookie 0x279651c
>>>  ct(table=15,zone=NXM_NX_REG13[0..15])
>>>  drop
>>>   -> A clone of the packet is forked to recirculate. The forked
>>> pipeline will be resumed at table 15.
>>>   -> Sets the packet to an untracked state, and clears all the
>>> conntrack fields.
>>> 
>>> Final flow: 
>>> tcp,reg0=0x1,reg11=0x155,reg12=0x1cf,reg13=0x16d,reg14=0xca,metadata=0x12,in_port=7753,vlan_tci=0x,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,nw_src=172.27.18.244,nw_dst=104.18.3.35,nw_tos=0,nw_ecn=0,nw_ttl=32,nw_frag=no,tp_src=52776,tp_dst=443,tcp_flags=syn
>>> Megaflow: 
>>> recirc_id=0,eth,tcp,in_port=7753,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,nw_src=172.27.18.244,nw_frag=no
>>> Datapath actions: ct(zone=365),recirc(0x13b5a)
>>> 
>>> ===
>>> recirc(0x13b5a) - resume conntrack with default ct_state=trk|new (use
>>> --ct-next to custom

Re: [ovs-discuss] Urgent Help needed: OVS 3.2.2 Strange TC DROPs

2024-04-18 Thread Paolo Valerio via discuss

Adrian Moreno via discuss  writes:

> Hi Gavin
>
> On 4/18/24 02:38, Gavin McKee via discuss wrote:
>> This is an example.
>> 
>> Again the TCP 3 handshake completes , but the next packet fails to NAT
>> and goes out onto the physical network using the private address .  An
>> example of this is in the packet trace I provided.
>> 
>
> Given you were using retis in your initial troubleshooting, you can use it 
> with 
> the additional "ct" collector to see if the kernel datapath is retrieving the 
> right conntrack entry and what's its state. If that shows some unexpected 
> conntrack entry change, it can be confirmed by monitoring "conntrack -E".
>
> Additionally, a dp flow dump (ovs-appctl dpctl/dump-flows -m) when the 
> problem 
> is happening might be also useful.
>

one thing to add on top of the above is a check for invalid logs (nf-log
can be used as well):

# modprobe nf_log_ipv4
## set logger for AF_INET (should be already set)
# sysctl -w net.netfilter.nf_log.2=nf_log_ipv4
## enable invalid logs for TCP
# sysctl net.netfilter.nf_conntrack_log_invalid=6

in the case an invalid packet gets logged, you should see in dmesg
something like:

[312352.460843] nf_ct_proto_6: invalid new IN=eno1 ...

once done:

# sysctl net.netfilter.nf_conntrack_log_invalid=6
# rmmod nf_log_syslog

Paolo

> --
> Adrián
>
>
>> ovs-appctl ofproto/trace br-int
>> in_port=7753,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,tcp,nw_src=172.27.18.244,nw_dst=104.18.3.35,nw_ttl=32,tcp_src=52776,tcp_dst=443,tcp_flags=2
>> Flow: 
>> tcp,in_port=7753,vlan_tci=0x,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,nw_src=172.27.18.244,nw_dst=104.18.3.35,nw_tos=0,nw_ecn=0,nw_ttl=32,nw_frag=no,tp_src=52776,tp_dst=443,tcp_flags=syn
>> 
>> bridge("br-int")
>> 
>>   0. in_port=7753, priority 100, cookie 0xc33f39c4
>>  set_field:0x16d->reg13
>>  set_field:0x155->reg11
>>  set_field:0x1cf->reg12
>>  set_field:0x12->metadata
>>  set_field:0xca->reg14
>>  resubmit(,8)
>>   8. metadata=0x12, priority 50, cookie 0x1645d3f2
>>  set_field:0/0x1000->reg10
>>  resubmit(,73)
>>  73. 
>> ip,reg14=0xca,metadata=0x12,dl_src=4e:42:14:a1:2a:fb,nw_src=172.27.18.244,
>> priority 90, cookie 0xc33f39c4
>>  set_field:0/0x1000->reg10
>>  move:NXM_NX_REG10[12]->NXM_NX_XXREG0[111]
>>   -> NXM_NX_XXREG0[111] is now 0
>>  resubmit(,9)
>>   9. metadata=0x12, priority 0, cookie 0xcc4fd106
>>  resubmit(,10)
>> 10. metadata=0x12, priority 0, cookie 0x9e10ad0e
>>  resubmit(,11)
>> 11. metadata=0x12, priority 0, cookie 0x557f3249
>>  resubmit(,12)
>> 12. ip,metadata=0x12, priority 100, cookie 0x14131a67
>>  
>> set_field:0x1/0x1->xxreg0
>>  resubmit(,13)
>> 13. metadata=0x12, priority 0, cookie 0x85f9ed4f
>>  resubmit(,14)
>> 14. ip,reg0=0x1/0x1,metadata=0x12, priority 100, cookie 0x279651c
>>  ct(table=15,zone=NXM_NX_REG13[0..15])
>>  drop
>>   -> A clone of the packet is forked to recirculate. The forked
>> pipeline will be resumed at table 15.
>>   -> Sets the packet to an untracked state, and clears all the
>> conntrack fields.
>> 
>> Final flow: 
>> tcp,reg0=0x1,reg11=0x155,reg12=0x1cf,reg13=0x16d,reg14=0xca,metadata=0x12,in_port=7753,vlan_tci=0x,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,nw_src=172.27.18.244,nw_dst=104.18.3.35,nw_tos=0,nw_ecn=0,nw_ttl=32,nw_frag=no,tp_src=52776,tp_dst=443,tcp_flags=syn
>> Megaflow: 
>> recirc_id=0,eth,tcp,in_port=7753,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,nw_src=172.27.18.244,nw_frag=no
>> Datapath actions: ct(zone=365),recirc(0x13b5a)
>> 
>> ===
>> recirc(0x13b5a) - resume conntrack with default ct_state=trk|new (use
>> --ct-next to customize)
>> ===
>> 
>> Flow: 
>> recirc_id=0x13b5a,ct_state=new|trk,ct_zone=365,eth,tcp,reg0=0x1,reg11=0x155,reg12=0x1cf,reg13=0x16d,reg14=0xca,metadata=0x12,in_port=7753,vlan_tci=0x,dl_src=4e:42:14:a1:2a:fb,dl_dst=1a:16:b1:58:e1:cd,nw_src=172.27.18.244,nw_dst=104.18.3.35,nw_tos=0,nw_ecn=0,nw_ttl=32,nw_frag=no,tp_src=52776,tp_dst=443,tcp_flags=syn
>> 
>> bridge("br-int")
>> 
>>  thaw
>>  Resuming from table 15
>> 15. ct_state=+new-est+trk,metadata=0x12, priority 7, cookie 0xa9e0ee6f
>>  
>> set_field:0x80/0x80->xxreg0
>>  
>> set_field:0x200/0x200->xxreg0
>>  resubmit(,16)
>> 16. conj_id=2865573479,tcp,reg0=0x80/0x80,reg14=0xca,metadata=0x12,
>> priority 3000, cookie 0xabdec111
>>  set_field:0x1/0x1->xreg4
>>  
>> set_field:0x2/0x2->xxreg0
>>  resubmit(,17)
>> 17. reg8=0x1/0x1,metadata=0x12, priority 1000, cookie 0x8171c04a
>>

[neon] [Bug 484940] libkcolorpicker-qt6-0 failed to install in updates

2024-04-03 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=484940

--- Comment #6 from Valerio Galdo  ---
this worked for me:
sudo apt --fix-broken install

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 484940] libkcolorpicker-qt6-0 failed to install in updates

2024-04-02 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=484940

Valerio Galdo  changed:

   What|Removed |Added

 CC||valerio.ga...@gmail.com

--- Comment #2 from Valerio Galdo  ---
Sorry but the workaround doesn't work...
this is the  output:
libkimageannotator-qt6-0 : Depends: libkcolorpicker-qt6-0 (>= 0.3.1) but
version 0.3.0-0+22.04+jammy+release+build1 is about to be installed
E: Unsatisfied dependencies. Try "apt --fix-broken install" without packages
(or specify a workaround).

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [ovs-dev] [PATCH] conntrack: Do not use icmp reverse helper for icmpv6.

Ilya Maximets  writes:

> On 3/12/24 11:02, Paolo Valerio wrote:
>> In the flush tuple code path, while populating the conn_key,
>> reverse_icmp_type() gets called for both icmp and icmpv6 cases,
>> while, depending on the proto, its respective helper should be
>> called, instead.
>
> Thanks for the fix!
>
> Some minor nits below.
>
>> 
>> The above leads to an abort:
>> 
>> [...]
>> 0x7f3d461888ff in __GI_abort () at abort.c:79
>> 0x0064eeb7 in reverse_icmp_type (type=128 '\200') at 
>> lib/conntrack.c:1795
>> 0x00650a63 in tuple_to_conn_key (tuple=0x7ffe0db5c620, zone=0, 
>> key=0x7ffe0db5c520)
>> at lib/conntrack.c:2590
>> 0x006510f7 in conntrack_flush_tuple (ct=0x25715a0, 
>> tuple=0x7ffe0db5c620, zone=0) at lib/conntrack.c:2787
>> 0x004b5988 in dpif_netdev_ct_flush (dpif=0x25e4640, 
>> zone=0x7ffe0db5c6a4, tuple=0x7ffe0db5c620)
>> at lib/dpif-netdev.c:9618
>> 0x0049938a in ct_dpif_flush_tuple (dpif=0x25e4640, zone=0x0, 
>> match=0x7ffe0db5c7e0) at lib/ct-dpif.c:331
>> 0x0049942a in ct_dpif_flush (dpif=0x25e4640, zone=0x0, 
>> match=0x7ffe0db5c7e0) at lib/ct-dpif.c:361
>> 0x00657b9a in dpctl_flush_conntrack (argc=2, argv=0x254ceb0, 
>> dpctl_p=0x7ffe0db5c8a0) at lib/dpctl.c:1797
>> 0x0065af36 in dpctl_unixctl_handler (conn=0x25c48d0, argc=2, 
>> argv=0x254ceb0,
>> [...]
>
> Could you, please, strip out some unnecessary information from
> the trace?  For example, function addresses in hex are not
> actually needed and most of the function arguments are not
> needed as well.  Only a few of the arguments are actually important.
> Removing those will shorten the lines and make the trace more
> clear for the reader.
>
>> 
>> Fix it by calling reverse_icmp6_type() when needed.
>> Furthermore, self tests have been modified in order to exercise and
>> check this behavior.
>> 
>> Fixes: 271e48a0e244 ("conntrack: Support conntrack flush by ct 5-tuple")
>> Reported-at: https://issues.redhat.com/browse/FDP-447
>> Signed-off-by: Paolo Valerio 
>> ---
>>  lib/conntrack.c |  4 +++-
>>  tests/system-traffic.at | 10 +-
>>  2 files changed, 12 insertions(+), 2 deletions(-)
>> 
>> diff --git a/lib/conntrack.c b/lib/conntrack.c
>> index 5786424f6..a62f27d24 100644
>> --- a/lib/conntrack.c
>> +++ b/lib/conntrack.c
>> @@ -2586,7 +2586,9 @@ tuple_to_conn_key(const struct ct_dpif_tuple *tuple, 
>> uint16_t zone,
>>  key->src.icmp_type = tuple->icmp_type;
>>  key->src.icmp_code = tuple->icmp_code;
>>  key->dst.icmp_id = tuple->icmp_id;
>> -key->dst.icmp_type = reverse_icmp_type(tuple->icmp_type);
>> +key->dst.icmp_type = (tuple->ip_proto == IPPROTO_ICMP) ?
>> +reverse_icmp_type(tuple->icmp_type) :
>> +reverse_icmp6_type(tuple->icmp_type);
>
> Please, wrap the lines before ?:, not after.  And align the branches
> of the ternary to the beginning of a condition, i.e.:
>
> +key->dst.icmp_type = (tuple->ip_proto == IPPROTO_ICMP)
> + ? reverse_icmp_type(tuple->icmp_type)
> + : reverse_icmp6_type(tuple->icmp_type);
>

Thank you Ilya.
I sent a v2 with your suggestions:

https://patchwork.ozlabs.org/project/openvswitch/patch/20240328165608.273344-1-pvale...@redhat.com/

> Best regards, Ilya Maximets.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] conntrack: Do not use icmp reverse helper for icmpv6.

In the flush tuple code path, while populating the conn_key,
reverse_icmp_type() gets called for both icmp and icmpv6 cases,
while, depending on the proto, its respective helper should be
called, instead.

The above leads to an abort:

[...]
__GI_abort () at abort.c:79
reverse_icmp_type (type=128 '\200') at lib/conntrack.c:1795
tuple_to_conn_key (...) at lib/conntrack.c:2590
in conntrack_flush_tuple (...) at lib/conntrack.c:2787
in dpif_netdev_ct_flush (...) at lib/dpif-netdev.c:9618
ct_dpif_flush_tuple (...) at lib/ct-dpif.c:331
ct_dpif_flush (...) at lib/ct-dpif.c:361
dpctl_flush_conntrack (...) at lib/dpctl.c:1797
[...]

Fix it by calling reverse_icmp6_type() when needed.
Furthermore, self tests have been modified in order to exercise and
check this behavior.

Fixes: 271e48a0e244 ("conntrack: Support conntrack flush by ct 5-tuple")
Reported-at: https://issues.redhat.com/browse/FDP-447
Signed-off-by: Paolo Valerio 
---
v2 (Ilya):
- stripped down backtrace
- aligned ternary
---
 lib/conntrack.c |  4 +++-
 tests/system-traffic.at | 10 +-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index 5786424f6..7e3ed0ee0 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2586,7 +2586,9 @@ tuple_to_conn_key(const struct ct_dpif_tuple *tuple, 
uint16_t zone,
 key->src.icmp_type = tuple->icmp_type;
 key->src.icmp_code = tuple->icmp_code;
 key->dst.icmp_id = tuple->icmp_id;
-key->dst.icmp_type = reverse_icmp_type(tuple->icmp_type);
+key->dst.icmp_type = (tuple->ip_proto == IPPROTO_ICMP)
+ ? reverse_icmp_type(tuple->icmp_type)
+ : reverse_icmp6_type(tuple->icmp_type);
 key->dst.icmp_code = tuple->icmp_code;
 } else {
 key->src.port = tuple->src_port;
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 2d12d558e..87de0692a 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -3103,7 +3103,10 @@ AT_CHECK([ovs-appctl dpctl/dump-conntrack | 
FORMAT_CT(10.1.1.2)], [0], [dnl
 
icmp,orig=(src=10.1.1.1,dst=10.1.1.2,id=,type=8,code=0),reply=(src=10.1.1.2,dst=10.1.1.1,id=,type=0,code=0)
 ])
 
-AT_CHECK([ovs-appctl dpctl/flush-conntrack])
+AT_CHECK([ovs-appctl dpctl/flush-conntrack 
'ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2'])
+
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl
+])
 
 dnl Pings from ns1->ns0 should fail.
 NS_CHECK_EXEC([at_ns1], [ping -q -c 3 -i 0.3 -w 2 10.1.1.1 | FORMAT_PING], 
[0], [dnl
@@ -3244,6 +3247,11 @@ AT_CHECK([ovs-appctl dpctl/dump-conntrack | 
FORMAT_CT(fc00::2)], [0], [dnl
 
icmpv6,orig=(src=fc00::1,dst=fc00::2,id=,type=128,code=0),reply=(src=fc00::2,dst=fc00::1,id=,type=129,code=0)
 ])
 
+AT_CHECK([ovs-appctl dpctl/flush-conntrack 
'ct_ipv6_src=fc00::1,ct_ipv6_dst=fc00::2'])
+
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(fc00::2)], [0], [dnl
+])
+
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
-- 
2.44.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] conntrack: Fix SNAT with exhaustion system test.

Recent kernels introduced a mechanism that allows to evict colliding
entries in a closing state whereas they were previously considered as
parts of a non-recoverable clash.
This new behavior makes "conntrack - SNAT with port range with
exhaustion test" fail, as it relies on the previous assumptions.

Fix it by creating and not advancing the first entry in SYN_SENT to
avoid early eviction.

Suggested-by: Ilya Maximets 
Reported-at: https://issues.redhat.com/browse/FDP-486
Signed-off-by: Paolo Valerio 
---
v2:
- replaced open-coded bytes with
  'ovs-ofctl compose-packet --bare' (Ilya)
---
 tests/system-traffic.at | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 2d12d558e..20b011b7e 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -6388,7 +6388,6 @@ OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
 AT_SETUP([conntrack - SNAT with port range with exhaustion])
-OVS_CHECK_GITHUB_ACTION()
 CHECK_CONNTRACK()
 CHECK_CONNTRACK_NAT()
 OVS_TRAFFIC_VSWITCHD_START()
@@ -6398,11 +6397,11 @@ ADD_NAMESPACES(at_ns0, at_ns1)
 ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
 NS_CHECK_EXEC([at_ns0], [ip link set dev p0 address 80:88:88:88:88:88])
 ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
+NS_CHECK_EXEC([at_ns1], [ip link set dev p1 address 80:89:89:89:89:89])
 
 dnl Allow any traffic from ns0->ns1. Only allow nd, return traffic from 
ns1->ns0.
 AT_DATA([flows.txt], [dnl
-in_port=1,tcp,action=ct(commit,zone=1,nat(src=10.1.1.240:34568,random)),2
-in_port=2,ct_state=-trk,tcp,tp_dst=34567,action=ct(table=0,zone=1,nat)
+in_port=1,tcp,action=ct(commit,zone=1,nat(src=10.1.1.240:34568)),2
 in_port=2,ct_state=-trk,tcp,tp_dst=34568,action=ct(table=0,zone=1,nat)
 in_port=2,ct_state=+trk,ct_zone=1,tcp,action=1
 dnl
@@ -6426,17 +6425,28 @@ AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt])
 
 dnl HTTP requests from p0->p1 should work fine.
 OVS_START_L7([at_ns1], [http])
-NS_CHECK_EXEC([at_ns0], [wget 10.1.1.2 -t 1 -T 1 --retry-connrefused -v -o 
wget0.log])
+
+dnl Send a valid SYN to make conntrack pick it up.
+dnl The source port used is 123 to prevent unwanted reuse in the next HTTP 
request.
+syn_pkt=$(ovs-ofctl compose-packet --bare 
"eth_src=80:88:88:88:88:88,eth_dst=80:89:89:89:89:89,\
+  
dl_type=0x0800,nw_src=10.1.1.1,nw_dst=10.1.1.2,nw_proto=6,nw_ttl=64,nw_frag=no,tcp_flags=syn,\
+  tcp_src=123,tcp_dst=80")
+AT_CHECK([ovs-ofctl packet-out br0 "packet=${syn_pkt} 
actions=ct(commit,zone=1,nat(src=10.1.1.240:34568))"])
+
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | uniq], [0], 
[dnl
+tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=10.1.1.2,dst=10.1.1.240,sport=,dport=),zone=1,protoinfo=(state=)
+])
 
 NS_CHECK_EXEC([at_ns0], [wget 10.1.1.2 -t 1 -T 1 --retry-connrefused -v -o 
wget0.log], [4])
 
-AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | sed -e 
's/dst=10.1.1.2[[45]][[0-9]]/dst=10.1.1.2XX/' | uniq], [0], [dnl
-tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=10.1.1.2,dst=10.1.1.2XX,sport=,dport=),zone=1,protoinfo=(state=)
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | uniq], [0], 
[dnl
+tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=10.1.1.2,dst=10.1.1.240,sport=,dport=),zone=1,protoinfo=(state=)
 ])
 
 OVS_TRAFFIC_VSWITCHD_STOP(["dnl
 /Unable to NAT due to tuple space exhaustion - if DoS attack, use firewalling 
and\/or zone partitioning./d
-/Dropped .* log messages in last .* seconds \(most recently, .* seconds ago\) 
due to excessive rate/d"])
+/Dropped .* log messages in last .* seconds \(most recently, .* seconds ago\) 
due to excessive rate/d
+/|WARN|.* execute ct.* failed/d"])
 AT_CLEANUP
 
 AT_SETUP([conntrack - more complex SNAT])
-- 
2.44.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] conntrack: Fix SNAT with exhaustion system test.

Ilya Maximets  writes:

> On 3/13/24 12:08, Paolo Valerio wrote:
>> Recent kernels introduced a mechanism that allows to evict colliding
>> entries in a closing state whereas they were previously considered as
>> parts of a non-recoverable clash.
>> This new behavior makes "conntrack - SNAT with port range with
>> exhaustion test" fail, as it relies on the previous assumptions.
>> 
>> Fix it by creating and not advancing the first entry in SYN_SENT to
>> avoid early eviction.
>> 
>> Suggested-by: Ilya Maximets 
>> Reported-at: https://issues.redhat.com/browse/FDP-486
>> Signed-off-by: Paolo Valerio 
>> ---
>
> Hi, Paolo.  Thanks for the fix!
>

Hi Ilya,

Thanks for the feedback!

> Some small comments inline.
>
>>  tests/system-traffic.at | 21 ++---
>>  1 file changed, 14 insertions(+), 7 deletions(-)
>> 
>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
>> index 2d12d558e..04559f5e8 100644
>> --- a/tests/system-traffic.at
>> +++ b/tests/system-traffic.at
>> @@ -6388,7 +6388,6 @@ OVS_TRAFFIC_VSWITCHD_STOP
>>  AT_CLEANUP
>>  
>>  AT_SETUP([conntrack - SNAT with port range with exhaustion])
>> -OVS_CHECK_GITHUB_ACTION()
>>  CHECK_CONNTRACK()
>>  CHECK_CONNTRACK_NAT()
>>  OVS_TRAFFIC_VSWITCHD_START()
>> @@ -6398,11 +6397,11 @@ ADD_NAMESPACES(at_ns0, at_ns1)
>>  ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
>>  NS_CHECK_EXEC([at_ns0], [ip link set dev p0 address 80:88:88:88:88:88])
>>  ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
>> +NS_CHECK_EXEC([at_ns1], [ip link set dev p1 address 80:89:89:89:89:89])
>>  
>>  dnl Allow any traffic from ns0->ns1. Only allow nd, return traffic from 
>> ns1->ns0.
>>  AT_DATA([flows.txt], [dnl
>> -in_port=1,tcp,action=ct(commit,zone=1,nat(src=10.1.1.240:34568,random)),2
>> -in_port=2,ct_state=-trk,tcp,tp_dst=34567,action=ct(table=0,zone=1,nat)
>
> Do you know why this flow was there in the first place?
>

AFAICT, this seemed to me part of C/P ("conntrack - SNAT with port
range").
While at it, I preferred to clean it a bit as this (along with a couple
of minor things) was not required.

>> +in_port=1,tcp,action=ct(commit,zone=1,nat(src=10.1.1.240:34568)),2
>>  in_port=2,ct_state=-trk,tcp,tp_dst=34568,action=ct(table=0,zone=1,nat)
>>  in_port=2,ct_state=+trk,ct_zone=1,tcp,action=1
>>  dnl
>> @@ -6426,17 +6425,25 @@ AT_CHECK([ovs-ofctl --bundle add-flows br0 
>> flows.txt])
>>  
>>  dnl HTTP requests from p0->p1 should work fine.
>>  OVS_START_L7([at_ns1], [http])
>> -NS_CHECK_EXEC([at_ns0], [wget 10.1.1.2 -t 1 -T 1 --retry-connrefused -v -o 
>> wget0.log])
>> +
>> +dnl Send a valid SYN to make conntrack pick it up.
>> +dnl The source port used is 123 to prevent unwanted reuse in the next HTTP 
>> request.
>> +AT_CHECK([ovs-ofctl packet-out br0 
>> "packet=8089898989898088080045280001400664cb0a0101010a010102007b0050500220007913
>>  actions=ct(commit,zone=1,nat(src=10.1.1.240:34568))"])
>
> Can we use 'ovs-ofctl compose-packet --bare' instead of open-coding bytes?
>

sure, I'll send a v2.

> Best regards, Ilya Maximets.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[Wikimedia-l] Re: Urgent attention required because Commons is blocked in Pakistan

2024-03-24 Thread Valerio Bozzolan via Wikimedia-l

Unfortunately a VPN is not a solution at the moment.

Because of interesting historical reasons, people using VPN or other
"open proxies" cannot edit most Wikimedia projects, as default

- even if they are logged-in
- even if they are autopatrolled
- even if they are sysop (!)
- ecc.

This is an interesting "feature" that will never change without RFC.

So no, unfortunately we are not ready to suggest a VPN since it does
not immediately work, so you cannot immediately quit censorship or
similar things, at least without additional on-wiki bureaucratic
procedure.

https://phabricator.wikimedia.org/T309328

Not something I would propose to an entire nation, at the moment.

I also have no other ideas...

-boz

On Tue, 2024-03-19 at 22:03 +0530, James Heilman wrote:
> Can you not just use a VPN?
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/LFV7TJORENRAAV656GV2EPM66SZESNPB/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[kio-admin] [Bug 482552] "Create New" menu disabled in kio-admin

2024-03-22 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=482552

--- Comment #2 from Valerio Galdo  ---
Today i've installed kio-admin update, but 
the problem is still there...

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 484100] Clipboard applet breaks due to missing libZXing.so.3

2024-03-21 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=484100

--- Comment #8 from Valerio Galdo  ---
Yes, it works! Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 484100] New: clipboard no longer works

2024-03-20 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=484100

Bug ID: 484100
   Summary: clipboard no longer works
Classification: Plasma
   Product: plasmashell
   Version: master
  Platform: Neon
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Clipboard
  Assignee: plasma-b...@kde.org
  Reporter: valerio.ga...@gmail.com
  Target Milestone: 1.0

SUMMARY
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug
symbols.
See
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***


STEPS TO REPRODUCE
1. copy something to clipboard
2. open clipboard
3. clipboard is empty

OBSERVED RESULT
it is not possible to configure clipboard

EXPECTED RESULT
hystory in clipboard


SOFTWARE/OS VERSIONS
Operating System: KDE neon 6.0
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.5.0-26-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD Phenom(tm) II X4 965 Processor
Memory: 3.8 GiB of RAM
Graphics Processor: AMD CAICOS

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 483427] In Plasma 6, plasma-welcome starts every login due to old code that checks for the value of "ShouldShow" in the config file still being run for some reason

2024-03-18 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=483427

--- Comment #7 from Valerio Galdo  ---
Created attachment 167406
  --> https://bugs.kde.org/attachment.cgi?id=167406=edit
Muon screenshot


I noticed what you see in the attached screenshot

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 483427] In Plasma 6, plasma-welcome starts every login due to old code that checks for the value of "ShouldShow" in the config file still being run for some reason

2024-03-18 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=483427

--- Comment #6 from Valerio Galdo  ---
(In reply to Nate Graham from comment #4)
> Well, we still need to investigate what caused the issue. You finding a
> local workaround doesn't fix it for everyone else (which is the point of
> having a bug report to track issues). Re-opening.

Excuse me, i did'nt know...

-- 
You are receiving this mail because:
You are watching all bug changes.

[Wikimedia-l] Re: Next Conversation with the Trustees, 21 March

2024-03-15 Thread Valerio Bozzolan via Wikimedia-l

Thanks Mike :)

Can we provide streaming access also on an Open tool, like PeerTube?

It is important to allow access to Wikimedia conversations without 
requiring to become a Google customer or Zoom customer and use their
proprietary software.

I'm available to help.

Here some general info:
https://meta.wikimedia.org/wiki/Wikimedians_for_software_freedom

Best regards

-Valerio

On Thu, 2024-03-14 at 14:17 +, Mike Peel wrote:
> Hi all,
> 
> The next Conversation with the Wikimedia Foundation’s Board of
> Trustees 
> [1] will take place on Thursday, 21 March at 19:00 UTC. The 90-minute
> call will take place on Zoom, with simultaneous streaming to YouTube 
> [2], and the recording will be uploaded to Commons.
> ...
> 
> Hope to see as many of you as possible there.
> 
> 
> [1] 
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Community_Affairs_Committee/2024-03-21_Conversation_with_Trustees
> [2] https://www.youtube.com/watch?v=zuaNdf_mqSM
> [3] 
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Community_Affairs_Committee/Talking:_2024
> 
> Thanks,
> Mike, on behalf of the Community Affairs Committee, Board of
> Trustees, 
> Wikimedia Foundation
> ___
> Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org,
> guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/7IPBJNLXYUZL2KB67UUPGBSYXY6TWZAA/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/4MJACGWLGDJNNE5WBFTL5MT7GLEXAUJA/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Welcome Center] [Bug 483427] Plasma-welcome starts everytime

2024-03-14 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=483427

Valerio Galdo  changed:

   What|Removed |Added

 Status|NEEDSINFO   |RESOLVED

-- 
You are receiving this mail because:
You are watching all bug changes.

[Welcome Center] [Bug 483427] Plasma-welcome starts everytime

2024-03-14 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=483427

--- Comment #3 from Valerio Galdo  ---
ok, i added
ShouldShow=false

and now it works!
Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.

[Welcome Center] [Bug 483427] Plasma-welcome starts everytime

2024-03-14 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=483427

--- Comment #2 from Valerio Galdo  ---
ok :
[General]
LastSeenVersion=6.0.2

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: GTK on PowerPC: does anyone have it actually working?

2024-03-14 Thread Valerio Messina via macports-dev


On 3/14/24 10:33 AM, Riccardo Mottola via macports-dev wrote:

What app(s) do you use?


can you please give a try to 'ReSolve':
https://github.com/efa/ReSolve
depends on GTK3.

I normally create binaries and DMG for x86_64,
targeting Quartz, last one is:
https://github.com/efa/ReSolve/releases/download/v0.11.09hbeta/reSolve01109h_2023-08-28_MacOS_x86_64_64bit.dmg
but, a PPC (or ARM) for X11 should work too.

thank you,
--
Valerio

[ovs-dev] [PATCH] conntrack: Fix SNAT with exhaustion system test.

2024-03-13 Thread Paolo Valerio

Recent kernels introduced a mechanism that allows to evict colliding
entries in a closing state whereas they were previously considered as
parts of a non-recoverable clash.
This new behavior makes "conntrack - SNAT with port range with
exhaustion test" fail, as it relies on the previous assumptions.

Fix it by creating and not advancing the first entry in SYN_SENT to
avoid early eviction.

Suggested-by: Ilya Maximets 
Reported-at: https://issues.redhat.com/browse/FDP-486
Signed-off-by: Paolo Valerio 
---
 tests/system-traffic.at | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 2d12d558e..04559f5e8 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -6388,7 +6388,6 @@ OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
 AT_SETUP([conntrack - SNAT with port range with exhaustion])
-OVS_CHECK_GITHUB_ACTION()
 CHECK_CONNTRACK()
 CHECK_CONNTRACK_NAT()
 OVS_TRAFFIC_VSWITCHD_START()
@@ -6398,11 +6397,11 @@ ADD_NAMESPACES(at_ns0, at_ns1)
 ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
 NS_CHECK_EXEC([at_ns0], [ip link set dev p0 address 80:88:88:88:88:88])
 ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
+NS_CHECK_EXEC([at_ns1], [ip link set dev p1 address 80:89:89:89:89:89])
 
 dnl Allow any traffic from ns0->ns1. Only allow nd, return traffic from 
ns1->ns0.
 AT_DATA([flows.txt], [dnl
-in_port=1,tcp,action=ct(commit,zone=1,nat(src=10.1.1.240:34568,random)),2
-in_port=2,ct_state=-trk,tcp,tp_dst=34567,action=ct(table=0,zone=1,nat)
+in_port=1,tcp,action=ct(commit,zone=1,nat(src=10.1.1.240:34568)),2
 in_port=2,ct_state=-trk,tcp,tp_dst=34568,action=ct(table=0,zone=1,nat)
 in_port=2,ct_state=+trk,ct_zone=1,tcp,action=1
 dnl
@@ -6426,17 +6425,25 @@ AT_CHECK([ovs-ofctl --bundle add-flows br0 flows.txt])
 
 dnl HTTP requests from p0->p1 should work fine.
 OVS_START_L7([at_ns1], [http])
-NS_CHECK_EXEC([at_ns0], [wget 10.1.1.2 -t 1 -T 1 --retry-connrefused -v -o 
wget0.log])
+
+dnl Send a valid SYN to make conntrack pick it up.
+dnl The source port used is 123 to prevent unwanted reuse in the next HTTP 
request.
+AT_CHECK([ovs-ofctl packet-out br0 
"packet=8089898989898088080045280001400664cb0a0101010a010102007b0050500220007913
 actions=ct(commit,zone=1,nat(src=10.1.1.240:34568))"])
+
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | uniq], [0], 
[dnl
+tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=10.1.1.2,dst=10.1.1.240,sport=,dport=),zone=1,protoinfo=(state=)
+])
 
 NS_CHECK_EXEC([at_ns0], [wget 10.1.1.2 -t 1 -T 1 --retry-connrefused -v -o 
wget0.log], [4])
 
-AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | sed -e 
's/dst=10.1.1.2[[45]][[0-9]]/dst=10.1.1.2XX/' | uniq], [0], [dnl
-tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=10.1.1.2,dst=10.1.1.2XX,sport=,dport=),zone=1,protoinfo=(state=)
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2) | uniq], [0], 
[dnl
+tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=,dport=),reply=(src=10.1.1.2,dst=10.1.1.240,sport=,dport=),zone=1,protoinfo=(state=)
 ])
 
 OVS_TRAFFIC_VSWITCHD_STOP(["dnl
 /Unable to NAT due to tuple space exhaustion - if DoS attack, use firewalling 
and\/or zone partitioning./d
-/Dropped .* log messages in last .* seconds \(most recently, .* seconds ago\) 
due to excessive rate/d"])
+/Dropped .* log messages in last .* seconds \(most recently, .* seconds ago\) 
due to excessive rate/d
+/|WARN|.* execute ct.* failed/d"])
 AT_CLEANUP
 
 AT_SETUP([conntrack - more complex SNAT])
-- 
2.44.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[Welcome Center] [Bug 483427] Plasma-welcome starts everytime

2024-03-13 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=483427

Valerio Galdo  changed:

   What|Removed |Added

Summary|Plasma-welcom starts|Plasma-welcome starts
   |everytime   |everytime

-- 
You are receiving this mail because:
You are watching all bug changes.

[Welcome Center] [Bug 483427] New: Plasma-welcom starts everytime

2024-03-13 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=483427

Bug ID: 483427
   Summary: Plasma-welcom starts everytime
Classification: Applications
   Product: Welcome Center
   Version: unspecified
  Platform: Neon
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: valerio.ga...@gmail.com
CC: n...@kde.org
  Target Milestone: ---

SUMMARY
***
i have created a new user and everytime i login plasma-welcom starts***


STEPS TO REPRODUCE
1. create a new user
2. login
3.welcom center starts everytime

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Operating System: KDE neon 6.0
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.5.0-25-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD Phenom(tm) II X4 965 Processor
Memory: 3.8 GiB of RAM
Graphics Processor: AMD CAICOS
ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[ovs-dev] [PATCH] conntrack: Do not use icmp reverse helper for icmpv6.

2024-03-12 Thread Paolo Valerio

In the flush tuple code path, while populating the conn_key,
reverse_icmp_type() gets called for both icmp and icmpv6 cases,
while, depending on the proto, its respective helper should be
called, instead.

The above leads to an abort:

[...]
0x7f3d461888ff in __GI_abort () at abort.c:79
0x0064eeb7 in reverse_icmp_type (type=128 '\200') at 
lib/conntrack.c:1795
0x00650a63 in tuple_to_conn_key (tuple=0x7ffe0db5c620, zone=0, 
key=0x7ffe0db5c520)
at lib/conntrack.c:2590
0x006510f7 in conntrack_flush_tuple (ct=0x25715a0, 
tuple=0x7ffe0db5c620, zone=0) at lib/conntrack.c:2787
0x004b5988 in dpif_netdev_ct_flush (dpif=0x25e4640, 
zone=0x7ffe0db5c6a4, tuple=0x7ffe0db5c620)
at lib/dpif-netdev.c:9618
0x0049938a in ct_dpif_flush_tuple (dpif=0x25e4640, zone=0x0, 
match=0x7ffe0db5c7e0) at lib/ct-dpif.c:331
0x0049942a in ct_dpif_flush (dpif=0x25e4640, zone=0x0, 
match=0x7ffe0db5c7e0) at lib/ct-dpif.c:361
0x00657b9a in dpctl_flush_conntrack (argc=2, argv=0x254ceb0, 
dpctl_p=0x7ffe0db5c8a0) at lib/dpctl.c:1797
0x0065af36 in dpctl_unixctl_handler (conn=0x25c48d0, argc=2, 
argv=0x254ceb0,
[...]

Fix it by calling reverse_icmp6_type() when needed.
Furthermore, self tests have been modified in order to exercise and
check this behavior.

Fixes: 271e48a0e244 ("conntrack: Support conntrack flush by ct 5-tuple")
Reported-at: https://issues.redhat.com/browse/FDP-447
Signed-off-by: Paolo Valerio 
---
 lib/conntrack.c |  4 +++-
 tests/system-traffic.at | 10 +-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/lib/conntrack.c b/lib/conntrack.c
index 5786424f6..a62f27d24 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2586,7 +2586,9 @@ tuple_to_conn_key(const struct ct_dpif_tuple *tuple, 
uint16_t zone,
 key->src.icmp_type = tuple->icmp_type;
 key->src.icmp_code = tuple->icmp_code;
 key->dst.icmp_id = tuple->icmp_id;
-key->dst.icmp_type = reverse_icmp_type(tuple->icmp_type);
+key->dst.icmp_type = (tuple->ip_proto == IPPROTO_ICMP) ?
+reverse_icmp_type(tuple->icmp_type) :
+reverse_icmp6_type(tuple->icmp_type);
 key->dst.icmp_code = tuple->icmp_code;
 } else {
 key->src.port = tuple->src_port;
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 2d12d558e..87de0692a 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -3103,7 +3103,10 @@ AT_CHECK([ovs-appctl dpctl/dump-conntrack | 
FORMAT_CT(10.1.1.2)], [0], [dnl
 
icmp,orig=(src=10.1.1.1,dst=10.1.1.2,id=,type=8,code=0),reply=(src=10.1.1.2,dst=10.1.1.1,id=,type=0,code=0)
 ])
 
-AT_CHECK([ovs-appctl dpctl/flush-conntrack])
+AT_CHECK([ovs-appctl dpctl/flush-conntrack 
'ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2'])
+
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl
+])
 
 dnl Pings from ns1->ns0 should fail.
 NS_CHECK_EXEC([at_ns1], [ping -q -c 3 -i 0.3 -w 2 10.1.1.1 | FORMAT_PING], 
[0], [dnl
@@ -3244,6 +3247,11 @@ AT_CHECK([ovs-appctl dpctl/dump-conntrack | 
FORMAT_CT(fc00::2)], [0], [dnl
 
icmpv6,orig=(src=fc00::1,dst=fc00::2,id=,type=128,code=0),reply=(src=fc00::2,dst=fc00::1,id=,type=129,code=0)
 ])
 
+AT_CHECK([ovs-appctl dpctl/flush-conntrack 
'ct_ipv6_src=fc00::1,ct_ipv6_dst=fc00::2'])
+
+AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(fc00::2)], [0], [dnl
+])
+
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
-- 
2.44.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[systemsettings] [Bug 482573] Left handed mode doesn't work

2024-03-09 Thread valerio pachera

https://bugs.kde.org/show_bug.cgi?id=482573

--- Comment #2 from valerio pachera  ---
(In reply to Nate Graham from comment #1)
> Make sure you've got the right mouse selected in the combobox on top.
> Sometimes it has multiple devices in it, depending on your hardware
> configuration. This works as expected for me when I make sure I'm changing
> the settings for the right device.

Ops, you are right!
I didn't notice there were more than one mouse to choose from.
I confirm it works as expected.

Thank you.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 482573] Left handed mode doesn't work

2024-03-06 Thread valerio pachera

https://bugs.kde.org/show_bug.cgi?id=482573

valerio pachera  changed:

   What|Removed |Added

   Platform|Other   |Neon

-- 
You are receiving this mail because:
You are watching all bug changes.

[kde] [Bug 482573] New: Left handed mode doesn't work

2024-03-06 Thread valerio pachera

https://bugs.kde.org/show_bug.cgi?id=482573

Bug ID: 482573
   Summary: Left handed mode doesn't work
Classification: I don't know
   Product: kde
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: siri...@gmail.com
  Target Milestone: ---

SUMMARY
***
Left handed mode doesn't work
***


STEPS TO REPRODUCE
1. system settings / Mouse & touchpad / Left handed mode


OBSERVED RESULT

The mouse still work as right handed.

EXPECTED RESULT

The mouse should work as left handed.

SOFTWARE/OS VERSIONS

Operating System: KDE neon 6.0
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.5.0-21-generic (64-bit)
Graphics Platform: Wayland
Processors: 16 × 12th Gen Intel® Core™ i7-1270P
Memory: 15,3 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: Dell Inc.
Product Name: Latitude 5530

ADDITIONAL INFORMATION

It was working fine before I upgraded kde neon to plasma 6.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 482552] Open Dolphin as Adiministrator doesn't work

2024-03-06 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=482552

--- Comment #1 from Valerio Galdo  ---
Created attachment 166484
  --> https://bugs.kde.org/attachment.cgi?id=166484=edit
screen record

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 482552] New: Open Dolphin as Adiministrator doesn't work

2024-03-06 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=482552

Bug ID: 482552
   Summary: Open Dolphin as Adiministrator doesn't work
Classification: Applications
   Product: dolphin
   Version: 24.02.0
  Platform: Neon
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: dolphin-bugs-n...@kde.org
  Reporter: valerio.ga...@gmail.com
CC: kfm-de...@kde.org
  Target Milestone: ---

SUMMARY
***
When i open root dir with dolphin as administrator i can't create anything
***


STEPS TO REPRODUCE
1. Open root dir as administrator in dolphin
2. tray to create something (file or folder)
3. it's impossibile

OBSERVED RESULTl
left click is unusable

EXPECTED RESULT
able to create

SOFTWARE/OS VERSIONS
Operating System: KDE neon 6.0
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.5.0-21-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD Phenom(tm) II X4 965 Processor
Memory: 3.8 GiB of RAM
Graphics Processor: AMD CAICOS
ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[Discover] [Bug 481993] Discover fails to launch after upgrade to Neon 6.0

2024-03-03 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=481993

Valerio Galdo  changed:

   What|Removed |Added

 CC||valerio.ga...@gmail.com

--- Comment #9 from Valerio Galdo  ---
(In reply to Quinn Brown from comment #1)
> (In reply to bmhieserich from comment #0)
> > SUMMARY
> > ***
> > NOTE: If you are reporting a crash, please try to attach a backtrace with
> > debug symbols.
> > See
> > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/
> > How_to_create_useful_crash_reports
> > ***
> > After fixing the other issues with the upgrade to Plasma 6 on KDE Neon
> > through the terminal, Discover will not launch via attempting to launch
> > through any method (launcher, krunner, terminal, etc).  An instance of the
> > application shows as running in the System Monitor, but there is no window
> > or other visible sign that an instance of Discover is running.
> > 
> > STEPS TO REPRODUCE
> > 1. Attempt to launch Discover by any means (click on launcher, run
> > "plasma-discover" in terminal, launch from krunner, etc)
> > 2. Wait for Discover to finish launching to find no window opens
> > 3. Open System Monitor to notice that it shows Discover as running
> > 
> > OBSERVED RESULT
> > Discover fails to provide any usable interface to do anything with.
> > 
> > EXPECTED RESULT
> > Discover launches and is usable.
> > 
> > SOFTWARE/OS VERSIONS
> > Linux/KDE Plasma: KDE Neon 6.0
> > (available in About System)
> > KDE Plasma Version: 6.0.0
> > KDE Frameworks Version: 6.0.0
> > Qt Version: 6.6.2
> > 
> > ADDITIONAL INFORMATION
> 
> I had the same situation myself. In addition to what they said, I had an
> update notifier from Discover in my systray that worked, but I couldn't
> launch the app from it.

I have the same issue!

-- 
You are receiving this mail because:
You are watching all bug changes.

Bug#1065267: libphonenumber8-protobuf32: required package missing in repositories

2024-03-02 Thread Valerio Passini

Package: libphonenumber8-protobuf32
Severity: important
X-Debbugs-Cc: passini.vale...@gmail.com

Dear Maintainer,

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

sudo apt install gnome
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libebook-contacts-1.2-4t64 : Depends: libphonenumber8-protobuf32 but it is not
installable

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


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

Kernel: Linux 6.7.6-acer-nitro5 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to 
default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

It's impossible to install KDE in unstable

2024-03-02 Thread Valerio Passini

Hello,

I'm having a lot of troubles to install KDE in unstable, apt tells there
are held packages but I've checked and there are not.

sudo apt install plasma-desktop
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 kactivitymanagerd : Depends: libqt5sql5 (>= 5.15.2~) but it is not
installable
 libkf5plasma5 : Depends: libqt5sql5 (>= 5.15.2~) but it is not installable
 plasma-desktop : Depends: plasma-workspace (>= 4:5.27.10~) but it is not
installable
  Depends: libkf5activitiesstats1 (>= 5.102.0~) but it is
not installable
  Depends: libqt5sql5 (>= 5.15.2~) but it is not installable
  Recommends: kinfocenter (>= 4:5.27.10~) but it is not
installable
  Recommends: kio-extras but it is not installable
  Recommends: plasma-workspace-wayland (>= 4:5.27.10~) but
it is not installable
E: Unable to correct problems, you have held broken packages.

dpkg --get-selections | grep hold
gives nothing
Is it a known problem?

--

Re: [ovs-dev] [PATCH] github: Temporarily disable SNAT with exhaustion system test.

2024-03-01 Thread Paolo Valerio

Ilya Maximets  writes:

> With a new runner update, GitHub Actions had a kernel update.
> And it seems like something changed between kernels 6.2 and 6.5
> so this test now fails very frequently.
>
> I can reproduce the same issue on RHEL 9, and I can't reproduce
> it on Ubuntu 23.04 (kernel 6.2).
>
> The test is creating a NAT with a single address+port pair in
> an attempt to simulate an address space exhaustion.  It is
> expected that a first connection with wget leaves a conntrack
> entry in a TIME_WAIT state and the second wget should fail
> as long as this entry remains, because the only available
> address+port pair is already taken.
>
> However, for some reason, very frequently (not always!) the
> second connection replaces the first conntrack entry with a
> new one and connection succeeds.  There is still only one
> connection in the conntrack at any single moment in time, so
> there is seemingly no issue with the NAT, but the behavior
> is unexpected and the test fails.
>
> Disable the test in CI until we figure out how to fix the
> kernel (if it is a kernel bug) or the test.
>
> Signed-off-by: Ilya Maximets 
> ---

Acked-by: Paolo Valerio 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[neon] [Bug 481938] Unable to leave session via Desktop menu on Plasma 6.0.0

2024-03-01 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=481938

--- Comment #48 from Valerio Galdo  ---
...and anyway it works only the first time

-- 
You are receiving this mail because:
You are watching all bug changes.

[neon] [Bug 481938] Unable to leave session via Desktop menu on Plasma 6.0.0

2024-03-01 Thread Valerio Galdo

https://bugs.kde.org/show_bug.cgi?id=481938

Valerio Galdo  changed:

   What|Removed |Added

 CC||valerio.ga...@gmail.com

--- Comment #47 from Valerio Galdo  ---
(In reply to Duns from comment #6)
> ok, it works.
> However I hope the problem will be solved for all users next update.

Yes, it will be right! Not everyone can do these corrections...

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [it-users] Bug riferimenti incrociati LO writer 7.6.2.1

2024-02-29 Thread Valerio Messina

per queste situazioni puoi usare l'AppImage, è il formato "portable" di 
Linux cross-distro:


scarichi
rendi eseguibile
lanci

Valerio


On 2/29/24 9:36 AM, Alberto Benedetto wrote:

Buongiorno,
grazie per le prove fatte, sono passato alla versione 7.6.4.1 e il problema
si è risolto.
Il problema è che usando openSUSE alla versione attuale 15.5 per installare
la versione successiva ho dovuto aggiungere un repository apposito dove
l'ultima versione disponibile è appunto la 7.6.4.1. E' a mio parere
abbastanza strano che con i soli repository "ufficiali" non ci si sia
accorti che la versione 7.6.2.1 è affetta da un problema così significativo.
La cosa più spiacevole, a mio parere, è che per chi utilizza windows spesso
non è così immediato effettuare questi cambi di versione e per chi ha
installato la versione 7.6.2.1 (che magari era destinata a utilizzatori
"sperimentatori") questo problema potrebbe forse generare dei dubbi
sull'affidabilità di LO.
Grazie ancora per la collaborazione
Alberto Benedetto

Il giorno mer 28 feb 2024 alle ore 17:53 gianpaolo_marcolongo <
gianpaolo_marcolo...@newwhitebear.net> ha scritto:


Buon pomeriggio,

io sto usando la versione 24.2.0 di LO writer e ho seguito le istruzioni
riportate dal link. Non ho riprodotto l'errore ovvero la ripetizione del
nome. La versione 7.6.2 non fa parte del set di versioni supportate. -
7.6.5 - 7.6.4 - 7.5.9 - 24.2 - Forse per questo non hanno preso in
carico la segnalazione perché l'errore non si presenta nelle versioni
successive. Almeno credo. Non avendo installata le versioni 7.6.3/4/5
oppure la loro appimage non posso verificare la mia affermazione. Di
sicuro la 24.2.0, la più recente uscita, non presenta l'inconveniente
citato.

Saluti

Gian Paolo Marcolongo

Il 28/02/24 09:35, Alberto Benedetto ha scritto:

Buongiorno,
come da oggetto ho riscontrato dei problemi nella gestione dei

riferimenti

incrociati e ho effettuato la segnalazione
https://bugs.documentfoundation.org/show_bug.cgi?id=159693
Il problema mi pare abbastanza banale, quando voglio impostare un
riferimento e, ad esempio, seleziono una parola e poi esegui "imposta
riferimento", il riferimento comprensivo della parola viene posto "a
fianco" della parola stessa. Se provvisoriamente posso risolvere il
problema cancellando la parola di origine, se voglio inserire il
riferimento per un campo di digitazione la soluzione non può funzionare.
Fino alla versione 7.5.4.1 la cosa funzionava bene e la funzionalità era
valida fin dalle prime versioni di LO.
Credo di aver segnalato il bug in modo piuttosto chiaro ma mi è stato
chiuso quasi subito come "not a bug". Ho provato a riaprirlo dettagliando
un altro esempio e modificando anche il titolo ma non ho più avuto

notizie.

Potete per favore verificare anche voi il problema e aggiungere eventuali
commenti alla mia segnalazione? Magari con più segnalazioni riusciamo a
portare la nota a una priorità più alta.
Grazie
Alberto Benedetto



--
Come cancellarsi: E-mail users+unsubscr...@it.libreoffice.org
Problemi?
https://it.libreoffice.org/supporto/mailing-lists/come-cancellarsi/
Linee guida per postare + altro:
https://wiki.documentfoundation.org/Local_Mailing_Lists/it
Archivio della lista: https://listarchives.libreoffice.org/it/users/
Privacy Policy: https://www.documentfoundation.org/privacy







--
Valerio

--
Come cancellarsi: E-mail users+unsubscr...@it.libreoffice.org
Problemi? https://it.libreoffice.org/supporto/mailing-lists/come-cancellarsi/
Linee guida per postare + altro: 
https://wiki.documentfoundation.org/Local_Mailing_Lists/it
Archivio della lista: https://listarchives.libreoffice.org/it/users/
Privacy Policy: https://www.documentfoundation.org/privacy

R: Need help to install Syncope on Ubuntu Server

2024-02-26 Thread Valerio Crescia

Hi Vikrant,
Nice to read about your interest in Apache Syncope project.
Since you're running in standalone mode, did you follow the guide?
[1] https://syncope.apache.org/docs/getting-started.html#standalone
If you want to start Syncope with MySQL I suggest following this guide.
[2] https://syncope.apache.org/docs/3.0/reference-guide.html#mysql
To better understand the causes of the errors you should analyze logs in
$CATALINA_HOME/logs folder.
You wrote that you want to use Syncope to make a POC.
About this, If you want to configure and customize Syncope, please also
consider working on a Syncope archetype [3]
https://syncope.apache.org/docs/getting-started.html#create-project and use it
instead of the standalone.
Please, for this type of question use the user mailing list,
u...@syncope.apache.org.

Best
Valerio

Da: Vikrant
Inviato: domenica 25 febbraio 2024 13:31
A: dev@syncope.apache.org
Oggetto: Need help to install Syncope on Ubuntu Server

Hi,

I am trying to explore Apache Syncope, want to create POC for one of my
projects where I need to use Syncope for multiple projects' Single Sign on.

I tried to install on one of my Ubuntu Server, below is current status of
installation

* Installed prerequisites for Tomcat Server
* Installed MySQL Server 8
* Downloaded
syncope-standalone-3.0.6-distribution.zip<http://www.apache.org/dyn/closer.lua/syncope/3.0.6/syncope-standalone-3.0.6-distribution.zip>
* Done setup for Apache Tomcat which received with the Syncope Standalone
package.
* Below is current status able to access URL for
* syncope/ - Able to see Swagger UI page
* syncope-wa/ -Able to see Login Page
* syncope-console/ - Showing "Whitelabel Error Page" with 500 error
* syncope-enduser/ - Showing "Whitelabel Error Page" with 500 error
* syncope-fit-build-tools/ - Show 404 page
* Need help for below points
* As I am trying to setup POC, need to configure with MySQL Database
* Need steps to setup MySQL database for all application, as unable to
find out.
* Need help to make all 5 applications to be work.

Please let me know if any additional information require.
Request you to help me on this, so I can work forward.

Regards,
Vikrant K

Bug#1064102: shim-signed: Shim needs to be updated to latest version for Microsoft Surface devices

2024-02-17 Thread Valerio Passini

Package: shim-signed
Version: 1.40+15.7-1
Severity: normal
Tags: upstream

Dear Maintainer,

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

I tried to install Debian on a Surface Pro 9, but it doesn't boot even with
a
disabled SecureBoot (secured core must be disabled in any case).
In order to have a bootable Linux you need to hack into /efi/boot/debian and
overwrite mmx64.efi with grubx64.efi or even try more exotic actions.
Here you can find a more detailed explanation on this bug and possible
working
solutions:
https://github.com/linux-surface/linux-surface/issues/1274

[...]The good news is: This issue is fixed on the shim main branch, so once
the
distributions update their shim, this issue should disappear. The bad news
is,
that it is not possible for us to fix this, since we can't get a signed
shim /
MokManager from Microsoft.

For now there are three possible solutions:

Disable secureboot and don't enroll any certificates. This is certainly
the
easiest.
There is a Linux Mint installation image (21.2) that contains a working
MokManager. When you are trapped in the bugged state, you can use this to
finish the enrollment process. After the certificate is enrolled, you
should be
able to boot normally.
Downgrading the firmware.
[...]



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


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

Kernel: Linux 6.7.2-surface-1 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages shim-signed depends on:
ii  grub-efi-amd64-bin 2.12-1
ii  grub2-common   2.12-1
ii  shim-helpers-amd64-signed  1+15.7+1
ii  shim-signed-common 1.40+15.7-1

shim-signed recommends no packages.

shim-signed suggests no packages.

-- no debconf information

Re: [ovs-dev] [PATCH v2 2/2] conntrack: Handle persistent selection for IP addresses.

2024-02-16 Thread Paolo Valerio

Simon Horman  writes:

> On Wed, Feb 07, 2024 at 06:38:08PM +0100, Paolo Valerio wrote:
>> The patch, when 'persistent' flag is specified, makes the IP selection
>> in a range persistent across reboots.
>> 
>> Signed-off-by: Paolo Valerio 
>
> Hi Paolo,
>
> I have some minor nits below - which you can feel free to take or leave.
> But overall this looks good to me.
>
> Acked-by: Simon Horman 
>
> ...
>
>> diff --git a/lib/conntrack.c b/lib/conntrack.c
>
> ...
>
>> @@ -2386,12 +2390,23 @@ nat_get_unique_tuple(struct conntrack *ct, struct 
>> conn *conn,
>>  bool pat_proto = fwd_key->nw_proto == IPPROTO_TCP ||
>>   fwd_key->nw_proto == IPPROTO_UDP ||
>>   fwd_key->nw_proto == IPPROTO_SCTP;
>> +uint32_t hash, port_off, basis = ct->hash_basis;
>>  uint16_t min_dport, max_dport, curr_dport;
>>  uint16_t min_sport, max_sport, curr_sport;
>> -uint32_t hash, port_off;
>>  
>> -hash = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
>> -port_off = nat_info->nat_flags & NAT_RANGE_RANDOM ? random_uint32() : 
>> hash;
>> +if (nat_info->nat_flags & NAT_PERSISTENT) {
>> +basis = 0;
>> +}
>
> nit: maybe it is nicer to set basis only once.
>
> basis = (nat_info->nat_flags & NAT_PERSISTENT) ? 0 : ct->hash_basis;
>
>> +
>> +hash = nat_range_hash(fwd_key, basis, nat_info);
>> +
>> +if (nat_info->nat_flags & NAT_RANGE_RANDOM) {
>> +port_off = random_uint32();
>> +} else {
>> +port_off =
>> +basis ? hash : nat_range_hash(fwd_key, ct->hash_basis, 
>> nat_info);
>> +}
>> +
>
> nit: maybe this is a little easier on the eyes (completely untested!)?
>
> if (nat_info->nat_flags & NAT_RANGE_RANDOM) {
> port_off = random_uint32();
> } else if (basis) {
> port_off = hash;
> } else {
> port_off = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
> }
>

thanks Simon for taking a look.
Agreed, looks easier on the eyes. I included your suggestions and your
acks in v3.

I guess the above solve Aaron's suggestions as well.

>>  min_addr = nat_info->min_addr;
>>  max_addr = nat_info->max_addr;
>>  
>
> ...

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3 2/2] conntrack: Handle persistent selection for IP addresses.

2024-02-16 Thread Paolo Valerio

The patch, when 'persistent' flag is specified, makes the IP selection
in a range persistent across reboots.

Signed-off-by: Paolo Valerio 
Acked-by: Simon Horman 
---
v3:
- rearranged branches in nat_get_unique_tuple() (Simon)
---
 NEWS  |  3 ++-
 lib/conntrack.c   | 25 +++--
 lib/conntrack.h   |  1 +
 lib/dpif-netdev.c |  2 ++
 4 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/NEWS b/NEWS
index 93046b963..0c86bba81 100644
--- a/NEWS
+++ b/NEWS
@@ -2,7 +2,8 @@ Post-v3.3.0
 
- Userspace datapath:
  * Conntrack now supports 'random' flag for selecting ports in a range
-   while natting.
+   while natting and 'persistent' flag for selection of the IP address
+   from a range.
 
 
 v3.3.0 - xx xxx 
diff --git a/lib/conntrack.c b/lib/conntrack.c
index e09ecdf33..8a7056bac 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2202,17 +2202,21 @@ nat_range_hash(const struct conn_key *key, uint32_t 
basis,
 {
 uint32_t hash = basis;
 
+if (!basis) {
+hash = ct_addr_hash_add(hash, >src.addr);
+} else {
+hash = ct_endpoint_hash_add(hash, >src);
+hash = ct_endpoint_hash_add(hash, >dst);
+}
+
 hash = ct_addr_hash_add(hash, _info->min_addr);
 hash = ct_addr_hash_add(hash, _info->max_addr);
 hash = hash_add(hash,
 ((uint32_t) nat_info->max_port << 16)
 | nat_info->min_port);
-hash = ct_endpoint_hash_add(hash, >src);
-hash = ct_endpoint_hash_add(hash, >dst);
 hash = hash_add(hash, (OVS_FORCE uint32_t) key->dl_type);
 hash = hash_add(hash, key->nw_proto);
 hash = hash_add(hash, key->zone);
-
 /* The purpose of the second parameter is to distinguish hashes of data of
  * different length; our data always has the same length so there is no
  * value in counting. */
@@ -2388,10 +2392,19 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
*conn,
  fwd_key->nw_proto == IPPROTO_SCTP;
 uint16_t min_dport, max_dport, curr_dport;
 uint16_t min_sport, max_sport, curr_sport;
-uint32_t hash, port_off;
+uint32_t hash, port_off, basis;
+
+basis = (nat_info->nat_flags & NAT_PERSISTENT) ? 0 : ct->hash_basis;
+hash = nat_range_hash(fwd_key, basis, nat_info);
+
+if (nat_info->nat_flags & NAT_RANGE_RANDOM) {
+port_off = random_uint32();
+} else if (basis) {
+port_off = hash;
+} else {
+port_off = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
+}
 
-hash = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
-port_off = nat_info->nat_flags & NAT_RANGE_RANDOM ? random_uint32() : hash;
 min_addr = nat_info->min_addr;
 max_addr = nat_info->max_addr;
 
diff --git a/lib/conntrack.h b/lib/conntrack.h
index 9b0c6aa88..ee7da099e 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -79,6 +79,7 @@ enum nat_action_e {
 
 enum nat_flags_e {
 NAT_RANGE_RANDOM = 1 << 0,
+NAT_PERSISTENT = 1 << 1,
 };
 
 struct nat_action_info_t {
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c3334c667..fbf7ccabd 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -9413,6 +9413,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 nat_action_info.nat_flags |= NAT_RANGE_RANDOM;
 break;
 case OVS_NAT_ATTR_PERSISTENT:
+nat_action_info.nat_flags |= NAT_PERSISTENT;
+break;
 case OVS_NAT_ATTR_PROTO_HASH:
 break;
 case OVS_NAT_ATTR_UNSPEC:
-- 
2.43.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3 1/2] conntrack: Handle random selection for port ranges.

2024-02-16 Thread Paolo Valerio

The userspace conntrack only supported hash for port selection.
With the patch, both userspace and kernel datapath support the random
flag.

The default behavior remains the same, that is, if no flags are
specified, hash is selected.

Signed-off-by: Paolo Valerio 
Acked-by: Simon Horman 
---
 Documentation/ref/ovs-actions.7.rst |  3 +--
 NEWS|  3 +++
 lib/conntrack.c | 15 ---
 lib/conntrack.h |  5 +
 lib/dpif-netdev.c   |  4 +++-
 5 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/ref/ovs-actions.7.rst 
b/Documentation/ref/ovs-actions.7.rst
index 36adcc5db..80acd9070 100644
--- a/Documentation/ref/ovs-actions.7.rst
+++ b/Documentation/ref/ovs-actions.7.rst
@@ -1551,8 +1551,7 @@ following arguments:
 should be selected. When a port range is specified, fallback to
 ephemeral ports does not happen, else, it will.  The port number
 selection can be informed by the optional ``random`` and ``hash`` flags
-described below.  The userspace datapath only supports the ``hash``
-behavior.
+described below.
 
 The optional *flags* are:
 
diff --git a/NEWS b/NEWS
index a6617546c..93046b963 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,8 @@
 Post-v3.3.0
 
+   - Userspace datapath:
+ * Conntrack now supports 'random' flag for selecting ports in a range
+   while natting.
 
 
 v3.3.0 - xx xxx 
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 013709bd6..e09ecdf33 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -,7 +,7 @@ nat_range_hash(const struct conn_key *key, uint32_t basis,
 /* Ports are stored in host byte order for convenience. */
 static void
 set_sport_range(const struct nat_action_info_t *ni, const struct conn_key *k,
-uint32_t hash, uint16_t *curr, uint16_t *min,
+uint32_t off, uint16_t *curr, uint16_t *min,
 uint16_t *max)
 {
 if (((ni->nat_action & NAT_ACTION_SNAT_ALL) == NAT_ACTION_SRC) ||
@@ -2241,19 +2241,19 @@ set_sport_range(const struct nat_action_info_t *ni, 
const struct conn_key *k,
 } else {
 *min = ni->min_port;
 *max = ni->max_port;
-*curr = *min + (hash % ((*max - *min) + 1));
+*curr =  *min + (off % ((*max - *min) + 1));
 }
 }
 
 static void
 set_dport_range(const struct nat_action_info_t *ni, const struct conn_key *k,
-uint32_t hash, uint16_t *curr, uint16_t *min,
+uint32_t off, uint16_t *curr, uint16_t *min,
 uint16_t *max)
 {
 if (ni->nat_action & NAT_ACTION_DST_PORT) {
 *min = ni->min_port;
 *max = ni->max_port;
-*curr = *min + (hash % ((*max - *min) + 1));
+*curr = *min + (off % ((*max - *min) + 1));
 } else {
 *curr = ntohs(k->dst.port);
 *min = *max = *curr;
@@ -2388,18 +2388,19 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
*conn,
  fwd_key->nw_proto == IPPROTO_SCTP;
 uint16_t min_dport, max_dport, curr_dport;
 uint16_t min_sport, max_sport, curr_sport;
-uint32_t hash;
+uint32_t hash, port_off;
 
 hash = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
+port_off = nat_info->nat_flags & NAT_RANGE_RANDOM ? random_uint32() : hash;
 min_addr = nat_info->min_addr;
 max_addr = nat_info->max_addr;
 
 find_addr(fwd_key, _addr, _addr, , hash,
   (fwd_key->dl_type == htons(ETH_TYPE_IP)), nat_info);
 
-set_sport_range(nat_info, fwd_key, hash, _sport,
+set_sport_range(nat_info, fwd_key, port_off, _sport,
 _sport, _sport);
-set_dport_range(nat_info, fwd_key, hash, _dport,
+set_dport_range(nat_info, fwd_key, port_off, _dport,
 _dport, _dport);
 
 if (pat_proto) {
diff --git a/lib/conntrack.h b/lib/conntrack.h
index 0a888be45..9b0c6aa88 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -77,12 +77,17 @@ enum nat_action_e {
 NAT_ACTION_DST_PORT = 1 << 3,
 };
 
+enum nat_flags_e {
+NAT_RANGE_RANDOM = 1 << 0,
+};
+
 struct nat_action_info_t {
 union ct_addr min_addr;
 union ct_addr max_addr;
 uint16_t min_port;
 uint16_t max_port;
 uint16_t nat_action;
+uint16_t nat_flags;
 };
 
 struct conntrack *conntrack_init(void);
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c1981137f..c3334c667 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -9409,9 +9409,11 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 nl_attr_get_u16(b_nest);
 proto_num_max_specified = true;
 break;
+case OVS_NAT_ATTR_PROTO_RANDOM:
+nat_action_info.nat_flags |= NAT_RANGE_RANDOM;
+break;

[ovs-dev] [PATCH v2 2/2] conntrack: Handle persistent selection for IP addresses.

The patch, when 'persistent' flag is specified, makes the IP selection
in a range persistent across reboots.

Signed-off-by: Paolo Valerio 
---
 NEWS  |  3 ++-
 lib/conntrack.c   | 27 +--
 lib/conntrack.h   |  1 +
 lib/dpif-netdev.c |  2 ++
 4 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/NEWS b/NEWS
index 93046b963..0c86bba81 100644
--- a/NEWS
+++ b/NEWS
@@ -2,7 +2,8 @@ Post-v3.3.0
 
- Userspace datapath:
  * Conntrack now supports 'random' flag for selecting ports in a range
-   while natting.
+   while natting and 'persistent' flag for selection of the IP address
+   from a range.
 
 
 v3.3.0 - xx xxx 
diff --git a/lib/conntrack.c b/lib/conntrack.c
index e09ecdf33..7868a67f7 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2202,17 +2202,21 @@ nat_range_hash(const struct conn_key *key, uint32_t 
basis,
 {
 uint32_t hash = basis;
 
+if (!basis) {
+hash = ct_addr_hash_add(hash, >src.addr);
+} else {
+hash = ct_endpoint_hash_add(hash, >src);
+hash = ct_endpoint_hash_add(hash, >dst);
+}
+
 hash = ct_addr_hash_add(hash, _info->min_addr);
 hash = ct_addr_hash_add(hash, _info->max_addr);
 hash = hash_add(hash,
 ((uint32_t) nat_info->max_port << 16)
 | nat_info->min_port);
-hash = ct_endpoint_hash_add(hash, >src);
-hash = ct_endpoint_hash_add(hash, >dst);
 hash = hash_add(hash, (OVS_FORCE uint32_t) key->dl_type);
 hash = hash_add(hash, key->nw_proto);
 hash = hash_add(hash, key->zone);
-
 /* The purpose of the second parameter is to distinguish hashes of data of
  * different length; our data always has the same length so there is no
  * value in counting. */
@@ -2386,12 +2390,23 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
*conn,
 bool pat_proto = fwd_key->nw_proto == IPPROTO_TCP ||
  fwd_key->nw_proto == IPPROTO_UDP ||
  fwd_key->nw_proto == IPPROTO_SCTP;
+uint32_t hash, port_off, basis = ct->hash_basis;
 uint16_t min_dport, max_dport, curr_dport;
 uint16_t min_sport, max_sport, curr_sport;
-uint32_t hash, port_off;
 
-hash = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
-port_off = nat_info->nat_flags & NAT_RANGE_RANDOM ? random_uint32() : hash;
+if (nat_info->nat_flags & NAT_PERSISTENT) {
+basis = 0;
+}
+
+hash = nat_range_hash(fwd_key, basis, nat_info);
+
+if (nat_info->nat_flags & NAT_RANGE_RANDOM) {
+port_off = random_uint32();
+} else {
+port_off =
+basis ? hash : nat_range_hash(fwd_key, ct->hash_basis, nat_info);
+}
+
 min_addr = nat_info->min_addr;
 max_addr = nat_info->max_addr;
 
diff --git a/lib/conntrack.h b/lib/conntrack.h
index 9b0c6aa88..ee7da099e 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -79,6 +79,7 @@ enum nat_action_e {
 
 enum nat_flags_e {
 NAT_RANGE_RANDOM = 1 << 0,
+NAT_PERSISTENT = 1 << 1,
 };
 
 struct nat_action_info_t {
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c3334c667..fbf7ccabd 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -9413,6 +9413,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 nat_action_info.nat_flags |= NAT_RANGE_RANDOM;
 break;
 case OVS_NAT_ATTR_PERSISTENT:
+nat_action_info.nat_flags |= NAT_PERSISTENT;
+break;
 case OVS_NAT_ATTR_PROTO_HASH:
 break;
 case OVS_NAT_ATTR_UNSPEC:
-- 
2.43.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2 1/2] conntrack: Handle random selection for port ranges.

The userspace conntrack only supported hash for port selection.
With the patch, both userspace and kernel datapath support the random
flag.

The default behavior remains the same, that is, if no flags are
specified, hash is selected.

Signed-off-by: Paolo Valerio 
---
 Documentation/ref/ovs-actions.7.rst |  3 +--
 NEWS|  3 +++
 lib/conntrack.c | 15 ---
 lib/conntrack.h |  5 +
 lib/dpif-netdev.c   |  4 +++-
 5 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/ref/ovs-actions.7.rst 
b/Documentation/ref/ovs-actions.7.rst
index 36adcc5db..80acd9070 100644
--- a/Documentation/ref/ovs-actions.7.rst
+++ b/Documentation/ref/ovs-actions.7.rst
@@ -1551,8 +1551,7 @@ following arguments:
 should be selected. When a port range is specified, fallback to
 ephemeral ports does not happen, else, it will.  The port number
 selection can be informed by the optional ``random`` and ``hash`` flags
-described below.  The userspace datapath only supports the ``hash``
-behavior.
+described below.
 
 The optional *flags* are:
 
diff --git a/NEWS b/NEWS
index a6617546c..93046b963 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,8 @@
 Post-v3.3.0
 
+   - Userspace datapath:
+ * Conntrack now supports 'random' flag for selecting ports in a range
+   while natting.
 
 
 v3.3.0 - xx xxx 
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 013709bd6..e09ecdf33 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -,7 +,7 @@ nat_range_hash(const struct conn_key *key, uint32_t basis,
 /* Ports are stored in host byte order for convenience. */
 static void
 set_sport_range(const struct nat_action_info_t *ni, const struct conn_key *k,
-uint32_t hash, uint16_t *curr, uint16_t *min,
+uint32_t off, uint16_t *curr, uint16_t *min,
 uint16_t *max)
 {
 if (((ni->nat_action & NAT_ACTION_SNAT_ALL) == NAT_ACTION_SRC) ||
@@ -2241,19 +2241,19 @@ set_sport_range(const struct nat_action_info_t *ni, 
const struct conn_key *k,
 } else {
 *min = ni->min_port;
 *max = ni->max_port;
-*curr = *min + (hash % ((*max - *min) + 1));
+*curr =  *min + (off % ((*max - *min) + 1));
 }
 }
 
 static void
 set_dport_range(const struct nat_action_info_t *ni, const struct conn_key *k,
-uint32_t hash, uint16_t *curr, uint16_t *min,
+uint32_t off, uint16_t *curr, uint16_t *min,
 uint16_t *max)
 {
 if (ni->nat_action & NAT_ACTION_DST_PORT) {
 *min = ni->min_port;
 *max = ni->max_port;
-*curr = *min + (hash % ((*max - *min) + 1));
+*curr = *min + (off % ((*max - *min) + 1));
 } else {
 *curr = ntohs(k->dst.port);
 *min = *max = *curr;
@@ -2388,18 +2388,19 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
*conn,
  fwd_key->nw_proto == IPPROTO_SCTP;
 uint16_t min_dport, max_dport, curr_dport;
 uint16_t min_sport, max_sport, curr_sport;
-uint32_t hash;
+uint32_t hash, port_off;
 
 hash = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
+port_off = nat_info->nat_flags & NAT_RANGE_RANDOM ? random_uint32() : hash;
 min_addr = nat_info->min_addr;
 max_addr = nat_info->max_addr;
 
 find_addr(fwd_key, _addr, _addr, , hash,
   (fwd_key->dl_type == htons(ETH_TYPE_IP)), nat_info);
 
-set_sport_range(nat_info, fwd_key, hash, _sport,
+set_sport_range(nat_info, fwd_key, port_off, _sport,
 _sport, _sport);
-set_dport_range(nat_info, fwd_key, hash, _dport,
+set_dport_range(nat_info, fwd_key, port_off, _dport,
 _dport, _dport);
 
 if (pat_proto) {
diff --git a/lib/conntrack.h b/lib/conntrack.h
index 0a888be45..9b0c6aa88 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -77,12 +77,17 @@ enum nat_action_e {
 NAT_ACTION_DST_PORT = 1 << 3,
 };
 
+enum nat_flags_e {
+NAT_RANGE_RANDOM = 1 << 0,
+};
+
 struct nat_action_info_t {
 union ct_addr min_addr;
 union ct_addr max_addr;
 uint16_t min_port;
 uint16_t max_port;
 uint16_t nat_action;
+uint16_t nat_flags;
 };
 
 struct conntrack *conntrack_init(void);
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c1981137f..c3334c667 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -9409,9 +9409,11 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 nl_attr_get_u16(b_nest);
 proto_num_max_specified = true;
 break;
+case OVS_NAT_ATTR_PROTO_RANDOM:
+nat_action_info.nat_flags |= NAT_RANGE_RANDOM;
+break;
 case OVS_NAT_ATT

Re: [ovs-dev] [PATCH 2/2] conntrack: Handle persistent selection for IP addresses.

Paolo Valerio  writes:

> The patch, when 'persistent' flag is specified, makes the IP selection
> in a range persistent across reboots.
>
> Signed-off-by: Paolo Valerio 
> ---
>  NEWS  |  3 ++-
>  lib/conntrack.c   | 26 ++
>  lib/conntrack.h   |  1 +
>  lib/dpif-netdev.c |  2 ++
>  4 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 93046b963..0c86bba81 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -2,7 +2,8 @@ Post-v3.3.0
>  

The patch needs a respin because of a leftover that slipped during a
rebase.
Will send a v2.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/2] conntrack: Handle persistent selection for IP addresses.

The patch, when 'persistent' flag is specified, makes the IP selection
in a range persistent across reboots.

Signed-off-by: Paolo Valerio 
---
 NEWS  |  3 ++-
 lib/conntrack.c   | 26 ++
 lib/conntrack.h   |  1 +
 lib/dpif-netdev.c |  2 ++
 4 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index 93046b963..0c86bba81 100644
--- a/NEWS
+++ b/NEWS
@@ -2,7 +2,8 @@ Post-v3.3.0
 
- Userspace datapath:
  * Conntrack now supports 'random' flag for selecting ports in a range
-   while natting.
+   while natting and 'persistent' flag for selection of the IP address
+   from a range.
 
 
 v3.3.0 - xx xxx 
diff --git a/lib/conntrack.c b/lib/conntrack.c
index e09ecdf33..e085ddee9 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2202,17 +2202,21 @@ nat_range_hash(const struct conn_key *key, uint32_t 
basis,
 {
 uint32_t hash = basis;
 
+if (!basis) {
+hash = ct_addr_hash_add(hash, >src.addr);
+} else {
+hash = ct_endpoint_hash_add(hash, >src);
+hash = ct_endpoint_hash_add(hash, >dst);
+}
+
 hash = ct_addr_hash_add(hash, _info->min_addr);
 hash = ct_addr_hash_add(hash, _info->max_addr);
 hash = hash_add(hash,
 ((uint32_t) nat_info->max_port << 16)
 | nat_info->min_port);
-hash = ct_endpoint_hash_add(hash, >src);
-hash = ct_endpoint_hash_add(hash, >dst);
 hash = hash_add(hash, (OVS_FORCE uint32_t) key->dl_type);
 hash = hash_add(hash, key->nw_proto);
 hash = hash_add(hash, key->zone);
-
 /* The purpose of the second parameter is to distinguish hashes of data of
  * different length; our data always has the same length so there is no
  * value in counting. */
@@ -2386,12 +2390,26 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
*conn,
 bool pat_proto = fwd_key->nw_proto == IPPROTO_TCP ||
  fwd_key->nw_proto == IPPROTO_UDP ||
  fwd_key->nw_proto == IPPROTO_SCTP;
+uint32_t hash, port_off, basis = ct->hash_basis;
 uint16_t min_dport, max_dport, curr_dport;
 uint16_t min_sport, max_sport, curr_sport;
-uint32_t hash, port_off;
 
 hash = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
 port_off = nat_info->nat_flags & NAT_RANGE_RANDOM ? random_uint32() : hash;
+
+if (nat_info->nat_flags & NAT_PERSISTENT) {
+basis = 0;
+}
+
+hash = nat_range_hash(fwd_key, basis, nat_info);
+
+if (nat_info->nat_flags & NAT_RANGE_RANDOM) {
+port_off = random_uint16();
+} else {
+port_off =
+basis ? hash : nat_range_hash(fwd_key, ct->hash_basis, nat_info);
+}
+
 min_addr = nat_info->min_addr;
 max_addr = nat_info->max_addr;
 
diff --git a/lib/conntrack.h b/lib/conntrack.h
index 9b0c6aa88..ee7da099e 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -79,6 +79,7 @@ enum nat_action_e {
 
 enum nat_flags_e {
 NAT_RANGE_RANDOM = 1 << 0,
+NAT_PERSISTENT = 1 << 1,
 };
 
 struct nat_action_info_t {
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c3334c667..fbf7ccabd 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -9413,6 +9413,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 nat_action_info.nat_flags |= NAT_RANGE_RANDOM;
 break;
 case OVS_NAT_ATTR_PERSISTENT:
+nat_action_info.nat_flags |= NAT_PERSISTENT;
+break;
 case OVS_NAT_ATTR_PROTO_HASH:
 break;
 case OVS_NAT_ATTR_UNSPEC:
-- 
2.43.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/2] conntrack: Handle random selection for port ranges.

The userspace conntrack only supported hash for port selection.
With the patch, both userspace and kernel datapath support the random
flag.

The default behavior remains the same, that is, if no flags are
specified, hash is selected.

Signed-off-by: Paolo Valerio 
---
 Documentation/ref/ovs-actions.7.rst |  3 +--
 NEWS|  3 +++
 lib/conntrack.c | 15 ---
 lib/conntrack.h |  5 +
 lib/dpif-netdev.c   |  4 +++-
 5 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/ref/ovs-actions.7.rst 
b/Documentation/ref/ovs-actions.7.rst
index 36adcc5db..80acd9070 100644
--- a/Documentation/ref/ovs-actions.7.rst
+++ b/Documentation/ref/ovs-actions.7.rst
@@ -1551,8 +1551,7 @@ following arguments:
 should be selected. When a port range is specified, fallback to
 ephemeral ports does not happen, else, it will.  The port number
 selection can be informed by the optional ``random`` and ``hash`` flags
-described below.  The userspace datapath only supports the ``hash``
-behavior.
+described below.
 
 The optional *flags* are:
 
diff --git a/NEWS b/NEWS
index a6617546c..93046b963 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,8 @@
 Post-v3.3.0
 
+   - Userspace datapath:
+ * Conntrack now supports 'random' flag for selecting ports in a range
+   while natting.
 
 
 v3.3.0 - xx xxx 
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 013709bd6..e09ecdf33 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -,7 +,7 @@ nat_range_hash(const struct conn_key *key, uint32_t basis,
 /* Ports are stored in host byte order for convenience. */
 static void
 set_sport_range(const struct nat_action_info_t *ni, const struct conn_key *k,
-uint32_t hash, uint16_t *curr, uint16_t *min,
+uint32_t off, uint16_t *curr, uint16_t *min,
 uint16_t *max)
 {
 if (((ni->nat_action & NAT_ACTION_SNAT_ALL) == NAT_ACTION_SRC) ||
@@ -2241,19 +2241,19 @@ set_sport_range(const struct nat_action_info_t *ni, 
const struct conn_key *k,
 } else {
 *min = ni->min_port;
 *max = ni->max_port;
-*curr = *min + (hash % ((*max - *min) + 1));
+*curr =  *min + (off % ((*max - *min) + 1));
 }
 }
 
 static void
 set_dport_range(const struct nat_action_info_t *ni, const struct conn_key *k,
-uint32_t hash, uint16_t *curr, uint16_t *min,
+uint32_t off, uint16_t *curr, uint16_t *min,
 uint16_t *max)
 {
 if (ni->nat_action & NAT_ACTION_DST_PORT) {
 *min = ni->min_port;
 *max = ni->max_port;
-*curr = *min + (hash % ((*max - *min) + 1));
+*curr = *min + (off % ((*max - *min) + 1));
 } else {
 *curr = ntohs(k->dst.port);
 *min = *max = *curr;
@@ -2388,18 +2388,19 @@ nat_get_unique_tuple(struct conntrack *ct, struct conn 
*conn,
  fwd_key->nw_proto == IPPROTO_SCTP;
 uint16_t min_dport, max_dport, curr_dport;
 uint16_t min_sport, max_sport, curr_sport;
-uint32_t hash;
+uint32_t hash, port_off;
 
 hash = nat_range_hash(fwd_key, ct->hash_basis, nat_info);
+port_off = nat_info->nat_flags & NAT_RANGE_RANDOM ? random_uint32() : hash;
 min_addr = nat_info->min_addr;
 max_addr = nat_info->max_addr;
 
 find_addr(fwd_key, _addr, _addr, , hash,
   (fwd_key->dl_type == htons(ETH_TYPE_IP)), nat_info);
 
-set_sport_range(nat_info, fwd_key, hash, _sport,
+set_sport_range(nat_info, fwd_key, port_off, _sport,
 _sport, _sport);
-set_dport_range(nat_info, fwd_key, hash, _dport,
+set_dport_range(nat_info, fwd_key, port_off, _dport,
 _dport, _dport);
 
 if (pat_proto) {
diff --git a/lib/conntrack.h b/lib/conntrack.h
index 0a888be45..9b0c6aa88 100644
--- a/lib/conntrack.h
+++ b/lib/conntrack.h
@@ -77,12 +77,17 @@ enum nat_action_e {
 NAT_ACTION_DST_PORT = 1 << 3,
 };
 
+enum nat_flags_e {
+NAT_RANGE_RANDOM = 1 << 0,
+};
+
 struct nat_action_info_t {
 union ct_addr min_addr;
 union ct_addr max_addr;
 uint16_t min_port;
 uint16_t max_port;
 uint16_t nat_action;
+uint16_t nat_flags;
 };
 
 struct conntrack *conntrack_init(void);
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c1981137f..c3334c667 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -9409,9 +9409,11 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 nl_attr_get_u16(b_nest);
 proto_num_max_specified = true;
 break;
+case OVS_NAT_ATTR_PROTO_RANDOM:
+nat_action_info.nat_flags |= NAT_RANGE_RANDOM;
+break;
 case OVS_NAT_ATT

Re: GEDA site dead?

2024-01-27 Thread Valerio Messina via macports-dev


domain was http://www.geda-project.org/
see: https://en.wikipedia.org/wiki/GEDA
seems payd till October 2024 but now is down

gEDA development has always been with the main focus on Linux and have 
never cared about macOS and Windows.
In recent years, competition from KiCad (which is madly actively 
developed cross platform by CERN and is still GPL) I think has killed 
the development of gEDA. The only exception is GerbV which is still 
maintained and is quite up to date for Linux and Windows, but not for macOS:

https://github.com/gerbv/gerbv

In reality GerbV has always been the only program in the package to 
compile correctly for Windows, I generated it annually for Linux and 
Windows colleagues, and due to its ease I still find it superior to the 
one integrated into KiCad, even if it does not support the Gerber X2 
standard is become obsolete.



Take a look to Lepton:
https://github.com/lepton-eda/lepton-eda
seems mantained

Valerio


On 1/27/24 1:46 PM, Nils Breunese wrote:

I’m not familiar with gEDA, but according to 
https://github.com/macports/macports-ports/blob/master/science/geda-gaf/Portfile
 the homepage is http://www.geda-project.org/

But requests to both the .com and the .org domains indeed fail for me.

Nils.


Op 26 jan 2024, om 03:37 heeft Mark Anderson  het volgende 
geschreven:

I've been having trouble getting to http://www.geda-project.com/ - anyone else? 
This doesn't bode well for the project / Portfile. It might be time to retire 
it, or mark it as deprecated.

—Mark
___
Mark E. Anderson 
MacPorts Trac WikiPage
GitHub Profile



--
Valerio

Re: pre-built quartz variant packages

2024-01-22 Thread Valerio Messina via macports-dev

> Il 17/01/2024 03:00 CET Joshua Root  ha scritto:
> I agree that the UX surrounding the quartz/x11 choice is bad. 
> Unfortunately it's harder to fix than you might hope, and gtk3 itself 
> may be the easiest part of the puzzle. A number of other ports like 
> glib2 and cairo are also involved, and have to support other dependents 
> that may be using gtk2 or something else entirely. Many intermediate 
> dependencies build differently depending on whether they are built 
> against quartz or x11 variants of their dependencies, so there's a whole 
> chain that has to be managed. Some ports fail to build against quartz 
> dependencies.
> 
> The proposed solution to all of the above is to split everything that 
> both has dependents and is affected by the quartz/x11 choice into two 
> subports. Unfortunately nobody has yet implemented this.

I saw that GTK 4.12 is the stable version, while GTK 3.24 is lastest old stable 
[1].
To download GTK 2 you have to go to 3.x download page [2] and navigate path up 
and down to find them. Seems 2.x do not receive update from 2019.

I know that there are still many GTK 2.x based app around (GIMP 2.10.36 too, 
while imminent GIMP 3.x will be based on GTK3.x), but those shouldn't be the 
main/default focus of the project.
Like I read for old target HW platform, you should accept fix, but please focus 
on current libraries.

In my opinion (at least for GTK) macpoprt should target to Quartz variant as 
default, and keep the Xquartz as "optional". If possible let users to install 
both. The variants mechanism seems good for its flexibility, plase use it.

Note: Glib is a prerequisite for both GTK2 and 3, I'm not sure but I expect 
should build independently of the graphics backend used by the upper layers GTK 
and GDK.

my 2 cents
thank you,
Valerio

[1] https://www.gtk.org/
[2] https://download.gnome.org/sources/gtk+/3.24/

Re: pre-built quartz variant packages

2024-01-16 Thread Valerio Messina via macports-dev


sorry, I have never made a native port installation.

But given the syntax I found online:
$ port install  + -
I expect a user can install every variant

If only default variant is pre-built what is shown by:
$ port variants gtk3
?

Native gtk3 building on macOS is trivial, I made that from source 
following instruction on GTK web site, and I use that for packaging of 
my applications.
Anyway this is not the macport version, it the one from gtk.org and is 
only source not pre-build.
Is trivial but require time, and again on new version, and require a 
developer access to macOS on another machine dedicated to that.


Using the pre-built gtk3 from macport (and osxcross), saved me the 
library built time just for test of my apps, and the requirement to 
access macOS on every run.
Then I discovered to start the app I had to install Xquartz on the real 
hw, and this is not a thing normal user is used to do, or is able to or 
want to do.


Seems to me that native Quartz variant of gtk3 work like or better than 
Xquartz (default) variant. At least better than gtk on Win.


Really hope you can please provide the gtk3 pre-built Quartz variant

a newby of macOS
thank you,
Valerio


On 1/14/24 5:08 PM, Sergio Had wrote:

AFAIK ports are only being pre-built with the default variant.

GTK should be trivial to build though.

>
On Jan 14, 2024 at 23:58 +0800, Valerio Messina via macports-dev 
, wrote:

I'm not sure this is the right list to ask for pre-built macports.

In case can you please direct me to the right one?

thank you,
Valerio


On 12/5/23 10:47 PM, Valerio Messina via macports-dev wrote:

hi,
as a user of osxcross, I also use the good of macports.
I read that is not your main target, but tolerate cross-built from other
OS. I'm on Debian.

I saw there are pre-built packages here:
https://packages.macports.org/
and this is where the 'osxcross-macport' get the packages.

Native macport client has support for variants with something like:
$ port variants  # show package variants
$ port install  + -   # install variant1, not variant2

I saw on packages.macports.org there are only X11 packages, and seems
native quartz variant are missing.
So for example for gtk3-devel:
https://ports.macports.org/port/gtk3-devel/details/
is available for X11 backend only as pre-built for foreign OS.

Is there a reason for this?

Having native quartz pre-built packages will help developer to target
quartz instead of xquartz, without the need to (cross)build the GTK
itself. This is so for other library with variants.

As now the bash script 'osxcross-macport' do not support variants, but
I'm sure can be easily upgraded if packages server will host quartz
variants.

thank you for explanation and work,



--
Valerio



--
Valerio

Re: smartctl cannot access my storage, need syntax help

2024-01-16 Thread Valerio Vanni


Il 16/01/2024 12:08, Felix Miata ha scritto:

Tom Furie composed on 2024-01-16 08:18 (UTC):


Felix Miata writes:



/dev/sdc 18 /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0 #
How does a printer get a storage device assignment???



By having some kind of SD card slot or similar.


So this pollution only results from a USB-connected printer? IP printer
connections don't cause it too?

Yes, IP printers don't.

[kaffeine] [Bug 479872] New: Option --lastchannel doesn't free dvb adapter after stop

2024-01-15 Thread Valerio Vanni

https://bugs.kde.org/show_bug.cgi?id=479872

Bug ID: 479872
   Summary: Option --lastchannel doesn't free dvb adapter after
stop
Classification: Applications
   Product: kaffeine
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mche...@kernel.org
  Reporter: valerio.va...@inwind.it
  Target Milestone: ---

SUMMARY
***
If I start kaffeine without options and I play a DVB channel when I click stop,
kaffeine frees immediately /dev/dvb/xxx device.
If I start kaffeine with --lastchannel and do the same (click stop),
/dev/dvb/xxx device is busy.

A child process is locking it: 

lsof finds this:
kioslave5 21356  valerio   35u  CHR 
212,3 0t01173529 /dev/dvb/adapter0/frontend0

  21356 ?S  0:00 /lib/x86_64-linux-gnu/libexec/kf5/kioslave5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags 
local:/run/user/1000/kaffeineppPvOO.1.kioworker.socket

After some minutes, this process ends and dvb device is free an can be
rmmod-ed.

***

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian Bookworm 64 bit
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.18

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: Change suspend type from kde menu

2024-01-15 Thread Valerio Vanni


Il 12/01/2024 22:51, Valerio Vanni ha scritto:

As Max replied to that post saying that you could avoid to kill 
Kaffeine   now you can try to:


- stop Kaffeine
- rmmod the module (what happens if you force unloading: -f option)
- suspend
- resume
- modprobe the module
- play Kaffeine

but I bet you've already realized that :)


Yes, it's what I'm going to try :-)


I found another issue: kaffeine also records DVB channels.

So, if I stop play but it's recording, module cannot be removed.

In method I find a "toggle instant record", but it doesn't help because 
it changes between on and off. If it's not recording and I "toggle", 
then it starts recording and grabs device.

It doesn't seem simple to tell *if* it's recording.

Re: Change suspend type from kde menu

2024-01-15 Thread Valerio Vanni


Il 14/01/2024 05:04, Max Nikulin ha scritto:

lsof for the same process may be more informative, but currently it 
does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does 
not set the O_CLOEXEC flag for open(2) (or does not call fcntl with 
FD_CLOEXEC). As a result, file descriptors leak to spawned processes. 
I suggest to reach a community more close to kaffeine (or maybe 
baloo) developers and ask if it could be improved.


In my system baloo is disabled.


Which package does tags.so belong to in your case?

I believe you that file indexer is disabled, but some components may 
still be called for reasons unclear for me. Maybe they do something 
useful. 


tags.so belongs to baloo-kf5, but "balooctl --status" says that it's 
disabled.

Re: pre-built quartz variant packages

2024-01-14 Thread Valerio Messina via macports-dev


I'm not sure this is the right list to ask for pre-built macports.

In case can you please direct me to the right one?

thank you,
Valerio


On 12/5/23 10:47 PM, Valerio Messina via macports-dev wrote:

hi,
as a user of osxcross, I also use the good of macports.
I read that is not your main target, but tolerate cross-built from other 
OS. I'm on Debian.


I saw there are pre-built packages here:
https://packages.macports.org/
and this is where the 'osxcross-macport' get the packages.

Native macport client has support for variants with something like:
$ port variants  # show package variants
$ port install  + -   # install variant1, not variant2

I saw on packages.macports.org there are only X11 packages, and seems 
native quartz variant are missing.

So for example for gtk3-devel:
https://ports.macports.org/port/gtk3-devel/details/
is available for X11 backend only as pre-built for foreign OS.

Is there a reason for this?

Having native quartz pre-built packages will help developer to target 
quartz instead of xquartz, without the need to (cross)build the GTK 
itself. This is so for other library with variants.


As now the bash script 'osxcross-macport' do not support variants, but 
I'm sure can be easily upgraded if packages server will host quartz 
variants.


thank you for explanation and work,



--
Valerio

Re: Change suspend type from kde menu

2024-01-13 Thread Valerio Vanni


Il 13/01/2024 16:20, Max Nikulin ha scritto:


And this is one with a --lastchannel launch:
lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> 
/dev/dvb/adapter0/frontend0


lsof for the same process may be more informative, but currently it does 
not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set 
the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). 
As a result, file descriptors leak to spawned processes. I suggest to 
reach a community more close to kaffeine (or maybe baloo) developers and 
ask if it could be improved.


In my system baloo is disabled.

Re: Change suspend type from kde menu


Il 12/01/2024 21:15, Franco Martelli ha scritto:


 > Tried, it works on DVB play.
 >
 > dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Stop


As Max replied to that post saying that you could avoid to kill Kaffeine 
  now you can try to:


- stop Kaffeine
- rmmod the module (what happens if you force unloading: -f option)
- suspend
- resume
- modprobe the module
- play Kaffeine

but I bet you've already realized that :)


Yes, it's what I'm going to try :-)
Force module unloading cannot work, it requires a specific option in 
kernel config that I've never enabled.


You can also try to not remove the module and check if stop Kaffeine, 
suspend/resume, play Kaffeine is enough.


The module does not support suspend / resume at all.
If you boot the system, *don't* open kaffeine or anything, suspend and 
resume, module is already in an unworkable state.

Re: Change suspend type from kde menu


Il 12/01/2024 17:24, Max Nikulin ha scritto:

On 12/01/2024 21:36, Valerio Vanni wrote:


Tried, it works on DVB play.

dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Stop


The question is if this action can be a replacement for killing kaffeine 
before unloading the dvb kernel module.


I'll try. It could make the script simpler.
If I launch kaffeine without --lastchannel, it should work. That way I'd 
have to open tv interface by hand when I start kaffeine.


What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof 
report? I still had a hope that there is a workarond against its 
annoying behavior.


This is a file descriptors list of kioslave process, with a plain launch:

lrwx-- 1 valerio valerio 64 12 gen 20.53 0 -> /dev/pts/1
lrwx-- 1 valerio valerio 64 12 gen 20.53 1 -> /dev/pts/1
lrwx------ 1 valerio valerio 64 12 gen 20.53 19 -> '/memfd:pulseaudio 
(deleted)'

lrwx-- 1 valerio valerio 64 12 gen 20.53 2 -> /dev/pts/1
lr-x-- 1 valerio valerio 64 12 gen 20.53 25 -> 
/run/user/1000/dvbpipe.m2t
l-wx-- 1 valerio valerio 64 12 gen 20.53 26 -> 
/run/user/1000/dvbpipe.m2t

lrwx-- 1 valerio valerio 64 12 gen 20.53 3 -> 'anon_inode:[eventfd]'
lr-x------ 1 valerio valerio 64 12 gen 20.53 31 -> anon_inode:inotify
lrwx-- 1 valerio valerio 64 12 gen 20.53 4 -> 'socket:[10323613]'

And this is one with a --lastchannel launch:

lr-x-- 1 valerio valerio 64 12 gen 20.52 0 -> 'pipe:[9256505]'
lrwx-- 1 valerio valerio 64 12 gen 20.52 1 -> 'socket:[71658]'
lrwx-- 1 valerio valerio 64 12 gen 20.52 19 -> '/memfd:pulseaudio 
(deleted)'

lrwx-- 1 valerio valerio 64 12 gen 20.52 2 -> 'socket:[71658]'
lr-x-- 1 valerio valerio 64 12 gen 20.52 25 -> 
/run/user/1000/dvbpipe.m2t
l-wx-- 1 valerio valerio 64 12 gen 20.52 26 -> 
/run/user/1000/dvbpipe.m2t

lrwx-- 1 valerio valerio 64 12 gen 20.52 3 -> 'anon_inode:[eventfd]'
lr-x-- 1 valerio valerio 64 12 gen 20.52 31 -> anon_inode:inotify
lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> 
/dev/dvb/adapter0/frontend0

lr-x-- 1 valerio valerio 64 12 gen 20.52 36 -> 'pipe:[9253331]'
l-wx-- 1 valerio valerio 64 12 gen 20.52 37 -> 'pipe:[9253331]'
lrwx-- 1 valerio valerio 64 12 gen 20.52 4 -> 'socket:[9247546]'
lr-x-- 1 valerio valerio 64 12 gen 20.52 48 -> anon_inode:inotify
lrwx-- 1 valerio valerio 64 12 gen 20.52 54 -> '/memfd:pulseaudio 
(deleted)'


But perhaps it says nothing new.

Re: Change suspend type from kde menu


Il 12/01/2024 15:03, Franco Martelli ha scritto:

On 11/01/24 at 15:10, Valerio Vanni wrote:
Yes, I tried, but I didn't see any "stop". There is a .Quit, but for 
this I already have "kill" command and I have to start it again.


valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /


Out of curiosity could you post the output of the following command:

~$ busctl --user tree | grep mpris


Service org.mpris.kaffeine:

Another question, can Kaffeine stop the video? Do you have a "Stop" 
button  to click over?


Yes, it has play/stop button.

Re: Change suspend type from kde menu


Il 12/01/2024 12:08, Valerio Vanni ha scritto:

Il 12/01/2024 03:52, Max Nikulin ha scritto:

I assume that "org/mpris/MediaPlayer2" after "/" was lost during 
copy


I don't have MediaPlayer2 there.


busctl --user introspect org.mpris.kaffeine /Player
# ...
.Stop   method    - -    -


I saw that, but I think it's for media player component of kaffeine.
With that, you could stop the play of an audio or video file.

Do you think it can also act on DVB channels?
I can give it a try.


Tried, it works on DVB play.

dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Stop


dbus-send --print-reply --dest=org.mpris.kaffeine /Player 
org.freedesktop.MediaPlayer.Play

Re: Change suspend type from kde menu


Il 12/01/2024 03:52, Max Nikulin ha scritto:

I assume that "org/mpris/MediaPlayer2" after "/" was lost during 
copy


I don't have MediaPlayer2 there.


busctl --user introspect org.mpris.kaffeine /Player
# ...
.Stop   method    - -    -


I saw that, but I think it's for media player component of kaffeine.
With that, you could stop the play of an audio or video file.

Do you think it can also act on DVB channels?
I can give it a try.

So it is baloo (former nepomuk) search framework. A crazy idea is to 
add /dev to the list of directories that should not be indexed. I 
would try to disable baloo completely to see if behavior in respect 
to rmmmod changes.


Baloo is already disabled.

Finally I am confused. If tags.so processes die after some interval of 
time, does it mean that the kernel module can be unloaded even when 
kaffeine is started with --lastchannel and enough time has passed since 
its start?


From its stop, not from its start. There are two main cases: plain 
kaffeine and lastchannel one.


I open kaffeine without options, I play a DVB channel.
kioslave process is active, but has no lock on /dev/dvb/*
I stop play and I can immediately remove module. Even if that kioslave 
process is active.



I open kaffeine with --lastchannel, and kioslave process already has a 
lock on /dev/dvb/*
I stop play and cannot remove module, it's locked from kioslave. When 
some minute has passed, kioslave disappears and I can remove module.


Now I see another case: even during channel play, some time kioslave 
process disappears. At that point, if I stop play, I can remove module.

Re: Vmware Workstation help opens abiword


Il 11/01/2024 15:42, Max Nikulin ha scritto:

On 11/01/2024 20:18, Valerio Vanni wrote:

Now it's working, but I don't understand why.



Now I find this:

/usr/share/applications/mimeinfo.cache:text/html=abiword.desktop;firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;org.kde.kimagemapeditor.desktop;
/usr/share/applications/mimeinfo.cache:x-scheme-handler/http=firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;


So Abiword does not pretend to be an http: protocol handler, just an 
application supporting HTML files.



/home/valerio/.config/mimeapps.list:text/html=firefox-esr.desktop;


Likely you have changed file associations for HTML files from KDE System 
Settings. Try to move away ~/.config/mimeapps.list or comment out 
text/html entry there and Abiword should pop back.


I confirm, it does pop back.
And every change (moving file) needs logout and login to take effect.

But I remember I already had done that (change kde settings, logout, login).

Re: Change suspend type from kde menu


Il 11/01/2024 16:25, Max Nikulin ha scritto:

On 11/01/2024 21:10, Valerio Vanni wrote:

There is a .Quit, but for this I already have "kill" command and I have
to start it again.


Applications might handle D-Bus messages more gracefully than SIGINT or 
SIGTERM signals. However in the case of kaffeine it is unlikely that 
some data may be lost.


It's what I think too.


valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /


I assume that "org/mpris/MediaPlayer2" after "/" was lost during 
copy


I don't have MediaPlayer2 there.

/lib/x86_64-linux-gnu/libexec/kf5/kioslave5 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags 
local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket


So it is baloo (former nepomuk) search framework. A crazy idea is to add 
/dev to the list of directories that should not be indexed. I would try 
to disable baloo completely to see if behavior in respect to rmmmod 
changes.


I am surprised that it dies immediately if you kill kaffeine.


It seems to always die, I've never had an error during rmmod.

Re: Change suspend type from kde menu


Il 11/01/2024 15:21, Valerio Vanni ha scritto:

Il 11/01/2024 04:57, Max Nikulin ha scritto:

On 10/01/2024 04:43, Valerio Vanni wrote:

Il 07/01/2024 06:44, Max Nikulin ha scritto:


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm



setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" >  $kafdis 
XDG_CURRENT_DESKTOP=KDE \

---^^^

Do you really need it?


It's all left there from when I used setpriv to launch directly 
kaffeine, before I decided to use systemd-run.
I'll try to remove it, now I checked and they are all listed in systemd 
user environment.


I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error 
"Failed to connect to bus: No medium found"

Re: Change suspend type from kde menu


Il 11/01/2024 04:57, Max Nikulin ha scritto:

On 10/01/2024 04:43, Valerio Vanni wrote:

Il 07/01/2024 06:44, Max Nikulin ha scritto:


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm



setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" >  $kafdis 
XDG_CURRENT_DESKTOP=KDE \

---^^^

Do you really need it?


It's all left there from when I used setpriv to launch directly 
kaffeine, before I decided to use systemd-run.
I'll try to remove it, now I checked and they are all listed in systemd 
user environment.



I find it not really safe to use $kafdis without quotes.


Yes, neither I liked to catch that string. But I considered it a 
temporary solution.

Re: Change suspend type from kde menu


Il 11/01/2024 05:10, Max Nikulin ha scritto:

On 10/01/2024 01:59, Valerio Vanni wrote:

Il 06/01/2024 17:38, Max Nikulin ha scritto:


I would expect something like "Stop" either from /Player or from 
org.mpris.kaffeine.


I too expected something similar: stop and play (play for resume)


Have you tried "tree" and "introspect" for org.mpris.kaffeine (not 
org.kde.kaffeine)? It works for mpv:


Yes, I tried, but I didn't see any "stop". There is a .Quit, but for 
this I already have "kill" command and I have to start it again.


valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /
NAMETYPE  SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer   interface - --
.GetMachineId   method- s-
.Ping   method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv   --
.PropertiesChanged  signalsa{sv}as  --
org.freedesktop.MediaPlayer interface - --
.Identity   method- s-
.MprisVersion   method- (qq) -
.Quit   method- --




busctl --user call org.mpris.MediaPlayer2.mpv \
     /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \
     Stop


For this we don't need to look here:
"rmmod: ERROR: Module cx23885 is in use" seems enough to see that 
kernel module cannot be removed.


I am surprised by it. You have shown that kaffeine closes the device, so 
it should be possible to remove the kernel module:



Started with --lastchannel
Video stopped:
lrwx-- 1 valerio valerio 64  9 gen 19.51 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.51 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 9 -> /dev/dri/card0

no more /dev/dvb/, but still unable to remove module cx23885


My hypotheses:
- there are more kaffeine processes (ps xuwf)


No, it has only one.

- some external process is holding the device, e.g. pulseaudio or 
pipeware sound server. Tools that might help to find it: lsof or fuser 
(unsure concerning proper options)

- Some other IPC exposed by the driver and used by kaffeine.
- I have not idea if it is possible to create direct connection between 
the dvb device and the video card so that data pass without intermediate 
interaction with kaffeine.


fuser -a /dev/dvb/adapter0/demux0 shows nothing
lsof | grep /dev/dvb shows

  10315 ?S  0:00 
/lib/x86_64-linux-gnu/libexec/kf5/kioslave5 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags 
local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket


But after some minutes this process disappeared, and I could rmmod.
Perhaps with --lastchannel it's slower to release it?

Re: Change suspend type from kde menu


Il 11/01/2024 04:48, Max Nikulin ha scritto:

So your idea would be stopping and starting channel play by dbus 
messages?
I'm looking again with introspect, and I don't see anything like 
"stop" in kaffeine.


It is independent ideas:
- Do not deal with user processes in system context (like 
/usr/lib/systemd/system-sleep/ scripts)

- Try to release dvb tuner device, so module can be unloaded.

I believe, it is a bug in the cx23885 module that it can not handle 
suspend/resume (and probably hibernate/thaw).


I agree.
If cx23885 module could handle suspend/resume, we wouldn't need all this 
mess.


Since we are talking about this module, I quote from another of your 
messages:



P.S. You have explicit modprobe cx23885. Does it mean that this module is not 
autoloaded when udev discovers the device?


The module is autoloaded when system boots.
But if I (after having moved away the script from 
/usr/lib/systemd/system-sleep/)


rmmod
systemctl-suspend
resume pc

the module is not loaded.

When I used pm-suspend, remove and reload was managed from the line
SUSPEND_MODULES="cx23885" in /etc/pm/config.d/modules

And now from rmmod and modprobe in my script.
By itself... no load.

The following is related to avoiding "setpriv" in system context and 
listening for D-Bus events in user session scope:


$ dbus-monitor --system 
"type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'"


suspend:

signal time=1704679441.870349 sender=:1.6 -> destination=(null 
destination) serial=3187 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; 
member=PrepareForSleep^^^

    boolean true


resume:

signal time=1704679448.065409 sender=:1.6 -> destination=(null 
destination) serial=3233 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; member=PrepareForSleep

    boolean false

---^

A tiny python script may be more convenient than dbus-monitor and 
similar tools.


Killing and starting kaffeine in response to these signals may be a 
workaround if the application does not allow to release the device.


Not stopping playback and not releasing the device in response to the 
PrepareForSleep signal, from my point of view, is a bug in kaffeine. I 
have no idea if vlc (broken hardware acceleration in bookworm) or 
another application may be an alternative for you.


To watch television, kaffeine seems very good to me.

Re: Vmware Workstation help opens abiword


Il 11/01/2024 03:33, Max Nikulin ha scritto:

On 11/01/2024 02:44, Valerio Vanni wrote:
After, guide was not showing anymore. Calling it (click on "help" on 
Vmware application) began opening Abiword.


In kde control panel -> app -> default, Firefox is set as default 
browser.


Likely when sorted by name Abiword is before Firefox and even before 
Chromium. So you you need to override defaults in a mimeapps.list either 
system-wide or user-wide.
Now it's working, but I don't understand why. When I was trying to check 
those locations, I found it working.
But it should have been something other. Perhaps something in sequence 
between uninstall abiword, reinstall abiword, modify default browser etc.


Now I find this:

/usr/share/applications/mimeinfo.cache:application/xhtml+xml=abiword.desktop;firefox-esr.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;
/usr/share/applications/mimeinfo.cache:application/xhtml_xml=google-chrome.desktop;
/usr/share/applications/mimeinfo.cache:text/html=abiword.desktop;firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;org.kde.kimagemapeditor.desktop;
/usr/share/applications/mimeinfo.cache:x-scheme-handler/http=firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;
/usr/share/applications/mimeinfo.cache:x-scheme-handler/https=firefox-esr.desktop;google-chrome.desktop;kfmclient_html.desktop;org.gnome.Epiphany.desktop;
grep: /etc/xdg/mimeapps.list: File o directory non esistente
/home/valerio/.config/mimeapps.list:text/html=firefox-esr.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/http=firefox-esr.desktop;kfmclient_html.desktop;abiword.desktop;google-chrome.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/https=firefox-esr.desktop;kfmclient_html.desktop;abiword.desktop;google-chrome.desktop;
/home/valerio/.config/mimeapps.list:text/html=firefox-esr.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/http=firefox-esr.desktop;
/home/valerio/.config/mimeapps.list:x-scheme-handler/https=firefox-esr.desktop;

I'll try to look again when I restore bullseye disk image, this upgrade 
to bookworm is only a test.

After the restore I'll find the broken "abiword instead of firefox" state.

Re: Vmware Workstation help opens abiword

2024-01-10 Thread Valerio Vanni


Il 10/01/2024 22:28, Cindy Sue Causey ha scritto:

On 1/10/24, Valerio Vanni  wrote:

The issue began after update from debian 10 to 11. And it persists in 12.

Before, Vmware Workstation help was shown in default browser (it's an
html guide).
After, guide was not showing anymore. Calling it (click on "help" on
Vmware application) began opening Abiword.

Vmware Workstation has no option "open guide with...".

In kde control panel -> app -> default, Firefox is set as default browser.

If I uninstall abiword, logoff and login to kde, guide is shown in
Firefox. If I reinstall abiword, issue comes back.

Where should I look?



Hi.. Am taking a stab at this while you're waiting for others here.
What kinds of options are you offered if you try accessing this same
via your favorite file manager?


Now I see that it' not local html pages, it's online.
I remember local pages, but perhaps it was on older versions.

Without Abiword, Firefox tries to open links such as:

docs.vmware.com/en/VMware-Workstation-Pro/17.0/context?id=IDH_MAIN
docs.vmware.com/en/VMware-Workstation-Pro/17.0/context?id=IDH_CFG_MEMORY

But then Vmware site redirect to generic page:
https://docs.vmware.com/en/VMware-Workstation-Pro/index.html
BTW this is vmware's fault, and renders guide almost useless.

But it's still interesting to know why a link is passed to abiword 
instead of default browser.

Vmware Workstation help opens abiword

2024-01-10 Thread Valerio Vanni


The issue began after update from debian 10 to 11. And it persists in 12.

Before, Vmware Workstation help was shown in default browser (it's an 
html guide).
After, guide was not showing anymore. Calling it (click on "help" on 
Vmware application) began opening Abiword.


Vmware Workstation has no option "open guide with...".

In kde control panel -> app -> default, Firefox is set as default browser.

If I uninstall abiword, logoff and login to kde, guide is shown in 
Firefox. If I reinstall abiword, issue comes back.


Where should I look?

Re: Change suspend type from kde menu

2024-01-10 Thread Valerio Vanni


Il 08/01/2024 04:29, Max Nikulin ha scritto:

On 07/01/2024 12:44, Max Nikulin wrote:


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm


Instead of tricks with setting proper context for a process executed 
system-wide, I would consider a process running in user sessions and 
listening for D-Bus events:


So your idea would be stopping and starting channel play by dbus messages?
I'm looking again with introspect, and I don't see anything like "stop" 
in kaffeine.


$ dbus-monitor --system 
"type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'"


dbus-monitor: unable to enable new-style monitoring: 
org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 
matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 
comm="dbus-monitor --system type='signal',interface='org") 
interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error 
name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" 
(bus)". Falling back to eavesdropping.
signal time=1704679328.754948 sender=org.freedesktop.DBus -> 
destination=:1.1080 serial=2 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=NameAcquired

    string ":1.1080"
signal time=1704679441.870349 sender=:1.6 -> destination=(null 
destination) serial=3187 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; member=PrepareForSleep

    boolean true
signal time=1704679448.065409 sender=:1.6 -> destination=(null 
destination) serial=3233 path=/org/freedesktop/login1; 
interface=org.freedesktop.login1.Manager; member=PrepareForSleep

    boolean false

A tiny python script may be more convenient than dbus-monitor and 
similar tools.


It seems too complex for me.

Re: Change suspend type from kde menu

2024-01-09 Thread Valerio Vanni


Il 07/01/2024 06:44, Max Nikulin ha scritto:

It seems neither su nor sudo add process to the user context (proper 
cgroup, XDG session), so attempts to talk to the systemd user session 
through D-Bus fail.


setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \
    env XDG_RUNTIME_DIR="/run/user/1000" \
    systemd-run --user --slice=app.slice -- \
    xterm

I have realized that earlier I forgot to add --user to systemd-run. To 
my surprise, it does not work if I set 
BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of 
XDG_RUNTIME_DIR. I expected that the former is required for systemd-run.


This command works from a root shell prompt, I hope it should work 
during resume as well.


It works :-)

setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \
  env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \
  systemd-run --user --slice=app.slice /usr/bin/kaffeine 
--lastchannel > /dev/null 2>&1


Even during resume it goes into right slice.

Re: Change suspend type from kde menu

2024-01-09 Thread Valerio Vanni


Il 06/01/2024 17:38, Max Nikulin ha scritto:

On 06/01/2024 00:07, Valerio Vanni wrote:


Now I'm looking: services are

├─/MainApplication
├─/Player
├─/Television
├─/TrackList
└─/org
   └─/org/kde
 └─/org/kde/kaffeine

I tried to introspect the more likely, MainApplication and Television



.RemoveProgram  method    u -    -


Do you have any idea what it should do?

I would expect something like "Stop" either from /Player or from 
org.mpris.kaffeine.


I too expected something similar: stop and play (play for resume)




If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.


Is there an action that releases the device? "ls -l /proc/PID/fd" to 
check.


What should I find here?


If no file descriptor is resolved to /dev/ (or maybe /sys) then likely 
the kernel module may be removed without killing the application.


For this we don't need to look here:
"rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel 
module cannot be removed.



Compare opened file descriptors when video is playing and when it is 
stopped.


Started with --lastchannel
Video playing:
lr-x-- 1 valerio valerio 64  9 gen 19.47 0 -> /dev/null
lrwx-- 1 valerio valerio 64  9 gen 19.47 34 -> 
/dev/dvb/adapter0/frontend0

lr-x-- 1 valerio valerio 64  9 gen 19.47 35 -> /dev/dvb/adapter0/dvr0
lr-x-- 1 valerio valerio 64  9 gen 19.47 40 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 41 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 42 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 43 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.47 44 -> /dev/dvb/adapter0/demux0
lrwx-- 1 valerio valerio 64  9 gen 19.47 55 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 56 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 57 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 59 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.47 6 -> /dev/dri/card0
lrwx------ 1 valerio valerio 64  9 gen 19.47 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.47 9 -> /dev/dri/card0

Video stopped:
lrwx-- 1 valerio valerio 64  9 gen 19.51 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.51 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.51 9 -> /dev/dri/card0

no more /dev/dvb/, but still unable to remove module cx23885

Started without --lastchannel

Video playing:
lrwx-- 1 valerio valerio 64  9 gen 19.56 37 -> 
/dev/dvb/adapter0/frontend0

lr-x-- 1 valerio valerio 64  9 gen 19.56 43 -> /dev/dvb/adapter0/dvr0
lr-x-- 1 valerio valerio 64  9 gen 19.56 47 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 49 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 50 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 51 -> /dev/dvb/adapter0/demux0
lr-x-- 1 valerio valerio 64  9 gen 19.56 52 -> /dev/dvb/adapter0/demux0
lrwx-- 1 valerio valerio 64  9 gen 19.56 58 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 59 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 60 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.56 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 9 -> /dev/dri/card0

Video stopped:
lrwx-- 1 valerio valerio 64  9 gen 19.56 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64  9 gen 19.56 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64  9 gen 19.56 9 -> /dev/dri/card0

It all seems like before, but this time module can be removed.

Re: Change suspend type from kde menu

2024-01-09 Thread Valerio Vanni


Il 06/01/2024 16:19, Max Nikulin ha scritto:

On 06/01/2024 19:44, Valerio Vanni wrote:

systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \

   /usr/bin/kaffeine --lastchannel > /dev/null 2>&1


I have not figured out how to do it, but systemd-run should not use 
--uid since this way it makes the application a part of system.slice. 
Instead the application should be in app.slice that is a child of 
user@1000.service. Inspect output of systemd-cgls.


I confirm, it's under system.slice.

So systemd-run should talk to the systemd --user instance. I have tried 
to set


XDG_RUNTIME_DIR="/run/user/1000" 
BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"


in setpriv ... env, but systemd requires authentication.


I don't see authentication requests, but it still stays under system.slice.

Re: [it-users] come lavorare in più persone su dei file ODS tramite cloud

2024-01-07 Thread Valerio Messina


On 1/1/24 9:19 PM, Claudio Ceribelli wrote:
esiste la possibilità di poter far editare/aggiungere dati in un file 
ODS a più persone e mantenerlo su di un cloud?
Cioè senza forzatamente dover scaricare il file sul pc, editarlo e 
ricaricarlo sul cloud.

A livello di cloud avremmo pensato a Drive (preferito) oppure a Onedrive.

Cosa ci dite e consigliate?


uso Google Docs, Sheet per i fogli elettronici
E' molto simile

--
Valerio

--
Come cancellarsi: E-mail users+unsubscr...@it.libreoffice.org
Problemi? https://it.libreoffice.org/supporto/mailing-lists/come-cancellarsi/
Linee guida per postare + altro: 
https://wiki.documentfoundation.org/Local_Mailing_Lists/it
Archivio della lista: https://listarchives.libreoffice.org/it/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Re: Change suspend type from kde menu

2024-01-06 Thread Valerio Vanni


Il 06/01/2024 01:04, Greg Wooledge ha scritto:

On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote:

This way works, I don't know if it has security flaws.

systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid
"$kafgid" --init-groups  --reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis
XDG_CURRENT_DESKTOP=KDE \
   /usr/bin/kaffeine --lastchannel > /dev/null 2>&1



systemd-run(1) appears to have its own --uid and --gid options.  If
you can live without supplementary groups and the variables that are
set by --reset-env, you can probably drop the setpriv part and just use
systemd-run's --uid and --gid.

On the other hand, if it ain't broke


I tried the options when I tried systemd-run, but it didn't work.
I only added them, but now I see that you have to choose: or them or 
setpriv.


Now it's:

systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \
  env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \

  /usr/bin/kaffeine --lastchannel > /dev/null 2>&1

Outcome is the same.

The only difference is that a line is added to syslog about unit creation:
Started kaffeine-resumed.service - /usr/bin/env 
XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE 
/usr/bin/kaffeine --lastchannel.

Re: Change suspend type from kde menu


Il 05/01/2024 21:47, Valerio Vanni ha scritto:

Il 05/01/2024 21:24, Valerio Vanni ha scritto:

For what I've seen, the issue is that kaffeine is started in another 
unit, systemd-suspend.service instead of user@1000.service.


systemd-suspend.service is deactivated after 90 seconds from resume, 
and kaffeine is shut down some msec before.


If I use "su" method instead of "setpriv" one, kaffeine doesn't go into 
systemd-suspend.service unit, and neither to user@1000.service one.

Instead, it goes to session-c2.scope. And works.

And systemd-suspend.service is finished and deactivated at the moment of 
resume.


It seems that systemd-suspend.service wants to end as soon as possible, 
but it cannot because it has kaffeine inside.

So it waits 90 seconds, and then terminates kaffeine.


This way works, I don't know if it has security flaws.

systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid 
"$kafgid" --init-groups  --reset-env \
  env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis 
XDG_CURRENT_DESKTOP=KDE \

  /usr/bin/kaffeine --lastchannel > /dev/null 2>&1

All is launched from systemd-run. I choosed kaffeine-resumed as unit 
name, but if you don't put any a casual name one is created.

So systemd-suspend.service unit is free and can close.

Re: Change suspend type from kde menu


Il 05/01/2024 21:24, Valerio Vanni ha scritto:

For what I've seen, the issue is that kaffeine is started in another 
unit, systemd-suspend.service instead of user@1000.service.


systemd-suspend.service is deactivated after 90 seconds from resume, and 
kaffeine is shut down some msec before.


And I found now that whole script cannot continue after this "takeover": 
final "rm" commands are not run.


-
2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service  ":1.299" 
unregistered
2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: 
Could not get icon for "audio-card-analog-pci"
2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: 
QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 
134217740, major code: 15 (QueryTree), minor code: 0
2024-01-05T19:39:20.501014+01:00 newton systemd[1]: 
systemd-suspend.service: Deactivated successfully.
2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished 
systemd-suspend.service - System Suspend.
2024-01-05T19:39:20.501227+01:00 newton systemd[1]: 
systemd-suspend.service: Consumed 1min 10.023s CPU time.
2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target 
sleep.target - Sleep.
2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target 
suspend.target - Suspend.
2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target 
suspend.target - Suspend.


If I use "su" method instead of "setpriv" one, kaffeine doesn't go into 
systemd-suspend.service unit, and neither to user@1000.service one.

Instead, it goes to session-c2.scope. And works.

And systemd-suspend.service is finished and deactivated at the moment of 
resume.


It seems that systemd-suspend.service wants to end as soon as possible, 
but it cannot because it has kaffeine inside.

So it waits 90 seconds, and then terminates kaffeine.

Re: Change suspend type from kde menu


Il 05/01/2024 20:47, Franco Martelli ha scritto:

On 05/01/24 at 20:01, Greg Wooledge wrote:

On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote:
    setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups 
--reset-env \

   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis
XDG_CURRENT_DESKTOP=KDE \
   /usr/bin/kaffeine --lastchannel >/dev/null 2>&1



Adding the parameter --reset-env seems to fix, kaffeine restarts.
But, after some minutes, it closes. I don't understand why.


My first guess would be that you also need $HOME to be set, or perhaps
the current working directory, or both.  --reset-env sets HOME, SHELL,
USER, LOGNAME and PATH.  That seems like a reasonable addition.

I have no idea why it crashes later.


Could it be that he doesn't run Kaffeine in the background?

...
/usr/bin/kaffeine --lastchannel >/dev/null 2>&1 &


If I add that final &, kaffeine doesn't start at all.

For what I've seen, the issue is that kaffeine is started in another 
unit, systemd-suspend.service instead of user@1000.service.


systemd-suspend.service is deactivated after 90 seconds from resume, and 
kaffeine is shut down some msec before.


And I found now that whole script cannot continue after this "takeover": 
final "rm" commands are not run.


-
2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service  ":1.299" 
unregistered
2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: 
Could not get icon for "audio-card-analog-pci"
2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: 
QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 
134217740, major code: 15 (QueryTree), minor code: 0
2024-01-05T19:39:20.501014+01:00 newton systemd[1]: 
systemd-suspend.service: Deactivated successfully.
2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished 
systemd-suspend.service - System Suspend.
2024-01-05T19:39:20.501227+01:00 newton systemd[1]: 
systemd-suspend.service: Consumed 1min 10.023s CPU time.
2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target 
sleep.target - Sleep.
2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target 
suspend.target - Suspend.
2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target 
suspend.target - Suspend.

Re: Change suspend type from kde menu


Il 05/01/2024 20:10, Valerio Vanni ha scritto:


My first guess would be that you also need $HOME to be set, or perhaps
the current working directory, or both.  --reset-env sets HOME, SHELL,
USER, LOGNAME and PATH.  That seems like a reasonable addition.

I have no idea why it crashes later.


If you see my latest message, it goes in a different unit and is shut 
down at the end of resume.


Perhaps I could try to remove --reset-env and set some parameter by hand


If I remove --reset-env and set HOME, kaffeine starts.
It seems that issue was to find file in home directory.

But still in systemd-suspend.service unit.

If, in a root shell, I launch

setpriv --reuid 1000 --regid 1000 --init-groups  \
  env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 HOME=/home/valerio 
XDG_CURRENT_DESKTOP=KDE \ 

  /usr/bin/kaffeine --lastchannel > 
/home/valerio/kaffeine_log_resumed 2>&1


kaffeine starts in user@1000.service.
Also with --reset-env.

It's only during resume that it gets into systemd-suspend.service.

Re: Change suspend type from kde menu


Il 05/01/2024 20:01, Greg Wooledge ha scritto:

On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote:

setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups 
--reset-env \
   env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis
XDG_CURRENT_DESKTOP=KDE \
   /usr/bin/kaffeine --lastchannel >/dev/null 2>&1



-
Uid, gid and display are saved and restored, so it can works also for other
users and x servers.
But with setpriv kaffeine was complaining it couldn't find .config/,
database etc and so it wasn't able to start. It seems that was ignorming
original user's home and tried to access root home.

Adding the parameter --reset-env seems to fix, kaffeine restarts.
But, after some minutes, it closes. I don't understand why.


My first guess would be that you also need $HOME to be set, or perhaps
the current working directory, or both.  --reset-env sets HOME, SHELL,
USER, LOGNAME and PATH.  That seems like a reasonable addition.

I have no idea why it crashes later.


If you see my latest message, it goes in a different unit and is shut 
down at the end of resume.


Perhaps I could try to remove --reset-env and set some parameter by hand

Re: Change suspend type from kde menu


Il 05/01/2024 17:52, Valerio Vanni ha scritto:


Adding the parameter --reset-env seems to fix, kaffeine restarts.
But, after some minutes, it closes. I don't understand why.

-Kaffeine launched by hand stays up
-Kaffeine restored with "su" method stays up
-Kaffeine restored with "setpriv" method lasts only some minute


I looked better: it lasts 90 seconds.
Not from kaffeine launch, from PC resume. If I try to set a delay inside 
the script, so that kaffeine launches after 80 seconds, it starts and 
then after 10 seconds it's closed.

If I set the delay after 90 seconds, it doesn't start at all.

I tried to redirect output to a file
/usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1

The file is created and gets data, but nothing is added at the moment of 
termination.

In syslog I found these lines at that moment:

-
2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service  ":1.299" 
unregistered
2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: 
Could not get icon for "audio-card-analog-pci"
2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: 
QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 
134217740, major code: 15 (QueryTree), minor code: 0
2024-01-05T19:39:20.501014+01:00 newton systemd[1]: 
systemd-suspend.service: Deactivated successfully.
2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished 
systemd-suspend.service - System Suspend.
2024-01-05T19:39:20.501227+01:00 newton systemd[1]: 
systemd-suspend.service: Consumed 1min 10.023s CPU time.
2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target 
sleep.target - Sleep.
2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target 
suspend.target - Suspend.
2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target 
suspend.target - Suspend.
2024-01-05T19:39:20.505334+01:00 newton NetworkManager[3208]:  
[1704479960.5049] manager: sleep: wake requested (sleeping: yes 
enabled: yes)
2024-01-05T19:39:20.505722+01:00 newton ModemManager[3206]:  
[sleep-monitor-systemd] system is resuming

--

It seems that something of resume process is ending 90 seconds after 
resume. And Service ":1.299" that gets unregistered is just kaffeine.



And now I see a difference between kaffeine launched by hand and resumed 
one:


busctl --user | grep kaffeine

with manual start
--
:1.305        44374 
kaffeinevalerio :1.305user@1000.service -   -
:1.306        44374 
kaffeinevalerio :1.306user@1000.service -   -
:1.307        44374 
kaffeinevalerio :1.307user@1000.service -   -
org.kde.kaffeine      44374 
kaffeinevalerio :1.305user@1000.service -   -
org.mpris.kaffeine        44374 
kaffeinevalerio :1.305user@1000.service -   -

--

after resume
--
1.312        45857 
kaffeinevalerio :1.312systemd-suspend.service -   -
:1.313        45857 
kaffeinevalerio :1.313systemd-suspend.service -   -
:1.314        45857 
kaffeinevalerio :1.314systemd-suspend.service -   -
org.kde.kaffeine      45857 
kaffeinevalerio :1.312systemd-suspend.service -   -
org.mpris.kaffeine        45857 
kaffeinevalerio :1.312systemd-suspend.service -   -

--

Re: Change suspend type from kde menu


Il 04/01/2024 17:11, Max Nikulin ha scritto:

On 04/01/2024 22:21, Valerio Vanni wrote:

Il 04/01/2024 15:48, Max Nikulin ha scritto:


Is it really necessary to kill kaffeine or it is enough to pause or 
to stop playing? It might be possible using a D-Bus query.

[...]

If it's started normally, it's enough to stop playing
But how would you try to request it to stop?


I would play with "busctl --user", "busctl --user tree SERVICE", "busctl 
--user introspect SERVICE OBJECT" to figure out if suitable methods are 
available.


I never used busctl.

Now I'm looking: services are

├─/MainApplication
├─/Player
├─/Television
├─/TrackList
└─/org
  └─/org/kde
└─/org/kde/kaffeine

I tried to introspect the more likely, MainApplication and Television

 /MainApplication
AMETYPE  SIGNATURE RESULT/VALUE 
 FL>

org.freedesktop.DBus.Introspectable interface - -  -
.Introspect method- s  -
org.freedesktop.DBus.Peer   interface - -  -
.GetMachineId   method- s  -
.Ping   method- -  -
org.freedesktop.DBus.Properties interface - -  -
.Getmethodssv  -
.GetAll methods a{sv}  -
.Setmethodssv   -  -
.PropertiesChanged  signalsa{sv}as  -  -
org.qtproject.Qt.QApplication   interface - -  -
.aboutQtmethod- -  -
.autoSipEnabled method- b  -
.closeAllWindowsmethod- -  -
.setAutoSipEnabled  methodb -  -
.setStyleSheet  methods -  -
lines 1-17


/Television
AMETYPE  SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer   interface - --
.GetMachineId   method- s-
.Ping   method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv   --
.PropertiesChanged  signalsa{sv}as  --
org.freedesktop.MediaPlayer interface - --
.DigitPressed   methodi --
.ListProgramSchedulemethod- a(uib)   -
.PlayChannelmethods --
.PlayLastChannelmethod- --
.RemoveProgram  methodu --



If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.


Is there an action that releases the device? "ls -l /proc/PID/fd" to check.


What should I find here?


Ideally kaffeine should implement the Inhibit interface and should close 
devices on suspend or on user session switch.


Ideally...

Re: Change suspend type from kde menu