from:"Fabio"

On Tue, May 28, 2024 at 4:15 PM Fabio Estevam  wrote:
>
> From: Fabio Estevam 
>
> Newer versions of the imx8mm-cl-iot-gate boards may come populated with a
> Samsung 4GB DDR model.
>
> Add support for it.
>
> Signed-off-by: Fabio Estevam 

Applied all to u-boot-imx/next, thanks.

Re: [PATCH 0/4] Support all phyCORE-i.MX8MP RAM variants

On Tue, May 28, 2024 at 10:35 AM Teresa Remmet  wrote:
>
> Add support for several RAM sizes and speed grades for phyCORE-i.MX8MP.
>
> We have support with this series for:
> - 1GB 1.5GHz
> - 1GB 2GHz
> - 2GB 1.5GHz (was supported before)
> - 2GB 2GHz (was supported before)
> - 4GB 1.5GHz
> - 4GB 2GHz
> - 8GB 2GHz
>
> RAM size and speed grade is detected and set using EEPROM data on default.
> Alternative it is possible to set fix RAM size and speed over Kconfig.

Applied all to u-boot-imx/next, thanks.

Re: [PATCH 0/2] Migrate PHYTEC imx8m boards to OF_UPSTREAM

On Tue, May 28, 2024 at 8:25 AM Yannic Moog  wrote:
>
> - update MAINTAINERS
> - delete synced dt files
> - imply OF_UPSTREAM
> - update default device tree

Applied all to u-boot-imx/next, thanks.

Re: [PATCH v1 0/5] board: toradex: Add new Verdin and Aquila SKUs

On Tue, May 28, 2024 at 7:00 AM Emanuele Ghidoli
 wrote:
>
> From: Emanuele Ghidoli 
>
> Hi,
> This series adds support for 0090 PID4 Verdin iMX8M Mini Quad 4GB WB ET SKU.
> It also adds two new SKUs config block support: 0088 Aquila AM69 Octa 32GB WB 
> IT and 0089 Verdin iMX95 Hexa 16GB WB IT.

Applied all to u-boot-imx/next, thanks.

[GIT PULL] Please pull u-boot-imx-next-20240603

Hi Tom,

Please pull from u-boot-imx/next, thanks.

The following changes since commit 7e52d6ccfb76e2afc2d183b357abe2a2e2f948cf:

  Merge patch series "FWU: Add support for FWU metadata version 2" (2024-05-24 
13:42:07 -0600)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
tags/u-boot-imx-next-20240603

for you to fetch changes up to fb95661116fb4269883721afd80578e6d88ce043:

  imx8mm-cl-iot-gate: Add support for the Realtek RTL8211E PHY (2024-06-03 
12:14:29 -0300)

u-boot-imx-next-20240603
--

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20956

- Support different RAM sizes on imx8m phycoce boards.
- Support new toradex variants.
- Support Samsung 4GB DDR and Realtek RTL8211E PHY on imx8mm-cl-iot-gate.
- Convert imx8mm-phycore and imx8mp-phycore boards to use OF_UPSTREAM.


Benjamin Hahn (1):
  board: phycore_imx8mp: enable setting 2GHz timings without RAM size

Emanuele Ghidoli (5):
  board: toradex: verdin-imx8mm: add 4 GB lpddr4 memory support
  board: toradex: verdin-imx8mm: increase maximum addressable ram to 4GB
  toradex: tdx-cfg-block: add aquila am69 sku 0088 pid4
  toradex: tdx-cfg-block: add verdin imx95 sku 0089 pid4
  toradex: tdx-cfg-block: add verdin i.mx8m mini 0090 pid4

Fabio Estevam (2):
  imx8mm-cl-iot-gate: Add support for Samsung 4GB DDR
  imx8mm-cl-iot-gate: Add support for the Realtek RTL8211E PHY

Teresa Remmet (3):
  board: phytec: phycore-imx8mp: spl: Fix syle issue
  board: phytec: phycore_imx8mp: Add support for different RAM sizes
  board: phytec: phycore_imx8mp: Make RAM size configuration fix

Yannic Moog (2):
  arm: imx8mm-phycore: move to OF_UPSTREAM
  arm: imx8mp-phycore: move to OF_UPSTREAM

 arch/arm/dts/Makefile  |   3 -
 arch/arm/dts/imx8mm-phyboard-polis-rdk.dts | 460 ---
 arch/arm/dts/imx8mm-phycore-som.dtsi   | 440 --
 arch/arm/dts/imx8mm-phygate-tauri-l.dts| 489 -
 arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts| 361 ---
 arch/arm/dts/imx8mp-phycore-som.dtsi   | 323 --
 arch/arm/mach-imx/imx8m/Kconfig|   2 +
 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c|   4 +-
 .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c| 106 -
 board/phytec/phycore_imx8mm/MAINTAINERS|   3 -
 board/phytec/phycore_imx8mp/Kconfig|  67 +++
 board/phytec/phycore_imx8mp/MAINTAINERS|   1 -
 board/phytec/phycore_imx8mp/lpddr4_timing.c| 153 +++
 board/phytec/phycore_imx8mp/lpddr4_timing.h|  16 +
 board/phytec/phycore_imx8mp/phycore-imx8mp.c   |  11 +
 board/phytec/phycore_imx8mp/spl.c  | 136 +++---
 board/toradex/common/tdx-cfg-block.c   |   3 +
 board/toradex/common/tdx-cfg-block.h   |   3 +
 board/toradex/verdin-imx8mm/lpddr4_timing.c|  14 +-
 board/toradex/verdin-imx8mm/verdin-imx8mm.c|   5 +-
 configs/imx8mm-phygate-tauri-l_defconfig   |   2 +-
 configs/phycore-imx8mm_defconfig   |   2 +-
 configs/phycore-imx8mp_defconfig   |   2 +-
 include/configs/imx8mm-cl-iot-gate.h   |   2 +-
 include/configs/phycore_imx8mp.h   |   4 +-
 include/configs/verdin-imx8mm.h|   6 +-
 26 files changed, 454 insertions(+), 2164 deletions(-)
 delete mode 100644 arch/arm/dts/imx8mm-phyboard-polis-rdk.dts
 delete mode 100644 arch/arm/dts/imx8mm-phycore-som.dtsi
 delete mode 100644 arch/arm/dts/imx8mm-phygate-tauri-l.dts
 delete mode 100644 arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts
 delete mode 100644 arch/arm/dts/imx8mp-phycore-som.dtsi
 create mode 100644 board/phytec/phycore_imx8mp/lpddr4_timing.h

[Git][archlinux/packaging/packages/sweethome3d][main] upgpkg: 7.4-1



Fabio Castelli pushed to branch main at Arch Linux / Packaging / Packages / 
sweethome3d


Commits:
de78d298 by Fabio Castelli (Muflone) at 2024-06-03T17:39:17+02:00
upgpkg: 7.4-1

- - - - -


2 changed files:

- .SRCINFO
- PKGBUILD


Changes:

=
.SRCINFO
=
@@ -1,6 +1,6 @@
 pkgbase = sweethome3d
pkgdesc = An interior design application to draw the plan of your house 
in a 3D environment
-   pkgver = 7.3
+   pkgver = 7.4
pkgrel = 1
url = http://www.sweethome3d.com/
install = sweethome3d.install
@@ -17,11 +17,11 @@ pkgbase = sweethome3d
depends = libgl
depends = libxrender
depends = libnsl
-   source = 
SweetHome3D-7.3-src.zip::https://downloads.sourceforge.net/sweethome3d/SweetHome3D-7.3-src.zip
+   source = 
SweetHome3D-7.4-src.zip::https://downloads.sourceforge.net/sweethome3d/SweetHome3D-7.4-src.zip
source = sweethome3d.sh
source = sweethome3d.desktop
source = sweethome3d.xml
-   sha256sums = 
8eaab3f269181077a26768cbd977fead72a04666325d201e1ea79949f6db70c3
+   sha256sums = 
98987ad5a088441963e0d1afaaf39b8437f9880d3240dda73de4a19702dc502d
sha256sums = 
9e95ebf426abffe91fe3046e024796d0408fee2987a458fd2782dc0b75124e03
sha256sums = 
5eea3337d956d773b05ddef69fe9d34b940ff550370dc92bf307f1b9a3957f9e
sha256sums = 
ec0ad1a0671f708af68ced46bec1f4ab377e24ca1a0a9984867ee5fe484f57c5


=
PKGBUILD
=
@@ -6,7 +6,7 @@
 # Contributor: Archan Paul 
 
 pkgname=sweethome3d
-pkgver=7.3
+pkgver=7.4
 pkgrel=1
 pkgdesc="An interior design application to draw the plan of your house in a 3D 
environment"
 arch=('x86_64')
@@ -18,7 +18,7 @@ 
source=("SweetHome3D-${pkgver}-src.zip"::"https://downloads.sourceforge.net/${pk
 "${pkgname}.sh"
 "${pkgname}.desktop"
 "${pkgname}.xml")
-sha256sums=('8eaab3f269181077a26768cbd977fead72a04666325d201e1ea79949f6db70c3'
+sha256sums=('98987ad5a088441963e0d1afaaf39b8437f9880d3240dda73de4a19702dc502d'
 '9e95ebf426abffe91fe3046e024796d0408fee2987a458fd2782dc0b75124e03'
 '5eea3337d956d773b05ddef69fe9d34b940ff550370dc92bf307f1b9a3957f9e'
 'ec0ad1a0671f708af68ced46bec1f4ab377e24ca1a0a9984867ee5fe484f57c5')



View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/sweethome3d/-/commit/de78d298168ea1e6eaa6192a5958490302143d51

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/sweethome3d/-/commit/de78d298168ea1e6eaa6192a5958490302143d51
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/sweethome3d] Pushed new tag 7.4-1



Fabio Castelli pushed new tag 7.4-1 at Arch Linux / Packaging / Packages / 
sweethome3d

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/sweethome3d/-/tree/7.4-1
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/dbeaver] Pushed new tag 24.1.0-1



Fabio Castelli pushed new tag 24.1.0-1 at Arch Linux / Packaging / Packages / 
dbeaver

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/tree/24.1.0-1
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/dbeaver][main] upgpkg: 24.1.0-1



Fabio Castelli pushed to branch main at Arch Linux / Packaging / Packages / 
dbeaver


Commits:
5b8e9839 by Fabio Castelli (Muflone) at 2024-06-03T16:44:17+02:00
upgpkg: 24.1.0-1

- - - - -


2 changed files:

- .SRCINFO
- PKGBUILD


Changes:

=
.SRCINFO
=
@@ -1,6 +1,6 @@
 pkgbase = dbeaver
pkgdesc = Free universal SQL Client for developers and database 
administrators (community edition)
-   pkgver = 24.0.5
+   pkgver = 24.1.0
pkgrel = 1
url = https://dbeaver.io/
install = dbeaver.install
@@ -16,15 +16,15 @@ pkgbase = dbeaver
optdepends = dbeaver-plugin-svg-format: save diagrams in SVG format
conflicts = dbeaver-plugin-sshj-lib
replaces = dbeaver-plugin-sshj-lib
-   source = 
dbeaver-24.0.5.tar.gz::https://github.com/dbeaver/dbeaver/archive/24.0.5.tar.gz
-   source = 
dbeaver-common-24.0.5.tar.gz::https://github.com/dbeaver/dbeaver-common/archive/fd76bbe199dd81d6538c188b1c5854094f7bdd0b.tar.gz
+   source = 
dbeaver-24.1.0.tar.gz::https://github.com/dbeaver/dbeaver/archive/24.1.0.tar.gz
+   source = 
dbeaver-common-24.1.0.tar.gz::https://github.com/dbeaver/dbeaver-common/archive/3a9c85663f797288955a85f35d8f991c8346027e.tar.gz
source = io.dbeaver.DBeaver.desktop
source = dbeaver.sh
source = dbeaver.profile.gz
source = dbeaver.hook
source = dbeaver.install
-   sha256sums = 
c30be0ff8e6770a0dcdd704a5c0a00dcd028850f4dd7f84f56e92ea6462b4e12
-   sha256sums = 
bf157f24580d1db54df39373751a0271583fe4e3f8829b2a892af71ee51b755f
+   sha256sums = 
70ecde6f5cab44c02c52624b1f4adf2f0a07ba835edad92cc010a948abab075d
+   sha256sums = 
d97fe2e810b1be4578f1737e0b705198a58bc1d94d92605d9c8c7d053d0f48ad
sha256sums = 
9480a7d08f680e10c399db070c5a04cbabf282442602a2ef83d1159fe7c3e88b
sha256sums = 
406a2980806c394670e88b1ae70134900be376c2ea4a4216610591cc8b557526
sha256sums = 
1863e74bdcf22b7328e6e8487cbebff7d5360e34bde85c1dd226b168b4737034


=
PKGBUILD
=
@@ -2,9 +2,9 @@
 # Contributor: Arne Hoch 
 
 pkgname=dbeaver
-pkgver=24.0.5
+pkgver=24.1.0
 pkgrel=1
-_COMMON_COMMIT_ID='fd76bbe199dd81d6538c188b1c5854094f7bdd0b'
+_COMMON_COMMIT_ID='3a9c85663f797288955a85f35d8f991c8346027e'
 pkgdesc="Free universal SQL Client for developers and database administrators 
(community edition)"
 arch=('x86_64')
 url="https://dbeaver.io/;
@@ -22,8 +22,8 @@ 
source=("${pkgname}-${pkgver}.tar.gz"::"https://github.com/dbeaver/dbeaver/archi
 "${pkgname}.profile.gz"
 "${pkgname}.hook"
 "${pkgname}.install")
