[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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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?
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. While most people prefer that alternative versions carry a "compat" suffix (i.e. the new version is the one without the suffix, and the old version has the suffix), this is - contrary to popular belief - not actually required or even mentioned in the packaging guidelines. Fabio > Regards, > Dominik > -- > Fedora https://fedoraproject.org > Deep in the human unconscious is a pervasive need for a logical universe > that > makes sense. But the real universe is always one step beyond logic. > -- from "The Sayings of Muad'Dib" by the Princess Irulan > -- > ___ > 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
[plasmashell] [Bug 486514] Discover available update notification window is shown in insufficient size for the content.
https://bugs.kde.org/show_bug.cgi?id=486514 --- Comment #5 from Fabio C. Barrionuevo --- Created attachment 169405 --> https://bugs.kde.org/attachment.cgi?id=169405=edit Notification window expands vertically instead of maintaining a default minimum horizontal size for the monitor resolution An update: the file copy progress notification also appears smaller, although it doesn't cut any text, the notification popup is stretched vertically, now I don't know if it's a bug or a feature. Notification window expands vertically instead of maintaining a default minimum horizontal size for the monitor resolution -- You are receiving this mail because: You are watching all bug changes.
Re: imx8mp: Flashing U-Boot into eMMC hardware partition via UUU
Hi Michael,
On Fri, May 10, 2024 at 11:28 AM Michael Nazzareno Trimarchi
wrote:
> You can just change as you want. We have this file in buildroot, uuu
> can run command on the device
> using FB command. Example how call it
Thanks for sharing the example.
I adapted the UUU script like this:
SDPS: boot -f flash.bin
FB: ucmd setenv fastboot_buffer ${loadaddr}
FB: ucmd mmc dev 2 1
FB: download -f flash.bin
FB: ucmd setexpr blkcnt $filesize + 0x1ff
FB: ucmd setexpr blkcnt $blkcnt / 0x200
FB: ucmd mmc write $loadaddr 0 $blkcnt
FB: reboot
FB: done
Did the following changes based on imx8mn_bsh_smm_s2pro:
index 024b46ef8bc2..0b6026c34309 100644
--- a/board/freescale/imx8mp_evk/imx8mp_evk.c
+++ b/board/freescale/imx8mp_evk/imx8mp_evk.c
@@ -3,6 +3,8 @@
* Copyright 2019 NXP
*/
+#include
+#include
#include
int board_init(void)
@@ -17,5 +19,11 @@ int board_late_init(void)
env_set("board_rev", "iMX8MP");
#endif
+ if (is_usb_boot()) {
+ printf("* Entering in USB download mode\n");
+ env_set("bootcmd", "fastboot usb 0");
+ env_set("bootdelay", "0");
+ }
+
return 0;
}
diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h
index 1759318fdd35..148b36bd3169 100644
--- a/include/configs/imx8mp_evk.h
+++ b/include/configs/imx8mp_evk.h
@@ -25,8 +25,17 @@
#include
+#define EMMCARGS \
+ "fastboot_partition_alias_all=" \
+ __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) ".0:0\0" \
+ "fastboot_partition_alias_bootloader=" \
+ __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) ".1:0\0" \
+ "emmc_dev=" __stringify(CONFIG_FASTBOOT_FLASH_MMC_DEV) "\0" \
+ "emmc_ack=1\0" \
+
/* Initial environment variables */
#define CFG_EXTRA_ENV_SETTINGS \
+ EMMCARGS \
BOOTENV \
"scriptaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
"kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
and now UUU correctly flashes the eMMC hardware partition.
Thanks a lot,
Fabio Estevam
imx8mp: Flashing U-Boot into eMMC hardware partition via UUU
Hi, I am using an imx8mp-evk board and I can flash the U-Boot into the eMMC hardware partition 0 by running: => tftpboot $loadaddr flash.bin => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200 => mmc dev 2 1 => mmc write $loadaddr 0 $blkcnt Now I want to do the same via UUU. I tried to create a script called emmc_flash: uuu_version 1.5.21 SDPS: boot -f flash.bin SDPS: done FB: ucmd setenv fastboot_dev mmc FB: ucmd mmc dev 2 1 FB: flash bootloader flash.bin FB: Done Then on the PC: uuu emmc_flash U-Boot is loaded to RAM, but the eMMC hardware partition is not programmed. What is the correct script for doing this? Any suggestions? Thanks
[PATCH] rockchip: rv1108: Remove unneeded local rv1108-cru.h
After the conversion of RV1108 to OF_UPSTREAM, include/dt-bindings/clock/rv1108-cru.h is no longer needed because there is dts/upstream/include/dt-bindings/clock/rv1108-cru.h from upstream Linux. Remove the unneeded rv1108-cru.h file. Reported-by: Jonas Karlman Signed-off-by: Fabio Estevam --- include/dt-bindings/clock/rv1108-cru.h | 356 - 1 file changed, 356 deletions(-) delete mode 100644 include/dt-bindings/clock/rv1108-cru.h diff --git a/include/dt-bindings/clock/rv1108-cru.h b/include/dt-bindings/clock/rv1108-cru.h deleted file mode 100644 index 10ed9d140f4b.. --- a/include/dt-bindings/clock/rv1108-cru.h +++ /dev/null @@ -1,356 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ -/* - * Copyright (c) 2017 Rockchip Electronics Co. Ltd. - * Author: Shawn Lin - */ - -#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RV1108_H -#define _DT_BINDINGS_CLK_ROCKCHIP_RV1108_H - -/* pll id */ -#define PLL_APLL 0 -#define PLL_DPLL 1 -#define PLL_GPLL 2 -#define ARMCLK 3 - -/* sclk gates (special clocks) */ -#define SCLK_SPI0 65 -#define SCLK_NANDC 67 -#define SCLK_SDMMC 68 -#define SCLK_SDIO 69 -#define SCLK_EMMC 71 -#define SCLK_UART0 72 -#define SCLK_UART1 73 -#define SCLK_UART2 74 -#define SCLK_I2S0 75 -#define SCLK_I2S1 76 -#define SCLK_I2S2 77 -#define SCLK_TIMER078 -#define SCLK_TIMER179 -#define SCLK_SFC 80 -#define SCLK_SDMMC_DRV 81 -#define SCLK_SDIO_DRV 82 -#define SCLK_EMMC_DRV 83 -#define SCLK_SDMMC_SAMPLE 84 -#define SCLK_SDIO_SAMPLE 85 -#define SCLK_EMMC_SAMPLE 86 -#define SCLK_VENC_CORE 87 -#define SCLK_HEVC_CORE 88 -#define SCLK_HEVC_CABAC89 -#define SCLK_PWM0_PMU 90 -#define SCLK_I2C0_PMU 91 -#define SCLK_WIFI 92 -#define SCLK_CIFOUT93 -#define SCLK_MIPI_CSI_OUT 94 -#define SCLK_CIF0 95 -#define SCLK_CIF1 96 -#define SCLK_CIF2 97 -#define SCLK_CIF3 98 -#define SCLK_DSP 99 -#define SCLK_DSP_IOP 100 -#define SCLK_DSP_EPP 101 -#define SCLK_DSP_EDP 102 -#define SCLK_DSP_EDAP 103 -#define SCLK_CVBS_HOST 104 -#define SCLK_HDMI_SFR 105 -#define SCLK_HDMI_CEC 106 -#define SCLK_CRYPTO107 -#define SCLK_SPI 108 -#define SCLK_SARADC109 -#define SCLK_TSADC 110 -#define SCLK_MAC_PRE 111 -#define SCLK_MAC 112 -#define SCLK_MAC_RX113 -#define SCLK_MAC_REF 114 -#define SCLK_MAC_REFOUT115 -#define SCLK_DSP_PFM 116 -#define SCLK_RGA 117 -#define SCLK_I2C1 118 -#define SCLK_I2C2 119 -#define SCLK_I2C3 120 -#define SCLK_PWM 121 -#define SCLK_ISP 122 -#define SCLK_USBPHY123 -#define SCLK_I2S0_SRC 124 -#define SCLK_I2S1_SRC 125 -#define SCLK_I2S2_SRC 126 -#define SCLK_UART0_SRC 127 -#define SCLK_UART1_SRC 128 -#define SCLK_UART2_SRC 129 -#define SCLK_MAC_TX130 -#define SCLK_MACREF131 -#define SCLK_MACREF_OUT132 - -#define DCLK_VOP_SRC 185 -#define DCLK_HDMIPHY 186 -#define DCLK_VOP 187 - -/* aclk gates */ -#define ACLK_DMAC 192 -#define ACLK_PRE 193 -#define ACLK_CORE 194 -#define ACLK_ENMCORE 195 -#define ACLK_RKVENC196 -#define ACLK_RKVDEC197 -#define ACLK_VPU 198 -#define ACLK_CIF0 199 -#define ACLK_VIO0 200 -#define ACLK_VIO1 201 -#define ACLK_VOP 202 -#define ACLK_IEP 203 -#define ACLK_RGA 204 -#define ACLK_ISP 205 -#define ACLK_CIF1 206 -#define ACLK_CIF2 207 -#define ACLK_CIF3 208 -#define ACLK_PERI 209 -#define ACLK_GMAC
Re: Review swaps
On Tue, Apr 23, 2024 at 1:10 AM Kan-Ru Chen wrote: > > Hi all, > > I have 3 packages awaiting reviews. I'm happy to exchange. > > First is a new IBus input method (code includes bits of C and Python): > > ibus-array: https://bugzilla.redhat.com/show_bug.cgi?id=2275556 > > The other two are trivial rust packages that I need for upcoming libchewing > release: > > rust-xflags-macrios: https://bugzilla.redhat.com/show_bug.cgi?id=2276537 > rust-xflags: https://bugzilla.redhat.com/show_bug.cgi?id=2276539 Hello! I see now that you have withdrawn the two Rust package reviews. Do you no longer need them? 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
[slurm-users] Re: StateSaveLocation and Slurm HA
You can try DRBD https://linbit.com/drbd/ or a shared-disk (clustered) FS like GFS2, OCFS2, etc https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_gfs2_file_systems/index https://docs.oracle.com/en/operating-systems/oracle-linux/9/shareadmin/shareadmin-ManagingtheOracleClusterFileSystemVersion2inOracleLinux.html -- *Fabio Ranalli* | Principal Systems Administrator Schrödinger, Inc. <https://schrodinger.com> -- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
[slurm-users] "token expired" errors with auth/slurm
Hi there, We've updated to 23.11.6 and replaced MUNGE with SACK. Performance and stability have both been pretty good, but we're occasionally seeing this in the slurmctld.log /[2024-05-07T03:50:16.638] error: decode_jwt: token expired at 1715053769 [2024-05-07T03:50:16.638] error: cred_p_unpack: decode_jwt() failed [2024-05-07T03:50:16.638] error: Malformed RPC of type REQUEST_BATCH_JOB_LAUNCH(4005) received [2024-05-07T03:50:16.641] error: slurm_receive_msg_and_forward: [[headnode.internal]:58286] failed: Header lengths are longer than data received [2024-05-07T03:50:16.648] error: service_connection: slurm_receive_msg: Header lengths are longer than data received/ it seems to impact a subset of nodes: jobs get killed and no new ones are allocated. Full functionality can be restored by simply restarting slurmctld first, and then slurmd. Is the token expected to actually expire? I didn't see this possibility mentioned in the docs. The problem occurs on an R cloud cluster based on EL9, with a pretty "flat" setup. _headnode_: configless slurmctld, slurmdbd, mariadb, nfsd _elastic compute nodes_: autofs, slurmd *//etc/slurm/slurm.conf/* AuthType=auth/slurm AuthInfo=use_client_ids CredType=cred/slurm *//etc/slurm/slurmdbd.conf/* AuthType=auth/slurm AuthInfo=use_client_ids Has anyone else encountered the same error? Thanks, Fabio -- *Fabio Ranalli* | Principal Systems Administrator Schrödinger, Inc. <https://schrodinger.com> -- slurm-users mailing list -- slurm-users@lists.schedmd.com To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
Re: [PATCH] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards
Hi Benjamin, On Mon, May 6, 2024 at 7:52 AM Benjamin Hahn wrote: > We are not registered at USB-IF and therefore don't have a valid > VENDOR_NUM and PRODUCT_NUM, so we rely on the VENDOR_NUM and PRODUCT_NUM > of the SoC Vendor, so the correct features get enabled by the driver. Ok, understood. Reviewed-by: Fabio Estevam
Re: [PRQ#60023] Deletion Request for amarok
mackel [1] filed a deletion request for amarok [2]: Now the Castaway version was updated. [1] https://aur.archlinux.org/account/mackel/ [2] https://aur.archlinux.org/pkgbase/amarok/ deletion requests are not intented for this an orphan one is pending Please go https://aur.archlinux.org/requests and reject this
[Active Window Control] [Bug 486645] New: Issue with the order of Activities (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=486645 Bug ID: 486645 Summary: Issue with the order of Activities (Plasma 6) Classification: Plasma Product: Active Window Control Version: unspecified Platform: Neon OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: zrenf...@gmail.com Reporter: fabiom...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- Created attachment 169228 --> https://bugs.kde.org/attachment.cgi?id=169228=edit Image of my desktop in the Activities settings. I'm not sure if I chose the right topic, but the problem is with Activities. Plasma comes with the Default Activity, but when creating a second activity, it sets the Default Activity as the second one instead of the first, which is bad for organization. Interestingly, after creating the second activity, it assumes the correct sequential order, except that the second activity becomes the first one. I'll send a picture for better clarification. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 486514] Discover available update notification window is shown in insufficient size for the content.
https://bugs.kde.org/show_bug.cgi?id=486514 --- Comment #2 from Fabio C. Barrionuevo --- (In reply to Nate Graham from comment #1) > Ew, this would be a bug with the code for the notifications themselves. > > Some questions to help us narrow it down: > 1. Do you observe it happening with any other notifications from other apps? No. I can't remember any other notification type with the same problem. Furthermore, the only notifications I remember seeing frequently are from Spectacle when I take a screenshot, and they have no issues. > 2. Can you make it happen with any permutations of running `notify-send` > with various options? I tried and was unable to reproduce the issue using notify-send . > 3. Does it happen in the Wayland session too, or only on X11? Currently, I only use X11 since Google Chrome has erratic behavior on Wayland, and my daily work doesn't give me time to have the patience to wait for it to stabilize. I tried to reproduce the problem in Wayland by simply logging out of the X11 session and logging into the Wayland session. However, the notification no longer appears, probably because the action that launches it has already been executed and/or has been marked as read (if such a thing exists). Since the notification only appears when I have cold-booted the computer and there is some new update to install, over the next few days, I will first try starting the computer in a Wayland session to see if the problem also occurs on Wayland. -- You are receiving this mail because: You are watching all bug changes.
Re: [PATCH 1/3] rng: Introduce SPL_DM_RNG
On Thu, Apr 25, 2024 at 8:03 PM Marek Vasut wrote: > > Add SPL variant of DM_RNG so that the DM_RNG can be disabled in SPL > if necessary. This may be necessary due to e.g. size constraints of > the SPL. > > Signed-off-by: Marek Vasut Applied all, thanks.
[GIT PULL] Please pull u-boot-imx-master-20240505
Hi Tom, Please pull from u-boot-imx/master, thanks. The following changes since commit 2f1e76bcfee75b9f99ade63002c05ffaaec86afb: Merge branch '2024-05-02-assorted-updates' (2024-05-03 16:18:51 -0600) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240505 for you to fetch changes up to cecb5fbb42c8b3de3d5a7df40bc01d1fdf4731d3: crypto/fsl: Differentiate between CAAM and DCP in Kconfig entry (2024-05-05 11:21:39 -0300) u-boot-imx-master-20240505 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20614 - Add SPL variant of DM_RNG so that the DM_RNG can be disabled in SPL if necessary. This may be necessary due to e.g. size constraints of the SPL. - dd SPL variant of SPL_FSL_CAAM_RNG so that the SPL_FSL_CAAM_RNG can be disabled in SPL if necessary. This may be necessary due to e.g. size constraints of the SPL. - Differentiate between CAAM and DCP in Kconfig entry. Marek Vasut (3): rng: Introduce SPL_DM_RNG crypto/fsl: Introduce SPL_FSL_CAAM_RNG crypto/fsl: Differentiate between CAAM and DCP in Kconfig entry boot/pxe_utils.c| 4 +--- boot/vbe_request.c | 2 +- drivers/Makefile| 2 +- drivers/crypto/fsl/Kconfig | 11 +-- drivers/crypto/fsl/Makefile | 2 +- drivers/crypto/fsl/jr.c | 4 ++-- drivers/rng/Kconfig | 7 +++ drivers/rng/Makefile| 2 +- lib/uuid.c | 2 +- net/net_rand.h | 2 +- test/dm/Makefile| 2 +- 11 files changed, 26 insertions(+), 14 deletions(-)
[nexa] Venezia, contributo di accesso e Smart Control Room - Smart Controlled - Ep1
Segnalo questa interessante inchiesta giornalistica di Alberto Puliafito e suoi collaboratori, in merito alla sorveglianza e tracciamento delle persone, con relative implicazioni sulla privacy. Qui il link: https://www.youtube.com/watch?v=LKFC0pvBsxA La sinossi: «Si può tracciare un telefono con i dati di geolocalizzazione dello smartphone? Le "smart city" sono un rischio per la libertà e la privacy delle persone? Il caso di Venezia: la Smart Control Room e il contributo di accesso dal 25 aprile 2024. La Smart Control Room di Venezia è stata finanziata anche con i fondi della politica di coesione europea, la più grande politica di redistribuzione della ricchezza in Europa, pensata per contrastare le disuguaglianze, migliorare le condizioni di vita nelle aree dove ci sono contesti di minore sviluppo, rafforzare la coesione economica, sociale e territoriale. Ma è questo che fa la Smart Control Room? È davvero un aiuto per tutte le persone che vivono Venezia e per la città?»
[oe] libeigen: Backport license fix to kirkstone
Hi Khem,
Can dff417630f26 ("libeigen: Update GPL-3.0-only to GPL-2.0-only") be
backported to kirkstone?
Akash sent a kirkstone backport sometime ago:
https://lists.openembedded.org/g/openembedded-devel/message/105451
Thanks,
Fabio Estevam
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#110249):
https://lists.openembedded.org/g/openembedded-devel/message/110249
Mute This Topic: https://lists.openembedded.org/mt/105893530/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[Discover] [Bug 486514] New: Discover available update notification window is shown in insufficient size for the content.
https://bugs.kde.org/show_bug.cgi?id=486514 Bug ID: 486514 Summary: Discover available update notification window is shown in insufficient size for the content. Classification: Applications Product: Discover Version: 6.0.4 Platform: Neon OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: bna...@gmail.com CC: aleix...@kde.org Target Milestone: --- Created attachment 169150 --> https://bugs.kde.org/attachment.cgi?id=169150=edit Discover available update notification window *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY Discover available update notification window is shown in insufficient size for the content. STEPS TO REPRODUCE 1. Start KDE Neon OS 2. If an update is available, the Discover notification will be displayed at the top of the screen. OBSERVED RESULT The notification window displayed at the top of the screen is smaller than the content to be shown, that is, it does not show all the content and cuts off the text. Check the attached image. EXPECTED RESULT The notification window must be displayed at the top of the screen as usual and be rendered at the correct size for the content to be displayed, as was the previous behavior we had in the last version of Plasma 5.x.x SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-28-generic (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4060 Ti/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X570 AORUS PRO WIFI System Version: -CF -- You are receiving this mail because: You are watching all bug changes.
Re: [PATCH] configs: Make USB_GADGET_MANUFACTURER consistent over all PHYTEC boards
Hi Benjamin, On Fri, May 3, 2024 at 4:01 AM Benjamin Hahn wrote: > -CONFIG_USB_GADGET_MANUFACTURER="FSL" > +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 ... > -CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_MANUFACTURER="PHYTEC" > CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 What about making VENDOR_NUM/PRODUCT_NUM consistent as well?
Re: Is glibc32 retired?
On Fri, May 3, 2024, 09:34 Florian Weimer wrote: > I didn't have a dist-git token for fedpkg, so retiring failed after > doing some work the first time. Is the package actually retired? > It looks like the retirement was successful The dist-git token is only necessary for one API call - disabling the "monitoring" setting. But that was already disabled for this package, so it wouldn't have changed anything. > This command > > koji list-history --package=glibc32 > > does not show any recent activity. I would expect something to untag it > from the buildroot. > This should happen when the retirement is processed during the next rawhide compose. > (Bonus question: can we retire the package from Fedora 40, too?) > No. Retirements can only happen until the start of the final freeze. Fabio > Thanks, > Florian > -- > ___ > 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
[Fedora-legal-list] License for Sublime Text language definitions for syntax highlighting
Hi all, I noticed that there are some packages that bundle data from Sublime Text, notably data for how to apply syntax highlighting for various programming languages. The license that applies to this data is in this file: https://github.com/sublimehq/Packages/blob/759d6eed9b4beed87e602a23303a121c3a6c2fb3/LICENSE (Yes, in one case that I'm looking at, the bundled data is a 5 years old snapshot. Apparently only the Sublime Text v3 format is supported by syntect.) The contents of this LICENSE file are very short, so I'll just include it verbatim for convenience: ``` If not otherwise specified (see below), files in this repository fall under the following license: Permission to copy, use, modify, sell and distribute this software is granted. This software is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose. An exception is made for files in readable text which contain their own license information, or files where an accompanying file exists (in the same directory) with a “-license” suffix added to the base-name name of the original file, and an extension of txt, html, or similar. For example “tidy” is accompanied by “tidy-license.txt”. ``` I could not find any SPDX license that matches this text. It looks very permissive to me, so it should be acceptable for content, but I would need to know how to classify it - both for existing packages where this was missed during package review, as well for a new package for a library that I need to package in order to be able to update an existing package to the latest version. 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: Use header file from external library in u-boot
Hi Johannes, On Thu, May 2, 2024 at 10:18 AM Johannes Kirchmair - SKIDATA wrote: > > Dear u-boot folks, > > we are trying to share some information between u-boot and a Linux user space > tool. For this we place some information in a FRAM. This information is just > some numeric values, indicating some wanted behaviour. I thought of using a > header file to keep these values aligned between the user space tool and > u-boot. This header is provided by a library. Including it into the user > space tool is straight forward, but into u-boot does seem complicated, as the > build system is not meant to include external libraries. Is there a preferred > way to do this kind of alignment or a suggestion on how to handle this? Would libubootenv work for you? https://github.com/sbabic/libubootenv
Re: imx8mn: bootcount does not increment
Hi Heiko, On Fri, Apr 26, 2024 at 12:40 AM Heiko Schocher wrote: > No chance for a bootcounter in a register? Yes, this is a better approach. I changed it to: CONFIG_BOOTCOUNT_LIMIT=y CONFIG_SYS_BOOTCOUNT_MAGIC=0xB0C4 CONFIG_SYS_BOOTCOUNT_ADDR=0x30370090 CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y and now bootcount increments. Thanks, Fabio Estevam
Re: [PRQ#59870] Orphan Request for quickemu-git
nikarh [1] filed an orphan request for quickemu-git [2]: The package does not build for almost a year, please either update the PKGBUILD or orphan the package [1] https://aur.archlinux.org/account/nikarh/ [2] https://aur.archlinux.org/pkgbase/quickemu-git/ Adopted and made a first revision, at least the package build now More work will follow
[krdc] [Bug 485215] KRDC hangs when trying to connect to VNC host
https://bugs.kde.org/show_bug.cgi?id=485215 Fabio changed: What|Removed |Added CC||ctrlal...@gmail.com --- Comment #5 from Fabio --- The original issue is possibly a duplicate of BUG 486178 -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 486342] Equalizer
https://bugs.kde.org/show_bug.cgi?id=486342 --- Comment #2 from Fabio --- Hello, This is exactly the symptom, it happened here I had to stop the music and start it again to get the equalizer effect. I don't know if it helps but I have VLC installed Em 30/04/2024 12:34, Tuomas Nurmi escreveu: > https://bugs.kde.org/show_bug.cgi?id=486342 > > Tuomas Nurmi changed: > > What|Removed |Added > > CC||tuo...@norsumanageri.org > > --- Comment #1 from Tuomas Nurmi --- > Thank you for your report. I assume you are using phonon-vlc backend. I tried > changing equalizer settings, and for them to have effect, I had to stop the > playback and start the track again (they didn't have effect right away). Can > you confirm if this is the case for you? > -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 486343] New: Unable to install Amarok
https://bugs.kde.org/show_bug.cgi?id=486343 Bug ID: 486343 Summary: Unable to install Amarok Classification: Applications Product: amarok Version: 3.0.0 Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: amarok-bugs-d...@kde.org Reporter: fabioam...@gmail.com Target Milestone: kf5 Created attachment 169033 --> https://bugs.kde.org/attachment.cgi?id=169033=edit error *** Dear Team, when I try to install the new version of amarok, I get the following error (attachment) *** SUMMARY I try to install Amarok from the following link: appstream://org.kde.amarok Using Lubuntu 24.04 and Discover app. Can you please package this application? STEPS TO REPRODUCE 1. click on appstream://org.kde.amarok OBSERVED RESULT see attachment EXPECTED RESULT Amarok is installed. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[amarok] [Bug 486342] New: Equalizer
https://bugs.kde.org/show_bug.cgi?id=486342 Bug ID: 486342 Summary: Equalizer Classification: Applications Product: amarok Version: 3.0.0 Platform: Neon OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: Tools/Equalizer Assignee: amarok-bugs-d...@kde.org Reporter: fabiom...@gmail.com Target Milestone: kf5 The equalizer, even when activated, does not work -- You are receiving this mail because: You are watching all bug changes.
Re: how to do minor bump using %autorelease?
On Mon, Apr 29, 2024 at 1:28 PM Richard W.M. Jones wrote: > > On Sat, Apr 27, 2024 at 10:41:59PM +0200, Julian Sikorski wrote: > > Hello, > > > > I need to rebuild mame on F40 only for qt-6.7. On rawhide, > > mame-0.265-1.fc41 is already built against it so I only need to > > build mame-0.265-1.fc40.1. Can it be done using %autorelease? > > I don't think anyone answered your actual question which is ... > > Release: %autorelease -e 1 No, this will make a Release like 2.1.fc40 - which is not what's needed (which would be 1.fc40.1). So it doesn't work because -e adds a component *before* the dist-tag, *and* because the main number is still incremented. 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 v2 1/3] binman: Add nxp_imx8mimage etype
On Thu, Apr 25, 2024 at 8:01 PM Marek Vasut wrote: > > Add new binman etype derived from mkimage etype which generates configuration > input file for mkimage -T imx8mimage, and runs the mkimage on input data. The > mkimage -T imx8mimage is used to generate combined image with SPL and DDR PHY > blobs which is bootable on i.MX8M. > > The configuration file generated here is equivalent of imx8mimage.cfg, which > is the file passed to '$ mkimage -T imx8mimage -n imx8mimage.cfg ...' . The > settings generated into the imx8mimage.cfg file are configured via supported > binman DT properties, nxp,boot-from, nxp,loader-address, nxp,rom-version. > > Signed-off-by: Marek Vasut Applied all, thanks.
Re: [PATCH 0/2] imx93-11x11-evk: Convert to OF_UPSTREAM
On Wed, Apr 24, 2024 at 5:12 AM Peng Fan (OSS) wrote: > > From: Peng Fan > > patch 1 is to avoid build break when using upstream dts > Patch 2 is moving to OF_UPSTREAM > > This is a resend of V3 imx93: Conver to OF_UPSTREAM patch 5,6 > > Peng Fan (2): > dt-bindings: imx93: sync clock header > imx: imx93-11x11-evk: convert to OF_UPSTREAM Applied all, thanks.
Re: [PATCH] ARM: dts: imx: Enable PCIe and NVMe on DH i.MX8M Plus DHCOM PDK3
On Tue, Apr 23, 2024 at 8:15 PM Marek Vasut wrote: > > Enable PCIe/NVMe support on DH i.MX8M Plus DHCOM PDK3. Except for > the configuration options which are enabled, add slight adjustment > to board u-boot.dtsi, which is necessary as there is currently no > driver for the I2C PCIe clock generator. Since the generator is > strapped to be always on, it is possible to supplant the generator > functionality by fixed-clock. > > Signed-off-by: Marek Vasut Applied, thanks.
Re: [PATCH v1] board: toradex: colibri-imx(6ull|imx7): Fix missing fdt_fixup boot error
On Tue, Apr 23, 2024 at 12:57 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> In commit 51aaaf5e7975 ("board: toradex: imx: Remove not needed env
> variables")
> the empty definition of fdt_fixup variable was removed, however this was
> still referenced from the boot command leading to boot failures:
> ## Error: \"fdt_fixup\" not defined`
>
> Fix this by removing "run fdt_fixup" from the boot command and instead
> enable CONFIG_OF_ENV_SETUP in the defconfig that would achieve the same
> but in a more robust way (it works fine even if the variable is not
> defined).
>
> Fixes: 51aaaf5e7975 ("board: toradex: imx: Remove not needed env variables")
> Signed-off-by: Francesco Dolcini
Applied, thanks.
[GIT PULL] Please pull u-boot-imx-master-20240429
Hi Tom, Please pull from u-boot-imx/master, thanks. The following changes since commit 174ac987655c888017c82df1883c0c2ea0dc2495: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-mmc (2024-04-26 07:39:18 -0600) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240429 for you to fetch changes up to 37e50627efacd8dae18b564e9d8886a033e181bc: ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman (2024-04-28 12:10:13 -0300) u-boot-imx-master-20240429 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20563 - Fix missing fdt_fixup on colibri-imx(6ull|imx7). - Enable PCIe and NVMe on DH i.MX8M Plus DHCOM PDK3. - Convert i.MX8M flash.bin image generation to binman - Convert imx93-11x11-evk to OF_UPSTREAM. Francesco Dolcini (1): board: toradex: colibri-imx(6ull|imx7): Fix missing fdt_fixup boot error Marek Vasut (4): ARM: dts: imx: Enable PCIe and NVMe on DH i.MX8M Plus DHCOM PDK3 binman: Add nxp_imx8mimage etype ARM: dts: imx: Switch Ronetix iMX8MQ-CM to imx8mq-u-boot.dtsi ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman Peng Fan (2): dt-bindings: imx93: sync clock header imx: imx93-11x11-evk: convert to OF_UPSTREAM arch/arm/dts/Makefile | 1 - arch/arm/dts/imx8mm-u-boot.dtsi | 126 -- arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi | 8 +- arch/arm/dts/imx8mn-u-boot.dtsi | 147 +-- arch/arm/dts/imx8mp-dhcom-pdk3-u-boot.dtsi | 12 + arch/arm/dts/imx8mp-dhcom-u-boot.dtsi | 2 +- arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi | 2 +- arch/arm/dts/imx8mp-u-boot.dtsi | 96 +++ arch/arm/dts/imx8mq-cm-u-boot.dtsi | 111 +--- arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi | 15 +- arch/arm/dts/imx8mq-u-boot.dtsi | 109 arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 118 + arch/arm/dts/imx93-11x11-evk.dts| 322 arch/arm/dts/imx93-u-boot.dtsi | 15 ++ arch/arm/mach-imx/imx9/Kconfig | 1 + configs/colibri-imx6ull_defconfig | 1 + configs/colibri_imx7_defconfig | 1 + configs/imx8mp_dhcom_pdk3_defconfig | 5 + configs/imx93_11x11_evk_defconfig | 2 +- configs/imx93_11x11_evk_ld_defconfig| 2 +- include/configs/colibri-imx6ull.h | 2 +- include/configs/colibri_imx7.h | 2 +- include/dt-bindings/clock/imx93-clock.h | 3 +- tools/binman/etype/nxp_imx8mimage.py| 74 ++ 24 files changed, 437 insertions(+), 740 deletions(-) delete mode 100644 arch/arm/dts/imx93-11x11-evk.dts create mode 100644 tools/binman/etype/nxp_imx8mimage.py
Re: how to do minor bump using %autorelease?
On Mon, Apr 29, 2024 at 11:17 AM Kevin Kofler via devel
wrote:
>
> Michael J Gruber wrote:
> > A minor bump (as in %{?dist}[.]) only comes into play
> > if a "lower" branch needs to move forward without creating a version
> > ahead of a "higher" branch. And (independent of autorelease) you cannot
> > do that unless you use divergent git branches and cherry-picks in
> > dist-git, in which case "version" makes sense per branch only anyways.
>
> But Release MUST maintain the upgrade path from one release to the next.
No, that's just wrong.
The "upgrade path" (wrt/ NVRs) is no longer enforced across release boundaries.
AFAIK, all supported release-upgrade methods now use distro-sync or
something equivalent, so NVR-based "upgrade path" is just not
important any more.
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
[jira] [Resolved] (SYNCOPE-1816) Provide the possibility to add a JcifsSpnegoAuthenticationHandler
[ https://issues.apache.org/jira/browse/SYNCOPE-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabio Martelli resolved SYNCOPE-1816. - Resolution: Fixed > Provide the possibility to add a JcifsSpnegoAuthenticationHandler > - > > Key: SYNCOPE-1816 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1816 > Project: Syncope > Issue Type: Improvement > Components: console, core, wa >Affects Versions: 3.0.6 >Reporter: Fabio Martelli >Assignee: Fabio Martelli >Priority: Minor > Fix For: 3.0.7, 4.0.0 > > > Provide the possibility to add JcifsSpnegoAuthenticationHandler -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: how to do minor bump using %autorelease?
On Sat, Apr 27, 2024 at 11:51 PM Sandro wrote: > > On 27-04-2024 22:41, Julian Sikorski wrote: > > I need to rebuild mame on F40 only for qt-6.7. On rawhide, > > mame-0.265-1.fc41 is already built against it so I only need to build > > mame-0.265-1.fc40.1. Can it be done using %autorelease? > > Make an empty commit: > > git commit -m 'Rebuild for mame' --allow-empty This is not the answer to the question. It will cause a normal Release bump. AFAIK using rpmautospec, it's not possible to do post-dist.tag .1 bumps. But it's also not really important either, since release-upgrades do distro-syncs. 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
About user Manjusaka
Hi, Manjusaka continue to re-upload his personal pkgbuild which have been deleted 3 times already, they have been informed to not do this yes persist https://aur.archlinux.org/pkgbase/linux-xanmod-manjusaka https://lists.archlinux.org/archives/search?count=25=aur-requests%40lists.archlinux.org=manjusaka
Re: [PRQ#59658] Deletion Request for rustic-bin
AlphaJack [1] filed a deletion request for rustic-bin [2]: Package is now available as [extra]/rustic [1] https://aur.archlinux.org/account/AlphaJack/ [2] https://aur.archlinux.org/pkgbase/rustic-bin/ A deletion request is already pending, [PRQ#59583], submitted yesterday
Bug#1069920: libtimezonemap: fixed-up port to libsoup3
Il 27/04/2024 07:03, Steve Langasek ha scritto: Package: libtimezonemap Version: 0.4.6-6 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear maintainers, Because webkit2gtk has now moved to libsoup3, and because we have reverse-dependencies that require both libtimezonemap and webkit2gtk, I have done the work in Ubuntu to fix up the port of libtimezonemap to libsoup3. This has been confirmed to work in the timezone picker in oem-config as used on our Ubuntu images for Raspberry Pi and has shipped in Ubuntu 24.04 LTS. Please consider including this revised patch in Debian. Thanks, Hi, you already opened a bug for this time ago (https://bugs.debian.org/1068679) and was solved in 0.4.6-7 (https://tracker.debian.org/news/1518035/accepted-libtimezonemap-046-7-source-into-unstable/) This was only a mistake or is there something to fix something did I miss? OpenPGP_signature.asc Description: OpenPGP digital signature
imx8mn: bootcount does not increment
Hi, When enabling bootcount on the imx8mm-evk like this: --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -120,3 +120,5 @@ CONFIG_SDP_LOADADDR=0x4040 CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_SPL_USB_SDP_SUPPORT=y CONFIG_IMX_WATCHDOG=y +CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_BOOTCOUNT_ENV=y It works as expected, and the "bootcount" environment variable gets incremented after a reset. However, if I try the same on an imx8mn_evk, the "bootcount" variable always stays at 1 and never increments. Do you happen to have any idea as to why imx8mn behaves differently in this aspect? Thanks, Fabio Estevam
Re: [PATCH] cmd: mmc: allow use of hardware parittion names for mmc partconf
On Thu, Apr 25, 2024 at 10:35 PM Fabio Estevam wrote: > This is a nice improvement: > > Reviewed-by: Fabio Estevam There is a typo in the Subject: "partition"
Re: [PATCH] cmd: mmc: allow use of hardware parittion names for mmc partconf
Hi Tim, On Thu, Apr 25, 2024 at 9:14 PM Tim Harvey wrote: > > eMMC devices have hardware partitions such as user, boot0, and boot1. > Allow these names to be displayed when reading the mmc PARTITION_CONFIG > field via 'mmc partconf'. Additionally allow a name to be specified when > setting the PARTITION_CONFIG. > > Before: > u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2 > EXT_CSD[179], PARTITION_CONFIG: > BOOT_ACK: 0x1 > BOOT_PARTITION_ENABLE: 0x2 > PARTITION_ACCESS: 0x0 > > After: > u-boot=> mmc partconf 2 1 1 0 && mmc partconf 2 > EXT_CSD[179], PARTITION_CONFIG: > BOOT_ACK: 0x1 > BOOT_PARTITION_ENABLE: 0x1 (boot0) > PARTITION_ACCESS: 0x0 > u-boot=> mmc partconf 2 1 boot1 0 && mmc partconf 2 > EXT_CSD[179], PARTITION_CONFIG: > BOOT_ACK: 0x1 > BOOT_PARTITION_ENABLE: 0x2 (boot1) > PARTITION_ACCESS: 0x0 This is a nice improvement: Reviewed-by: Fabio Estevam
Re: [PATCH 3/3] ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman
On Thu, Apr 25, 2024 at 5:34 PM Tim Harvey wrote: > Marek, > > Thanks - this is neat and I look forward to seeing a CST signing etype! > > Reviewed-By: Tim Harvey > > I did test this on imx8mm_venice_defconfig and it worked great: > Tested-By: Tim Harvey # imx8mm_venice I tested on imx8mm-evk and imx8mn-evk, thanks! Tested-by: Fabio Estevam
[krdc] [Bug 483638] TAB key not functional inside rdp windows client
https://bugs.kde.org/show_bug.cgi?id=483638 Fabio changed: What|Removed |Added CC||ctrlal...@gmail.com --- Comment #6 from Fabio --- https://invent.kde.org/network/krdc/-/merge_requests/94 fixes this issue. -- You are receiving this mail because: You are watching all bug changes.
[PATCH v3] rockchip: rv1108: Convert to OF_UPSTREAM
Instead of using the local rv1108 devicetree copies from U-Boot,
let's convert the rv1108 boards to OF_UPSTREAM so that the upstream kernel
devicetrees can be used instead.
Tested on a rv1108-elgin-r1 board.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Also removed the arch/arm/dts/Makefile entries.
arch/arm/dts/Makefile| 4 -
arch/arm/dts/rv1108-elgin-r1.dts | 59
arch/arm/dts/rv1108-evb.dts | 79 -
arch/arm/dts/rv1108.dtsi | 581 ---
arch/arm/mach-rockchip/Kconfig | 1 +
configs/elgin-rv1108_defconfig | 2 +-
configs/evb-rv1108_defconfig | 2 +-
7 files changed, 3 insertions(+), 725 deletions(-)
delete mode 100644 arch/arm/dts/rv1108-elgin-r1.dts
delete mode 100644 arch/arm/dts/rv1108-evb.dts
delete mode 100644 arch/arm/dts/rv1108.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b1c9c6222e5d..e600f9c6ed25 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -182,10 +182,6 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-rock-5b.dtb \
rk3588-turing-rk1.dtb
-dtb-$(CONFIG_ROCKCHIP_RV1108) += \
- rv1108-elgin-r1.dtb \
- rv1108-evb.dtb
-
dtb-$(CONFIG_ROCKCHIP_RV1126) += \
rv1126-edgeble-neu2-io.dtb
diff --git a/arch/arm/dts/rv1108-elgin-r1.dts b/arch/arm/dts/rv1108-elgin-r1.dts
deleted file mode 100644
index 83e8b3183847..
--- a/arch/arm/dts/rv1108-elgin-r1.dts
+++ /dev/null
@@ -1,59 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-/dts-v1/;
-
-#include "rv1108.dtsi"
-
-/ {
- model = "Elgin RV1108 R1 board";
- compatible = "elgin,rv1108-elgin", "rockchip,rv1108";
-
- memory@6000 {
- device_type = "memory";
- reg = <0x6000 0x0800>;
- };
-
- chosen {
- stdout-path = "serial2:150n8";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_clk _cmd _bus8>;
- bus-width = <8>;
- cap-mmc-highspeed;
- disable-wp;
- non-removable;
- status = "okay";
-};
-
- {
- status = "okay";
-
- u2phy_otg: otg-port {
- status = "okay";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_xfer_pullup>;
- status = "okay";
-};
-
-_otg {
- status = "okay";
-};
-
- {
- uart2m0 {
- uart2m0_xfer_pullup: uart2m0-xfer-pullup {
- rockchip,pins = <2 RK_PD2 RK_FUNC_1
_pull_up_drv_8ma>,
- <2 RK_PD1 RK_FUNC_1
_pull_up_drv_8ma>;
- };
- };
-};
diff --git a/arch/arm/dts/rv1108-evb.dts b/arch/arm/dts/rv1108-evb.dts
deleted file mode 100644
index c91776bc106e..
--- a/arch/arm/dts/rv1108-evb.dts
+++ /dev/null
@@ -1,79 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-/dts-v1/;
-
-#include "rv1108.dtsi"
-
-/ {
- model = "Rockchip RV1108 Evaluation board";
- compatible = "rockchip,rv1108-evb", "rockchip,rv1108";
-
- memory@6000 {
- device_type = "memory";
- reg = <0x6000 0x0800>;
- };
-
- chosen {
- stdout-path = "serial2:150n8";
- };
-
- vcc5v0_otg: vcc5v0-otg-drv {
- compatible = "regulator-fixed";
- enable-active-high;
- regulator-name = "vcc5v0_otg";
- gpio = < RK_PB0 GPIO_ACTIVE_HIGH>;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- };
-};
-
- {
- status = "okay";
- clock_in_out = <0>;
- snps,reset-active-low;
- snps,reset-delays-us = <0 1 100>;
- snps,reset-gpio = < RK_PC1 GPIO_ACTIVE_LOW>;
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
- flash@0 {
- compatible = "gd25q256","jedec,spi-nor";
- reg = <0>;
- spi-tx-bus-width = <1>;
- spi-rx-bus-width = <1>;
- spi-max-frequency = <9600>;
- };
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
-_otg {
- vbus-supply = <_otg>;
- status = "okay";
-};
-
-_host_ehci {
- status = "okay";
-};
-
-_host_ohci {
- status = "okay";
-};
diff --git a/arch/arm/dts/rv1108.dtsi b/arch/arm/dts/rv1108.dtsi
deleted file mode 100644
index
Re: [OE-core] Set the CMake BUILD_TESTING option to OFF as the default setting
Hi Alex,
What should I test to measure build time, all recipes that use cmake
from OE-Core and meta-openembedded? Is there a way to build all recipes,
or should I find all recipes that use cmake and run bitbake ?
Regards,
Fabio Berton
On 4/23/2024 2:01 PM, Alexander Kanavin wrote:
I'm not sure I like the idea. This is going to break ptests or other
usage of CTest in cmake-based recipes that aren't under our control.
Building tests is also a test in itself even if you don't run them.
I'd say unless this adds significantly to build times we should leave
it as it is.
Alex
On Tue, 23 Apr 2024 at 14:31, Fabio Berton via lists.openembedded.org
wrote:
I've noticed that some recipes, like json-c [1], which use the cmake bbclass,
are generating files that aren't being used. This is because CMake sets the
BUILD_TESTING option to ON by default. According to the CMake documentation
[2], when CTest is included, as json-c does here [3], the module automatically
creates a BUILD_TESTING option. This option determines whether to enable
testing support, and it is ON by default.
In the json-c example, the tests used by the do_install_ptest task are always
generated. Thus, ${B}/tests/ exists even when ptests are not included in
DISTRO_FEATURES.
As the behavior of CTest/CMake to build tests by default is rather surprising,
we are wondering whether disabling this option by default is feasible in the
OpenEmbedded context. Recipes expecting tests to be built (e.g. because of
ptest support) would then turn on the flag explicitly.
For example, adding this to cmake.bbclass:
OECMAKE_BUILD_TESTING ??= "false"
EXTRA_OECMAKE:append = "\\
${@bb.utils.contains('OECMAKE_BUILD_TESTING', 'false',
'-DBUILD_TESTING=OFF', '', d)} \\
"
and then set the OECMAKE_BUILD_TESTING in the recipe that requires
BUILD_TESTING=ON
Do you have any suggestions on which steps we should take to verify that this
does not introduce any regressions?
1
-https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/json-c/json-c_0.17.bb?h=master
2 -https://cmake.org/cmake/help/latest/module/CTest.html
3 -https://github.com/json-c/json-c/blob/master/CMakeLists.txt#L19
Regards,
Fabio Berton
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198640):
https://lists.openembedded.org/g/openembedded-core/message/198640
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]
-=-=-=-=-=-=-=-=-=-=-=-
[Git][archlinux/packaging/packages/dbeaver][main] upgpkg: 24.0.3-1
Fabio Castelli pushed to branch main at Arch Linux / Packaging / Packages /
dbeaver
Commits:
c5c593e1 by Fabio Castelli (Muflone) at 2024-04-23T00:29:42+02:00
upgpkg: 24.0.3-1
- - - - -
2 changed files:
- .SRCINFO
- PKGBUILD
Changes:
=
.SRCINFO
=
@@ -1,11 +1,11 @@
pkgbase = dbeaver
pkgdesc = Free universal SQL Client for developers and database
administrators (community edition)
- pkgver = 24.0.2
+ pkgver = 24.0.3
pkgrel = 1
url = https://dbeaver.io/
install = dbeaver.install
arch = x86_64
- license = Apache
+ license = Apache-2.0
makedepends = maven
makedepends = java-environment=17
depends = java-runtime>=17
@@ -16,16 +16,16 @@ 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.2.tar.gz::https://github.com/dbeaver/dbeaver/archive/24.0.2.tar.gz
- source =
dbeaver-common-24.0.2.tar.gz::https://github.com/dbeaver/dbeaver-common/archive/bad57b3814edbbcc5c0f8263a4ca64e802dc38e7.tar.gz
+ source =
dbeaver-24.0.3.tar.gz::https://github.com/dbeaver/dbeaver/archive/24.0.3.tar.gz
+ source =
dbeaver-common-24.0.3.tar.gz::https://github.com/dbeaver/dbeaver-common/archive/28bf1386f7a8b67e76118447addbcdd21eadc264.tar.gz
source = io.dbeaver.DBeaver.desktop
source = dbeaver.sh
source = dbeaver.profile.gz
source = dbeaver.hook
source = dbeaver.install
source = tycho_3_0_5.patch
- sha256sums =
ae11d17a548f3b1ef6da331b12106acbedb25465d69881cf9ba421171b3e
- sha256sums =
6a011fbf874a2e7d1d7690e359a147a6e94ec741c504bea2a42a94552b39e4f5
+ sha256sums =
7fbabeda65f20b855a973badec13d265b5b24a7ff85a7bdfd37b9996d4cb0acc
+ sha256sums =
e66353ad5924a0ca410909124f83a09cae204d9fa71476e55ea2ed13149c
sha256sums =
9480a7d08f680e10c399db070c5a04cbabf282442602a2ef83d1159fe7c3e88b
sha256sums =
406a2980806c394670e88b1ae70134900be376c2ea4a4216610591cc8b557526
sha256sums =
1863e74bdcf22b7328e6e8487cbebff7d5360e34bde85c1dd226b168b4737034
=
PKGBUILD
=
@@ -2,13 +2,13 @@
# Contributor: Arne Hoch
pkgname=dbeaver
-pkgver=24.0.2
+pkgver=24.0.3
pkgrel=1
-_COMMON_COMMIT_ID='bad57b3814edbbcc5c0f8263a4ca64e802dc38e7'
+_COMMON_COMMIT_ID='28bf1386f7a8b67e76118447addbcdd21eadc264'
pkgdesc="Free universal SQL Client for developers and database administrators
(community edition)"
arch=('x86_64')
url="https://dbeaver.io/;
-license=("Apache")
+license=("Apache-2.0")
depends=('java-runtime>=17' 'gtk3' 'gtk-update-icon-cache' 'libsecret')
makedepends=('maven' 'java-environment=17')
optdepends=('dbeaver-plugin-office: export data in Microsoft Office Excel
format'
@@ -23,8 +23,8 @@
source=("${pkgname}-${pkgver}.tar.gz"::"https://github.com/dbeaver/dbeaver/archi
"${pkgname}.hook"
"${pkgname}.install"
"tycho_3_0_5.patch")
-sha256sums=('ae11d17a548f3b1ef6da331b12106acbedb25465d69881cf9ba421171b3e'
-'6a011fbf874a2e7d1d7690e359a147a6e94ec741c504bea2a42a94552b39e4f5'
+sha256sums=('7fbabeda65f20b855a973badec13d265b5b24a7ff85a7bdfd37b9996d4cb0acc'
+'e66353ad5924a0ca410909124f83a09cae204d9fa71476e55ea2ed13149c'
'9480a7d08f680e10c399db070c5a04cbabf282442602a2ef83d1159fe7c3e88b'
'406a2980806c394670e88b1ae70134900be376c2ea4a4216610591cc8b557526'
'1863e74bdcf22b7328e6e8487cbebff7d5360e34bde85c1dd226b168b4737034'
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/commit/c5c593e18cf79c43a97bf884cbc2dae406631856
--
This project does not include diff previews in email notifications.
View it on GitLab:
https://gitlab.archlinux.org/archlinux/packaging/packages/dbeaver/-/commit/c5c593e18cf79c43a97bf884cbc2dae406631856
You're receiving this email because of your account on gitlab.archlinux.org.
[Git][archlinux/packaging/packages/dbeaver] Pushed new tag 24.0.3-1
Fabio Castelli pushed new tag 24.0.3-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.3-1 You're receiving this email because of your account on gitlab.archlinux.org.
Re: [PATCH 2/2] tools: type arguemnts
On Fri, Apr 19, 2024 at 9:13 AM Heinrich Schuchardt wrote: > > %s/arguemnts/arguemnts/ There is a typo in the Subject: %s/type/typo/
Re: [PRQ#59466] Orphan Request for midori-bin
Il 23/04/24 00:38, not...@aur.archlinux.org ha scritto: lluisparcet [1] filed an orphan request for midori-bin [2]: I try to install midori-bin and I receive an error on the package download website: Error downloading https://astian.org/wp- content/uploads/midori-browser/linux/midori_11.2.2_amd64.deb You have to change the download website to: https://astian.org/midori- browser/download/linux/midori_11.3.2_amd64.deb [1] https://aur.archlinux.org/account/lluisparcet/ [2] https://aur.archlinux.org/pkgbase/midori-bin/ Please disregard, inappropriate request. lluisparcet requests (oprhan,merge,delete) are not for asking help and neither for suggesting improvemenets (also already given) You already commented on 2024-04-22 at 22:41 with the same message This request was on 23/04/24 at 00:38 The pkgbuild was already flagged OOD since only 21/04/24 at 22:55
bug#43364: with-output-to-port works with file ports
Dear All , I've been encountering a few times the need for a procedure like 'system' or 'system*' but that might be capable of capturing the output of the program that's being called. While this is something that can be solved with a simple 'open-pipe*' wrapper, the pattern seems relatively frequent in Guix, which is where I noticed it. I suggested that some variant of such a wrapper could be added to '(guix build utils)'⁰. In reply to my post, it was brought to my attention that the problem might be addressed at the Guile level and pointed me to this bug report. I thought of sending a quick follow-up here to see if there's any rough consensus on a possible way of addressing this - or why it might be difficult or potentially not worth the effort. Thanks, all best, Fabio. ⁰ https://lists.gnu.org/archive/html/guix-devel/2024-04/msg00199.html -- Fabio Natali https://fabionatali.com
Re: A capture-stdout wrapper procedure in (guix build utils)?
On 2024-04-21, 08:35 -0700, Felix Lechner wrote: > It may be better, however, to finally fix Guile's 'system' and > 'system*' to work with 'with-output-to-string'. [2] Hi Felix, Thanks for getting back to me. Great point re potentially fixing this further up in the "chain", i.e. in Guile. I'll try and raise this on the Guile IRC channel and/or ML and update this thread with my findings. Thanks, best wishes, Fabio. -- Fabio Natali https://fabionatali.com
[PATCH v2] rockchip: rv1108: Convert to OF_UPSTREAM
Instead of using the local rv1108 devicetree copies from U-Boot,
let's convert the rv1108 boards to OF_UPSTREAM so that the upstream kernel
devicetrees can be used instead.
Tested on a rv1108-elgin-r1 board.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fixed typo in commit log.
arch/arm/dts/rv1108-elgin-r1.dts | 59
arch/arm/dts/rv1108-evb.dts | 79 -
arch/arm/dts/rv1108.dtsi | 581 ---
arch/arm/mach-rockchip/Kconfig | 1 +
configs/elgin-rv1108_defconfig | 2 +-
configs/evb-rv1108_defconfig | 2 +-
6 files changed, 3 insertions(+), 721 deletions(-)
delete mode 100644 arch/arm/dts/rv1108-elgin-r1.dts
delete mode 100644 arch/arm/dts/rv1108-evb.dts
delete mode 100644 arch/arm/dts/rv1108.dtsi
diff --git a/arch/arm/dts/rv1108-elgin-r1.dts b/arch/arm/dts/rv1108-elgin-r1.dts
deleted file mode 100644
index 83e8b3183847..
--- a/arch/arm/dts/rv1108-elgin-r1.dts
+++ /dev/null
@@ -1,59 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-/dts-v1/;
-
-#include "rv1108.dtsi"
-
-/ {
- model = "Elgin RV1108 R1 board";
- compatible = "elgin,rv1108-elgin", "rockchip,rv1108";
-
- memory@6000 {
- device_type = "memory";
- reg = <0x6000 0x0800>;
- };
-
- chosen {
- stdout-path = "serial2:150n8";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_clk _cmd _bus8>;
- bus-width = <8>;
- cap-mmc-highspeed;
- disable-wp;
- non-removable;
- status = "okay";
-};
-
- {
- status = "okay";
-
- u2phy_otg: otg-port {
- status = "okay";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_xfer_pullup>;
- status = "okay";
-};
-
-_otg {
- status = "okay";
-};
-
- {
- uart2m0 {
- uart2m0_xfer_pullup: uart2m0-xfer-pullup {
- rockchip,pins = <2 RK_PD2 RK_FUNC_1
_pull_up_drv_8ma>,
- <2 RK_PD1 RK_FUNC_1
_pull_up_drv_8ma>;
- };
- };
-};
diff --git a/arch/arm/dts/rv1108-evb.dts b/arch/arm/dts/rv1108-evb.dts
deleted file mode 100644
index c91776bc106e..
--- a/arch/arm/dts/rv1108-evb.dts
+++ /dev/null
@@ -1,79 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-/dts-v1/;
-
-#include "rv1108.dtsi"
-
-/ {
- model = "Rockchip RV1108 Evaluation board";
- compatible = "rockchip,rv1108-evb", "rockchip,rv1108";
-
- memory@6000 {
- device_type = "memory";
- reg = <0x6000 0x0800>;
- };
-
- chosen {
- stdout-path = "serial2:150n8";
- };
-
- vcc5v0_otg: vcc5v0-otg-drv {
- compatible = "regulator-fixed";
- enable-active-high;
- regulator-name = "vcc5v0_otg";
- gpio = < RK_PB0 GPIO_ACTIVE_HIGH>;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- };
-};
-
- {
- status = "okay";
- clock_in_out = <0>;
- snps,reset-active-low;
- snps,reset-delays-us = <0 1 100>;
- snps,reset-gpio = < RK_PC1 GPIO_ACTIVE_LOW>;
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
- flash@0 {
- compatible = "gd25q256","jedec,spi-nor";
- reg = <0>;
- spi-tx-bus-width = <1>;
- spi-rx-bus-width = <1>;
- spi-max-frequency = <9600>;
- };
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
-_otg {
- vbus-supply = <_otg>;
- status = "okay";
-};
-
-_host_ehci {
- status = "okay";
-};
-
-_host_ohci {
- status = "okay";
-};
diff --git a/arch/arm/dts/rv1108.dtsi b/arch/arm/dts/rv1108.dtsi
deleted file mode 100644
index 215d88522587..
--- a/arch/arm/dts/rv1108.dtsi
+++ /dev/null
@@ -1,581 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-#include
-#include
-#include
-#include
-#include
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- compatible = "rockchip,rv1108";
-
- interrupt-parent = <>;
-
- aliases {
- serial0 =
- serial1
[PATCH] rockchip: rv1108: Convert to OF_UPSTREAM
Instead of using the local rv1108 devicetree copies from U-Boot,
let's convert the rv11008 board to OF_UPSTREAM so that the upstream kernel
devicetrees can be used instead.
Tested on a rv1108-elgin-r1 board.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/rv1108-elgin-r1.dts | 59
arch/arm/dts/rv1108-evb.dts | 79 -
arch/arm/dts/rv1108.dtsi | 581 ---
arch/arm/mach-rockchip/Kconfig | 1 +
configs/elgin-rv1108_defconfig | 2 +-
configs/evb-rv1108_defconfig | 2 +-
6 files changed, 3 insertions(+), 721 deletions(-)
delete mode 100644 arch/arm/dts/rv1108-elgin-r1.dts
delete mode 100644 arch/arm/dts/rv1108-evb.dts
delete mode 100644 arch/arm/dts/rv1108.dtsi
diff --git a/arch/arm/dts/rv1108-elgin-r1.dts b/arch/arm/dts/rv1108-elgin-r1.dts
deleted file mode 100644
index 83e8b3183847..
--- a/arch/arm/dts/rv1108-elgin-r1.dts
+++ /dev/null
@@ -1,59 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-/dts-v1/;
-
-#include "rv1108.dtsi"
-
-/ {
- model = "Elgin RV1108 R1 board";
- compatible = "elgin,rv1108-elgin", "rockchip,rv1108";
-
- memory@6000 {
- device_type = "memory";
- reg = <0x6000 0x0800>;
- };
-
- chosen {
- stdout-path = "serial2:150n8";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_clk _cmd _bus8>;
- bus-width = <8>;
- cap-mmc-highspeed;
- disable-wp;
- non-removable;
- status = "okay";
-};
-
- {
- status = "okay";
-
- u2phy_otg: otg-port {
- status = "okay";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_xfer_pullup>;
- status = "okay";
-};
-
-_otg {
- status = "okay";
-};
-
- {
- uart2m0 {
- uart2m0_xfer_pullup: uart2m0-xfer-pullup {
- rockchip,pins = <2 RK_PD2 RK_FUNC_1
_pull_up_drv_8ma>,
- <2 RK_PD1 RK_FUNC_1
_pull_up_drv_8ma>;
- };
- };
-};
diff --git a/arch/arm/dts/rv1108-evb.dts b/arch/arm/dts/rv1108-evb.dts
deleted file mode 100644
index c91776bc106e..
--- a/arch/arm/dts/rv1108-evb.dts
+++ /dev/null
@@ -1,79 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-/dts-v1/;
-
-#include "rv1108.dtsi"
-
-/ {
- model = "Rockchip RV1108 Evaluation board";
- compatible = "rockchip,rv1108-evb", "rockchip,rv1108";
-
- memory@6000 {
- device_type = "memory";
- reg = <0x6000 0x0800>;
- };
-
- chosen {
- stdout-path = "serial2:150n8";
- };
-
- vcc5v0_otg: vcc5v0-otg-drv {
- compatible = "regulator-fixed";
- enable-active-high;
- regulator-name = "vcc5v0_otg";
- gpio = < RK_PB0 GPIO_ACTIVE_HIGH>;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- };
-};
-
- {
- status = "okay";
- clock_in_out = <0>;
- snps,reset-active-low;
- snps,reset-delays-us = <0 1 100>;
- snps,reset-gpio = < RK_PC1 GPIO_ACTIVE_LOW>;
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
- flash@0 {
- compatible = "gd25q256","jedec,spi-nor";
- reg = <0>;
- spi-tx-bus-width = <1>;
- spi-rx-bus-width = <1>;
- spi-max-frequency = <9600>;
- };
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
-_otg {
- vbus-supply = <_otg>;
- status = "okay";
-};
-
-_host_ehci {
- status = "okay";
-};
-
-_host_ohci {
- status = "okay";
-};
diff --git a/arch/arm/dts/rv1108.dtsi b/arch/arm/dts/rv1108.dtsi
deleted file mode 100644
index 215d88522587..
--- a/arch/arm/dts/rv1108.dtsi
+++ /dev/null
@@ -1,581 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
- */
-
-#include
-#include
-#include
-#include
-#include
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- compatible = "rockchip,rv1108";
-
- interrupt-parent = <>;
-
- aliases {
- serial0 =
- serial1 =
- serial2 =
- spi0=
- };
-
-
[OE-core] Set the CMake BUILD_TESTING option to OFF as the default setting
I've noticed that some recipes, like json-c [1], which use the cmake
bbclass, are generating files that aren't being used. This is because
CMake sets the BUILD_TESTING option to ON by default. According to the
CMake documentation [2], when CTest is included, as json-c does here
[3], the module automatically creates a |BUILD_TESTING| option. This
option determines whether to enable testing support, and it is ON by
default.
In the json-c example, the tests used by the do_install_ptest task are
always generated. Thus, ${B}/tests/ exists even when ptests are not
included in DISTRO_FEATURES.
As the behavior of CTest/CMake to build tests by default is rather
surprising, we are wondering whether disabling this option by default is
feasible in the OpenEmbedded context. Recipes expecting tests to be
built (e.g. because of ptest support) would then turn on the flag
explicitly.
For example, adding this to cmake.bbclass:
|OECMAKE_BUILD_TESTING ??= "false" EXTRA_OECMAKE:append = "\\
${@bb.utils.contains('OECMAKE_BUILD_TESTING', 'false',
'-DBUILD_TESTING=OFF', '', d)} \\ " |
and then set the OECMAKE_BUILD_TESTING in the recipe that requires
BUILD_TESTING=ON
Do you have any suggestions on which steps we should take to verify that
this does not introduce any regressions?
1 -
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/json-c/json-c_0.17.bb?h=master
2 - https://cmake.org/cmake/help/latest/module/CTest.html
3 - https://github.com/json-c/json-c/blob/master/CMakeLists.txt#L19
Regards,
Fabio Berton
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#198621):
https://lists.openembedded.org/g/openembedded-core/message/198621
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: [Heads-up] More spring cleaning: orphaning bamf
On Mon, Apr 22, 2024 at 11:12 PM Michel Lind wrote: > > Dear all, > > I've been maintaining bamf for... quite some time, and don't actually have a > need for it anymore. > > It's pretty much in maintenance mode upstream as well. > > I've built the last stable version in Rawhide to close > https://bugzilla.redhat.com/show_bug.cgi?id=2055853 > > but will probably not build for stable releases, I'll let the new > maintainer(s) > handle that. > > Right now it looks like only plank actually uses it; its maintainer is cc:ed > > $ fedrq whatrequires bamf > bamf-daemon-0.5.5-8.fc40.x86_64 > bamf-devel-0.5.5-8.fc40.i686 > bamf-devel-0.5.5-8.fc40.x86_64 > plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 > plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 > > So if you use plank, or otherwise have a need for this, feel free to take > this over. The story with plank is a bit weird ... The last release was in 2019, and elementary OS forked it some years later, because upstream development was pretty much dead. At that point, I was a (co-)maintainer of the plank package, and switched the package to build from the elementary fork, because it had fixes and support for some new stuff. However, elementary has been developing their own dock from scratch (with eyes on eventual Wayland support), and the plank project on launchpad actually looks more active again :| So maybe the package should be switched back to the original upstream when / if the new elementary Dock is ready (it's not yet) ... 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: Self Introduction: Łukasz W.
On Mon, Apr 22, 2024 at 10:43 PM Fabio Valentini wrote: > > On Mon, Apr 22, 2024 at 9:16 PM Łukasz Wojniłowicz > wrote: > > > > You're welcome. rust-appdirs got in and I believe is waiting to be > > available in the repositories. > > No, it's waiting for *you* to actually import the package. :) > Just getting the package review ticket approved does nothing on its own. Sorry, I just saw that you imported and built the package for Rawhide. Congratulations for getting your first package into Fedora then! :) 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: Self Introduction: Łukasz W.
On Mon, Apr 22, 2024 at 9:16 PM Łukasz Wojniłowicz wrote: > > You're welcome. rust-appdirs got in and I believe is waiting to be > available in the repositories. No, it's waiting for *you* to actually import the package. :) Just getting the package review ticket approved does nothing on its own. > Meanwhile, I try to get another dependencies in at: > https://bugzilla.redhat.com/show_bug.cgi?id=2276462 > https://bugzilla.redhat.com/show_bug.cgi?id=2276290 I will try to get to those soon, but I can't promise when I will have the time to do so. 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: Rust Stack Spring Cleaning - 2024 Edition
On Mon, Apr 22, 2024 at 5:13 PM Peter Robinson wrote: > > I am aware of a few of the above I'm listed against that my deps no > longer requre (eg passwd) but I hadn't got around to working out what > else depended on them to retire without possibly breaking something > else, overall happy for them to be retired as part of the mass > retirement if there's no other deps. Whoops, sorry about that - I constructed the "packages per maintainer" list manually, apparently I was too tired to check that everybody included in the table is also included in the per-maintainer lists :( > There's also some that are deps on things still in progress like > rust-rustls-pki-types (rhbz 2272351 has dep details), not sure how to > tag those so I don't have to do more work to repackage them. Thanks for checking! FYI, rustls-pki-types is no longer a leaf package since I updated rustls / reqwest to newer versions. 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] clk: imx8mn: add video clocks support
Hi Michael, On Mon, Apr 22, 2024 at 7:36 AM Michael Nazzareno Trimarchi wrote: > Are you considering if I wrap properly with VIDEO IS_ENABLED? I prefer you resend this patch as part of a complete series that adds panel support to an imx8mn board target. Otherwise, if this gets in as-is, it will become a dead code, which we want to avoid.
Re: [PATCH] clk: imx8mn: add video clocks support
Hi Michael, On Sun, Apr 21, 2024 at 11:07 AM Michael Trimarchi wrote: > > Add clocks support for the video subsystem. > > Signed-off-by: Michael Trimarchi Which target will make use of these clocks? As-is this patch adds only dead code. Adding a defconfig that uses these newly introduced clocks would be nice. Also, to avoid size increase, please protect this code against CONFIG_VIDEO or something, like done here: https://source.denx.de/u-boot/custodians/u-boot-imx/-/commit/2b3310ef13998dfd03196a0806e03035212b102c
Re: Should we include nss-certs out of the box?
On 2024-04-20, 11:06 +0100, Fabio Natali wrote: > I'll send an update here. Hi Maxim, There's a couple of mentions of 'nss-certs' in the manual that might be rephrased to reflect '65e8472a4b6fc6f66871ba0dad518b7d4c63595e'. For what it's worth, I put together a micro-patch and sent it over as a follow-up to #70451. https://issues.guix.gnu.org/70451#4 Thanks, cheers, Fabio. -- Fabio Natali https://fabionatali.com
A capture-stdout wrapper procedure in (guix build utils)?
Hallo, I noticed this capture-stdout wrapper procedure while reviewing Tomas' patch 68289⁰: , | (define (capture-stdout . prog+args) | (let* ((port (apply open-pipe* OPEN_READ prog+args)) | (data (get-string-all port))) | (if (= 0 (status:exit-val (close-pipe port))) | (string-trim-right data #\newline) | (error "command failed" ` Since this seems to be a somewhat general and useful pattern, do you think it might be worth to add it (or a variation thereof) to '(guix build utils)'? Thanks, best wishes, Fabio. ⁰ https://issues.guix.gnu.org/issue/68289/#0-lineno93 -- Fabio Natali https://fabionatali.com
Re: [PATCH v3 1/3] clk: imx8mm: Add support for PCIe clocks
On Fri, Apr 19, 2024 at 12:29 PM Tim Harvey wrote: > > Add support for PCIe clocks required to enable PCIe support on > iMX8MM SoC. > > Signed-off-by: Tim Harvey > --- > v3: wrap pcie clk config around IS_ENABLED to avoid SPL growth as > suggested by Marek Applied all, thanks.
Re: [PATCH v1] board: toradex: imx: Remove not needed env variables
On Thu, Apr 18, 2024 at 10:12 AM Francesco Dolcini wrote: > > From: Francesco Dolcini > > Remove not needed variables from environment and include config files. > > - setup variable used to be executed from some bootscript, however >it's not required and there is no point on having this small helper >here > - boot_file, kernel_file, ip_dyn variables are not used anywhere > - fdt_fixup variable is just set empty > - defargs, vidargs variables used to be used from some bootscript, >however there is no point on having it here and even old legacy >bootscript can work without them > - removed CONFIG_ENABLE_DDR_TRAINING_DEBUG, this is a leftover from >some copy/paste > > On colibri imx6ull/imx7 NAND module, remove consoleblank=0, this is > already the Linux kernel default therefore useless. > > Various Linux Kernel command line options removed are not-existing > left-over that applied to some old NXP i.MX downstream branch > > Signed-off-by: Francesco Dolcini Applied, thanks.
Re: [PATCH] imx8m*_venice_defconfig: enable ipv6, wget and tftpput
On Wed, Apr 17, 2024 at 5:03 PM Tim Harvey wrote: > > Enable ipv6, wget, and tftpput support > > Signed-off-by: Tim Harvey Applied, thanks.
Re: [PATCH] board: gateworks: venice: fix dt adjustment for gw73xx baseboard for imx8mp
On Wed, Apr 17, 2024 at 5:01 PM Tim Harvey wrote: > > The GW73xx baseboard needs a PCI dt adjustment for revC/D based on a > change of the PCIe switch. Make sure we are only doing this for a pci > based ethernet to avoid causing a boot hang when the ethernet1 alias > points to eqos or fec. To know this is a pcie device ensure the alias > begins with the pcie controller. > > Signed-off-by: Tim Harvey Applied, thanks.
Re: [PATCH v1] arm: dts: verdin-imx8mm/imx8mp: use gpio-hog for sleep moci
On Wed, Apr 17, 2024 at 5:49 AM Stefan Eichenberger wrote:
>
> From: Stefan Eichenberger
>
> In Linux, we allow sleep moci to be turned off when the carrier board
> supports it and the system is in suspend. In U-Boot, however, we want
> the sleep moci to be always on. So we use a gpio hog and disable the
> regulator. This change is necessary because we switched to upstream
> device tree files with commit 23fe2def1edf
> ("verdin-imx8mm/verdin-imx8mp: move imx verdins to OF_UPSTREAM"). A
> recent upstream patch removes the gpio hog from the Linux device tree,
> so we need to add it to the u-boot dtsi. The following patch will remove
> the gpio hog from the Linux device tree:
> https://lore.kernel.org/linux-devicetree/20240405160720.5977-1-eich...@gmail.com/
> The U-Boot patch can be applied without it and will not break the build.
>
> Signed-off-by: Stefan Eichenberger
Applied, thanks.
Re: [PATCH] imx93: Move SoC and lifeclycle information to debug level
On Mon, Apr 15, 2024 at 6:57 PM Fabio Estevam wrote: > > From: Fabio Estevam > > The following information printed on every boot is not very > helpful for the users: > > SOC: 0xa0009300 > LC: 0x40040 > > Move them to debug() level. > > Signed-off-by: Fabio Estevam Applied, thanks.