-sha256sums=('c30be0ff8e6770a0dcdd704a5c0a00dcd028850f4dd7f84f56e92ea6462b4e12'
-'bf157f24580d1db54df39373751a0271583fe4e3f8829b2a892af71ee51b755f'
+sha256sums=('70ecde6f5cab44c02c52624b1f4adf2f0a07ba835edad92cc010a948abab075d'
+'d97fe2e810b1be4578f1737e0b705198a58bc1d94d92605d9c8c7d053d0f48ad'
 '9480a7d08f680e10c399db070c5a04cbabf282442602a2ef83d1159fe7c3e88b'
 '406a2980806c394670e88b1ae70134900be376c2ea4a4216610591cc8b557526'
 '1863e74bdcf22b7328e6e8487cbebff7d5360e34bde85c1dd226b168b4737034'



View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/commit/5b8e98393b46b80e366d4fcbc25d334f68049b24

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/commit/5b8e98393b46b80e366d4fcbc25d334f68049b24
You're receiving this email because of your account on gitlab.archlinux.org.

Re: [OE-core] Set the CMake BUILD_TESTING option to OFF as the default setting

2024-06-03 Thread Fabio Berton

Hi Alex,

I ran a few builds disabling CMake DBUILD_TESTING and the build time was about 
the same. I'm not sure if by building plenty of recipes we can see a difference 
in build time, since bitbake needs to build all the recipe dependencies that 
use cmake bbclass.

Looking for some recipes that use ptest, I see examples like this:

- meta/recipes-multimedia/gstreamer/gstreamer1.0_1.24.3.bb: PACKAGECONFIG ??= 
"${@bb.utils.contains('PTEST_ENABLED', '1', 'tests', '', d)}"
- meta/recipes-core/glib-networking/glib-networking_2.78.1.bb: PACKAGECONFIG 
??= "gnutls environment ${@bb.utils.contains('PTEST_ENABLED', '1', 'tests', '', 
d)}"
- meta/recipes-support/libnl/libnl_3.9.0.bb: do_compile_ptest to compile only 
when PTEST_ENABLED is enabled
- ... (and several more)
- one interesting one is meta/recipes-devtools/flex/flex_2.6.4.bb: 
${@bb.utils.contains('PTEST_ENABLED', '1', '', 'file://disable-tests.patch', d)}
they decided to apply a patch to disable tests when ptest is off

Based on this, I would say that we don't want to build tests unless ptests are 
enabled (so the argument that building tests also tests the code is moot). In 
turn, it may be sensible to use the default CMake option to disable building of 
tests.

Thanks,

Fabio

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

Re: [Fedocal] Reminder meeting : ELN SIG

2024-05-31 Thread Fabio Valentini

On Fri, May 31, 2024 at 7:47 PM Stephen Gallagher  wrote:
>
> On Fri, May 31, 2024 at 1:22 PM Fabio Valentini  wrote:
> >
> > On Fri, May 31, 2024 at 7:15 PM Stephen Gallagher  
> > wrote:
> > >
> >
> > Looking forward to EPEL 10! More work for me, yay!
> > Just a few questions - I would have looked them up in the meeting log,
> > but it's not linked.
> >
>
> https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-31/eln.2024-05-31-16.01.txt
>
> I'm not sure why that wasn't part of the "minutes" output. Probably
> worth looking into...
>
> > > * AGREED: All packages currently included in ELN Extras will have
> > > an EPEL 10 branch created for them (@sgallagh:fedora.im, 16:28:51)
> >
> > Is there a list of these packages available somewhere?
> >
>
> https://tiny.distro.builders/view--view-eln-extras.html
>
> > > * AGREED: We will mass-create empty branches for EPEL 10 and will
> > > work towards a better solution for EPEL 11 (@sgallagh:fedora.im,
> > > 16:51:54)
> >
> > I hope you will not create epel10 branches for *all* packages in Fedora.
> > Which packages *will* get an epel10 branch auto-created?
> >
>
> This was the result of a discussion as to whether we should
> pre-populate the branch contents. We settled on creating them as
> empty. It's the same list as above.
>
> > > * INFO: Investigation topic: Drop ELN Extras in favor of starting
> > > EPEL 11 soon after EPEL 10, backed by ELN until branching.
> > > (@sgallagh:fedora.im, 16:56:06)
> >
> > This sounds great! ELN Extras has always been confusing to me.
> >
>
> The idea behind ELN Extras was to get an early preview of stuff that
> people want in the next EPEL release. During the discussion today, we
> decided that it might be easier to essentially just create EPEL N+1
> earlier and take advantage of the ELN tooling and tagging. I'm going
> to work up a proposal over the next week or so and send it out for
> discussion.

Great, thank you for the quick response!

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedocal] Reminder meeting : ELN SIG

2024-05-31 Thread Fabio Valentini

On Fri, May 31, 2024 at 7:15 PM Stephen Gallagher  wrote:
>

Looking forward to EPEL 10! More work for me, yay!
Just a few questions - I would have looked them up in the meeting log,
but it's not linked.

> * AGREED: All packages currently included in ELN Extras will have
> an EPEL 10 branch created for them (@sgallagh:fedora.im, 16:28:51)

Is there a list of these packages available somewhere?

> * AGREED: We will mass-create empty branches for EPEL 10 and will
> work towards a better solution for EPEL 11 (@sgallagh:fedora.im,
> 16:51:54)

I hope you will not create epel10 branches for *all* packages in Fedora.
Which packages *will* get an epel10 branch auto-created?

> * INFO: Investigation topic: Drop ELN Extras in favor of starting
> EPEL 11 soon after EPEL 10, backed by ELN until branching.
> (@sgallagh:fedora.im, 16:56:06)

This sounds great! ELN Extras has always been confusing to me.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[kdesu] [Bug 482036] root apps not launching via desktop menu in plasma 6

2024-05-31 Thread Fabio C. Barrionuevo

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

Fabio C. Barrionuevo  changed:

   What|Removed |Added

 CC||bna...@gmail.com
Version|6.0.0   |6.1.0

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

[neon] [Bug 483701] unable to launch Software Sources - root password never accepted

2024-05-31 Thread Fabio C. Barrionuevo

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

Fabio C. Barrionuevo  changed:

   What|Removed |Added

 CC||bna...@gmail.com

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

Bug#1039691: cinnamon: Missing "Science" category in menu

2024-05-31 Thread Fabio Fantoni


Control: tags -1 + fixed-upstream

This is now fixed upstream for next major version: 
https://github.com/linuxmint/cinnamon/commit/bc9b012694eb81db7f154754557caf3ca431491f




OpenPGP_signature.asc
Description: OpenPGP digital signature

VMware Volume Snapshot Performance

2024-05-31 Thread fabio


Hello everyone,

I read the Cloudstack docs about the performances of VMware volume 
snapshot but it's not quite clear to me how this " A Snapshot is not 
immediately exported from vCenter to a mounted NFS share and packaged 
into an OVA file format. This operation would consume time and 
resources. Instead, the original file formats (e.g., VMDK) provided by 
vCenter are retained." is working.


Is there some configuration I need to setup in globabl config or in 
cluster config?

Thank you for your help

[PATCH 2/2] ACPI: extlog: Trace CPER PCI Express Error Section

2024-05-30 Thread Fabio M. De Francesco

Currently, extlog_print() (ELOG) only reports CPER PCIe section (UEFI
v2.10, Appendix N.2.7) to the kernel log via print_extlog_rcd(). Instead,
the similar ghes_do_proc() (GHES) prints to kernel log and calls
pci_print_aer() to report via the ftrace infrastructure.

Add support to report the CPER PCIe Error section also via the ftrace
infrastructure by calling pci_print_aer() to make ELOG act consistently
with GHES.

Cc: Dan Williams 
Signed-off-by: Fabio M. De Francesco 
---
 drivers/acpi/acpi_extlog.c | 30 ++
 drivers/pci/pcie/aer.c |  2 +-
 include/linux/aer.h| 13 +++--
 3 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index e025ae390737..007ce96f8672 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -131,6 +131,32 @@ static int print_extlog_rcd(const char *pfx,
return 1;
 }
 
+static void extlog_print_pcie(struct cper_sec_pcie *pcie_err,
+ int severity)
+{
+   struct aer_capability_regs *aer;
+   struct pci_dev *pdev;
+   unsigned int devfn;
+   unsigned int bus;
+   int aer_severity;
+   int domain;
+
+   if (pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
+   pcie_err->validation_bits & CPER_PCIE_VALID_AER_INFO) {
+   aer_severity = cper_severity_to_aer(severity);
+   aer = (struct aer_capability_regs *)pcie_err->aer_info;
+   domain = pcie_err->device_id.segment;
+   bus = pcie_err->device_id.bus;
+   devfn = PCI_DEVFN(pcie_err->device_id.device,
+ pcie_err->device_id.function);
+   pdev = pci_get_domain_bus_and_slot(domain, bus, devfn);
+   if (!pdev)
+   return;
+   pci_print_aer(pdev, aer_severity, aer);
+   pci_dev_put(pdev);
+   }
+}
+
 static int extlog_print(struct notifier_block *nb, unsigned long val,
void *data)
 {
@@ -179,6 +205,10 @@ static int extlog_print(struct notifier_block *nb, 
unsigned long val,
if (gdata->error_data_length >= sizeof(*mem))
trace_extlog_mem_event(mem, err_seq, fru_id, 
fru_text,
   
(u8)gdata->error_severity);
+   } else if (guid_equal(sec_type, _SEC_PCIE)) {
+   struct cper_sec_pcie *pcie_err = 
acpi_hest_get_payload(gdata);
+
+   extlog_print_pcie(pcie_err, gdata->error_severity);
} else {
void *err = acpi_hest_get_payload(gdata);
 
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index ac6293c24976..794aa15527ba 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -801,7 +801,7 @@ void pci_print_aer(struct pci_dev *dev, int aer_severity,
trace_aer_event(dev_name(>dev), (status & ~mask),
aer_severity, tlp_header_valid, >header_log);
 }
-EXPORT_SYMBOL_NS_GPL(pci_print_aer, CXL);
+EXPORT_SYMBOL_GPL(pci_print_aer);
 
 /**
  * add_error_device - list device to be handled
diff --git a/include/linux/aer.h b/include/linux/aer.h
index 4b97f38f3fcf..fbc82206045c 100644
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@ -42,17 +42,26 @@ int pcie_read_tlp_log(struct pci_dev *dev, int where, 
struct pcie_tlp_log *log);
 #if defined(CONFIG_PCIEAER)
 int pci_aer_clear_nonfatal_status(struct pci_dev *dev);
 int pcie_aer_is_native(struct pci_dev *dev);
+void pci_print_aer(struct pci_dev *dev, int aer_severity,
+  struct aer_capability_regs *aer);
 #else
 static inline int pci_aer_clear_nonfatal_status(struct pci_dev *dev)
 {
return -EINVAL;
 }
+
 static inline int pcie_aer_is_native(struct pci_dev *dev) { return 0; }
+static inline void pci_print_aer(struct pci_dev *dev, int aer_severity,
+struct aer_capability_regs *aer)
+{ }
 #endif
 
-void pci_print_aer(struct pci_dev *dev, int aer_severity,
-   struct aer_capability_regs *aer);
+#if defined(CONFIG_ACPI_APEI_PCIEAER)
 int cper_severity_to_aer(int cper_severity);
+#else
+static inline int cper_severity_to_aer(int cper_severity) { return 0; }
+#endif
+
 void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
   int severity, struct aer_capability_regs *aer_regs);
 #endif //_AER_H_
-- 
2.45.1

[PATCH 1/2] ACPI: extlog: Trace CPER Non-standard Section Body

2024-05-30 Thread Fabio M. De Francesco

In extlog_print(), trace "Non-standard Section Body" reported by firmware
to the OS via Common Platform Error Record (CPER) (UEFI v2.10 Appendix N
2.3) to add further debug information and so to make ELOG log
consistently with ghes_do_proc() (GHES).

Cc: Dan Williams 
Signed-off-by: Fabio M. De Francesco 
---
 drivers/acpi/acpi_extlog.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index f055609d4b64..e025ae390737 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -179,6 +179,12 @@ static int extlog_print(struct notifier_block *nb, 
unsigned long val,
if (gdata->error_data_length >= sizeof(*mem))
trace_extlog_mem_event(mem, err_seq, fru_id, 
fru_text,
   
(u8)gdata->error_severity);
+   } else {
+   void *err = acpi_hest_get_payload(gdata);
+
+   trace_non_standard_event(sec_type, fru_id, fru_text,
+gdata->error_severity, err,
+gdata->error_data_length);
}
}
 
-- 
2.45.1

[PATCH 0/2] Make ELOG log and trace consistently with GHES

2024-05-30 Thread Fabio M. De Francesco

When Firmware First is enabled, BIOS handles errors first and then it
makes them available to the kernel via the Common Platform Error Record
(CPER) sections (UEFI 2.10 Appendix N). Linux parses the CPER sections
via one of two similar paths, either ELOG or GHES.

Currently, ELOG and GHES show some inconsistencies in how they print to
the kernel log as well as in how they report to userspace via trace
events.

Make the two mentioned paths act similarly for what relates to logging
and tracing.

--- Changes for v1 ---

- Drop the RFC prefix and restart from PATCH v1
- Drop patch 3/3 because a discussion on it has not yet been
  settled
- Drop namespacing in export of pci_print_aer while() (Dan)
- Don't use '#ifdef' in *.c files (Dan)
- Drop a reference on pdev after operation is complete (Dan)
- Don't log an error message if pdev is NULL (Dan)

--- Changes for RFC v2 ---

- 0/3: rework the subject line and the letter.
- 1/3: no changes.
- 2/3: trace CPER PCIe Section only if CONFIG_ACPI_APEI_PCIEAER
  is defined; the kernel test robot reported the use of two
  undefined symbols because the test for the config option was
  missing; rewrite the subject line and part of commit message.
- 3/3: no changes.

Fabio M. De Francesco (2):
  ACPI: extlog: Trace CPER Non-standard Section Body
  ACPI: extlog: Trace CPER PCI Express Error Section

 drivers/acpi/acpi_extlog.c | 35 +++
 drivers/pci/pcie/aer.c |  2 +-
 include/linux/aer.h|  9 ++---
 3 files changed, 42 insertions(+), 4 deletions(-)

-- 
2.45.1

[MARMAM] Soundscape Ecology Summer School - Registrations open

2024-05-30 Thread Fabio Ronchetti

Revamp your summer plans with the Soundscape Ecology Summer School! Embark
on a transformative journey to the breathtaking landscapes of Alghero,
nestled in the heart of Sardinia Island, Italy.

>From September 14th to 22nd, 2024, dive deep into the cutting-edge realm of
Soundscape Ecology, a riveting fusion of bioacoustics and ecology.

Led by the esteemed Dr. Gabriella La Manna, this immersive experience
promises to broaden your horizons and ignite your passion for environmental
stewardship.


Where: Alghero, Sardinia Island (Italy).

When: 14-22 September 2024.

How: lessons, exercises and field activities, focusing on fish and cetacean
monitoring.

Organization: MareTerra Onlus - University of Sassari - Porto Conte
Regional Natural Park - Capo Caccia-Isola Piana Marine Protected Area.

Summer School Director: Dr. Gabriella La Manna.


Soundscape Ecology is a recent discipline that integrates bioacoustics (the
study of animal acoustic communication) and ecology with broad applications
(understanding of ecological processes, environmental monitoring and
management, biodiversity conservation, restoration ecology) and various
employment opportunities. The Summer School offers the chance to study
bioacoustics and ecoacoustics in one of the Mediterranean regions with the
highest biodiversity, Sardinia island. As you delve into the captivating
realm of bioacoustics and ecoacoustics, unlock the secrets of animal
acoustic communication and unravel the intricate tapestry of natural and
anthropic sounds that shape our environment.

But that's not all – brace yourself for thrilling field activities and boat
trips for fish and cetacean monitoring. Engage in hands-on exercises and
cutting-edge research, all while contributing to vital conservation efforts
and restoration ecology.

Whether you're a seasoned scholar, an aspiring student or an environmental
enthusiast, the Soundscape Ecology Summer School offers unparalleled
opportunities for personal and professional growth. Expand your skill set,
forge lasting connections, and chart a course towards a bright ecoacoustic
and environmental management career.

Secure your spot today by emailing i...@mareterra-erc.org.

Join us in Alghero!

Gabriella La Manna, Ph.D.
---

Dr Fabio Ronchetti
www.mareterragroup.net

www.progettonaturasardegna.com
www.instagram.com/progetto_natura_ecoturismo
www.facebook.com/progettonaturasardegna
progettonat...@mareterragroup.net.com
Via P. Enrico 42
07041 Alghero (SS)
Tel: +393921404069

Research associate *MareTerra ERC*

www.mareterra-erc.org
ronchettifa...@gmail.com
Via P. Enrico 42
07041 Alghero (SS)
Tel: +393921404069
___
MARMAM mailing list
MARMAM@lists.uvic.ca
https://lists.uvic.ca/mailman/listinfo/marmam

Bug#1054093: monit: diff for NMU version 1:5.33.0-2.1

2024-05-30 Thread Fabio A. De Muzio Tobich


Em 29/05/2024 21:59, Chris Hofstaedtler escreveu:

Control: tags 1054093 + pending


Dear maintainer,

I've prepared an NMU for monit (versioned as 1:5.33.0-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.



Hi Chris,

Your NMU is welcome, and feel free to reduce the delay if you see fit.

Thanks.

--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁   Fabio Augusto De Muzio Tobich
⢿⡄⠘⠷⠚⠋⠀   9730 4066 E5AE FAC2 2683  D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄


OpenPGP_signature.asc
Description: OpenPGP digital signature

guix system vm, QEMU, virtfs, and the security_model option

2024-05-30 Thread Fabio Natali

Hi,

A quick question re the 'guix system vm' command. When used in
combination with '--share=/foo=/bar', the command takes advantage of
QEMU's 'virtfs' option to share a folder between the host and the guest.

Interestingly, the command makes use of the 'security_model=none'
option. An alternative, one that I've seen recommended in some QEMU
docs⁰, would be using 'security_model=mapped-xattr'.

Is there any particular reason why we're using 'none' instead of
'mapped-xattr'?  The reason I'm asking is because I'm struggling with
some permission issues on a shared folder and I'd have a vague intuition
(or some hope) that 'mapped-xattr' might be a solution.

Thanks, best wishes, Fabio.

⁰ https://wiki.qemu.org/Documentation/9psetup'


-- 
Fabio Natali
https://fabionatali.com

[nexa] Automated Fortress Europe

2024-05-30 Thread fabio chiusi via nexa

Cari amici della lista Nexa,
un breve messaggio per salutarvi con affetto e per condividere il frutto del 
lavoro degli ultimi mesi, che penso possa interessarvi. 
Con i colleghi di AlgorithmWatch abbiamo collaborato per lungo tempo con una 
importante trasmissione di notizie e satira tedesca, ZDF Magazin Royale, a 
un'inchiesta su come automazione e AI vengono usate ai confini dell'UE per 
gestire e controllare i fenomeni migratori; in particolare, ci siamo 
concentrati sui progetti di ricerca e innovazione a tema finanziati dall'UE con 
milioni di euro negli ultimi anni, e sulla visione che emerge per il futuro del 
rapporto tra automazione e "people on the move" in UE. 

Io per AlgorithmWatch ho condotto la ricerca e l'inchiesta, su cui poi si è 
innestato il lavoro del team giornalistico di ZDF, che ha anche prodotto il 
segmento satirico andato in onda qualche giorno fa sulla tv tedesca. 
Ve ne lascio i link: 

-- La versione di ZDF, che include il video del segmento satirico che hanno 
ricavato dal nostro lavoro di ricerca: https://fuckoffai.eu/en/ (anche il nome 
del sito si spiega con una risata)
-- La base giornalistica e scientifica delle affermazioni fatte, nella nostra 
inchiesta integrale: https://algorithmwatch.org/en/automated-fortress-europe/. 

Per chi volesse saperne di più, insieme alla collega e amica Antonella 
Napolitano abbiamo parlato della "Automated Fortress Europe" oggetto 
dell'inchiesta anche in un talk a re:publica 2024, manifestazione appena 
conclusasi: https://youtu.be/ZB41Xsu4zgE?si=bF2vTYnNL4jYaIaO
Ogni feedback è, come sempre, il benvenuto. 

A presto, e buona giornata a tutti.

f.

[Bug 2064657] Re: Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

2024-05-29 Thread Fabio Augusto Miranda Martins

Based on discussions at https://github.com/nfs-ganesha/nfs-
ganesha/issues/1123, it seems this is something released with nfs-
ganesha V4, so IIUC, this is something that will only be available to an
Openstack + Manila + Ceph + NFS Ganesha in Noble Numbat, since it offers
nfs-ganesha 4.3-8ubuntu1

** Changed in: nfs-ganesha (Ubuntu)
   Status: Incomplete => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064657

Title:
  Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/2064657/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH 2/2] imx8mm-cl-iot-gate: Add support for the Realtek RTL8211E PHY

From: Fabio Estevam 

Newer imx8mm-cl-iot-gate versions are populated with a Realtek RTL8211E
PHY instead of the Atheros AR8033.

Adapted Compulab's patch from:
https://github.com/compulab-yokneam/meta-bsp-imx8mm/blob/iot-gate-imx8_5.10.72/recipes-bsp/u-boot/compulab/imx8mm/0125-imx8mm-net-enable-phy-Realtek-RTL8211E.patch

to support both PHYs in U-Boot.

Signed-off-by: Fabio Estevam 
---
 .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c   | 106 +-
 include/configs/imx8mm-cl-iot-gate.h  |   2 +-
 2 files changed, 104 insertions(+), 4 deletions(-)

diff --git a/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c 
b/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c
index af070ec315c4..bf196e062bd0 100644
--- a/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c
+++ b/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,6 +32,8 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+static int fec_phyaddr = -1;
+
 #if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)
 struct efi_fw_image fw_images[] = {
 #if defined(CONFIG_TARGET_IMX8MM_CL_IOT_GATE)
@@ -110,10 +113,72 @@ static int setup_fec(void)
return 0;
 }
 
+#define FDT_PHYADDR "/soc@0/bus@3080/ethernet@30be/mdio/ethernet-phy@0"
+#define FLIP_32B(val) (((val >> 24) & 0xff) | ((val << 8) & 0xff) | ((val 
>> 8) & 0xff00) | ((val << 24) & 0xff00))
+static int fdt_set_fec_phy_addr(void *blob)
+{
+   u32 val;
+
+   if (fec_phyaddr < 0)
+   return -EINVAL;
+
+   val = FLIP_32B(fec_phyaddr);
+   return fdt_find_and_setprop(blob, FDT_PHYADDR, "reg", (const void 
*),
+   sizeof(val), 0);
+}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+   fdt_set_fec_phy_addr(blob);
+   return 0;
+}
+
+/*
+ * These are specific ID, purposed to distiguish between PHY vendors.
+ * These values are not equal to real vendors' OUI (half of MAC address)
+ */
+#define OUI_PHY_ATHEROS 0x1374
+#define OUI_PHY_REALTEK 0x0732
+
 int board_phy_config(struct phy_device *phydev)
 {
-   if (IS_ENABLED(CONFIG_FEC_MXC)) {
+   unsigned int model, rev, oui;
+   int phyid1, phyid2;
+   unsigned int reg;
+
+   if (!IS_ENABLED(CONFIG_FEC_MXC))
+   return 0;
+
+   phyid1 = phy_read(phydev, MDIO_DEVAD_NONE, MII_PHYSID1);
+   if (phyid1 < 0) {
+   printf("%s: PHYID1 registry read fail %i\n", __func__, phyid1);
+   return phyid1;
+   }
+
+   phyid2 = phy_read(phydev, MDIO_DEVAD_NONE, MII_PHYSID2);
+   if (phyid2 < 0) {
+   printf("%s: PHYID2 registry read fail %i\n", __func__, phyid2);
+   return phyid2;
+   }
+
+   reg = phyid2 | phyid1 << 16;
+   if (reg == 0x) {
+   printf("%s: There is no device @%i\n", __func__, phydev->addr);
+   return -ENODEV;
+   }
+
+   rev = reg & 0xf;
+   reg >>= 4;
+   model = reg & 0x3f;
+   reg >>= 6;
+   oui = reg;
+   debug("%s: PHY @0x%x OUI 0x%06x model 0x%x rev 0x%x\n",
+ __func__, phydev->addr, oui, model, rev);
+
+   switch (oui) {
+   case OUI_PHY_ATHEROS:
/* enable rgmii rxc skew and phy mode select to RGMII copper */
+   printf("phy: AR803x@%x\t", phydev->addr);
phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x1f);
phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x8);
 
@@ -121,10 +186,45 @@ int board_phy_config(struct phy_device *phydev)
phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x82ee);
phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100);
+   break;
+   case OUI_PHY_REALTEK:
+   printf("phy: RTL8211E@%x\t", phydev->addr);
+   /* RTL8211E-VB-CG - add TX and RX delay */
+   unsigned short val;
+
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1f, 0x07);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0xa4);
+   val = phy_read(phydev, MDIO_DEVAD_NONE, 0x1c);
+   val |= (0x1 << 13) | (0x1 << 12) | (0x1 << 11);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1c, val);
+   /* LEDs: set to extension page */
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1f, 0x0007);
+   /* extension Page44 */
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x002c);
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1c, 0x0430);//LCR
+   phy_write(phydev, MDIO_DEVAD_NONE, 0x1a, 0x0010);//LACR
+   /*
+* To disable EEE LED mode (blinking .4s/2s)
+* Extension Page5
+*/
+

[PATCH 1/2] imx8mm-cl-iot-gate: Add support for Samsung 4GB DDR

From: Fabio Estevam 

Newer versions of the imx8mm-cl-iot-gate boards may come populated with a
Samsung 4GB DDR model.

Add support for it.

Signed-off-by: Fabio Estevam 
---
 board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c 
b/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
index b230478b611a..f1048a1ab2ab 100644
--- a/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
+++ b/board/compulab/imx8mm-cl-iot-gate/ddr/ddr.c
@@ -47,7 +47,9 @@ struct lpddr4_desc {
 static const struct lpddr4_desc lpddr4_array[] = {
{ .name = "Nanya",  .id = 0x0510, .subind = 0xff,
  .size = 2048, .count = 1, .timing = _dram_timing_01061010},
-   { .name = "Samsung",.id = 0x01061010, .subind = 0xff,
+   { .name = "Samsung",.id = 0x01061010, .subind = 0x04,
+ .size = 4096, .count = 1, .timing = _dram_timing_ff000110},
+   { .name = "Samsung",.id = 0x01061010, .subind = 0x02,
  .size = 2048, .count = 1, .timing = _dram_timing_01061010},
{ .name = "Kingston",   .id = 0xff10, .subind = 0x04,
  .size = 4096, .count = 1, .timing = _dram_timing_ff000110},
-- 
2.34.1

Re: [PATCH 2/2] arm: imx8mp-phycore: move to OF_UPSTREAM

On Tue, May 28, 2024 at 8:25 AM Yannic Moog  wrote:
>
> The PHYCORE_IMX8MP is used by the phyBOARD-Pollux. Migrate board to
> OF_UPSTREAM. Linux kernel device tree for the board can be used as is,
> corresponding U-Boot device tree files are removed. U-Boot tweaks are
> kept unchanged.
>
> Signed-off-by: Yannic Moog 

Reviewed-by: Fabio Estevam

Re: [PATCH 1/2] arm: imx8mm-phycore: move to OF_UPSTREAM

Hi Yannic,

On Tue, May 28, 2024 at 8:25 AM Yannic Moog  wrote:
>
> The PHYCORE_IMX8MM is used by the phyBOARD-Polis and the
> phyGATE-Tauri-L. Migrate both boards to OF_UPSTREAM. Linux kernel device
> trees for both boards can be used as is, corresponding U-Boot device
> tree files are removed. U-Boot tweaks are kept unchanged.
>
> Signed-off-by: Yannic Moog 

Reviewed-by: Fabio Estevam

Re: [PATCH v1 0/5] board: toradex: Add new Verdin and Aquila SKUs

Hi Francesco,

On Tue, May 28, 2024 at 9:39 AM Francesco Dolcini  wrote:

> I disagree on doing this on this specific series. The reason is that the
> changes on the tdx-cfg-block are depending one on each other and they
> have nothing nxp nor ti specific, they are toradex specific.
>
> If I misunderstood your request, how would you do it?
> Patches 1,2,4 and 5 are for Toradex NXP board variant, patch 3 is for a
> Toradex TI board, patches 4 and 5 depend on patch 3.

Thanks for the clarification. I will assign this series to me in patchwork then.

Re: [PATCH v1 0/5] board: toradex: Add new Verdin and Aquila SKUs

Hi Emanuele,

On Tue, May 28, 2024 at 7:00 AM Emanuele Ghidoli
 wrote:
>
> From: Emanuele Ghidoli 
>
> Hi,
> This series adds support for 0090 PID4 Verdin iMX8M Mini Quad 4GB WB ET SKU.
> It also adds two new SKUs config block support: 0088 Aquila AM69 Octa 32GB WB 
> IT and 0089 Verdin iMX95 Hexa 16GB WB IT.
>
> Signed-off-by: Emanuele Ghidoli 
>
> Emanuele Ghidoli (5):
>   board: toradex: verdin-imx8mm: add 4 GB lpddr4 memory support
>   board: toradex: verdin-imx8mm: increase maximum addressable ram to 4GB
>   toradex: tdx-cfg-block: add aquila am69 sku 0088 pid4
>   toradex: tdx-cfg-block: add verdin imx95 sku 0089 pid4
>   toradex: tdx-cfg-block: add verdin i.mx8m mini 0090 pid4

It would be better to split the series in two: one for the TI-SoC
boards and another one for the NXP-SoC boards.

Re: [HEADS-UP] Upcoming Rust SIG mini-mass-rebuild

2024-05-26 Thread Fabio Valentini

On Mon, May 20, 2024 at 9:29 PM Fabio Valentini  wrote:
>
> Hi all,
>
> As discussed in the Fedora Rust channel on Matrix, I am planning to do
> a mini-mass-rebuild of all Rust applications (that are co-maintained
> by the Rust SIG), likely by the end of this week. I estimate that it
> will involve just shy of 200 packages per branch.

This is now done. The updates are in bodhi:

https://bodhi.fedoraproject.org/updates/FEDORA-2024-c4bf73eb40
https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce2936b568
https://bodhi.fedoraproject.org/updates/FEDORA-2024-40ee18b2e7
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-74745ddb2a

I have included some additional (non rust-*) packages, including some
GNOME applications (gnome-tour, snapshot, loupe, librsvg2).
The EPEL9 builds have only picked up security fixes but not the better
debuginfo, since that change has not yet landed in RHEL 9's Rust
toolchain.

A quick check shows that debuginfo seems to be 10-15 MB larger after
the toolchain changes that landed in the package for Rust 1.78 in
Fedora. So it looks like debuginfo should indeed be more complete now
- and hopefully backtraces should now be on par with backtraces
generated by binaries that were built with the "official" upstream
Rust toolchain.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS-UP] GStreamer 1.24 landing in Fedora 40 soon

2024-05-25 Thread Fabio Valentini

On Sat, May 25, 2024 at 12:18 PM Fabio Valentini  wrote:
>
> Hi all,
>
> The Multimedia SIG has been working on rebasing GStreamer from 1.22 to
> 1.24 in Fedora 40.

The update has now been submitted to bodhi:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-2aa4a3bbf0

I've set high limits for stable karma to make sure the update doesn't
get pushed to stable too quickly.
Please let us know if there are any GStreamer-related issues.

The Multimedia SIG and some GStreamer upstream devs are in
#multimedia:fedoraproject.org on matrix.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

User TalionRanger comments

2024-05-25 Thread Fabio Loli


A request for help quickly degenerated in several insults

https://aur.archlinux.org/packages/octopi#comment-974574

https://aur.archlinux.org/packages/octopi#comment-974594

Please take appropriate action

[HEADS-UP] GStreamer 1.24 landing in Fedora 40 soon

2024-05-25 Thread Fabio Valentini

Hi all,

The Multimedia SIG has been working on rebasing GStreamer from 1.22 to
1.24 in Fedora 40.

We requested an exception to the Updates Policy, which was granted by FESCo:
https://pagure.io/fesco/issue/3204

This ticket also has more background why updating from 1.22 to 1.24 is
desirable.

The builds for GStreamer 1.24 itself are already done in a side-tag,
and I will handle the necessary rebuilds (apparently things need to be
rebuilt for the gstreamer-plugins-bad 1.22 -> 1.24 update):

- caja-extensions
- cheese
- fractal
- gnome-sound-recorder
- gnome-subtitles
- gtk4
- libva-nvidia-driver
- nheko
- pitivi
- qt5-qtmultimedia
- qt5-qtwebkit
- qt6-qtmultimedia
- snapshot
- webkit2gtk4.0
- webkitgtk
- wxGTK

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[amarok] [Bug 486342] Equalizer

2024-05-24 Thread Fabio

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

--- Comment #11 from Fabio  ---
ok, thank you for your effort, I understand the technical difficulty, 
and I look forward to a solution in the near future, a big hug!

Em 23/05/2024 18:58, Sebastian escreveu:
> https://bugs.kde.org/show_bug.cgi?id=486342
>
> --- Comment #10 from Sebastian  ---
> (In reply to Tuomas Nurmi from comment #9)
>> Yes, fine questions. Some answers:
>> As phonon-gstreamer backend is unmaintainend (related discussion at
>> https://invent.kde.org/libraries/phonon-gstreamer/-/issues/1  ) and thus
>> unsupported, it has lately been removed from various distribution
>> repositories. For openSUSE, the packages are still available at various
>> experimental repositories (
>> https://software.opensuse.org/package/phonon4qt5-backend-gstreamer  )
>> However, due to fact that it is unsupported, even its most obvious and
>> fixable bugs will not get fixed (e.g.
>> https://bugs.kde.org/show_bug.cgi?id=475880  )
>>
>> If multiple backends are installed, Phonon backend can be changed using
>> phononsettings application (available from separate phononsettings package,
>> at least on openSUSE). The packagers have set phonon-vlc-qt5 as dependency
>> probably as it is the only supported backend at the moment (okay, there's
>> apparently also phonon4qt5-backend-mpv but I have no experience with that
>> one, and it being a fork of phonon-vlc, its features are likely subset of
>> those of phonon-vlcs), and some backend is needed.
>>
>> When talking about "phonon-vlc team", one should be aware that although
>> there are some people keeping the lights on with phonon-vlc, the actual
>> development work on it (as well as anything phonon-related) has been quite
>> limited for 5 years or so, as observable from e.g. the code history at
>> https://invent.kde.org/libraries/phonon-vlc/-/commits/master/?ref_type=HEADS
>>
>> Additionally, I believe Amarok is the only software using the more specific
>> audio functionalities in Phonon nowadays.
>> (Some Amarok functionality related phonon-vlc bugreports, which are not very
>> likely to get implemented any time soon mostly due to vlc library
>> architechture:https://bugs.kde.org/show_bug.cgi?id=323332  and
>> https://bugs.kde.org/show_bug.cgi?id=320215  )
>>
>> Next steps of Amarok audio playback technology are something that should
>> receive some thoughts after/during Qt6 porting, I think. (The most obvious
>> options being someone spending a lot of effort on phonon-vlc, someone taking
>> up maintaining phonon-gstreamer, or rewriting Amarok audio playback to use
>> e.g. gstreamer directly)
> Ok, all is understood. Many thanks for the hint for phononsettings - I tried
> that (it was installed already under openSUSE); however, it only shows Phonon
> VLC in the backend section but no gstreamer. That's weird, as gstreamer is
> installed, too.
>
> Anyway, it seems that there is only one chance to solve the issue - the Amarok
> Qt6 porting. It is pretty pity that there is no immediate solution; Amarok in
> my eyes is one of the best players...
>
> Anything else I can help with? Otherwise, I would propose to close this issue
> as there is no fast solution available.
>

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

Re: [PATCH] ARM: imx: mx5: Simplify TFTP server layout on MX53 Menlo board

On Tue, May 21, 2024 at 7:50 AM Marek Vasut  wrote:
>
> From: Olaf Mandel 
>
> By removing the "boot" directory in the "m53menlo/boot/fitImage" path,
> we simplify the TFTP server directory layout a bit. This also requires a
> change to the mmcload command as it (mis-)uses the same variable as the
> TFTP boot.
>
> Signed-off-by: Olaf Mandel 
> Signed-off-by: Marek Vasut 

Applied, thanks.

Re: [PATCH] ARM: imx: mx5: Enable BMODE command on MX53 Menlo board

On Tue, May 21, 2024 at 6:42 AM Marek Vasut  wrote:
>
> The board can do primary/secondary boot switching, enable the bmode command.
>
> Signed-off-by: Marek Vasut 

Applied, thanks.

Re: [PATCH] ARM: dts: imx8mm: Update iMX8MM Menlo board configuration

On Tue, May 21, 2024 at 6:41 AM Marek Vasut  wrote:
>
> Synchronize Toradex Verdin iMX8MM based MX8Menlo board configuration
> with Toradex Verdin iMX8MM and enable convenience commands like cat,
> hexdump, xxd.
>
> Signed-off-by: Marek Vasut 

Applied, thanks.

Re: [PATCH] ARM: imx: Increase PHY auto-negotiation timeout to 20s on MX8Menlo

On Tue, May 21, 2024 at 6:40 AM Marek Vasut  wrote:
>
> The ethernet PHY on MX8Menlo board takes a while to come out of
> reset, increase the auto-negotiation timeout to prevent it from
> timing out in case the ethernet is used right after the board was
> reset.
>
> Signed-off-by: Marek Vasut 

Applied, thanks.

Re: [PATCH v2] imx: hab: add documentation about the required keys/certs

On Thu, May 16, 2024 at 5:36 AM Claudius Heine  wrote:
>
> For CST to find the certificates and keys for signing, some keys and
> certs need to be copied into the u-boot build directory.
>
> Signed-off-by: Claudius Heine 

Applied, thanks.

Re: [PATCH] ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry

On Mon, May 13, 2024 at 12:28 AM Marek Vasut  wrote:
>
> Make sure i.MX maintainers are CCed on doc/imx/ patches.
>
> Signed-off-by: Marek Vasut 

Applied, thanks.

Re: [PATCH v4 1/4] binman: Add nxp_imx8mcst etype for i.MX8M flash.bin signing

On Tue, May 21, 2024 at 7:48 AM Marek Vasut  wrote:
>
> Add new binman etype which allows signing both the SPL and fitImage sections
> of i.MX8M flash.bin using CST. There are multiple DT properties which govern
> the signing process, nxp,loader-address is the only mandatory one which sets
> the SPL signature start address without the imx8mimage header, this should be
> SPL text base. The key material can be configured using optional DT properties
> nxp,srk-table, nxp,csf-crt, nxp,img-crt, all of which default the key material
> names generated by CST tool scripts. The nxp,unlock property can be used to
> unlock CAAM access in SPL section.
>
> Reviewed-by: Tim Harvey 
> Signed-off-by: Marek Vasut 

Applied the series, thanks.

[GIT PULL] Please pull u-boot-imx-next-20240524

Hi Tom,

Please pull from u-boot-imx/next, thanks.

The following changes since commit 377e91c162ab09ec20f96f966f380cb55c590edd:

  Merge patch series "Clean-up patch set for MbedTLS integration" (2024-05-22 
08:55:35 -0600)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
tags/u-boot-imx-next-20240524

for you to fetch changes up to 7457dc6f183303aaf2d58fff0a622e6791aba33c:

  imx: hab: add documentation about the required keys/certs (2024-05-24 
11:33:15 -0300)

u-boot-imx-master-20240524
--

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20834

- Allow signing i.MX8M flash.bin via binman, which is a much more elegant
solution that using scripts.
- Improve i.MX8M HAB documentation.
- Increase PHY auto-negotiation timeout to 20s on MX8Menlo
- Add bmode support for the MX53 Menlo board.
- Update Update iMX8MM Menlo board configuration

Claudius Heine (1):
  imx: hab: add documentation about the required keys/certs

Marek Vasut (8):
  binman: Add nxp_imx8mcst etype for i.MX8M flash.bin signing
  ARM: dts: imx: Introduce SPL and FIT labels to i.MX8M DTs binman nodes
  ARM: dts: imx: Wrap i.MX8M binman SPL and FIT nodes in CST node if 
IMX_HAB enabled
  imx: hab: Use nxp_imx8mcst etype for i.MX8M flash.bin signing
  ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry
  ARM: imx: Increase PHY auto-negotiation timeout to 20s on MX8Menlo
  ARM: dts: imx8mm: Update iMX8MM Menlo board configuration
  ARM: imx: mx5: Enable BMODE command on MX53 Menlo board

Olaf Mandel (1):
  ARM: imx: mx5: Simplify TFTP server layout on MX53 Menlo board

 .gitignore  |   2 +
 MAINTAINERS |   1 +
 Makefile|   2 +-
 arch/arm/dts/imx8mm-u-boot.dtsi | 195 --
 arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi |   8 +-
 arch/arm/dts/imx8mn-u-boot.dtsi | 209 +---
 arch/arm/dts/imx8mp-dhcom-u-boot.dtsi   | 124 +++---
 arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi  |  26 ++-
 arch/arm/dts/imx8mp-u-boot.dtsi | 172 ++-
 arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi  |  10 +-
 arch/arm/dts/imx8mq-u-boot.dtsi | 182 -
 configs/imx8mm-mx8menlo_defconfig   |  28 +++-
 configs/m53menlo_defconfig  |   3 +-
 doc/imx/habv4/csf_examples/mx8m/csf.sh  |  92 ---
 doc/imx/habv4/csf_examples/mx8m/csf_fit.txt |  30 
 doc/imx/habv4/csf_examples/mx8m/csf_spl.txt |  33 
 doc/imx/habv4/guides/mx8m_spl_secure_boot.txt   | 131 ++-
 include/configs/imx8mm-mx8menlo.h   |   3 +
 include/configs/m53menlo.h  |   2 +-
 tools/binman/btool/cst.py   |  48 ++
 tools/binman/etype/nxp_imx8mcst.py  | 164 +++
 21 files changed, 799 insertions(+), 666 deletions(-)
 delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf.sh
 delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_fit.txt
 delete mode 100644 doc/imx/habv4/csf_examples/mx8m/csf_spl.txt
 create mode 100644 tools/binman/btool/cst.py
 create mode 100644 tools/binman/etype/nxp_imx8mcst.py

Re: Intention to unretire and rename pyftpdlib

2024-05-24 Thread Fabio Valentini

On Fri, May 24, 2024 at 2:48 PM Kevin Kofler via devel
 wrote:
>
> Sandro wrote:
> > I was probably overthinking this. In practice it will turn out to be a
> > new package submission indeed. Moreover, the last remaining active
> > branch of the retired package (F38) is now EOL.
> >
> > I've submitted the review [1] without any Obsoletes.
>
> Since we support upgrades from Fedora n to n+2, there SHOULD be Obsoletes in
> place until at least the F40 EOL. I would recommend just keeping the
> Obsoletes forever.

Why? The only thing that is being renamed as part of the unretirement
is the *source* package.
Obsoletes and Provides have zero effect for those. So not adding them
is correct here.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Virtualisation alternatives for deploying a small number of services

2024-05-23 Thread Fabio Natali

On 2024-05-22, 19:16 +0200, Tomas Volf <~@wolfsden.cz> wrote:
> If your main goal is strong isolation and security, you probably might
> want to take a look at firecracker[0].  Downside is non-existent
> support in Guix, not even a package.

Hey Tomas,

Thanks for getting back to me!

You're right, Firecracker seems to perfectly address my objectives - but
yeah, the fact that there's no Guix support makes it a bit less
appealing. I guess I'm willing to accept some performance overhead in
exchange for QEMU's good level of integration. But thanks for suggesting
this as an option.

Looking at Firecracker brought another project to my attention,
MicroVM.nix⁰. If I'm not mistaken, it would look like the NixOS
equivalent of what I was looking for.

It'd be nice to create a 'least-authority-wrapper' variant that's
VM-based. If you like, keep me posted on your findings and feel free to
DM me if you want to brainstorm the idea together.

Cheers, Fabio.

⁰ https://github.com/astro/microvm.nix

[amarok] [Bug 486342] Equalizer

2024-05-22 Thread Fabio

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

--- Comment #5 from Fabio  ---
Yes, I confirm that the analyzer applet is not working together with the 
equalizer

my system is KDE neon 6.0.4

  intel core i5 processor

16gb memory

  wayland graphics server

Em 22/05/2024 17:57, Sebastian escreveu:
> https://bugs.kde.org/show_bug.cgi?id=486342
>
> Sebastian  changed:
>
> What|Removed |Added
> 
>   CC||sebastian.ku...@mailbox.org
>
> --- Comment #4 from Sebastian  ---
> Hi, I was looking for a potential bug report as in Amarok Version 3.0.0 the
> Analyzer Applet is not working for me.
>
> However, I found this Equalizer issue, and I can confirm the same behavior.
>
> I am running the following system:
> Operating System: openSUSE Tumbleweed 20240521
> KDE Plasma Version: 6.0.4
> KDE Frameworks Version: 6.2.0
> Qt Version: 6.7.0
> Kernel Version: 6.9.1-1-default (64-bit)
> Graphics Platform: Wayland
> Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G
> Memory: 14.6 GiB of RAM
> Graphics Processor: KAVERI
>
> Would be great to get an update here, and *maybe* the issue is even related to
> the Analyzer Applet?
>
> Many thanks!
>

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

[Bug 2064657] Re: Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

2024-05-22 Thread Fabio Augusto Miranda Martins

This is also being discussed upstream: https://github.com/nfs-
ganesha/nfs-ganesha/issues/1123

** Bug watch added: github.com/nfs-ganesha/nfs-ganesha/issues #1123
   https://github.com/nfs-ganesha/nfs-ganesha/issues/1123

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064657

Title:
  Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/2064657/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064657] Re: Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

2024-05-22 Thread Fabio Augusto Miranda Martins

Hi Peter,

The NFS client is a Jammy VM running nfs-common 1:2.6.1-1ubuntu1.2 and
kernel 5.15.0-102-generic.

I'm running a sosreport and will attach it here soon.

Regards,
Fabio

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064657

Title:
  Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/2064657/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2064657] Re: Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

2024-05-22 Thread Fabio Augusto Miranda Martins

** Attachment added: "sosreport-jammy-130612-2024-05-22-dnjwtoi.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/2064657/+attachment/5781410/+files/sosreport-jammy-130612-2024-05-22-dnjwtoi.tar.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064657

Title:
  Add support for CEPH ceph.file.layout and ceph.dir.layout xattr

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-ganesha/+bug/2064657/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Virtualisation alternatives for deploying a small number of services

2024-05-22 Thread Fabio Natali

Hi,

I'd like to run a small number of VMs on a single physical machine. The
reason for using VMs is security, i.e. to get a strong level of
isolation when deploying some services.

Among the options I've been considering:

+ libvirt, which I understand would imply some manual (potentially non
  declarative?) setup, beyond defining and bringing up the libvirt Guix
  service.
+ Ganeti, which might be a bit of an overkill for this particular use
  case.
+ Guix's 'least-authority-wrapper', which of course would give me
  containerisation rather than virtualisation, so not really what I'm
  looking for.

I think libvirt is my favourite option so far but I was wondering if
there's any further alternative that I haven't been considering.

I think the ideal solution would be some wrapper similar to the
least-authority one, but that spins up a VM rather than a container. I
see there's 'virtual-build-machine-service-type' which of course
wouldn't fit the bill, but it might be close to the idea of a VM-based
wrapper?

Any ideas or pointers to existing solution are welcome.

Thanks, best, Fabio.

(I'd be grateful if you could CC me in if replying as otherwise I might
miss your email.)


-- 
Fabio Natali
https://fabionatali.com

[krdc] [Bug 455691] Cannot connect to older Windows server "ERRCONNECT_TLS_CONNECT_FAILED"

2024-05-21 Thread Fabio

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

Fabio  changed:

   What|Removed |Added

  Latest Commit||https://invent.kde.org/netw
   ||ork/krdc/-/commit/8bca0c765
   ||c75e38f26f38bde650a48308ab1
   ||aaeb
 Status|REPORTED|RESOLVED
 CC||ctrlal...@gmail.com
 Resolution|--- |FIXED
   Version Fixed In||24.05

--- Comment #1 from Fabio  ---
Fixed by https://invent.kde.org/network/krdc/-/merge_requests/65
An option to set the minimum TLS security level has been added

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

[krdc] [Bug 482137] Regression: Filesystem/Clipboard not shared anymore

2024-05-21 Thread Fabio

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

Fabio  changed:

   What|Removed |Added

 CC||teej.d@gmail.com

--- Comment #4 from Fabio  ---
*** Bug 484607 has been marked as a duplicate of this bug. ***

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

[krdc] [Bug 484607] Copy and Paste and Folder Sharing not working

2024-05-21 Thread Fabio

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

Fabio  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|REPORTED|RESOLVED
 CC||ctrlal...@gmail.com

--- Comment #1 from Fabio  ---
Clipboard has been fixed in current development version (see BUG 484666),
filesystem sharing is still missing.

*** This bug has been marked as a duplicate of bug 482137 ***

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

[krdc] [Bug 482137] Regression: Filesystem/Clipboard not shared anymore

2024-05-21 Thread Fabio

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

Fabio  changed:

   What|Removed |Added

 CC||ctrlal...@gmail.com

--- Comment #3 from Fabio  ---
Clipboard has been fixed in current development version (see BUG 484666),
filesystem sharing is still missing.

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

[krdc] [Bug 484666] Copy - Paste is not working

2024-05-21 Thread Fabio

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

Fabio  changed:

   What|Removed |Added

 CC||sunwe...@gmail.com

--- Comment #5 from Fabio  ---
*** Bug 487140 has been marked as a duplicate of this bug. ***

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

[krdc] [Bug 487140] Clipboard doesn't work

2024-05-21 Thread Fabio

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

Fabio  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |DUPLICATE
 CC||ctrlal...@gmail.com

--- Comment #1 from Fabio  ---
Duplicate of 484666.
Fixed in current development version

*** This bug has been marked as a duplicate of bug 484666 ***

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

Re: [android-building] configuring android environment on ubuntu 24.04

2024-05-21 Thread Fabio Porcedda

Il giorno martedì 14 maggio 2024 alle 17:50:05 UTC+2 Mathieu Fluhr ha 
scritto: 

Another issue that you will face with 24.04 is some nsjail warning messages 
at the start of the build.
This is due to an AppArmor change that was introduced in 23.10 and 
restricted unprivileged user namespaces.
For this, my solution was to alter AppArmor configuration, 
setting kernel.apparmor_restrict_unprivileged_userns to 0.


How can be done?

Thanks
Fabio

-- 
-- 
You received this message because you are subscribed to the "Android Building" 
mailing list.
To post to this group, send email to android-building@googlegroups.com
To unsubscribe from this group, send email to
android-building+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-building+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-building/dc26f0ef-e4b8-4b26-b944-be48facf32e4n%40googlegroups.com.

Re: Intention to retire mlocate

2024-05-21 Thread Fabio Valentini

On Mon, May 20, 2024 at 2:42 PM Michal Sekletar  wrote:
>
> On Fri, May 17, 2024 at 6:14 PM Michal Sekletar  wrote:
>>
>> Hi everyone,
>>
>> We have had a plocate as a drop-in replacement for mlocate for quite a while 
>> now. My intention is to retire the mlocate package next week in order to 
>> prevent duplication and so that we can focus only on plocate going forward.
>
>
> mlocate is now retired in Rawhide.
>
> https://src.fedoraproject.org/rpms/mlocate/c/7277dd5f59db126d1046a6aa5c4077a597dc?branch=rawhide

Thanks for the heads-up!
Should the package also be added to fedora-obsolete-packages so that
it is - if installed - removed on upgrade to Fedora 41?

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedora-legal-list] Re: Brainpool Curves in Fedora (openssl, libgcrypt, gnupg)

2024-05-21 Thread Fabio Valentini

On Tue, May 21, 2024 at 3:00 AM Richard Fontana  wrote:
>
> On Thu, May 16, 2024 at 10:00 AM Fabio Valentini  wrote:
> >
> > Can somebody with edit privileges on that page update the list?
> > Or should this documentation be moved somewhere else altogether (legal
> > docs on docs.fp.o)?
>
> It should probably be moved to docs.fp.o, we've been treating the
> legal portions of the wiki as deprecated.

Thanks, I've now opened a merge request that does so:
https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/296

Fabio
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[HEADS-UP] Upcoming Rust SIG mini-mass-rebuild

2024-05-20 Thread Fabio Valentini

Hi all,

As discussed in the Fedora Rust channel on Matrix, I am planning to do
a mini-mass-rebuild of all Rust applications (that are co-maintained
by the Rust SIG), likely by the end of this week. I estimate that it
will involve just shy of 200 packages per branch.

The motivation for a mini-mass-rebuild is two-fold:

1. Until very recently, the Rust standard library (shipped as a static
archive by the "rust" package) was accidentally shipped with stripped
debuginfo, which resulted in Rust applications that linked the
standard library to have incomplete debuginfo - and as a result, they
produced incomplete backtraces for any stack traces that involved the
Rust standard library. This has been fixed since rust 1.78, but
applications need to be rebuilt to pick up this improvement.

2. I regularly rebuild applications for "major" / "high priority"
security issues in Rust crates, but there are a few accumulated
"minor" / "low priority" security issues where I didn't yet have the
time to rebuild the affected applications against the library versions
that contain the necessary fixes. A mini-mass-rebuild would take care
of all of these at the same time.

I plan to only rebuild Rust applications that are associated with the
Rust SIG (i.e. packages "rust-*"), but no other packages (for example,
firefox, thunderbird, or librsvg2). If any maintainers of packages
that contain Rust code but that are not co-maintained by the Rust SIG
would like their packages to be included in the mini-mass-rebuild as
well, just let me know and I'll add them to my list.

Fabio

PS: Packages that build with vendored Rust dependencies (there are a
handful of them, and most are not co-maintained by the Rust SIG) would
only benefit from better debuginfo / backtraces, but not from security
updates (that would require manually updating the vendor tarball),
which is why I will not include them in the mini-mass-rebuild.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Opinionated Query Definition

2024-05-20 Thread fabio trabattoni

o summarise:*
>
> 1. jOOQ will continue to add more convenience for nesting data structures 
> in queries with even more focus on path traversal and projections / 
> selections / correlations based on paths
> 2. jOOQ will not offer an alternative, "opinionated" API on top of jOOQ 
> that solves only root/aggregate based entity traversal (and thus not repeat 
> the mistake of countless ORMs of separating querying from entity 
> interactions, leading to confusion and limitation). Any jOOQ solution will 
> be fully integrated into the entirety of the query language in a way that 
> would even be idiomatic for SQL itself.
>
> An example of 2) is the DAO API, which I regret so much. It is such a 
> terrible bikeshed, being the only really opinionated thing in jOOQ. Sure, 
> users like it, and it can't be removed again for this reason. But it is not 
> well-designed. It was a "quick win," that will never implement the features 
> users ultimately desire. Jakarta Data is making the same mistake right now 
> by copying Spring's Repository and thus opening up endless bikesheds 
> instead of truly innovating, at least in my opinion.
>
> In order to respond to your criticism, jOOQ's approach is the *only* way 
> to result in code:
>
> - That is not hard to read
> - That is consistent
> - That is easy to maintain
>
> Users can build opinionated APIs on top of jOOQ if they think its approach 
> is not convenient enough, though, incidentally, well-designed convenience 
> within the jOOQ query system may lead to satisfactory results for 
> not-extremely-opinionated users nonetheless.
>
>
> On Sat, May 18, 2024 at 6:41 PM Fabio Trabattoni  
> wrote:
>
>> Hello everyone,
>>
>> I hope this message finds you well. I’d like to share an idea for a 
>> potential feature request, inspired by a brief discussion on SO with Lukas.
>>
>> *INTRO* When starting a Java Spring project, developers often use JPA 
>> for data mapping because it allows for quick and straightforward setup. 
>> However, as the project grows, they start encountering performance issues 
>> like the infamous N+1 problem et similia. 
>>
>> At this stage, devs make one of the two things happen:
>>
>>1. Refactoring JPA Mappings: They push themselves to restructure 
>>mappings and use more efficient querying mechanisms with JPA.
>>2. Switching to Alternatives: They opt for alternatives like JOOQ or 
>>QueryDSL to handle their queries.
>>
>> Unfortunately, most of the times ,both approaches result in code that is 
>> hard to read, inconsistent, and difficult to maintain. At least in my 
>> experience.
>>
>> *THE IDEA *Here’s the idea: a strongly opinionated way of defining 
>> queries that starts from the basic thought steps when dealing with data 
>> querying in Java. The focus would be on defining a query plan with filter 
>> criteria and specifying what to load and how it should be loaded, possibly 
>> even in a recursive fashion.
>>
>>1. Specify Filters: A straightforward mechanism to define and apply 
>>filters to the data set.
>>2. Specify What to Fetch: A clear way to determine which fields to 
>>retrieve.
>>3. Recursive Query Plan: The ability to define a query plan that can 
>>handle recursive fetching and recursive criteria, ensuring that related 
>>data is queried efficiently.
>>
>> At a glance it could look something like this: 
>> https://github.com/thestroke82/leanquery/blob/master/src/main/java/org/frappa/leanquery/controller/CustomerController.java
>>  
>> I've worked with a custom solution very much like this in the past and 
>> observed it performing its job remarkably well. The strongest advantage of 
>> such an approach is that as the codebase grows, readability remains 
>> practically constant, significantly improving maintainability. *CONCLUSION 
>> *The ideas are now out in the open, both in words and code (see the 
>> GitHub link above). I’m eager to hear your thoughts and advice, and I hope 
>> we can work together to evolve this concept into a formal feature request 
>> for JOOQ. 
>>
>> One final request: Please refrain from comments that patronize or dismiss 
>> the idea with statements like "JPA already does that" or "X does that too." 
>> Instead, I’m looking for constructive feedback and suggestions on how we 
>> can make this feature a valuable addition to the JOOQ ecosystem.
>>
>> Thank you for your time and consideration. I look forward to your 
>> feedback and collaboration!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "jOOQ User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jooq-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jooq-user/99bbd0c3-e5af-4ee7-a897-7ff869098288n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jooq-user/99bbd0c3-e5af-4ee7-a897-7ff869098288n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups "jOOQ 
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jooq-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jooq-user/5a7d663b-b1cc-4729-be62-21dbffe25573n%40googlegroups.com.

Re: Opinionated Query Definition

2024-05-20 Thread fabio trabattoni

Mine is a smaller attempt. I didn't want to build a general query engine, I 
just wanted something that made sense inside a specific domain. The primary 
goal is to force the devs to act in a well-defined pattern.

The general apporach is very similar though:
1) Create a simple grammar in the form of OOP classes
2) Instrument an engine that translates 1) for the lower levels

Il giorno lunedì 20 maggio 2024 alle 13:38:58 UTC+2 5kil...@googlemail.com 
ha scritto:

> Hello Fabio,
>
> i just want to share my similar use-case, just to give a perspective to a 
> different way to solve dynamic querying.
>
> - 1. a common Query-Model
> - 2. a Mapper that maps the Query-Model to Dynamic Jooq
> - 3. a Repository for each use-case that resolves data with help of 
> MULTISET, Pagination, Filtering etc.
>
> The common Query-Model (FkQuery). 
> - See: 
> https://github.com/funkrusher/fk-framework-quarkus-jooq/tree/main/_core/fk_core/src/main/java/org/fk/core/query/model
>
> The mapper that maps the Query-Model to Dynamic Jooq: 
> - See: 
> https://github.com/funkrusher/fk-framework-quarkus-jooq/blob/main/_core/fk_core/src/main/java/org/fk/core/query/jooq/FkQueryJooqMapper.java
>
> The Repository: 
> - See: 
> https://github.com/funkrusher/fk-framework-quarkus-jooq/blob/main/_modules/fk_product/src/main/java/org/fk/product/repository/ProductRepository.java
>
> ---
>
> I think my solution is not recursive or as strong in regards to dynamic 
> flexibility, but it does also provide a dynamic way to interact with the 
> Repository 
> to filter specific data in a Table-Relationship (Main-Table, Subtables). 
> Its not as strongly typesafe though, because the query-model can also 
> contain invalid selectors,
> because it can also come directly from frontends for example. 
>
> The Repository here is providing a static (always the same) Select 
> Statements on multiple tables. In your solution you would dynamically build 
> a different
> Select, so your way to do this would be more performant and more specific, 
> while this approach is more uniform but less dynamic.
>
> I found your approach interesting, because a clean way to define 
> "Fragments" and dynamically use them is surely helpful.
> lukas...@gmail.com schrieb am Montag, 20. Mai 2024 um 10:14:05 UTC:
>
>> Thanks for your message.
>>
>> For the record of others following this discussion, it's a follow-up to 
>> this Stack Overflow question:
>> https://stackoverflow.com/q/78495895/521799
>>
>> Fetch plans like these aren't a new idea. JPA does indeed already explore 
>> such functionality via entity graphs. I've seen similar things in .NET's 
>> LLBLGen, and numerous other environments. Spring Data and their whole idea 
>> of DDD tries to model database interaction via a set of aggregates and 
>> roots, which aren't too different from fetch plans / entity graphs. In a 
>> way, GraphQL does this as well. Your quick prototype isn't so different. 
>> The most revolutionary attempt so far IMO is Oracle 23ai's JSON-relational 
>> duality views concept:
>> https://oracle-base.com/articles/23/json-relational-duality-views-23
>>
>> The idea is always similar:
>>
>> - You have a root
>> - From this root, you want to optionally navigate a tree of related data
>>
>> It's not "patronising" to look into prior art, because we can learn from 
>> others' successes and mistakes, so I'm not quite sure why you'd like others 
>> to refrain from making comparisons. If you will, "constructive feedback" is 
>> only ever possible if it is informed, and in order to be informed, one 
>> needs to combine the experience of others' with additional ideas.
>>
>> Why doesn't jOOQ have this yet? jOOQ's primary objective is to model the 
>> SQL language. In SQL, we write queries against the underlying relational 
>> data model, which is typically but not necessarily normalised at least in 
>> 3NF. This is a fundamental part of jOOQ's philosophy, and thus any 
>> DDD-style root/aggregate traversal does seem foreign to jOOQ (and to SQL). 
>> The impedance mismatch between DDD and SQL is non-negligible. To this day, 
>> I'm not 100% sure whether this is because DDD is fundamentally flawed, or 
>> existing attempts at implementing DDD principles are fundamentally flawed, 
>> in that they seem to completely dismiss the idea of an underlying 
>> relational data model (e.g. by being "data store agnostic"). The way these 
>> flaws manifest, in my opinion, is that the existing frameworks are 
>> extremely limited in the way they allow for non-entity querying. Everything 
>> is always fetched entirely (all attrib

Re: [VOTE] Apache Syncope 3.0.7 2nd attempt

2024-05-20 Thread Fabio Martelli

+1
Regards

On Mon, May 20, 2024 at 9:15 AM Francesco Chicchiriccò 
wrote:

> I've created a 3.0.7 release, with the following artifacts up for a vote:
>
> GIT source tag (f0a9c658c7):
> https://github.com/apache/syncope/releases/tag/syncope-3.0.7
>
> List of changes:
> https://github.com/apache/syncope/blob/syncope-3.0.7/CHANGES
>
> Staging artifacts:
> https://dist.apache.org/repos/dist/dev/syncope/3.0.7/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachesyncope-1088/
>
> Staging site:
> https://syncope.apache.org/3.0.7/index.html
>
> PGP release keys (signed using 273DF287):
> http://www.apache.org/dist/syncope/KEYS
>
> Vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here's my +1
> Regards.
>
>
>
>

[Git][archlinux/packaging/packages/dbeaver][main] upgpkg: 24.0.5-1



Fabio Castelli pushed to branch main at Arch Linux / Packaging / Packages / 
dbeaver


Commits:
132b4ecb by Fabio Castelli (Muflone) at 2024-05-20T01:10:23+02:00
upgpkg: 24.0.5-1

- - - - -


2 changed files:

- .SRCINFO
- PKGBUILD


Changes:

=
.SRCINFO
=
@@ -1,6 +1,6 @@
 pkgbase = dbeaver
pkgdesc = Free universal SQL Client for developers and database 
administrators (community edition)
-   pkgver = 24.0.4
+   pkgver = 24.0.5
pkgrel = 1
url = https://dbeaver.io/
install = dbeaver.install
@@ -16,15 +16,15 @@ pkgbase = dbeaver
optdepends = dbeaver-plugin-svg-format: save diagrams in SVG format
conflicts = dbeaver-plugin-sshj-lib
replaces = dbeaver-plugin-sshj-lib
-   source = 
dbeaver-24.0.4.tar.gz::https://github.com/dbeaver/dbeaver/archive/24.0.4.tar.gz
-   source = 
dbeaver-common-24.0.4.tar.gz::https://github.com/dbeaver/dbeaver-common/archive/84808663652ad45e04396d1692ae7f53f77cdbd2.tar.gz
+   source = 
dbeaver-24.0.5.tar.gz::https://github.com/dbeaver/dbeaver/archive/24.0.5.tar.gz
+   source = 
dbeaver-common-24.0.5.tar.gz::https://github.com/dbeaver/dbeaver-common/archive/fd76bbe199dd81d6538c188b1c5854094f7bdd0b.tar.gz
source = io.dbeaver.DBeaver.desktop
source = dbeaver.sh
source = dbeaver.profile.gz
source = dbeaver.hook
source = dbeaver.install
-   sha256sums = 
7bb932d6cb3f8e1a0c2564ab40f8882084b540cd7fdbaa054e4da5edf17e9b6e
-   sha256sums = 
08e611b65980566d2bfb79c300a7a27df0d894e302fd889b68403e9feb225fbe
+   sha256sums = 
c30be0ff8e6770a0dcdd704a5c0a00dcd028850f4dd7f84f56e92ea6462b4e12
+   sha256sums = 
bf157f24580d1db54df39373751a0271583fe4e3f8829b2a892af71ee51b755f
sha256sums = 
9480a7d08f680e10c399db070c5a04cbabf282442602a2ef83d1159fe7c3e88b
sha256sums = 
406a2980806c394670e88b1ae70134900be376c2ea4a4216610591cc8b557526
sha256sums = 
1863e74bdcf22b7328e6e8487cbebff7d5360e34bde85c1dd226b168b4737034


=
PKGBUILD
=
@@ -2,9 +2,9 @@
 # Contributor: Arne Hoch 
 
 pkgname=dbeaver
-pkgver=24.0.4
+pkgver=24.0.5
 pkgrel=1
-_COMMON_COMMIT_ID='84808663652ad45e04396d1692ae7f53f77cdbd2'
+_COMMON_COMMIT_ID='fd76bbe199dd81d6538c188b1c5854094f7bdd0b'
 pkgdesc="Free universal SQL Client for developers and database administrators 
(community edition)"
 arch=('x86_64')
 url="https://dbeaver.io/;
@@ -22,8 +22,8 @@ 
source=("${pkgname}-${pkgver}.tar.gz"::"https://github.com/dbeaver/dbeaver/archi
 "${pkgname}.profile.gz"
 "${pkgname}.hook"
 "${pkgname}.install")
-sha256sums=('7bb932d6cb3f8e1a0c2564ab40f8882084b540cd7fdbaa054e4da5edf17e9b6e'
-'08e611b65980566d2bfb79c300a7a27df0d894e302fd889b68403e9feb225fbe'
+sha256sums=('c30be0ff8e6770a0dcdd704a5c0a00dcd028850f4dd7f84f56e92ea6462b4e12'
+'bf157f24580d1db54df39373751a0271583fe4e3f8829b2a892af71ee51b755f'
 '9480a7d08f680e10c399db070c5a04cbabf282442602a2ef83d1159fe7c3e88b'
 '406a2980806c394670e88b1ae70134900be376c2ea4a4216610591cc8b557526'
 '1863e74bdcf22b7328e6e8487cbebff7d5360e34bde85c1dd226b168b4737034'



View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/commit/132b4ecb16ffdfee8a868523cf6077a16ea2d9ed

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/commit/132b4ecb16ffdfee8a868523cf6077a16ea2d9ed
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/dbeaver] Pushed new tag 24.0.5-1



Fabio Castelli pushed new tag 24.0.5-1 at Arch Linux / Packaging / Packages / 
dbeaver

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/tree/24.0.5-1
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/vorta] Pushed new branch main



Fabio Castelli pushed new branch main at Arch Linux / Packaging / Packages / 
vorta

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/vorta/-/tree/main
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/vorta] Pushed new tag 0.9.1-4



Fabio Castelli pushed new tag 0.9.1-4 at Arch Linux / Packaging / Packages / 
vorta

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/vorta/-/tree/0.9.1-4
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/perl-pdf-api2] Pushed new tag 2.047-1



Fabio Castelli pushed new tag 2.047-1 at Arch Linux / Packaging / Packages / 
perl-pdf-api2

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/perl-pdf-api2/-/tree/2.047-1
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/perl-pdf-api2][main] upgpkg: 2.047-1



Fabio Castelli pushed to branch main at Arch Linux / Packaging / Packages / 
perl-pdf-api2


Commits:
18102434 by Fabio Castelli (Muflone) at 2024-05-19T15:07:30+02:00
upgpkg: 2.047-1

- - - - -


2 changed files:

- .SRCINFO
- PKGBUILD


Changes:

=
.SRCINFO
=
@@ -1,16 +1,16 @@
 pkgbase = perl-pdf-api2
pkgdesc = Faciliates the creation and modification of PDF files
-   pkgver = 2.045
+   pkgver = 2.047
pkgrel = 1
url = https://metacpan.org/release/PDF-API2
arch = any
-   license = LGPL
+   license = LGPL-2.1-or-later
checkdepends = perl-test-exception
checkdepends = perl-test-memory-cycle
depends = perl
depends = perl-font-ttf
options = !emptydirs
-   source = 
https://www.cpan.org/modules/by-module/PDF/PDF-API2-2.045.tar.gz
-   sha256sums = 
b6bdb4e0d0cd6526103fdd58c171e0560c36b843b7fe3ca4ddc9bb1e4c832406
+   source = 
https://www.cpan.org/modules/by-module/PDF/PDF-API2-2.047.tar.gz
+   sha256sums = 
84d6318279d77844923e4de4275fe4345cd08b225edd7f9ed6a16f87a91aca39
 
 pkgname = perl-pdf-api2


=
PKGBUILD
=
@@ -8,16 +8,16 @@
 pkgname=perl-pdf-api2
 _perl_namespace=PDF
 _perl_module=API2
-pkgver=2.045
+pkgver=2.047
 pkgrel=1
 pkgdesc="Faciliates the creation and modification of PDF files"
 arch=('any')
 url="https://metacpan.org/release/${_perl_namespace}-${_perl_module};
-license=('LGPL')
+license=('LGPL-2.1-or-later')
 depends=('perl' 'perl-font-ttf')
 checkdepends=('perl-test-exception' 'perl-test-memory-cycle')
 
source=("https://www.cpan.org/modules/by-module/${_perl_namespace}/${_perl_namespace}-${_perl_module}-${pkgver}.tar.gz;)
-sha256sums=('b6bdb4e0d0cd6526103fdd58c171e0560c36b843b7fe3ca4ddc9bb1e4c832406')
+sha256sums=('84d6318279d77844923e4de4275fe4345cd08b225edd7f9ed6a16f87a91aca39')
 options=('!emptydirs')
 
 build() {



View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/perl-pdf-api2/-/commit/18102434fa67339f0b0b274f193bb2a1c2effa18

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/perl-pdf-api2/-/commit/18102434fa67339f0b0b274f193bb2a1c2effa18
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/perl-graphics-tiff] Pushed new tag 21-1



Fabio Castelli pushed new tag 21-1 at Arch Linux / Packaging / Packages / 
perl-graphics-tiff

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/perl-graphics-tiff/-/tree/21-1
You're receiving this email because of your account on gitlab.archlinux.org.

[Git][archlinux/packaging/packages/perl-graphics-tiff][main] upgpkg: 21-1



Fabio Castelli pushed to branch main at Arch Linux / Packaging / Packages / 
perl-graphics-tiff


Commits:
c5838b72 by Fabio Castelli (Muflone) at 2024-05-19T15:07:07+02:00
upgpkg: 21-1

- - - - -


2 changed files:

- + .SRCINFO
- PKGBUILD


Changes:

=
.SRCINFO
=
@@ -0,0 +1,21 @@
+pkgbase = perl-graphics-tiff
+   pkgdesc = Extension for the libtiff library
+   pkgver = 21
+   pkgrel = 1
+   url = https://metacpan.org/dist/Graphics-TIFF
+   arch = x86_64
+   license = GPL-1.0-or-later
+   license = Artistic-1.0-Perl
+   checkdepends = perl-readonly
+   checkdepends = perl-test-requires
+   checkdepends = perl-test-deep
+   checkdepends = imagemagick
+   makedepends = perl-extutils-depends
+   makedepends = perl-extutils-pkgconfig
+   depends = perl
+   depends = libtiff
+   options = !emptydirs
+   source = 
perl-graphics-tiff-21.tar.gz::https://github.com/carygravel/graphics-tiff/archive/refs/tags/21.tar.gz
+   sha256sums = 
f22b5b5885a99b0df14aacda60491aae4b5faa2253687ee19c77ed799ab7b1de
+
+pkgname = perl-graphics-tiff


=
PKGBUILD
=
@@ -1,23 +1,21 @@
 # Maintainer: Muflone http://www.muflone.com/contacts/english/
 
 pkgname=perl-graphics-tiff
-_perl_namespace=Graphics
-_perl_module=TIFF
-pkgver=20
-pkgrel=2
+pkgver=21
+pkgrel=1
 pkgdesc="Extension for the libtiff library"
 arch=('x86_64')
-url="https://metacpan.org/dist/${_perl_namespace}-${_perl_module};
-license=('LGPL')
+url="https://metacpan.org/dist/Graphics-TIFF;
+license=('GPL-1.0-or-later' 'Artistic-1.0-Perl')
 makedepends=('perl-extutils-depends' 'perl-extutils-pkgconfig')
 depends=('perl' 'libtiff')
-checkdepends=('perl-readonly' 'perl-test-requires' 'perl-test-deep')
-source=("https://www.cpan.org/modules/by-module/${_perl_namespace}/${_perl_namespace}-${_perl_module}-${pkgver}.tar.gz;)
-sha256sums=('3e55cc209465e064019a215a52f05ff51040297d020393fe9fb3de27ad020e35')
+checkdepends=('perl-readonly' 'perl-test-requires' 'perl-test-deep' 
'imagemagick')
+source=("${pkgname}-${pkgver}.tar.gz"::"https://github.com/carygravel/graphics-tiff/archive/refs/tags/${pkgver}.tar.gz;)
+sha256sums=('f22b5b5885a99b0df14aacda60491aae4b5faa2253687ee19c77ed799ab7b1de')
 options=('!emptydirs')
 
 build() {
-  cd "${_perl_namespace}-${_perl_module}-${pkgver}"
+  cd "${pkgname#perl-}-${pkgver}"
   unset PERL5LIB PERL_MM_OPT PERL_MB_OPT PERL_LOCAL_LIB_ROOT
   export PERL_MM_USE_DEFAULT=1 PERL_AUTOINSTALL=--skipdeps
   perl Makefile.PL
@@ -25,14 +23,14 @@ build() {
 }
 
 check() {
-  cd "${_perl_namespace}-${_perl_module}-${pkgver}"
+  cd "${pkgname#perl-}-${pkgver}"
   unset PERL5LIB PERL_MM_OPT PERL_MB_OPT PERL_LOCAL_LIB_ROOT
   export PERL_MM_USE_DEFAULT=1
   make test
 }
 
 package() {
-  cd "${_perl_namespace}-${_perl_module}-${pkgver}"
+  cd "${pkgname#perl-}-${pkgver}"
   unset PERL5LIB PERL_MM_OPT PERL_MB_OPT PERL_LOCAL_LIB_ROOT
   make pure_install INSTALLDIRS=vendor DESTDIR="${pkgdir}"
   # Delete unuseful files



View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/perl-graphics-tiff/-/commit/c5838b727fa5652db020b6a89724caac5876317e

-- 
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/perl-graphics-tiff/-/commit/c5838b727fa5652db020b6a89724caac5876317e
You're receiving this email because of your account on gitlab.archlinux.org.

Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices

2024-05-18 Thread Fabio Fantoni

On Thu, 16 May 2024 12:47:44 +0200 Tobias Frost  wrote:
> >
> >   * Don't fixed: P: imsprog source:
> > package-uses-old-debhelper-compat-version 12 - I want to maintain
> > compatibility for |Jammy| and |Focal| releases.
>
> If you package for different distributions, let me recommend me to 
utilize
> dedicated branches for those, for example by following the DEP14 
proposal;

> this will allow to optimize for the different Debian derivates.
>
> For a Debian upload, please use a acutal compat level; >12 has a lots of
> benefits.

Hi, I think compat 12 is not too old and can be keeped for now to make 
possible to do unofficial build and individual build (any people also 
without experience) on multiple Debian versions and derivatives still 
supported easier and faster using debian/latest.

About creation of other packaging branches following DEP14 I think is 
good only for official build (for example possible official backports), 
but before I think is good update the package to 1.3.9-1 before consider 
doing official backports and don't backports of 1.3.2-1.

OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069942: RFS: imsprog/1.3.7-1 -- Linux chip programmer for CH341a devices

2024-05-18 Thread Fabio Fantoni

On Thu, 16 May 2024 12:47:44 +0200 Tobias Frost  wrote:
> >
> >   * Don't fixed: P: imsprog source:
> > package-uses-old-debhelper-compat-version 12 - I want to maintain
> > compatibility for |Jammy| and |Focal| releases.
>
> If you package for different distributions, let me recommend me to 
utilize
> dedicated branches for those, for example by following the DEP14 
proposal;

> this will allow to optimize for the different Debian derivates.
>
> For a Debian upload, please use a acutal compat level; >12 has a lots of
> benefits.

Hi, I think compat 12 is not too old and can be keeped for now to make 
possible to do unofficial build and individual build (any people also 
without experience) on multiple Debian versions and derivatives still 
supported easier and faster using debian/latest.

About creation of other packaging branches following DEP14 I think is 
good only for official build (for example possible official backports), 
but before I think is good update the package to 1.3.9-1 before consider 
doing official backports and don't backports of 1.3.2-1.

OpenPGP_signature.asc
Description: OpenPGP digital signature

Opinionated Query Definition

2024-05-18 Thread Fabio Trabattoni

Hello everyone,

I hope this message finds you well. I’d like to share an idea for a
potential feature request, inspired by a brief discussion on SO with Lukas.

*INTRO* When starting a Java Spring project, developers often use JPA for
data mapping because it allows for quick and straightforward setup.
However, as the project grows, they start encountering performance issues
like the infamous N+1 problem et similia.

At this stage, devs make one of the two things happen:

1. Refactoring JPA Mappings: They push themselves to restructure
mappings and use more efficient querying mechanisms with JPA.
2. Switching to Alternatives: They opt for alternatives like JOOQ or
QueryDSL to handle their queries.

Unfortunately, most of the times ,both approaches result in code that is
hard to read, inconsistent, and difficult to maintain. At least in my
experience.

*THE IDEA *Here’s the idea: a strongly opinionated way of defining queries
that starts from the basic thought steps when dealing with data querying in
Java. The focus would be on defining a query plan with filter criteria and
specifying what to load and how it should be loaded, possibly even in a
recursive fashion.

1. Specify Filters: A straightforward mechanism to define and apply
filters to the data set.
2. Specify What to Fetch: A clear way to determine which fields to
retrieve.
3. Recursive Query Plan: The ability to define a query plan that can
handle recursive fetching and recursive criteria, ensuring that related
data is queried efficiently.

At a glance it could look something like this:
https://github.com/thestroke82/leanquery/blob/master/src/main/java/org/frappa/leanquery/controller/CustomerController.java

I've worked with a custom solution very much like this in the past and
observed it performing its job remarkably well. The strongest advantage of
such an approach is that as the codebase grows, readability remains
practically constant, significantly improving maintainability. *CONCLUSION *The
ideas are now out in the open, both in words and code (see the GitHub link
above). I’m eager to hear your thoughts and advice, and I hope we can work
together to evolve this concept into a formal feature request for JOOQ.

One final request: Please refrain from comments that patronize or dismiss
the idea with statements like "JPA already does that" or "X does that too."
Instead, I’m looking for constructive feedback and suggestions on how we
can make this feature a valuable addition to the JOOQ ecosystem.

Thank you for your time and consideration. I look forward to your feedback
and collaboration!

--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jooq-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jooq-user/99bbd0c3-e5af-4ee7-a897-7ff869098288n%40googlegroups.com.

Re: [Input Requested] Ending support for i686 builds of Node.js

2024-05-17 Thread Fabio Valentini

On Thu, May 16, 2024 at 4:24 PM Stephen Gallagher  wrote:
>
> On Tue, May 14, 2024 at 3:47 PM Fabio Valentini  wrote:
> >
> > On Tue, May 14, 2024 at 9:43 PM Stephen Gallagher  
> > wrote:
> > >
> > > Do you think that's worth a separate Change from the Node.js 22 Change
> > > I already filed? I can amend that  (and ask FESCo to re-vote based on
> > > new information).
> >
> > I think the change is significant enough, yes.
> > Having a separate change would lead to more visibility, but I think
> > just amending the existing Change and having FESCo re-approve would be
> > fine too.
> >
>
> Looks like we can avoid this question for a bit longer. Node.js 22.2.0
> appears to have fixed the incompatibility with i686 builds. Phew.

Even better! Thank you for looking into it.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[krdc] [Bug 484666] Copy - Paste is not working

2024-05-17 Thread Fabio

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

Fabio  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Latest Commit||https://invent.kde.org/netw
   ||ork/krdc/-/commit/d1cc1829a
   ||554696a2893a02d5d400e6e6353
   ||48c9

--- Comment #4 from Fabio  ---
Git commit d1cc1829a554696a2893a02d5d400e6e635348c9 by Fabio Bas.
Committed on 17/05/2024 at 12:36.
Pushed by ctrlaltca into branch 'master'.

rdp: add clipboard support

M  +1-0rdp/CMakeLists.txt
A  +371  -0rdp/rdpcliprdr.cpp [License: GPL(v2.0+)]
A  +26   -0rdp/rdpcliprdr.h [License: GPL(v2.0+)]
M  +34   -7rdp/rdpsession.cpp
M  +21   -0rdp/rdpsession.h
M  +1-1rdp/rdpview.cpp
M  +1-0rdp/rdpview.h

https://invent.kde.org/network/krdc/-/commit/d1cc1829a554696a2893a02d5d400e6e635348c9

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

Productes

2024-05-17 Thread Fabio Capo

Hola,

som el fabricant líder a Europa en la indústria domèstica.

T'interessa ampliar la teva oferta amb accessoris de cuina i productes de 
neteja d'alta qualitat que augmentaran les teves vendes?

Oferim preus a l'engròs atractius, que us permeten aconseguir marges 
satisfactoris.

Vols comprovar què et podem oferir?


Atentamente
Fabio Capo

[plasmashell] [Bug 486514] Notifications are too narrow

2024-05-16 Thread Fabio C. Barrionuevo

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

--- Comment #8 from Fabio C. Barrionuevo  ---
Created attachment 169547
  --> https://bugs.kde.org/attachment.cgi?id=169547=edit
nvidia control panel configurations

(In reply to Nate Graham from comment #6)
> Also have you used the NVIDIA control panel to change any screen
> settings?

No. I left everything as it was in the default configuration on Nvidia control
panel. 

I have attached the screenshot of the NVidia control panel as well

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

[plasmashell] [Bug 486514] Notifications are too narrow

2024-05-16 Thread Fabio C. Barrionuevo

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

--- Comment #7 from Fabio C. Barrionuevo  ---
Created attachment 169546
  --> https://bugs.kde.org/attachment.cgi?id=169546=edit
System Settings > Display & Monitor page

(In reply to Nate Graham from comment #6)
> Do you have multiple screens, or did you in the past? 

Yes, I use 2 screens, both connected using individual DisplayPort cables,
connected to an Nvidia RTX 4060 Ti.

> If so can you attach a screenshot of the System Settings > Display & Monitor 
> page that shows the
> layout? 

Attached

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

[Fedora-legal-list] Re: Brainpool Curves in Fedora (openssl, libgcrypt, gnupg)

2024-05-16 Thread Fabio Valentini

On Tue, Nov 8, 2022 at 4:19 PM Matthew Miller  wrote:
>
> On Wed, Apr 06, 2022 at 05:31:10PM +0200, Felix Schwarz wrote:
> > Am 06.04.22 um 16:13 schrieb Matthew Miller:
> > >So, these things move slowly, but this _is_ being worked on. I'll let
> > >you know when I can.
> >
> > Thanks :-)
> > The day Red Hat is able to distribute the brainpool curves will be a
> > great one for us.
>
> I have been told that it is okay to include Brainpool ECC in Fedora. Thank
> you for your patience.

Sorry for resurrecting this old thread.
I just realized that the wiki has not been updated to reflect the fact
that the Brainpool curves are considered OK now:
https://fedoraproject.org/wiki/Legal:ECC

Can somebody with edit privileges on that page update the list?
Or should this documentation be moved somewhere else altogether (legal
docs on docs.fp.o)?

Fabio
--
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rich deps result in packages being uninstalled from buildroot

2024-05-16 Thread Fabio Valentini

On Thu, May 16, 2024 at 9:25 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
>
> I've been trying to get 'add-determinism' deployed in buildroots. This
> has been unsuccessful because of the following issue.
>
> The dependency chain is:
> redhat-rpm-config has
>   Requires build-reproducibility-srpm-macros
> and build-reproducibility-srpm-macros has
>   Requires:(add-determinism if python3-libs else add-determinism-nopython)
>   Suggests:add-determinism-nopython
>
> (The idea is that we install 'add-determinism-nopython' which is 
> self-contained,
> but if python3 is installed into the buildroot, we pull in the heavier version
> which has a dependency on python3-libs.)
>
> This works well enough when installing packages using dnf on a test system.
> But, in koji and mock builds, this results in rpm-build being unistalled (!).
>
> For example, see https://koji.fedoraproject.org/koji/taskinfo?taskID=117684626
> and root.log there: first rpm-build is installed along with a bunch of other
> packages expected in the buildroot, but then cargo-rpm-macros is requested
> (presumably via %generate_buildrequires), which depends on python3 and
> python3-libs.
>
> Dnf5 realizes that to satisfy all bounds, it can either:
> a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and 
> remove add-determinism-nopython
> b) install cargo-rpm-macros, python3, python3-libs, and remove 
> build-reproducibility-srpm-macros,
>rpm-build, fonts-srpm-macros, redhat-rpm-config, and a few other packages.
> and picks option b).

This looks like you're putting the resolver between a rock and a hard
place. :thinking:
I don't think I've ever seen packages being *removed* when installing
BuildRequires on top of the minimal buildroot ...

Would it be possible to adapt the packages so that add-determinism and
add-determinism-nopython are parallel-installable, and have the macro
fall back to the add-determinism-nopython executable if the
add-determinism executable is not available?
That way BuildRequires are additive and wouldn't force package removal
from the buildroot, and the rich dependency could be simpler - i.e.
`Requires: (add-determinism if python3-libs)`, without Suggests or
else branch.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Upgrading Xwayland to version 24.1.0 in Fedora 40

2024-05-15 Thread Fabio Valentini

On Wed, May 15, 2024 at 6:23 PM Leigh Scott  wrote:
>
> > On Wed, May 15, 2024 at 4:31 PM Olivier Fourdan  > wrote:
> >
> > Not directly related, but hopefully not entirely off-topic:
> > Are there plans to update the xorg-x11-server package itself to the
> > new stable branch too?
> >
> > It's been stuck on the 1.20.14 release for a long time (on the last
> > release from the 1.20 branch from 2021 - admittedly, with a lot of
> > backports).
> > But the last stable release of xorg-server (21.1.13) was just a month ago.
> >
> > Fabio
>
> Updating the xorg abi would mean retirement for nvidia 340xx and 390xx.

Does this mean "I'm against it" or "it would involve retiring two
legacy NVidia driver packages"?

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LLVM Packaging Ideas for Fedora 41

2024-05-15 Thread Fabio Valentini

On Wed, May 15, 2024 at 2:02 PM Miro Hrončok  wrote:
>
> On 15. 05. 24 13:31, Vít Ondruch wrote:
> > I am saying that Python is bad example and nobody should follow it.
>
> I respectfully disagree. The LLVM maintainers think it is a good example worth
> following. So did the NodeJS maintainers. Name-versioning all the components
> makes things so much easier for the maintainers.

Right - IMO the Python stack is the *best* example of how to provide
multiple versions of something in Fedora, and for how transitions to
new major versions are handled in Rawhide.
(And any remaining Python vs. Python 3 confusions are an orthogonal problem.)
Being able to use both newer and older versions of Python on different
branches of Fedora is *awesome*, for example for running tests against
different Python versions with tox.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Upgrading Xwayland to version 24.1.0 in Fedora 40

2024-05-15 Thread Fabio Valentini

On Wed, May 15, 2024 at 4:31 PM Olivier Fourdan  wrote:
>
> Hi all,
>
> Today was released Xwayland 24.1.0, a new stable branch of Xwayland.

Not directly related, but hopefully not entirely off-topic:
Are there plans to update the xorg-x11-server package itself to the
new stable branch too?

It's been stuck on the 1.20.14 release for a long time (on the last
release from the 1.20 branch from 2021 - admittedly, with a lot of
backports).
But the last stable release of xorg-server (21.1.13) was just a month ago.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Input Requested] Ending support for i686 builds of Node.js

2024-05-14 Thread Fabio Valentini

On Tue, May 14, 2024 at 9:43 PM Stephen Gallagher  wrote:
>
> Do you think that's worth a separate Change from the Node.js 22 Change
> I already filed? I can amend that  (and ask FESCo to re-vote based on
> new information).

I think the change is significant enough, yes.
Having a separate change would lead to more visibility, but I think
just amending the existing Change and having FESCo re-approve would be
fine too.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Input Requested] Ending support for i686 builds of Node.js

2024-05-14 Thread Fabio Valentini

On Tue, May 14, 2024 at 9:33 PM Stephen Gallagher  wrote:
>
> On Mon, May 13, 2024 at 8:21 AM Fabio Valentini  wrote:
> >
> > On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher  
> > wrote:
> > >
> > > Upstream Node.js has not supported the i686 architecture officially
> > > since Node.js 10.x (released in 2018). As of Node.js 22, it appears
> > > that v8 will no longer build at all on that architecture.
> > >
> > > I'm not particularly willing to go to any great lengths to keep it
> > > alive on i686, but I want to know if there's anyone out there who is
> > > *desperately* in need of it in Fedora.
> >
> > Most (all?) nodejs "library" packages were retired, right?
> >
> > And even if there are still some of them around, most of them should
> > be "noarch"? In that case, they shouldn't need adaptations, since koji
> > now no longer schedules noarch builds to run on i686.
> > But those nodejs packages that are not noarch (however many of them
> > are still in Fedora) will need ExcludeArch: i686.
> >
> > However, another problem might arched non-nodejs packages that need
> > nodejs at build-time. It looks like there's a bunch of packages that
> > "BuildRequires: nodejs" - among them, chromium, firefox, thunderbird,
> > RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these
> > still build on i686, but some might not be able to disable the nodejs
> > BR, so they would need to stop building on i686 too.
> >
>
> I've looked through most of these and they generally seem to be either
> noarch or else using one of %nodejs_arches or %java_arches for their
> BuildArch. If I make this change, I'll adapt %nodejs_arches to exclude
> i686 and %java_arches already does so.

That sounds good to me, but it doesn't really answer my question:
Those packages dropping i686 might cause follow-up issues in *their*
dependent packages, and so on.
If they are leaf packages, that's not an issue, but dropping
architecture support is a breaking change that needs to be
coordinated.

So what you're *really* saying is that you will drop i686 from %nodejs_arches?
I think that has a big enough (and possibly ill-defined) scope that it
would qualify as a Change.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Git][archlinux/packaging/packages/dbeaver] Pushed new tag 24.0.4-1

2024-05-13 Thread Fabio Castelli (@muflone)



Fabio Castelli pushed new tag 24.0.4-1 at Arch Linux / Packaging / Packages / 
dbeaver

-- 
This project does not include diff previews in email notifications.
View it on GitLab: 
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/tree/24.0.4-1
You're receiving this email because of your account on gitlab.archlinux.org.

Re: GIMP 3.0 in F41?

On Mon, May 13, 2024 at 8:38 PM Vitaly Zaitsev via devel
 wrote:
>
> On 13/05/2024 13:24, Nils Philippsen wrote:
> > If I’m not off track, renaming the existing version to “gimp2” would at
> > least make people install it as an update to “gimp-2.10.x” without any
> > real benefit to them. And it would make ”gimp” jump to version 3 which
> > is wildly different
>
> Fedora is a bleeding edge distribution. All packages should be updated
> to the latest releases.
>
> > and would probably go against package
> > compatibility guidelines if done in Fedora <= 40
>
> Major updates in stable Fedora releases are prohibited by the Updates
> Policy[1].
>
> [1]: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/

This is why the current "gimp version 3 is a new package" approach
works better for stable branches:
Existing users don't get the update, but can manually opt-in for testing.

For rawhide (at least as soon as it's reasonable to do so), the thing
can be reversed - package gimp v3 as "gimp" and move v2 to a "gimp2"
package, so that users *do* get the upgrade at some point.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gdk-pixbuf removing several icon loaders

On Mon, May 13, 2024 at 8:36 PM Michael Catanzaro  wrote:
>
> Hi,
>
> gdk-pixbuf 2.42.11 has dropped support for several uncommon image
> formats. This is causing several applications to crash in Fedora
> rawhide [1][2]. (The change also got backported to F40 and F39, but
> I've reverted it there.)
>
> Benjamin Gilbert has proposed reenabling the removed loaders [3], but
> this is not likely to be accepted upstream. So he's currently planning
> to package the removed loaders for Fedora in a separate package. You'll
> be able to depend on these if needed to avoid crashing, but please do
> so only if you really need to, since the goal of removing the extra
> loaders is to reduce attack surface. (Unfortunately gdk-pixbuf is a
> fairly risky dependency: many applications require it, but it's not
> very safe.) Most applications should use modern image formats instead.

Just out of curiosity, would glycin be a better mechanism than
gdk-pixbuf for loading "untrusted" images / "unsafe" image formats?
Its loaders are sandboxed via SECCOMP and support for most image
formats is implemented in Rust (except HEIF and JPEG-XL - they use the
C reference implementations).
(It looks like the Rust "image" crate doesn't - yet - support some
obscure image formats like XPM, so it wouldn't help in this particular
case, though.)

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - Hulk edition

On Fri, May 10, 2024 at 11:29 AM Miro Hrončok  wrote:
>
> On 10. 05. 24 10:55, Miroslav Suchý wrote:
> > Hot news:
> >
> > SPDX v3 has been published. The biggest change for us is that license
> > expression allows lowercase operators (and, or, with). This got into the
> > specification because of your (Fedora maintainers) feedback!
>
> So we can now have packages with uppercase AND/ORs and packages with lowercase
> and/ors and we can no longer quickly recognize SPDX expression by observing
> uppercase AND/ORs?
>
> That does not sound like improvement to me :/

I agree, this is just making things more confusing.
Can we at least still recommend to use the AND / OR / WITH
capitalization for Fedora license tags, even if the lower-case ones
are technically considered valid now?

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LLVM Packaging Ideas for Fedora 41

On Mon, May 13, 2024 at 3:23 PM Vít Ondruch  wrote:
>
>
> Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):
>
> * Switch to python-style compat/main packages.  In order to make the 
> packaging more
> consistent between the main package (e.g. llvm) and the compat package (e.g. 
> llvm18),
> we would retire the un-versioned dist-git for llvm, and create a new 
> versioned dist-git
> for each new release (e.g. llvm19, llvm20, llvm21 etc.).  We would then 
> designate one
> of these as the 'main version', and that version would produce binary rpms 
> that look
> like the current main package (i.e. llvm-libs instead of  llvm19-libs).
>
> Ehh? I guess? I don't think this buys us that much.
>
> * Invert the order of compat/main packages.  Instead of having the compat 
> package be
> the old version, and the main package be the new version, we would have the 
> compat package
> be newer and the main package be older.  This would allow us to introduce a 
> new version of
> llvm without impacting other packages that depend on the main version of LLVM.
>
> I don't like this idea, it makes things harder to reason about and
> doesn't actually solve any problems.
>
>
> I concur with Neal here.
>
> I we were living in ideal world, we would have just one `llvm` package. Since 
> we are not living in ideal world, it makes sense to have some compat 
> versions. But we should try to get as close as possible to ideal world. 
> Versioning packages by default goes against that goal, because it encourages 
> sticking to some specific version for no particular reason.

For the special case of LLVM, I disagree here. Some projects are just
not compatible with newer LLVM versions until upstream moves first,
and that can take time. So I don't think that counts as "sticking to
some specific version for no particular reason", it's "upstream
doesn't support LLVM X at all yet, they only support LLVM X-1 for
now". I have never seen a Fedora package that uses an LLVM compat
package "for no particular reason".

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PATCH] ARM: imx: Add doc/imx/ to i.MX MAINTAINERS entry

2024-05-13 Thread Fabio Estevam

Hi Marek,

On Mon, May 13, 2024 at 12:28 AM Marek Vasut  wrote:
>
> Make sure i.MX maintainers are CCed on doc/imx/ patches.
>
> Signed-off-by: Marek Vasut 

Reviewed-by: Fabio Estevam 

Thanks

Re: [Input Requested] Ending support for i686 builds of Node.js

On Mon, May 13, 2024 at 2:02 PM Stephen Gallagher  wrote:
>
> Upstream Node.js has not supported the i686 architecture officially
> since Node.js 10.x (released in 2018). As of Node.js 22, it appears
> that v8 will no longer build at all on that architecture.
>
> I'm not particularly willing to go to any great lengths to keep it
> alive on i686, but I want to know if there's anyone out there who is
> *desperately* in need of it in Fedora.

Most (all?) nodejs "library" packages were retired, right?

And even if there are still some of them around, most of them should
be "noarch"? In that case, they shouldn't need adaptations, since koji
now no longer schedules noarch builds to run on i686.
But those nodejs packages that are not noarch (however many of them
are still in Fedora) will need ExcludeArch: i686.

However, another problem might arched non-nodejs packages that need
nodejs at build-time. It looks like there's a bunch of packages that
"BuildRequires: nodejs" - among them, chromium, firefox, thunderbird,
RStudio, qt?-webengine, tinygo, etc. I'm not sure how many of these
still build on i686, but some might not be able to disable the nodejs
BR, so they would need to stop building on i686 too.

Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GIMP 3.0 in F41?

On Mon, May 13, 2024, 12:34 Daniel P. Berrangé  wrote:

> On Mon, May 13, 2024 at 12:14:14PM +0200, Fabio Valentini wrote:
> > On Mon, May 13, 2024, 11:50 Dominik 'Rathann' Mierzejewski <
> > domi...@greysector.net> wrote:
> >
> > > On Monday, 13 May 2024 at 01:00, Neal Gompa wrote:
> > > > On Sun, May 12, 2024 at 4:59 PM Sérgio Basto 
> wrote:
> > > > >
> > > > >
> > > > >
> > > > > https://src.fedoraproject.org/rpms/gimp3
> > > > >
> > > >
> > > > What the heck? This should have been gimp2 for the old version, not
> > > > gimp3 for the new version...
> > >
> > > Also, how did this pass review?
> > >
> > > License:LGPLv3+
> > >
> > > And I'll answer myself: it hasn't or at least I can't find any review
> > > ticket.
> > >
> > > Nils, could you explain how this package ended up in Fedora?
> >
> > Standard procedure, everything seems to be in order:
> >
> > https://pagure.io/releng/fedora-scm-requests/issue/62152
> >
> > The review exception is valid because it's an alternative version of an
> > existing package, and Nils is also the maintainer of the existing
> package.
>
> It that exception automatic ? I thought it had to be explicitly
> requested from FPC ? eg in
>
>
> https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure
>
> It says:
>
>   "The FPC can grant exceptions to the normal package review process.
>This may happen, for instance, if a large number of similar packages
>are being submitted at once or if a package is being updated to a
>new major version while the old version is being kept in the
>distribution with a different name.
>..
>Just file a ticket here, set the component to "Review Process Exception"
>and explain (with detail) why you're requesting the exemption and the
>committee will consider it in the next meeting. "
>
> So gimp3 falls under the 2nd example documented there, but still sounds
> like an FPC ticket was needed ?
>

The wiki is outdated. All documentation from FPC has been moved to
docs.fp.o.

The exceptions are documented here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

These cases are treated as "automatically approved" and don't need package
review nor FPC approval.

Fabio


> With regards,
> Daniel
> --
> |: https://berrange.com  -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-
> https://www.instagram.com/dberrange :|
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GIMP 3.0 in F41?