Re: LibreOffice packages
On Fri, Jun 2, 2023, 9:09 AM Matthew Miller mailto:mat...@fedoraproject.org>> wrote: I think this sentiment is getting ahead of things. This thread _is_ that effort. Yes, but. In general, a better approach is to say "we plan on orphaning the packages in $timeframe". ... RH, for the moment is still represented as on the DocFoundation's Advisory Board, https://wiki.documentfoundation.org/TDF/Advisory_Board#Composition_of_the_Advisory_Board https://www.documentfoundation.org/advisory-board/ Has there been any indication yet as to their withdrawal there? or not? Dev comms with devs is one approach aspect of engagement with LO. Engagement at the organizational level is another. If RH's organizational support, or lack thereof, is now a risk -- existential or not -- then perhaps spreading that risk across other orgs' interests & support has possible value. Do any of the Fedora Project guidelines -- particularly any restrictions by RH's legal -- prevent increased/direct engagement with the DF's governance/advisory groups? Dev list is probly also not the right place for that discussion. BUT, it's where the immediate, legitimate discussion IS being had. ___ 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: Status of the forge macros?
If the need to package a snapshot goes away
'need' is certainly one right operative question.
whose?
Redhat's?
official Fedora packaging's?
"just us COPR users"?
i'm in the last camp.
i build/package to scratch my own projects' requirements' itch(es).
here's one, below, that depends on forge macros, making the build
manageable/trivial
no, i don't expect this to be used by anyone else, especially not official
packaging
but, without the ease/convenience forge macros, the cost of building here rises
quickly
-
%{?_pgnd_macros}
%global _owner pgnd
%global _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S --utc )
%bcond_without testcondition 1
%define _ngx_namenginx
%define _ngx_comment Nginx Web Server
%define _ngx_version 1.25.0
%define _modsecurity_version 1.0.3
%define _ngx_usr wwwrun
%define _ngx_grp www
%define _ngx_prefix /usr/local/nginx
%define _ngx_logdir /var/log/nginx
%define _ngx_confdir /usr/local/etc/ORIG-nginx
%define _ngx_moddir /usr/local/nginx-modules
%define _ngx_tmpdir %{_localstatedir}/lib/nginx/tmp
%define _ngx_cc /usr/bin/gcc
%define _ngx_cpp /usr/bin/cpp
%define _ngx_debug_flags -Wp,-D_FORTIFY_SOURCE=2
%global forgeurl0 https://github.com/nginx/nginx
Version: %{_ngx_version}
%global tag0 release-%{version}
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%global branch1 master
%global forgeurl4 https://github.com/leev/ngx_http_geoip2_module
%global branch4 master
%global forgeurl5 https://github.com/vision5/ngx_devel_kit
%global branch5 master
%global forgeurl8 https://github.com/google/ngx_brotli
%global branch8 master
%global forgeurl9 https://github.com/nginx/njs
%global branch9 master
%global forgeurl11 https://github.com/GetPageSpeed/ngx_security_headers
%global branch11 master
%global forgeurl12 https://github.com/nulab/nginx-length-hiding-filter-module
%global branch12 master
%global forgeurl13 https://github.com/GetPageSpeed/ngx_immutable
%global branch13 master
%global forgeurl14 https://github.com/SpiderLabs/ModSecurity-nginx
%global tag14 v%{_modsecurity_version}
%forgemeta -i -a
%global dist .%{_owner}_%{_build_timestamp}.fc%{fedora}
Name: %{_ngx_name}
Release: 0%{?dist}
Summary: %{_ngx_comment}
License: BSD-2-Clause
URL: %{forgeurl0}
Source0: %{forgesource0}
Source1: %{forgesource1}
Source4: %{forgesource4}
Source5: %{forgesource5}
Source8: %{forgesource8}
Source9: %{forgesource9}
Source11: %{forgesource11}
Source12: %{forgesource12}
Source13: %{forgesource13}
Source14: %{forgesource14}
Source100: https://nginx.org/en/CHANGES
Source101: https://nginx.org/LICENSE
BuildRequires: brotli-devel
BuildRequires: coreutils
BuildRequires: gcc
BuildRequires: gd-devel
BuildRequires: git
BuildRequires: grep
BuildRequires: gnupg2
BuildRequires: libatomic_ops-devel
BuildRequires: libmaxminddb-devel
BuildRequires: libmodsecurity-devel
BuildRequires: libxml2-devel
BuildRequires: libxslt-devel
BuildRequires: make
BuildRequires: openssl-devel
BuildRequires: pcre2-devel
BuildRequires: perl-ExtUtils-Embed
BuildRequires: perl-generators
BuildRequires: pkgconf-pkg-config
BuildRequires: zlib-devel
Requires: nginx-filesystem
Requires: libmodsecurity
Requires: mod_security_crs
Requires: openssl
Requires: pcre2
BuildRequires: systemd
Requires(post):systemd
Requires(preun): systemd
Requires(postun): systemd
Provides: webserver
Conflicts: nginx-core
Conflicts: nginx-mimetypes
Obsoletes: nginx< %{_ngx_version}
Obsoletes: nginx-filesystem < %{_ngx_version}
%description
%{_ngx_comment}
%package filesystem
Summary: nginx directory layout
BuildArch: noarch
Requires(pre): shadow-utils
%description filesystem
nginx directory layout
dummy, to satisfy php-fpm reqt and prevent pulling distro pkg
%prep
%forgesetup -a
cp %{SOURCE100} %{SOURCE101} .
%build
export CFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export CPPFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export CXXFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export LDFLAGS="%{_LDFLAGS} -Wno-dangling-pointer"
export DESTDIR=%{buildroot}
cd %{_builddir}/%{name}-%{tag0}
export LUAJIT_LIB=""
export LUAJIT_INC=""
./auto/configure \
--with-debug \
--build="PGNd Custom Build" \
--user=%{_ngx_usr} --group=%{_ngx_grp} \
--prefix=%{_ngx_prefix} \
--conf-path=%{_ngx_confdir}/nginx.conf \
--error-log-path=%{_ngx_logdir}/main.error.log \
--http-log-path=%{_ngx_logdir}/main.access.log \
--modules-path=%{_ngx_moddir} \
--http-client-body-temp-path=%{_ngx_tmpdir}/client_body \
--http-proxy-temp-path=%{_ngx_tmpdir}/proxy \
Re: Status of the forge macros?
Original Message From: Richard W.M. Jones [mailto:rjo...@redhat.com] Sent: Tuesday, May 23, 2023 at 1:27 PM EDT To: devel@lists.fedoraproject.org Subject: Status of the forge macros? I've been using the so-called forge macros in lots of packages: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. m_oO_m ?! Is this true, and if so can we actually document that? Else un-deprecate them as they are really useful. +1 to that. been similarly using them for ages, particularly given the i've been often pointed to the d.f.o link above as current :-/ imo, immensely useful, with unique capabilities (tho, similar to OBS) for forge src mgmt. ___ 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: Review Request: ImageMagick7
As I said earlier in the thread: of the 25 reverse dependencies of the ImageMagick libraries, only five don't build[1]. Further analysis indicates that dvdauthor has a patch in openSUSE[2], but the fix breaks support for GraphicsMagick as an alternative. I want to rework that patch so it doesn't break GraphicsMagick and old ImageMagick support so that it's suitable for upstreaming. I don't expect this to be too difficult to do. I understand this^^ is re: distro building/packaging there's been at least one mention/question about run-time compatibility in this thread I've not noticed mention previously, so just in case relevant here, fwiw lsb_release -rd Description:Fedora release 37 (Thirty Seven) Release:37 rpm -qa | grep -i magick | sort GraphicsMagick-1.3.38-3.fc37.x86_64 GraphicsMagick-c++-1.3.38-3.fc37.x86_64 GraphicsMagick-c++-devel-1.3.38-3.fc37.x86_64 GraphicsMagick-devel-1.3.38-3.fc37.x86_64 GraphicsMagick-perl-1.3.38-3.fc37.x86_64 ImageMagick7-7.1.0.52-1.fc37.remi.x86_64 ImageMagick7-c++-7.1.0.52-1.fc37.remi.x86_64 ImageMagick7-c++-devel-7.1.0.52-1.fc37.remi.x86_64 ImageMagick7-devel-7.1.0.52-1.fc37.remi.x86_64 ImageMagick7-libs-7.1.0.52-1.fc37.remi.x86_64 ImageMagick7-perl-7.1.0.52-1.fc37.remi.x86_64 ImageMagick-c++-6.9.12.67-1.fc37.remi.x86_64 ImageMagick-libs-6.9.12.67-1.fc37.remi.x86_64 php-pecl-imagick-im6-3.7.0-2.fc37.remi.8.2.x86_64 rpm -q --whatprovides `which convert` ImageMagick7-7.1.0.52-1.fc37.remi.x86_64 IM7 has been in-place for quite awhile here, installed from Remi's repos, https://blog.remirepo.net/post/2016/12/12/ImageMagick6-and-ImageMagick7 https://www.howtofixthis.com/categories/installing-linux-tools/installing-imagemagick-from-remi-repository-or-via-source-code https://ask.fedoraproject.org/t/how-to-install-imagemagick-7-on-fedora-35/20354 my machines certainly do not touch all packages with any IM deps. but, so far, I'm not aware of any complaint/error/etc re: that mix/use of *Magick pkgs on a bunch of similarly configured boxes. ___ 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: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Let's Encrypt also supports the dns-01 challenge[1] that doesn't require any publicly available IPs. Using dns verification is required to obtain a Let's Encrypt wildcard certificate. While I tend to prefer using the dns-01 challenge approach when possible, not all DNS providers have made it easy to accomplish (the certbot folk have implementations for a number of the major DNS providers, and one can sometimes find other 3rd party code for others, but it can still be hard to setup and use, which means just enough additional impedance that sometimes people will choose not to use it; I can't blame them, as sometimes free has a higher cost than having someone else order the cert from one of the non-free CAs). fwiw, IME, one of the lowest-friction dns-challenge tools I've recommended, and see actually getting used by clients, is acme.sh, https://github.com/acmesh-official/acme.sh#user-content-8-automatic-dns-api-integration which supports 'most' of the big dns apis, https://github.com/acmesh-official/acme.sh/wiki/dnsapi and, when not an option, is fairly trivial to use manually https://github.com/acmesh-official/acme.sh#user-content-9-use-dns-manual-mode https://github.com/acmesh-official/acme.sh/wiki/dns-manual-mode all of this with no cumbersome python, go, webserver, etc deps. just bash shell. ___ 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: Copr delete-by-default expiration policy still unacceptable
Don't get me wrong, the folks who work on Koji and Copr are great, but even they'll admit that they're woefully underfunded. The compose tooling, PDC, etc. are also examples of this problem. Can't agree enough. Hats off to the COPR folks. Without it, even it current state, RH/Fed ecosystem is, at least here, a LOT less tenable/attractive, if at all. Even in a world where I would be *able* to pay for it (and there's plenty of commercial evidence that such a service would be something people would pay for), I just don't think it would stick. Here's 1 'mid-sized umbrella' vote. I'm happy to pay for a COPR service. Particularly if it were to exist on at-least-arm's-length infrastructure, and provides decoupling from RH/IBM's corporate legal paranoias and policies. That could be managed as reasonable subscription fees. Another option is to get the containerized COPR efforts polished & available. Then, any/all could spin them up easily (aka, far easier than now), and deploy locally, &/or make available ... and, charge some reasonable fee for those downloads. And by reasonable fees, I'm not talking about Enterprise-sized profit-generating-fees, but enough given Fedora-project's real needs (devs & infrastructure) to defray, at least some of the, operating costs. And something that a significant majority of current contributors -- paid & volunteer alike -- would consider a worthwhile bargain for the value received. ___ 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
Non-responsive maintainer check for Othman Madjoudj a.k.a. athmane
Does anyone know how to contact Othman Madjoudj a.k.a. athmane? https://bugzilla.redhat.com/show_bug.cgi?id=2129515 Bug List, pkg libmodsecurity ID Status ResolSummary Changed 2129515 NEW Non-responsive maintainer check for athmane 2022-09-24T10:19:52Z 2129200 NEW is libmodsecurity pkg still being maintained? 2022-09-22T21:44:55Z 2128321 NEW Please port your pcre dependency to pcre2. Pcre has been deprecated 2022-09-20T13:46:18Z 2113484 NEW libmodsecurity: FTBFS in Fedora rawhidef37 2022-08-10T23:38:43Z 1957933 CLOSED EOL CVE-2019-25043 libmodsecurity: crafted key-value pair can lead t... 2022-06-07T20:07:31Z 2031842 NEW CVE-2021-42717 libmodsecurity: crafted JSON objects with nesting... 2022-01-06T06:32:29Z 2021301 NEW CVE-2021-35368 libmodsecurity: request body bypass via a trailin... 2021-11-08T18:42:06Z 1879589 CLOSED EOL CVE-2020-15598 libmodsecurity: specially crafted payload could r... 2021-05-25T18:33:30Z 1801719 CLOSED ERRATA CVE-2019-19886 libmodsecurity: denial of service in Transaction:... 2020-04-06T01:05:43Z 1672678 CLOSED RAWHIDE libmodsecurity: update to 3.0.3 release 2019-07-02T08:22:43Z ___ 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: Thunderbird 102 pushed to F36 stable
As I did those updates.. well explained, thx. But this then seems to be a more general problem of how we want to support a switch an application from one ESR/LTS release if it is EOL to the next. not terribly differently than others -- with an abundance of end-user education and caution? tbird version update -- across ESLs or not -- breaking one's install, or eating one's mailstore, is not _automatically_ a universal fact for tbird, it's more often an issue specific to one's system; not uncommmonly, your config &/or your addons. for other ppl, the upgrade's been working fine in production for awhile now with upstream releases, with early fedora tbird builds, and now the fedora release pkgs. for me, the lack of a long-overdue v102 update was 'costing' much more than not ... on F36, thunderbird packages are still available in two major versions dnf list --showduplicates thunderbird Last metadata expiration check: 0:01:09 ago on Sat 03 Sep 2022 07:36:45 AM EDT. Available Packages thunderbird.x86_6491.7.0-1.fc36 fedora thunderbird.x86_64 102.2.1-1.fc36 updates older version's still easily installed, dnf install thunderbird-91.7.0-1.fc36.x86_64 historical versions are still available, and quite easily installed & functional, from https://www.thunderbird.net/en-US/thunderbird/releases/ ESL or not, how exactly was thunderbird 102 'pushed' to ppl's systems? did they enable autoupdates? or, click to allow the update? if tbird's a critical update for 'you', you do have backups of your tbird configs & mailstores? keep up to date with thunderbird version progress/news/chengelogs/notes? remembered that addons are not tbird or fedora issues, and checked current/future compatibility of your addons, as well as whether they're well maintained? communicated issues/bugs/etc to the respective projects? and have waited to update until after checking/verifying that it works for you? and, in case none of that was done, since firefox/tbird major-version update issues _are_ historically well-known (if unfortunate), you froze version upgrades of tbird on your system https://dnf-plugins-core.readthedocs.io/en/latest/versionlock.html to make sure that you're never surprised by an update you don't want/expect? my $0.02. ___ 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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
I'm shutting up now, because this comment from ngompa is, IMO, very well/thoroughly said. thx Neal! On 4/6/22 8:16 AM, Neal Gompa wrote: If you really have a need to reinstall such machine, you'll take the F36 image and upgrade to F37+ and you should still be good. This is not a deprecation change, this is effectively a removal change. By removing the packages and the tooling support for legacy BIOS, it makes several scenarios (including recovery) harder. Moreover, it puts the burden on people to figure out if their hardware can boot and install Fedora when we clearly haven't reached a critical mass yet for doing so, like we did when we finally removed the i686 kernel build. I'm personally a fan of using UEFI instead of BIOS. Heck, I implemented support for UEFI in Fedora's cloud images when other people told me it was not possible, while preserving BIOS support. I've been trying to figure out the roadmap for BIOS deprecation for a year now, and the reason *I* didn't propose a Change yet is because I have not sufficiently determined that it was reasonable to do so. I'm particularly upset about this Change because it feels like a hostage change where the proposal owners blithely ignore what we're saying as unimportant or irrelevant and abuse our principles to do things that are clearly against what the community feels is right. I have been trying in the background for years to try to figure out solutions for usability problems in Fedora Linux on UEFI because *I want our experience to be good there*. But it's extremely hard when: 1. Bugs and feature requests around UEFI related features are ignored 2. The packages are locked down so there is no way for the community to help 3. At various times, people have explicitly said "patches NOT welcome" I'm angry because we're doing this without any real thought around the consequences for the user experience, and we should not do that as a premier Linux distribution. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/6/22 8:03 AM, Vít Ondruch wrote: If you really have a need to reinstall such machine, you'll take the F36 image and upgrade to F37+ and you should still be good. With 100s - 1000s of of affected machines -- real & virtual -- still in operation, with usable lifetimes of years-to-come, from a planner's perspective, given the choice of that^ risk vs moving to a different distro where there's a more realistic sunset, curious ... ... what do ppl here think will be the choice (about continued use of RH/Centos/Fedora)? best for developers != (necessarily) best for customers/users. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
Akamai owns Linode, which is a prominent VPS that focuses on Linux (Linode is a contraction meaning "Linux Node"). +1 DigitalOcean similarly is Linux centric and so Windows doesn't matter. +1 Most web hosting providers and VPSes are Linux-centric and so Windows doesn't matter. +1 Ironic that Windows11 compat is being floated as any kind of rationale here. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
(Akamai is, to my knowledge, not a provider of VPSs.) https://www.linode.com/press-release/akamai-to-acquire-linode/ ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
So you've heard that we're overloaded, and you know that UEFI is the direction the world is heading. Well, so is (was?) 'IPv6' ... Your solution to this is... what, stick our heads in the sand and ignore that? Just do legacy? We already have UEFI-only platforms (see also: the mention of ARM you're belaboring), so that's obviously not going to fly, even if we were willing to, which we're not. There are enough, different plots of sand for different folks to stick their heads into. To my read, noone's suggested ignoring the future -- rather the suggestions appear to be to NOT ignore reality. Curious, has anyone from @redhat or @fedora though to actually communicate with any of the 'big' hosting providers, to perhaps coordinate/influence/compromise/plan? I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest hosting providers where 'new installs' would be happening on their VPSs -- would be quite interested in making sure that THEIR customers had smooth install/migration options for Redhat/Centos*/Fedora variants. I know my _own_ solution to UEFI-install only if those^ providers don't support it; I'm guessing not everyone will have the same goals/approach. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
On 2/24/22 10:12 AM, Fabio Valentini wrote: On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev wrote: especially since they don't really provide value for standard GitHub tarball downloads etc. compared to the "old" SourceURL some of us strongly disagree. admittedly, with no weight ... Admittedly, packages like the .spec for nginx you linked are very far outliers regarding package complexity. Perhaps very far outliers for _your_ use cases. Quite common, here. Especially for numbers of enterprise packages that, for better or worse, lag upstream in either versions, or capabilities. And the flexibility to address that level of 'complexity' is exactly what we look to a major-distro's build systems for. My wholesale move(s) to Fedora from Opensuse were well-considered -- and long overdue. For a large number of reasons. The biggest risk was the drop in functionality/flexibility of the build system -- for end-user use cases, NOT necessarily (just) for official packaging. COPR + the forgemeta stuff gets a heck of a lot closer to par, than not. I doubt there's many packages that need to reference *that* many different source repos and tarballs ... For these really complex cases, the forge macros are ~fine~, I guess. But you really don't - and shouldn't - need to rely on hundreds of lines of complex lua macros to be able to specify one or two GitHub tarballs. With that I don't disagree in the slightest. I've repeatedly advocated for a different approach, similar to OBS' capabilities. It got zero traction/interest. So forgemeta seems to be "functionally best available" option, currently. It would be far less of a concern if ANY of those discussions had gotten any traction, and there was a good/flexible ALTERNATIVE to forgemeta, rather than simply talk of deprecating current capabilities, without a good option. There _are_ options, of course. And I have two in place -- our own, LFS distro with rpm build system, and building Fedora+pkgs on OBS. Neither are optimal, both are costly, and in both cases I'd prefer something @Fedora buildsys. But again, i ACK that 'my' needs have little weight. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
especially since they don't really provide value for standard GitHub tarball downloads etc. compared to the "old" SourceURL some of us strongly disagree. admittedly, with no weight ... ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
Aside from the other follow-ups about whether or not to use them... here's an example of a SPEC I wrote for a proposed package: not all are concerned with building according to Fedora Packaging standards, for proposal in inclusion some of us use forgemeta because it provides capability that allows us to build what/when we require with capabilities approaching Opensuse's OBS. in any case, more flexible than not. particularly the nice git branch support; incredibly useful, imo. here's one of mine: https://pagure.io/pgnd/nginx-mainline/blob/main/f/nginx/nginx.spec used for my regular COPR builds. it would be ... unfortunate ... if forgemeta were to vanish. my $0.02 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packaging my own software?
On 1/18/22 14:29, Chris Adams wrote: to make it easier for me to install my own script and dependencies. :) COPR (https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/) exists, in part, to scratch that specific itch. Moving eventually to official builds once a COPR build is humming along is fairly straightforward process, although it comes of course with the addition of specific 'official' Fedora et al packaging guidelines. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
VDPAU is not VA-API
that's correct
Setting VDPAU_DRIVER means nothing to Firefox because it is not using VDPAU.
https://fedoraproject.org/wiki/Changes/VA-API_1.0.0#Detailed_Description
https://ffmpeg.org/doxygen/0.8/group__VDPAU__Decoding.html
"libva-vdpau-driver which allows to use the VA-API enabled players with
VDPAU backend (such as NVIDIA binary driver)."
https://trac.ffmpeg.org/wiki/HWAccelIntro#PlatformAPIAvailability
VDPAU / Linux / NVIDIA -> 'Fully usable'
ffmpeg -hwaccels
...
Hardware acceleration methods:
vdpau
cuda
vaapi
qsv
drm
opencl
vulkan
find/dl a 'busy' 4K+ h264 vid
e.g. @
https://jell.yfish.us/media/jellyfish-250-mbps-4k-uhd-h264.mkv
T="jellyfish-250-mbps-4k-uhd-h264.mkv"
F="jellyfish-250-mbps-4k-uhd-h264.mp4"
ffmpeg -i ${T} -codec copy ${F}
ls -al ${F} ${T}
-rw-r--r-- 1 test test 896M Dec 21 2016
jellyfish-250-mbps-4k-uhd-h264.mkv
-rw-r--r-- 1 test test 896M Nov 17 14:37
jellyfish-250-mbps-4k-uhd-h264.mp4
exec un-accel'd FFmpeg decoder
rm -f test.ts && ffmpeg -i ${F} test.ts
sar 1 100
Linux 5.14.17-301.fc35.x86_64 (test.loc)11/17/2021
_x86_64_(16 CPU)
02:23:27 PM CPU %user %nice %system %iowait
%steal %idle
02:23:28 PM all 0.38 0.00 0.50 1.95
0.00 97.17
02:23:29 PM all 19.29 0.00 1.44 0.00
0.00 79.27
02:23:30 PM all 88.85 0.13 2.01 0.00
0.00 9.02
02:23:31 PM all 88.08 0.00 1.63 0.00
0.00 10.29
02:23:32 PM all 87.38 0.00 1.87 0.00
0.00 10.74
02:23:33 PM all 89.01 0.00 1.76 0.06
0.00 9.17
02:23:34 PM all 87.81 0.06 1.95 0.00
0.00 10.18
02:23:35 PM all 87.95 0.06 1.62 0.00
0.00 10.37
02:23:36 PM all 89.77 0.00 1.95 0.00
0.00 8.29
02:23:37 PM all 89.36 0.00 2.00 0.00
0.00 8.64
02:23:38 PM all 55.63 0.13 1.32 0.19
0.00 42.74
02:23:39 PM all 0.44 0.00 0.56 0.00
0.00 99.00
02:23:40 PM all 0.62 0.00 0.56 0.06
0.00 98.75
...
exec vaapi<-vdpau accel'd VA-API FFmpeg decoder
rm -f test.ts && ffmpeg -hwaccel vdpau -i ${F} test.ts
sar 1 100
Linux 5.14.17-301.fc35.x86_64 (test.loc)11/17/2021
_x86_64_(16 CPU)
02:29:09 PM CPU %user %nice %system %iowait
%steal %idle
02:29:10 PM all 0.63 0.06 0.31 0.00
0.00 99.00
02:29:11 PM all 0.50 0.00 0.69 0.25
0.00 98.56
02:29:12 PM all 8.48 0.13 2.07 0.31
0.00 89.01
02:29:13 PM all 31.32 0.00 2.76 0.00
0.00 65.91
02:29:14 PM all 31.47 0.00 2.01 0.00
0.00 66.52
02:29:15 PM all 33.98 0.00 2.81 0.00
0.00 63.21
02:29:16 PM all 34.43 0.12 2.79 0.12
0.00 62.54
02:29:17 PM all 32.87 0.13 2.38 0.44
0.00 64.18
02:29:18 PM all 30.01 0.00 2.62 0.19
0.00 67.19
02:29:19 PM all 27.51 0.06 2.62 0.00
0.00 69.81
02:29:20 PM all 29.92 0.06 2.61 0.00
0.00 67.41
02:29:21 PM all 28.58 0.00 2.59 0.06
0.00 68.77
02:29:22 PM all 28.25 0.00 2.46 0.13
0.00 69.17
02:29:23 PM all 5.11 0.06 1.62 0.00
0.00 93.20
02:29:24 PM all 0.31 0.00 0.31 0.00
0.00 99.37
02:29:25 PM all 0.87 0.12 0.81 0.06
0.00 98.13
no vaapi without vdpau translation
rm -f test.ts && ffmpeg -hwaccel vaapi -i ${F} test.ts
[AVHWDeviceContext @ 0x557bc805f840] libva:
vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[AVHWDeviceContext @ 0x557bc805f840] Failed to initialise VAAPI
connection: -1 (unknown libva error).
Device creation failed: -5.
Re: Firefox Hardware acceleration & VA-API how-to
On 11/16/21 22:48, Michael Cronenworth wrote:
On 11/15/21 12:03 PM, PGNet Dev wrote:
launch @ shell
VDPAU_DRIVER=nvidia MOZ_LOG="Dmabuf:5, PlatformDecoderModule:5" firefox
I think you mean:
LIBVA_DRIVER_NAME=nvidia firefox
nope.
https://en.wikipedia.org/wiki/Video_Acceleration_API
"As of 2019, VA-API is natively supported by libva-vdpau-driver for
cards supported by VDPAU"
libva-vdpau-driver is the translation layer that provides a VDPAU-based backend
for VA-API.
@ https://wiki.archlinux.org/title/Hardware_video_acceleration#Configuring_VDPAU
"
Configuring VDPAU
You can override the driver for VDPAU by using the VDPAU_DRIVER
environment variable.
The correct driver name depends on your setup:
...
For NVIDIA's proprietary version set it to nvidia.
Note:
You can find the installed drivers in /usr/lib/vdpau/. They are
used as /usr/lib/vdpau/libvdpau_${VDPAU_DRIVER}.so
"
ls -al /usr/lib64/vdpau//libvdpau*nvidia*
lrwxrwxrwx 1 root root 25 Nov 15 10:04 /usr/lib64/vdpau//libvdpau_nvidia.so.1
-> libvdpau_nvidia.so.495.44*
-rwxr-xr-x 1 root root 620K Nov 15 10:04
/usr/lib64/vdpau//libvdpau_nvidia.so.495.44*
cref:
https://wiki.archlinux.org/title/Hardware_video_acceleration#VDPAU_drivers
https://wiki.archlinux.org/title/Hardware_video_acceleration#NVIDIA_driver_only
https://wiki.archlinux.org/title/Hardware_video_acceleration#Application_support
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Firefox Hardware acceleration & VA-API how-to
Video decoding on NVIDIA
Please buy some real Linux hardware.
This doesn't really help at all. Is it supposed to be funny, or is it
just cynical resignation?
After trying to configure HW acceleration on 9xx series GPU, I'll just take
that as a serious response.
Consider following points:
* VDPAU is not compatible with Wayland, our main desktop scenario.
* Video decoding in Firefox on X11 is limited to X11/EGL, which does not work
with the Nvidia proprietary driver (but at least there's a hope for that
scenario).
* There's no NVDEC vaapi backend, and I see opinions that it would be hard to
fit NVDEC into vaapi model.
* Nouveau support ends at VP5 (7xx series).
The wording might be different, but _at the moment_ any recent Nvidia hardware
cannot be used for HW video acceleration in Firefox.
currently,for proprietary nvidia hw accel
useful docs
https://wiki.archlinux.org/title/Hardware_video_acceleration
e.g.
on
lsb_release -rd
Description:Fedora release 35 (Thirty Five)
Release:35
with nvidia hw,
hwinfo --gfxcard | egrep " Model| Device| Driver:"
Model: "nVidia GP108 [GeForce GT 1030]"
Device: pci 0x1d01 "GP108 [GeForce GT 1030]"
Driver: "nvidia"
latest upstream driver,
nvidia-settings -q NvidiaDriverVersion
Attribute 'NvidiaDriverVersion' (test.loc:0.0): 495.44
Attribute 'NvidiaDriverVersion' (test.loc:0[gpu:0]): 495.44
lsmod | grep nv
nvidia_uvm 1167360 0
nvidia_drm 73728 8
nvidia_modeset 1150976 20 nvidia_drm
nvidia 36950016 1354 nvidia_uvm,nvidia_modeset
drm_kms_helper303104 1 nvidia_drm
drm 630784 14
drm_kms_helper,nvidia,drm_ttm_helper,nvidia_drm,ttm
currently, this set of relevant pkgs
rpm -qa | egrep
"libva|nvidia|vdpau|dkms|kernel-devel|glx|^egl|glvnd|libvpx|vulkan"
dkms-2.8.6-1.fc35.noarch
egl-utils-8.4.0-12.20210504git0f9e7d9.fc35.x86_64
glx-utils-8.4.0-12.20210504git0f9e7d9.fc35.x86_64
kernel-devel-5.14.17-301.fc35.x86_64
libglvnd-1.3.4-2.fc35.x86_64
libglvnd-core-devel-1.3.4-2.fc35.x86_64
libglvnd-devel-1.3.4-2.fc35.x86_64
libglvnd-egl-1.3.4-2.fc35.x86_64
libglvnd-gles-1.3.4-2.fc35.x86_64
libglvnd-glx-1.3.4-2.fc35.x86_64
libglvnd-opengl-1.3.4-2.fc35.x86_64
libva-2.13.0-2.fc35.x86_64
libva-utils-2.13.0-1.fc35.x86_64
libva-vdpau-driver-0.7.4-110.fc35.x86_64
libvdpau-1.4-6.fc35.x86_64
libvdpau-devel-1.4-6.fc35.x86_64
libvdpau-trace-1.4-6.fc35.x86_64
libvdpau-va-gl-0.4.2-20.fc35.x86_64
libvpx-1.10.0-2.fc35.x86_64
mesa-vdpau-drivers-21.2.5-1.fc35.x86_64
mesa-vulkan-drivers-21.2.5-1.fc35.x86_64
vdpauinfo-1.4-1.fc35.x86_64
vulkan-headers-1.2.189.0-1.fc35.noarch
vulkan-loader-1.2.189.0-1.fc35.x86_64
vulkan-loader-devel-1.2.189.0-1.fc35.x86_64
vulkan-tools-1.2.189.0-1.fc35.x86_64
checking for X11
grep -iE 'vdpau | dri driver' /var/log/Xorg.0.log
[37.637] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia
verifying
ldd `which mpv` | egrep -i "egl|nvidia|vdpau"
libEGL.so.1 => /lib64/libEGL.so.1 (0x7fadfdbb4000)
libwayland-egl.so.1 => /lib64/libwayland-egl.so.1
(0x7fadfbdbe000)
libvdpau.so.1 => /lib64/libvdpau.so.1 (0x7fadfacea000)
VDPAU_DRIVER=nvidia mpv --hwdec=auto TEST.mp4
(+) Video --vid=1 (*) (h264 1920x1080 30.015fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
Using hardware decoding (nvdec).
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 cuda[nv12]
AV: 00:00:02 / 00:00:39 (7%) A-V: 0.026 ct: 0.256
for FF
rpm -qa firefox
firefox-94.0-1.fc35.x86_64
read
https://www.phoronix.com/scan.php?page=news_item=Firefox-94-EGL-Linux-Usage
https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/
note
"In X.org, since 94, Firefox will run in EGL mode by default which is
sufficient [19]."
user.js settings currently include,
user_pref("media.ffmpeg.enabled", true);
user_pref("media.ffmpeg.vaapi.enabled", true);
user_pref("media.ffmpeg.vaapi-drm-display.enabled", true);
user_pref("media.ffvpx.enabled", false);
user_pref("media.navigator.mediadatadecoder_vpx_enabled", true);
Re: kernel mod build on Ryzen5/f34/kernel-5.14.13 builds OK, but FAILs @ modprobe insertion: "ERROR: could not insert ... Exec format error" ?
randomly poking at headers, just dnf reinstall kernel-devel made no difference to the problem but, complete removal/install dnf remove kernel-devel dnf reinstall kernel-core dnf install kernel-devel dkms bison flex did. now, after nvidia install & subsequent modprobe, lsmod | grep nvidia nvidia_drm 69632 0 nvidia_modeset 1200128 1 nvidia_drm nvidia 35332096 1 nvidia_modeset drm_kms_helper303104 2 amdgpu,nvidia_drm drm 630784 8 gpu_sched,drm_kms_helper,nvidia,amdgpu,drm_ttm_helper,nvidia_drm,ttm no idea why on a new/clean install this was necessary, or what diagnostic should've indicated the problem. in any case, sorted. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel mod build on Ryzen5/f34/kernel-5.14.13 builds OK, but FAILs @ modprobe insertion: "ERROR: could not insert ... Exec format error" ?
On 10/24/21 00:10, Reon Beon via devel wrote: This is what I found. "11 hour ago" https://forums.developer.nvidia.com/t/nvidia-470-74-build-error-unable-to-load-the-nvidia-drm-kernel-module-modprobe-error-could-not-insert-nvidia-drm-exec-format-error/19287 Right. I posted it. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
kernel mod build on Ryzen5/f34/kernel-5.14.13 builds OK, but FAILs @ modprobe insertion: "ERROR: could not insert ... Exec format error" ?
i'm building nvidia kernel mod, for use with a pci nvidia card
inxi -G | grep Dev
Graphics: Device-1: NVIDIA GK208B [GeForce GT 710] driver: N/A
Device-2: Advanced Micro Devices [AMD/ATI] Cezanne driver: N/A
on a new install/build,
cat /proc/cpuinfo | grep "model name" | uniq
model name : AMD Ryzen 5 5600G with Radeon Graphics
on
lsb_release -rd
Description:Fedora release 34 (Thirty Four)
Release:34
uname -r
5.14.13-200.fc34.x86_64
dkms -V
dkms-2.8.6
gcc --version
gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)
BIOS is fully updated; secure boot's disabled
mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode
build, as per my usual, is with upstream's `nvidia-installer`,
F="NVIDIA-Linux-x86_64-470.74-no-compat32"
wget
http://http.download.nvidia.com/XFree86/Linux-x86_64/470.74/${F}.run
chmod +x ${F}.run
./${F}.run --extract-only
cd ${F}/
dkms status -m nvidia --all
(empty)
./nvidia-installer --expert \
--dkms \
--accept-license \
--ui=none \
--no-questions \
--disable-nouveau --no-nouveau-check \
--no-check-for-alternate-installs \
--no-distro-scripts \
--force-selinux=no \
--no-systemd \
--no-install-compat32-libs \
--no-install-libglvnd \
--no-cc-version-check \
--no-precompiled-interface
which FAILs @ `modprobe`
...
Searching for conflicting files:
Searching: [##] 100%
Installing 'NVIDIA Accelerated Graphics Driver for Linux-x86_64'
(470.74):
Installing: [##] 100%
Driver file installation is complete.
Installing DKMS kernel module:
Adding to DKMS: [##] 100%
ERROR: Unable to load the 'nvidia-drm' kernel module: 'modprobe: ERROR:
could not insert 'nvidia_drm': Exec format error'
ERROR: Installation has failed. Please see the file
'/var/log/nvidia-installer.log' for details. You may find suggestions
on fixing installation problems in the README available on the
Linux driver download page at www.nvidia.com.
and
dmesg
...
[13680.181756] module: x86/modules: Skipping invalid relocation
target, existing value is nonzero for type 1, loc 5a6a71ea, val
c1979de7
and a not-particularly-helpful,
cat /var/log/nvidia-installer.log
-> Executing: /usr/sbin/ldconfig
executing: '/usr/sbin/ldconfig'...
-> done.
-> Driver file installation is complete.
-> Installing DKMS kernel module:
-> done.
ERROR: Unable to load the 'nvidia-drm' kernel module:
'modprobe: ERROR: could not insert 'nvidia_drm': Exec format error'
ERROR: Installation has failed. Please see the file
'/var/log/nvidia-installer.log' for details. You may find suggestions on
fixing installation problems in the README available on the Linux driver
download page at www.nvidia.com.
the mods *are* built
cd /var/lib/dkms/nvidia/kernel-5.14.13-200.fc34.x86_64-x86_64/module/
treev
├── [-rw-r--r-- root 24048 2021-10-23 18:18:00 -0400]
nvidia-drm.ko.xz
├── [-rw-r--r-- root23785248 2021-10-23 18:17:59 -0400]
nvidia.ko.xz
├── [-rw-r--r-- root 515764 2021-10-23 18:18:00 -0400]
nvidia-modeset.ko.xz
├── [-rw-r--r-- root 996 2021-10-23 18:18:00 -0400]
nvidia-peermem.ko.xz
└── [-rw-r--r-- root 342256 2021-10-23 18:17:59 -0400]
nvidia-uvm.ko.xz
and installed in module tree
find /lib/modules/5.14.13-200.fc34.x86_64/ | grep extra/nvidia.*ko
/lib/modules/5.14.13-200.fc34.x86_64/extra/nvidia-drm.ko.xz
/lib/modules/5.14.13-200.fc34.x86_64/extra/nvidia-peermem.ko.xz
/lib/modules/5.14.13-200.fc34.x86_64/extra/nvidia.ko.xz
/lib/modules/5.14.13-200.fc34.x86_64/extra/nvidia-modeset.ko.xz
/lib/modules/5.14.13-200.fc34.x86_64/extra/nvidia-uvm.ko.xz
but aren't insertable
lsmod | grep nvidia
(emtpy)
modinfo nvidia-drm
filename:
/lib/modules/5.14.13-200.fc34.x86_64/extra/nvidia-drm.ko.xz
version:470.74
supported: external
license:MIT
srcversion: CBB4EE4C99F37AD0FDDB887
alias: pci:v10DEd*sv*sd*bc03sc02i00*
alias:
Re: Fedora Java: The Death of Two SIGs
So if you only rely in things like OpenJDK (like for running Minecraft, as I do, too), then you'll be fine. If you need ant or maven, you should be fine too, since those two (and their dependencies) will continue to be maintained. But everything else ... *tumbleweeds* Just one user's snapshot; On a not-atypical dev-box here, installed java apps are PHPStorm (upstream snap) IntelliJ* (upstream snap) Eclipse (upstream tarball) DBeaver-CE (upstream rpm) android-studio (upstream) In dev-user cases, any additional 'needed' apps are typically getting installed from upstreams -- as tarballs, snaps, flatpaks, or rpms. Seldom, if ever, from Fedora pkgs. and pkgs rpm -qa | egrep -i "java|jdk|mvn|maven" | sort copy-jdk-configs-4.0-1.fc34.noarch java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 java-11-openjdk-devel-11.0.12.0.7-4.fc34.x86_64 java-11-openjdk-headless-11.0.12.0.7-4.fc34.x86_64 java-latest-openjdk-17.0.0.0.35-1.rolling.fc34.x86_64 java-latest-openjdk-devel-17.0.0.0.35-1.rolling.fc34.x86_64 java-latest-openjdk-headless-17.0.0.0.35-1.rolling.fc34.x86_64 javapackages-filesystem-5.3.0-15.fc34.noarch javapackages-tools-5.3.0-15.fc34.noarch maven-3.6.3-8.fc34.noarch maven-archiver-3.5.1-1.fc34.noarch maven-artifact-2.2.1-67.fc34.noarch maven-artifact-transfer-0.11.0-5.fc34.noarch maven-common-artifact-filters-3.1.1-1.fc34.noarch maven-compiler-plugin-3.8.1-8.fc34.noarch maven-dependency-tree-3.0.1-6.fc34.noarch maven-doxia-core-1.9.1-4.fc34.noarch maven-doxia-logging-api-1.9.1-4.fc34.noarch maven-doxia-module-apt-1.9.1-4.fc34.noarch maven-doxia-module-fml-1.9.1-4.fc34.noarch maven-doxia-module-xdoc-1.9.1-4.fc34.noarch maven-doxia-module-xhtml-1.9.1-4.fc34.noarch maven-doxia-module-xhtml5-1.9.1-4.fc34.noarch maven-doxia-sink-api-1.9.1-4.fc34.noarch maven-doxia-sitetools-1.9.2-4.fc34.noarch maven-file-management-3.0.0-12.fc34.noarch maven-filtering-3.2.0-2.fc34.noarch maven-jar-plugin-3.2.0-5.fc34.noarch maven-lib-3.6.3-8.fc34.noarch maven-model-2.2.1-67.fc34.noarch maven-plugin-bundle-4.2.1-4.fc34.noarch maven-reporting-api-3.0-21.fc34.noarch maven-resolver-api-1.4.2-5.fc34.noarch maven-resolver-connector-basic-1.4.2-5.fc34.noarch maven-resolver-impl-1.4.2-5.fc34.noarch maven-resolver-spi-1.4.2-5.fc34.noarch maven-resolver-transport-wagon-1.4.2-5.fc34.noarch maven-resolver-util-1.4.2-5.fc34.noarch maven-resources-plugin-3.2.0-2.fc34.noarch maven-shared-incremental-1.1-21.fc34.noarch maven-shared-io-3.0.0-12.fc34.noarch maven-shared-utils-3.2.1-0.8.fc34.noarch maven-source-plugin-3.2.1-4.fc34.noarch maven-surefire-3.0.0~M4-1.fc34.noarch maven-surefire-plugin-3.0.0~M4-1.fc34.noarch maven-surefire-provider-junit-3.0.0~M4-1.fc34.noarch maven-toolchain-2.2.1-67.fc34.noarch maven-wagon-file-3.4.2-1.fc34.noarch maven-wagon-http-3.4.2-1.fc34.noarch maven-wagon-http-shared-3.4.2-1.fc34.noarch maven-wagon-provider-api-3.4.2-1.fc34.noarch system-switch-java-1.1.8-5.fc34.noarch tzdata-java-2021a-1.fc34.noarch xz-java-1.8-10.fc34.noarch everything ELSE gets built locally -- either per-machine, or on our in-house distro/pgg'ing -- as needed. similarly, on not-atypical non-dev end-user around here, rpm -qa | egrep -i "java|jdk|mvn|maven" | sort copy-jdk-configs-4.0-1.fc34.noarch java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 java-11-openjdk-devel-11.0.12.0.7-4.fc34.x86_64 java-11-openjdk-headless-11.0.12.0.7-4.fc34.x86_64 java-latest-openjdk-17.0.0.0.35-1.rolling.fc34.x86_64 java-latest-openjdk-devel-17.0.0.0.35-1.rolling.fc34.x86_64 java-latest-openjdk-headless-17.0.0.0.35-1.rolling.fc34.x86_64 javapackages-filesystem-5.3.0-15.fc34.noarch javapackages-tools-5.3.0-15.fc34.noarch system-switch-java-1.1.8-5.fc34.noarch tzdata-java-2021a-1.fc34.noarch and that's mostly it. And again, in _some_ end-user cases, any 'needed' end-user apps are getting installed from upstreams -- as tarballs, snaps, flatpaks, or rpms. Seldom, if ever, from Fedora
Re: Fedora Java: The Death of Two SIGs
Many valid/interesting points being made. Most of them sound, reasonably, like developer-/maintainer-centric issues. Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 'service' its (java app) users? If so, what's the current understanding of a user-driven ProductRequirements spec'n of JAVA apps 'round here? Who's included in "users"? Developers? End-users? etc. Perhaps I've missed it ... I know as a representative of my end-users I've got plenty of opinions about our JAVA env. Also as a representative of my org's JAVA devs. But as a developer/maintainer OF java/apps @ Fedora, not much at all; the "solid OpenJDK & Maven" approach is good enuf here. Mostly. And, if that^ is not a primary goal, then back to the discussion at hand. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: FF builds
On 9/9/21 14:22, Neal Gompa wrote: On Thu, Sep 9, 2021 at 2:06 PM PGNet Dev wrote: On 9/9/21 13:53, Florian Weimer wrote: Can the Firefox build be distributed among multiple machines? I frequently deploy FF from upstream builds, with updates managed from within the app. Q: Is there any historical _measure_ of security issues fixed in @Fedora FF pkgs, before upstream gets around to fixing them? Considering that Fedora Firefox packages don't bundle as much as Mozilla's Firefox bundles do, I would say yes. We fix issues all the time in its dependency graph at a much faster pace than Mozilla does. noted. never gave it a sufficient, closer look. yet. tgif. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: FF builds
On 9/9/21 13:53, Florian Weimer wrote: Can the Firefox build be distributed among multiple machines? I frequently deploy FF from upstream builds, with updates managed from within the app. Q: Is there any historical _measure_ of security issues fixed in @Fedora FF pkgs, before upstream gets around to fixing them? ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: pdftk retired?
On 9/8/21 06:28, Sérgio Basto wrote: I think the gui of pdftk that I used is pdfchain, I also built pdfchain in my copr repo [3] , if both packages works well I can unretire them . Thank you fyi, here on f34 dnf install bouncycastle rpm -Uvh \ https://download.copr.fedorainfracloud.org/results/sergiomb/builds_for_Stable_Releases/fedora-34-x86_64/02684742-pdfchain/pdfchain-0.4.4.2-1.fc34.x86_64.rpm \ https://download.copr.fedorainfracloud.org/results/sergiomb/builds_for_Stable_Releases/fedora-34-x86_64/02680106-pdftk/pdftk-3.3.1-1.fc34.noarch.rpm launches fine https://i.imgur.com/NSzerXU.png and appears to function well on initial/simple tests to concat/explode files via GUI ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On 6/24/21 6:40 AM, Miro Hrončok wrote: On 24. 06. 21 11:16, Tomas Tomecek wrote: ## Choosing git forge to host source-git repositories We need to find a home for all the source-git repositories. This is actually a really hard task because we have many options (github.com, gitlab.com, pagure.io, src.fedoraproject.org, something custom or on-premise) and different expectations: some projects already have repos set up on different platforms while Pagure is the primary forge now. Since the CPE team is investigating GitLab as a forge, it's even harder for us to figure out the primary forge. We may end up supporting both actually: pagure.io and gitlab.com. What are your thoughts on this topic? Would you prefer pagure.io or gitlab.com More info: * https://pagure.io/fedora-source-git/sig/issue/1 * https://pagure.io/fedora-source-git/sig/issue/7 Indirectly related: my scm-sourced COPR projects often pull from git repos (upstream @ Fedora src projects), and use forgemeta macros in rpm config. ime, forgemeta had lots of issues in the past with gitlab source matching when pulling specific tags/commits, requiring customized source strings -- usually after a bunch of trial-n-error. github & pagure had no such problems. to work around the challenges, I 1st mirrored gitlab repos to pagure, then pulled from there in my COPR specs, originally specifying commits/tags. I haven't revisited gitlab for a fairly long while to check again. Neither have I tested forgemeta's newer support for packaging a branch state https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_branch_example which is now available, stable & terribly convenient -- for github & pagure. TL;DR in this particular case: as long as it plays nicely with COPR forgemeta source-reference macros, no preference ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: x86_64-v2 in Fedora
On 6/18/21 1:42 AM, Mark Otaris wrote: For Fedora, linux-hardware.org says 78% use EFI and 16% have Secure Boot enabled. Not a very good data set, though Fedora telemetry wouldn’t be either. Of ~ 1K linux boxes in my env -- bare metal & VM, servers & desktops -- ~ 550 are now running fully updated F34. Of those, ~ 95% are AMD; remainder are Intel. No ARM. Of the total, per a quick survey, ~ 15% have _no_ avx/avx2 support ~ 40% have avx-only support rest have avx/avx2 support NONE of the no-avx or avx-only machines are "suffering" from any performance problems for their current business/technical usage. Here, the 1st response to "my OS suddenly no longer supports this hardware" will seldom-if-ever be to replace the hardware. At best, I'll freeze the machine's s/w base @ last-supported, and look to replace the OS. There are real/significant costs to H/W upgrade/replacement -- both capital & expense; Planning & budgeting for them is often on a multi-year timeframe. Particularly at scale. And my env is relatively quite small on the global stage. This seemingly endless stream of drop-the-old-hardware discussions, even if reasonable for some, is a cause for tangible concern that I've gotten myself into a tactical, eggs-in-one-basket mess. Again. With RockyLinux today at GA, time to explore/compare a 'plan B' & whether it provides some differently sensible support planning. Or whether YA-x-distro firedrill is inevitable. ( "fun fact" for me: my own laptop that sits ~ 3 ft from me as I type this, serves as my diagnostic/troubleshooting box on my LAN, and when traveling, obviously falls into the currently discussed 'decrepit' pile, lacking modern flags egrep "model name|flags" /proc/cpuinfo | head -n2 model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm arat flush_l1d but _very_ capably runs lsb_release -rd Description:Fedora release 34 (Thirty Four) Release:34 uname -rm 5.12.11-300.fc34.x86_64 x86_64 with KDE 5.82.0 / Plasma 5.21.5 and, although I don't use, or plan to use, it as a networked build farm anytime soon ... bind9 certainly builds from source well enough on it; though, admittedly, takes awhile. ) ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
one of the more important trusts we place in the parties in question is to protect the privacy of tens of thousands of *other* people's private conversations. Sure. As do we all. Mostly. Kind of. Ok, hopefully. Again, to _my_ read, _I_ see absolutely nothing in either side's recent behavior that builds _my_ trust. And sufficient cause for it to be called into some question. By _me_. If privacy of _credentials_ are in question, again, there's nothing but assumptions here. Unless/until _I_ see provable behavior, contractual accountability, and auditable infrastructure, _I_ remain ... diligent. If privacy of _discussions_ are in question, then #IRC isn't the right platform to start with. At all. And arguing about who's more trustworthy in managing privacy in an infra with the general leak-proofing of a pasta colander, is simply circular-debate about the color of the lipstick on the pig. Paraphrasing the old adage -- takes a lifetime to build a rep, 5 seconds to lose one. BOTH sides have lost trust & rep. In the end, I'm not convinced it was worth the "pantscon 1" (chuckle) hullabaloo, and wait to see if more harm than good comes of it. So thought I'd add/share a doc or 2 to read. /me is really shutting up now. About this, anyway. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
due specifically to Andrew Lee's actions. I'd bet $0.05 and a half-eaten donut that most folks shrieking about this would be hard-pressed to regurgitate much of anything beyond 'headlines', with little actual insight into objective details. But then, I'm often wrong. Now, back to real work for me. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
Andrew Lee has a flexible relationship with the truth. This is not a both sides issue, as every other free software project has also agreed. Well, it seems you're good then. So, great. Just for me, not my 1st rodeo dealing with the spectrum from megalomaniacal-sociopathic-CEOs to petulant-lemming-staff-actions And, like I said, to my read, not so clear cut, despite declarations that "This is not a both sides issue". I just shared some add'l info that I thought was relevant so folks could read a bit (more) & make their OWN decisions rather than just blindly do what (arguably) "every other free software project" is doing. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On 5/28/21 12:14 PM, Adam Williamson wrote: On Fri, 2021-05-28 at 12:01 -0400, PGNet Dev wrote: On 5/27/21 2:04 PM, Nick Bebout wrote: Since its beginnings, the Fedora Project has used the freenode IRC network for our project communications. Due to a variety of recent changes to that network, the Fedora Project is moving our IRC communications to Libera.Chat. If a still-fuzzy "variety of recent changes to that network" are the reason for this latest fire-drill/tempest, then just fyi, A Lee's provided some documented reply, https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf https://freenode.net/news/post-mortem-may21 To my read it doesn't seem as clear-cut as some are making it all out to be. If 'trust' is the underlying issue here, there seems to be enuf not passing the smell test on 'both sides'. IME, projects want a place to talk that's trustworthy. Freenode has also shut down every channel that posted a libera.chat link in its topic. That's not very 'trustworthy'. This happened to multiple Fedora-related projects/channels, including #cockpit , for instance. Sure. And, what? Not the 1st time projects have acted on "don't talk about other projects in here" ... Did anyone try to contact @freenode about that? I certainly dunno about that. Maybe so, maybe not. Just reading through those screenshotted chats, etc, seems 2 me there's enough "shouldn't have handled it that way" to go around. I'm not 'defending' _any_ purile/petty/powermad/etc. BS. I'm jut fyi'ing here, in the hopes that folks will make / have made an informed decision -- and pick-their-poison, and not simply to the lemmings-off-a-cliff biz cuz, "hey, it's the new hotness". If it's all thoroughly researched, understood, and rationally decided, then I'm certainly cool with it. All _I_ heard was some buzz in #fedora* @ freenode a week or so back that "moving fast/immediately is too hard, and would be too disruptive to users", and then suddenly, this^^ email. Beyond that, not a clue as to what discussion was had. Not that it's "my project" to begin with, so few expectations 'bout that in the 1st place. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC Announcement
On 5/27/21 2:04 PM, Nick Bebout wrote: Since its beginnings, the Fedora Project has used the freenode IRC network for our project communications. Due to a variety of recent changes to that network, the Fedora Project is moving our IRC communications to Libera.Chat. If a still-fuzzy "variety of recent changes to that network" are the reason for this latest fire-drill/tempest, then just fyi, A Lee's provided some documented reply, https://raw.githubusercontent.com/freenode/web-7.0/main/static/files/on-freenode.pdf https://freenode.net/news/post-mortem-may21 To my read it doesn't seem as clear-cut as some are making it all out to be. If 'trust' is the underlying issue here, there seems to be enuf not passing the smell test on 'both sides'. IME, projects want a place to talk that's trustworthy. caveat emptor. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
On 5/27/21 10:45 AM, Nikolay Nikolov wrote: That is quite a painful process. And how do you do that on a MBR system that dual boots Fedora and Windows 10? I really don't want to go through the pain of reinstalling Windows and all the programs that I have there. There's no migration path that doesn't have some (eventual) pain. And that includes not migrating. A useful place to start is a thorough read of https://opensource.com/article/19/5/dual-booting-windows-linux-uefi https://www.maketecheasier.com/convert-legacy-bios-uefi-windows10/ , considering what exactly your system supports (gpt, efi, etc.), and identifying where you want to end up. I don't migrate hardware until it's demonstrated to make technical & business sense. We've *lots* of legacy-bios/MBR hardware that's perfectly serviceable with either/both modern linux / windows. "It's bright & shiny" isn't a valid argument for change here. Any _software_ that forces unnecessary cost on the ecosystem, including dropping BIOS support or generally breaking stable user-space, will get removed from the picture. Or, at least, _very_ marginalized/compartmentalized. Personally I'm banking on the 'old, wise hats' @ distro here to prevent making foolish choices. So far, so good. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
the assumption that all of those several million
people will want to print from anything with a CPU ("whatever computing
devices one uses") or that that is even the common case.
There's been no assumption that "all" want any-one-thing.
As for common, print-from-any-device-you-use is common here, with ~ 1K
'in-house' users, and easily-dozens-per-day of 'guests'.
That's FAR more common than your 'objection' to it.
As has been said repeatedly here -- paraphrasing, "different strokes for different
folks".
If the developers think its important to support their user-base, what are you
objecting to?
___
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 4:47 PM, Solomon Peachy wrote: But disabling mDNS altogether might cause undesired regerssions elsewhere. Sure. Particularly if you don't set up your /etc/nsswitch.conf correctly. Hence the 'YMMV'. In general, we assume zero-trust and avoid enabling auto-anything. We add trust and loosen constraints, cautiously, when said 'regressions elsewhere' absolutely demand it. Avoids the 'fun' of accidentally exposing a printer queue in the CEOs office ;-) ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 4:28 PM, Björn Persson wrote: You have always had (and always will) have that choice; the ability to disable automatic printer discovery has been present since discovery was added with CUPS 1.2 (released back in 2006!) I'll have to see if I can find that option. Thanks for the hint. fyi, also useful, man cups-browsed here, I systemctl disable cups-browsed systemctl disable avahi-daemon setup printers @ dhcp/dns explicitly, and avoid autodiscovery 'surprises' altogether. ymmv. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Endless theoretical discussions ... Interesting, but _is_ there real-world, end-user doc available for installing and using papp-et-al on Fedora, today? A "do this now" for end users? TBH, I'm unclear (and no, I haven't gone digging ...) Here, I've got hundreds of networked printers. _Many_ of them old warhorses. E.g., ~ 50 HP LaserJet 4050n. Slow, but incredibly reliable. Unlike the modern 'options' from HP, made cheaply overseas, prone to breakage, and locked down with print-cartridge DRM, these 4050s have outlasted virtually every desktop & server we have, and quite a number of staff as well, and 3rd party parts & cartridges abound. CUPS 2.3.3op2 runs on virtually every Fedora desktop here, in addition to quite a few of the servers. For the 4050s, the drivers are all 'HP LaserJet 4050 Series pcl3, hpcups 3.19.6 (color, 2-sided printing)', and the connections are "socket://static.i.p.address". The PPDs are older than dirt, *PPD-Adobe: "4.3" * PPD file for HP LaserJet 4050 Series with CUPS. * Created by the CUPS PPD Compiler CUPS v1.5.0. *% (c) 2008 Copyright HP Development Company, LP *FormatVersion: "4.3" *FileVersion: "3.19.6" ... and work flawlessly. Admittedly, PS drivers are buggy-to-useless, and NONE of the "toner level" reporting seems attached to reality in any way. Neither, for me, has been a concern. Same holds generally true for all other networked printers, with the exception of some of high-volume/color machines that bundle their own raster/spool/networking/etc. If any of that^^ ceases to function, then that'll be a problem. Personally, I'm not the slightest bit interesting in wasting time/money replacing what work s well *AND* losing capbility for the sake of the next bringh-n-shiny OTOH, If papp-future _at_the_very_least_ maintains that^^ functionality through legacy wrappers, then I have zero concerns. Additional features/functionality are welcome gravy. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On 5/14/21 2:05 AM, Juha Tuomala wrote: here, Sure. But this is devel list. Are developers themselves the target audience? :) Hopefully not. Is it defined somewhere? by 'here', I meant my company environment, not just this list. and, yes, 'developers themselves' -- again, "here" -- *are* a target audience. their usage of OS installs, whether VM or baremetal, is far higher than end-users'. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 pkg.spec rpmbuild OK on local dev; same spec fails @ my COPR. why?
hi,
On 5/13/21 6:06 PM, Sérgio Basto wrote:
mock -r fedora-34-x86_64 --rebuild
lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212639.fc34.src.rpm
also fails in my machine, %forgesetup -z 0 is where it fails
hm. whereas a non-isolated, local rpmbuild works, as per my OP,
a *mock* build here fails similarly to @ COPR:
wget
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-34-x86_64/02184528-lua-resty-luajit2/lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212639.fc34.src.rpm
mock \
-r fedora-34-x86_64 \
--rebuild \
--addrepo=https://download.copr.fedorainfracloud.org/results/pgfed/pgnd-rpmbuild-macros/fedora-34-x86_64
\
./lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212639.fc34.src.rpm
...
Packaging variables read or set by %forgemeta
forgeurl0: https://github.com/openresty/luajit2
forgesource0:
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
forgesetupargs0: -n luajit2-2.1-agentzh
archivename0: luajit2-2.1-agentzh
archiveext0: tar.gz
archiveurl0:
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
topdir0: luajit2-2.1-agentzh
extractdir0: luajit2-2.1-agentzh
repo0: luajit2
scm0: git
branch0: v2.1-agentzh
distprefix0: .20210513gitv2.1-agentzh
dist: .20210513gitv2.1-agentzh.fc34
(snapshot date is either manually supplied or computed once
%{_sourcedir}/%{archivename0}.%{archiveext0} is available)
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.9O1tue
+ umask 022
+ cd /builddir/build/BUILD
+ cd /builddir/build/BUILD
+ rm -rf luajit2-2.1-agentzh
+ /usr/bin/gzip -dc /builddir/build/SOURCES/luajit2-2.1-agentzh.tar.gz
+ /usr/bin/tar -xof -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd luajit2-2.1-agentzh
/var/tmp/rpm-tmp.9O1tue: line 38: cd: luajit2-2.1-agentzh: No such file
or directory
RPM build errors:
error: Bad exit status from /var/tmp/rpm-tmp.9O1tue (%prep)
Setting %{branch} = v2.1-agentzh
Setting %{forgeurl0} = https://github.com/openresty/luajit2
Setting %{fileref0} = 2.1-agentzh
Setting %{ref0} = v2.1-agentzh
Setting %{archivename0} = %{repo0}-2.1-agentzh
Setting %{archiveext0} = tar.gz
Setting %{archiveurl0} =
https://github.com/openresty/luajit2/archive/v2.1-agentzh/%{repo0}-2.1-agentzh.tar.gz
Setting %{scm0} = git
Setting %{topdir0} = %{repo0}-2.1-agentzh
Setting %{repo0} = luajit2
Setting %{forgesource0} =
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
Setting %{forgesetupargs0} = -n %{extractdir0}
Setting %{extractdir0} = luajit2-2.1-agentzh
Setting %{distprefix0} = .20210513gitv2.1-agentzh
Setting %{forgesource} =
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
Setting %{forgesetupargs} = -n luajit2-2.1-agentzh
Setting %{archivename} = luajit2-2.1-agentzh
Setting %{archiveext} = tar.gz
Setting %{archiveurl} =
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
Setting %{topdir} = luajit2-2.1-agentzh
Setting %{extractdir} = luajit2-2.1-agentzh
Setting %{repo} = luajit2
Setting %{scm} = git
Setting %{distprefix} = .20210513gitv2.1-agentzh
Bad exit status from /var/tmp/rpm-tmp.9O1tue (%prep)
Finish: rpmbuild
lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212639.fc34.src.rpm
Finish: build phase for
lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212639.fc34.src.rpm
ERROR:
Exception(./lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212639.fc34.src.rpm)
Config(fedora-34-x86_64) 0 minutes 19 seconds
INFO: Results and/or logs in: /home/mock/resultdir
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
Finish: clean chroot
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M a5a65f56173f44919d9e4890b40b3e55 -D
/var/lib/mock/fedora-34-x86_64/root -a -u mockbuild --capability=cap_ipc_lock
--bind=/dev/btrfs-control --bind=/dev/loop-control --bind=/dev/loop0 --bind=/dev/loop1
--bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4 --bind=/dev/loop5 --bind=/dev/loop6
--bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11
--console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir
--setenv=HOSTNAME=mock
F34 pkg.spec rpmbuild OK on local dev; same spec fails @ my COPR. why?
I've a package .spec, that uses forgemeta macros, that builds locally just fine
on F34.
Same spec @ COPR, F34 chroot, fails.
Something's either missing on my end, or broken @COPR. Likely obvious pebkac,
but I'm not seeing it.
Any insights as to why the same spec, @COPR, is failing would be appreciated.
With this spec,
cat ~/rpmbuild/SPECS/lua-resty-luajit2.spec
---
%{?_pgnd_macros}
%define _owner pgnd
%define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S --utc )
%define _lua_resty_luajit2_name lua-resty-luajit2
%define _lua_resty_luajit2_comment OpenResty's
maintained branch of LuaJIT
%define _lua_resty_luajit2_checkout_dirname luajit2
%define _lua_resty_luajit2_branch v2.1-agentzh
%define _lua_resty_luajit2_shortbranch HEAD
%define compat_lua_ver 5.1
%define compat_lua_ext 5.2
%global forgeurl0 https://github.com/openresty/luajit2
%global branch0 %{_lua_resty_luajit2_branch}
%forgemeta -i -v -a
%global dist .%{_owner}_%{_build_timestamp}.fc%{fedora}
Name: %{_lua_resty_luajit2_name}
Version: %{scm0}.%{_lua_resty_luajit2_shortbranch}
Release: 0%{?dist}
Summary: %{_lua_resty_luajit2_comment}
License: MIT
URL: %{forgeurl0}
Source0: %{forgesource0}
BuildRequires: compat-lua
BuildRequires: compat-lua-devel
BuildRequires: coreutils
BuildRequires: gcc
BuildRequires: git
BuildRequires: gzip
BuildRequires: openssl-devel
Requires: compat-lua >= %{compat_lua_ver}
Requires: compat-lua < %{compat_lua_ext}
Requires: compat-lua-devel >= %{compat_lua_ver}
Requires: compat-lua-devel < %{compat_lua_ext}
Requires: openssl
Requires: gzip
Requires: unzip
Requires: zip
Provides: %{_lua_resty_luajit2_name}
Conflicts: luajit
Conflicts: luajit-devel
%description
%{_lua_resty_luajit2_comment}
%prep
%forgesetup -z 0
%build
perl -pi -e '\
s|^(export PREFIX=).*|${1}
/usr/local/%{_lua_resty_luajit2_name}|g; \
s|^(export MULTILIB=).*|${1} lib64|g' \
Makefile
make %{?_smp_mflags}
%install
make DESTDIR=%{buildroot} install
%post
%preun
%files
/usr/local/%{_lua_resty_luajit2_name}/
%changelog
---
a local build
cd ~/rpmbuild/SPECS/
rpmbuild -bb ./lua-resty-luajit2.spec
builds OK, no error
...
Packaging variables read or set by %forgemeta
forgeurl0: https://github.com/openresty/luajit2
forgesource0:
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
forgesetupargs0: -n luajit2-2.1-agentzh
archivename0: luajit2-2.1-agentzh
archiveext0: tar.gz
archiveurl0:
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
topdir0: luajit2-2.1-agentzh
extractdir0: luajit2-2.1-agentzh
repo0: luajit2
scm0: git
branch0: v2.1-agentzh
distprefix0: .gitv2.1-agentzh
dist: .gitv2.1-agentzh.fc34
(snapshot date is either manually supplied or computed once
%{_sourcedir}/%{archivename0}.%{archiveext0} is available)
warning: Downloading
https://github.com/openresty/luajit2/archive/v2.1-agentzh/luajit2-2.1-agentzh.tar.gz
to /root/rpmbuild/SOURCES/luajit2-2.1-agentzh.tar.gz
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.2DphWx
...
Wrote:
/root/rpmbuild/RPMS/x86_64/lua-resty-luajit2-git.HEAD-0.pgnd_20210513_212124.fc34.x86_64.rpm
the resultant rpm's install-/use-able
pushing the same spec to COPR, fails @ %prep
@,
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-34-x86_64/02184528-lua-resty-luajit2/builder-live.log.gz
Packaging variables read or set by %forgemeta
forgeurl0: https://github.com/openresty/luajit2
Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On 5/13/21 10:48 AM, Juha Tuomala wrote: Virtual machine installation is hopefully a special use case and majority of installations are bare metal end users. hardly. here, for any given single bare-metal install, between cloud & local VMs, there are typically *many*/*frequent* VM installs -- of all shapes-n-sizes. it's FAR more frequent (among devs/ops, even some end-users) than bare-metal installs. a bog-simple, not-uncommon workflow is: launch VirtualBox, drop in an OS iso, run the UI install. for that, a simple password option is more than sufficient. again, why not simply 'leave it be'. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Drop the the "Allow SSH root login with password" option from the installer GUI (Self-Contained Change proposal)
On 5/13/21 10:09 AM, Richard W.M. Jones wrote: Not everyone is installing a public facing server. On my isolated, non-networked test instances I want to put up a short-lived VM with a root password of "123456" quickly and no user account, and this option lets me do that. this^^ is a _very_ frequent use case here, as well. it's been mentioned, and seconded b4. i'll do it again: +10 'use kickstart' isn't a simplifying solution. 'leave it be', otoh, is. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On 5/1/21 8:02 PM, Chris Adams wrote: Once upon a time, PGNet Dev said: my $0.02 leave the root via password option, but simply DISABLE it by default, rather than REMOVING it. That's what is going to happen - the openssh-server package will follow upstream default (PermitRootLogin without-password), and Anaconda will drop the option of changing the sshd config. Sry, I meant _leave_ the *option* in Anaconda, but just ensure it's toggled OFF by default ( if that's not what it already does). But that's me. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On 5/1/21 7:23 PM, patra...@gmail.com wrote: On 4/30/21 10:23 AM, Richard W.M. Jones wrote: +1 in addition to, e.g., an _initial_ setup on a remote/headless box at a VPS. Ubuntu Server installer handles this in a very nice way by allowing to import SSH keys from a GitHub account given a username, i.e. via an URL like this: https://github.com/patrakov.keys . Maybe it's a good idea to implement the same feature in Anaconda? this is all getting too complicated. my $0.02 leave the root via password option, but simply DISABLE it by default, rather than REMOVING it. let admins worry about SSH keys. the 'rest' can be handled, as mentioned, with kickstart/ansible ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On 4/30/21 10:23 AM, Richard W.M. Jones wrote: Because distributing SSH keys to temporary VMs is hard? Not everything is a long-lived machine connected to the internet. +1 in addition to, e.g., an _initial_ setup on a remote/headless box at a VPS. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
OFFLIST Re: Call for testing: nginx 1.20.0 with permission changes on logs
Hi, OFFLIST as it's not directly pertinent to your specific distro pkgs. but, since you're packaging, fwiw, I take a very different approach than distro-pkgd atm, https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-33-x86_64/02142389-nginx/nginx.spec that puts runtime service files under /run/nginx and logs under /var/log/nginx, both chown'd as wwwrun:www. personally, I find it a lot cleaner, easier to manage. my $0.02, anyway. that said, I'm very clear 'my' pkg'ing is not even close to release canonical ... i.e., just fyi. On 4/21/21 1:25 PM, Felix Kaechele via devel wrote: Dear Fedorans, Nginx 1.20.0 stable was just released and I took the opportunity to squash some long standing open bugs while updating the package. The new release is on it's way to updates-testing right now. I would like to encourage some extra testing for this release as there is one behaviour change, specific to Fedora/EPEL, that may affect some use cases: The ownership and mode of the log directory has changed to root:root and 700 respectively. Logrotate (if in use) no longer creates the logfiles when rotating and leaves this to nginx which will create them as root:root-owned. This matches the behaviour of httpd in Fedora. You may see the effects of this if you are using external tools to process these logs that do not run as root, but as the nginx user instead. The bugs relating to this are: - BZ#1390183 CVE-2016-1247 nginx: Local privilege escalation via log files [fedora-all] - BZ#1683388 Log file ownership created by logrotate inconsistent with the one created by systemd In my local testing I have not seen any changes to behaviour but I would like to make extra sure everything continues to work as expected for users as this version of the package will make it's way to EPEL 7 as well to replace the EOL version of nginx that is currently packaged there. Quite a number of other bugs that I deem to have no effect on simple upgrades have made it's way into this release of the package as well. Specifically: - BZ#1565377 Service reload should check configuration file - BZ#1708799 Drop nginx requirement on nginx-all-modules - BZ#1834452 Enable --with-compat configure option - BZ#1869026 nginx.service fails to parse /run/nginx.pid - BZ#1943779 nginx.service wants wrong network target - causes race condition on boot Here are the links to Bodhi for this update. Please test these releases and provide feedback/karma. Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3aa9ac7fd1 Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-10c1cd4cba Fedora 32: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1556d440ba Thanks a ton! Regards, Felix ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 4/12/21 3:51 AM, Javier Martinez Canillas wrote: I dropped it by mistake when rebasing to 2.06, sorry about that. I've fixed it now in F33, F34 and Rawhide. i see rawhide has 'stable' already; and that F33/F34 are 'pending->testing'. thx! ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
Ordinarily, no. But in this case, since GRUB 2.06~rc1 is required to solve major critical vulnerabilities and it's very difficult to pull the patch set that fixes it (>115 patches!) backwards, GRUB got moved forward instead. GRUB 2.06~rc1 was pretty much released to release the patch set... got it. then will stick with v2.06, and try to get it re-patched for Xen @ the bug. thx. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
tangentially related ... distro update on f33 from grub 2.04-release -> 2.06-rc (re)breaks Xen boot on EFI. already reopened the original bug, but a question: is it normal/expected to push an *rc* (grub 2.06-rc, in this case), to 'supported' fedora (33) *release*? unreleased f34/rawhide I can understand. ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
If the /boot/loader/entries directory is exists, kernel-install will use it. systemd-boot cannot read configs from this directory. fyi, https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-1-boot-loader-specification-entries https://www.freedesktop.org/software/systemd/man/systemd-boot.html "During boot systemd-boot automatically assembles a list of boot entries from the following sources: Boot entries defined with Boot Loader Specification description files located in /loader/entries/ on the ESP and the Extended Boot Loader Partition. These usually describe Linux kernel images with associated initrd images, but alternatively may also describe arbitrary other EFI executables." ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Xen support dead?
Actually, the buggy file (/etc/grub.d/20_linux_xen) belongs to the grub2 package, so the bug is assigned to a wrong package. Not that it matters, but I'd originally assigned it to grub. It was ignored there as well. I switched it to Xen after I was told in #irc to do so. Too much pushing rocks uphill for my taste. Building my own. ___ 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
Re: Xen support dead?
On 2/5/21 8:13 AM, Neal Gompa wrote: On Fri, Feb 5, 2021 at 6:31 AM PGNet Dev wrote: Hm. Can't manage to get a fix, a reply, or interest. Is Xen packaging/support abandoned for Fedora? No. But the maintainer of Xen in Fedora doesn't pay attention to the devel@ mailing list. You can see it's actively maintained here: https://src.fedoraproject.org/rpms/xen/commits/rawhide One would hope that filed bugs would get addressed, then. But, not here. Fair enuf. Thx o/ ___ 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
Xen support dead?
Hm. Can't manage to get a fix, a reply, or interest. Is Xen packaging/support abandoned for Fedora? On 2/3/21 12:09 PM, PGNet Dev wrote: F33 on EFI + Xen delays 30+ seconds, sometimes hangs, on boot @ grub2 error, ... Loading Xen 4.14.1 ... error: ../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found. Loading Linux 5.10.9-201.fc33.x86_64 ... Loading initial ramdisk ... error: ../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found. ... It's been reported/closed/ignored since, at least, F27 ~ 2017, https://bugzilla.redhat.com/show_bug.cgi?id=1515694 https://bugzilla.redhat.com/show_bug.cgi?id=1858364 , and still occurs in current F33. Not clear where the fix _needs_ to be -- grub2 &/or Xen pkgs. But sed workarounds are a non-starter for production. Can appropriate devs help get this addressed? If not, that's fine too -- but can we at least get a clear statement that Xen@Fedoras's not going to be maintained, so we can make other arrangements? ___ 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
F27->F33 + EFI + Xen boot error: "../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found."
F33 on EFI + Xen delays 30+ seconds, sometimes hangs, on boot @ grub2 error, ... Loading Xen 4.14.1 ... error: ../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found. Loading Linux 5.10.9-201.fc33.x86_64 ... Loading initial ramdisk ... error: ../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found. ... It's been reported/closed/ignored since, at least, F27 ~ 2017, https://bugzilla.redhat.com/show_bug.cgi?id=1515694 https://bugzilla.redhat.com/show_bug.cgi?id=1858364 , and still occurs in current F33. Not clear where the fix _needs_ to be -- grub2 &/or Xen pkgs. But sed workarounds are a non-starter for production. Can appropriate devs help get this addressed? If not, that's fine too -- but can we at least get a clear statement that Xen@Fedoras's not going to be maintained, so we can make other arrangements? ___ 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
Re: COMMERCIAL - Bosch - Architect
And you're spamming MY 'private mailbox' now? Who made you the consumer police? Now, get lost, troll. On 1/27/21 11:01 AM, Marius Schwarz wrote: Am 27.01.21 um 16:53 schrieb PGNet Dev: And that somehow justifies 'notifying the legal department' as a 1st response? Yeap, because he spammed my private mailbox too. As an Ex-Bosch employe i know that Bosch is a good company, who won't tolerate spamming in their name and it was also a violation of customer protection laws in Germany. He can be happy, that it didn't go directly to the feds. How a about a public -1 now? Best regards, Marius ___ 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
Re: COMMERCIAL - Bosch - Architect
On 1/27/21 10:44 AM, Matthew Miller wrote: On Wed, Jan 27, 2021 at 03:32:33PM +, George Bastin wrote: I thought it was a public mailing list, I noted the subject was Commercial in the Header as stated on the Fedora Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines#Before_Posting_to_the_List Sure seems reasonable to a 1st read here. At best the 'Guidelines' lack clarity. That paragraph doesn't mean that the list can be used for general commercial messages. https://fedoraproject.org/wiki/Mailing_list_guidelines#Stay_on-topic still also applies. If this job posting is directly relevant to Fedora (rather than just "some people in Fedora may have relevant skills"), that should be directly called out. And that somehow justifies 'notifying the legal department' as a 1st response? However, going out of your way to try to sabotage another person’s livelihood is way out of line. +1 to that. ___ 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
Re: pkg build @ COPR succeeds for F32 chroot, FAILS for F33. .spec issue, or problem in buildenv?
On 1/16/21 12:35 PM, PGNet Dev wrote:
+ /usr/lib/rpm/brp-strip /usr/bin/strip
/usr/bin/strip: unable to copy file
'/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/sbin/dhcpcd';
reason: Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.3UY5yu (%install)
disabling stripping in the rpm spec by adding
%global __os_install_post %{nil}
per,
"Stripping Binary files in rpmbuild
"
https://livecipher.blogspot.com/2012/06/disable-binary-stripping-in-rpmbuild.html
gets past the problem ... both F32 & F33 chroot target builds now succeed
https://copr.fedorainfracloud.org/coprs/pgfed/dhcpcd/build/1885367/
So that's a workaround.
As to _why_ strip has an issue on F33 chroot, dunno yet.
___
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
pkg build @ COPR succeeds for F32 chroot, FAILS for F33. .spec issue, or problem in buildenv?
I'm building a pkg @ COPR, 'dhcpcd',
https://copr.fedorainfracloud.org/coprs/pgfed/dhcpcd/build/1885349/
for both F32 & F33 chroot targets.
The F32 build succeeds, pkg installs & execs OK,
https://download.copr.fedorainfracloud.org/results/pgfed/dhcpcd/fedora-32-x86_64/01885349-dhcpcd/builder-live.log.gz
The concurrent F33 build, with same .spec, FAILs,
https://download.copr.fedorainfracloud.org/results/pgfed/dhcpcd/fedora-33-x86_64/01885349-dhcpcd/builder-live.log.gz
@
...
install -m 0444 dhcpcd-run-hooks.8
/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/share/man/man8
make[1]: Leaving directory
'/builddir/build/BUILD/dhcpcd-dhcpcd-9.4.0/hooks'
+ /usr/bin/mkdir -p
/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/etc/dhcpcd
+ find
/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64 -name
'*.la' -delete -print
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-ldconfig
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip /usr/bin/strip
/usr/bin/strip: unable to copy file
'/builddir/build/BUILDROOT/dhcpcd-9.4.0-0.pgnd_20210116_172904.fc33.x86_64/usr/local/dhcpcd/sbin/dhcpcd';
reason: Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.3UY5yu (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.3UY5yu (%install)
Finish: rpmbuild dhcpcd-9.4.0-0.pgnd_20210116_172845.fc33.src.rpm
Finish: build phase for dhcpcd-9.4.0-0.pgnd_20210116_172845.fc33.src.rpm
INFO: chroot_scan: 3 files copied to
/var/lib/copr-rpmbuild/results/chroot_scan
INFO:
/var/lib/mock/fedora-33-x86_64-1610818126.163401/root/var/log/dnf.rpm.log
/var/lib/mock/fedora-33-x86_64-1610818126.163401/root/var/log/dnf.librepo.log
/var/lib/mock/fedora-33-x86_64-1610818126.163401/root/var/log/dnf.log
ERROR:
Exception(/var/lib/copr-rpmbuild/results/dhcpcd-9.4.0-0.pgnd_20210116_172845.fc33.src.rpm)
Config(fedora-33-x86_64) 0 minutes 27 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
INFO: unmounting tmpfs.
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M 1e25f0a21cae4984b852a89713f1da74 -D
/var/lib/mock/fedora-33-x86_64-1610818126.163401/root -a -u mockbuild --capability=cap_ipc_lock
--rlimit=RLIMIT_NOFILE=10240 --capability=cap_ipc_lock
--bind=/tmp/mock-resolv.qfqx7vr9:/etc/resolv.conf --bind=/dev/btrfs-control --bind=/dev/loop-control
--bind=/dev/loop0 --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4
--bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8 --bind=/dev/loop9
--bind=/dev/loop10 --bind=/dev/loop11 --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
--setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
--setenv=PROMPT_COMMAND=printf "\033]0;\007"
--setenv=PS1= \s-\v\$ --setenv=LANG=C.UTF-8 --resolv-conf=off bash --login -c
/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/dhcpcd.spec
Copr build error: Build failed
So far, I've no idea what F33-chroot-specific issue is causing the problem,
whether something in my .spec, or in the COPR build env.
Any hints/suggestions as to the cause, and a fix?
___
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
status of 'dhcpcd' pkg builds ?
dhcpcd client pkgs @Fedora https://src.fedoraproject.org/rpms/dhcpcd are years out of date, currently versioned at Fedora 33 dhcpcd-6.11.3-11.fc33 Fedora 32 dhcpcd-6.11.3-10.fc32 as per comment, https://bugzilla.redhat.com/show_bug.cgi?id=1382961#c91 latest upstream version is 9.4.0 2020-12-28 14:05 (cref: https://release-monitoring.org/project/11429/) afaict, no response -- or recent activity -- from current maintainer. anyone have any further info/status on this pkg, or its maintainer? ___ 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
Re: unbound pkgs ?
On 12/4/20 3:08 AM, Matthias Runge wrote: otherwise, it's YA-trivial DIY build ... Thank you for looking into this. Since you already did the work, would you mind to propose a patch here, especially, if it's trivial? I'm asking abt non-response -- if the 'official' pkgs are maintained, or available elsewhere. For DIY, I'm not pkging it, I'm build locally from src. ___ 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
unbound pkgs ?
unbound upstream release version is now a 1.13 Fedora packages https://src.fedoraproject.org/rpms/unbound are several versions behind. no response from maintainer in months, re updates, @ https://bugzilla.redhat.com/show_bug.cgi?id=1860887 anyone know what's up with unbound pkgs status/plans/support in Fedora? otherwise, it's YA-trivial DIY build ... ___ 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
Re: VirtualBox pkgs for F33?
On 12/2/20 8:13 AM, Artem Tim wrote: Vbox also available in RPM Fusion repo https://admin.rpmfusion.org/pkgdb/package/free/VirtualBox/ Works OK in f33. Didn't know about those -- thx. Visit to the rpmfusion site returns: "Firefox does not trust koji.rpmfusion.org because its certificate issuer is unknown, the certificate is self-signed, or the server is not sending the correct intermediate certificates." Normal state of affairs? New issue? Poking around now ... ___ 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
VirtualBox pkgs for F33?
Is there an available/alternative option for VirtualBox repo installs on F33? Currently, http://download.virtualbox.org/virtualbox/rpm/fedora/ has only up to F32. This thread https://forums.virtualbox.org/viewtopic.php?f=7=100418 is the latest info I've found; atm, no pkgs, no timeline, and a Fedora+PulseAudio bug. Yes, DIY via shellscript install is, apparently, do-able ... I'm asking re: DNF-installable F33 packages, for end-users that would like to upgrade F32->F33 ___ 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
Re: Retiring ntp
On 11/2/20 9:22 AM, Neal Gompa wrote: Work migrated to Chrony a year or so ago. The only thing I use from ntp is the "ntpdate" tool. Everything else is chrony now. :) out of curiosity, what's lacking for your use case? ntpdate, here, was primarily for "set it now" interventions. that, at least, is easily done with chronyd -q 'server iburst' ___ 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
Re: The future of legacy BIOS support in Fedora.
On 10/19/20 11:33 AM, Hans de Goede wrote: I guess those machines are more or less the cut-off point and slower machines are not worth keeping around. But that means that there still are a ton of BIOS machines worth keeping around. Note that even most sandy bridge machines do not support UEFI and those machines are still very capable. I've got ~30 non-EFI Acer TimelineX Aspire 3820Ts, circa ~ 2009-10 still in 'production' across the enterprise. e.g., dmesg | grep DMI: [0.00] DMI: Acer Aspire 3820/JM31_CP, BIOS V1.19 10/27/2010 They currently run (recently migrated) grep _NAME /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" CPE_NAME="cpe:/o:fedoraproject:fedora:32" uname -rm 5.8.15-201.fc32.x86_64 x86_64 **ALL* have cat /proc/cpuinfo |grep "^model name" model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz , 8GB RAM free totalusedfree shared buff/cache available Mem:7806944 673488 3105532 102896 4027924 6733392 Swap: 8388604 0 8388604 , 500GB ssds, hwinfo --disk | grep Device: Device: "CT1000MX500SSD1" and run libreoffice-x11-6.4.7.2-1.fc32.x86_64 VirtualBox-6.1-6.1.14_140239_fedora32-1.x86_64 (Win10 guests) Firefox 81.0.2 Thunderbird 78.3.3 as well as java --version openjdk 15 2020-09-15 OpenJDK Runtime Environment 20.9 (build 15+36) OpenJDK 64-Bit Server VM 20.9 (build 15+36, mixed mode, sharing) a number run PhpStorm 2020.3 EAP Build #PS-203.4818.52, built on October 15, 2020 &/or Eclipse Platform Version: 2020-03 (4.15) Build id: I20200305-0155 My own manages nginx/php & mariadb quite nicely as well. Are these screamin' fast? Do they have 8K screens to play video games on? No. Of course not. But they are *perfectly* serviceable/functional; and that's just one model of 'oldies' around here. All that^ is _still_ more 'juice' than many a VPS ... what it requires to make old boxes 'serve well' is some due diligence on right-sizing your kernel/app/server/tool/etc configs. AND a distro (even if it's a DIY LFS ...) that makes it possible. It really just is way too early / too soon to cut of BIOS booting support. big emphasis on the 'way'. i for one am certainly glad that that's the decision that's been taken, and that i won't have to face migrating to yet-another-OS because of bad enterprise policy decisions. esp, since Fedora's grown on me ... ___ 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
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 2:34 PM, Paul Wouters wrote: > And as I indicated earlier, most server installs have no use for > systemd-resolved. Yes it can be disabled, but we didn't go all the > way to virtual servers and containers to have to install things > we will never use. +1, & simply 'minimal' installs ... > The ask I have is very small. When I install and upgrade, no? > a server via kickstart, > I want to be able to do a minimum install, and that it should be > possible that this does not include systemd-resolved". it'd be nice-to-have to have that level of granularity/selection in an Anaconda minimal server install, as well. > I have explained my use case, and I believe it is _very_ common use case. ___ 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
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
anyone else more confused? On 9/30/20 1:26 PM, Neal Gompa wrote: > And like it or not, all our legacy network configuration mechanisms > are deprecated and*will be removed eventually*. is plain-vanilla systemd-networkd -- no NM wrapper around it, no (in)direct dependency on systemd-resolved -- considered 'legacy'? > Moreover, *all* Fedora variants use NetworkManager. *ALL* OSTree variants, as shipped today, *MUST* use NetworkManager. how 'bout I turn the question around ... what specific steps must be done POST- F32->F32 upgrade to (1) not use NetworkManager (2) not use systemd-resolved (3) return/preserve local configs for systemd-networkd & 'enterprise' (own resolver) DNS configs? ? > Regular Fedora is considerably more customizable post-installation than OSTree-based variants. For those of us that don't live the lingo, it's not exactly clear what 'Regular Fedora' is. Is there _any_ variant of Fedora that's immune now, and in the planned future, from "use NetworkManger" and (therefore) systemd-resolved? Iiuc, the upgrades WILL install/enable systemd-resolved; that's post-upgrade maintenance that apparently needs to be planned for -- as long as its still doable. If/when does that no longer remain an option? ___ 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
Re: splitting out systemd-networkd, systemd-standalone-{sysusers,tmpfiles} subpackages in F33+
On 9/30/20 11:21 AM, Paul Wouters wrote: > It also allows those Destop users that want to use their own validating > resolvers on the end node to uninstall systemd-resolved. Would separating the package preserve existing setups across upgrades? It's not simply Enterprise/Server 'or' Desktops that use "own validating resolvers". Here, that's standard/default for both. Ideally, a mechanism to "leave existing configs as is", without exceptional intervention -- using kickstart, re-UNinstalling or re-DISabling after upgrade -- would be preferred. I'm all for new capabilities. What's concerning is the insistence on monkeying with (long) established, and perfectly viable/standard configurations. ___ 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
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 9/30/20 9:50 AM, Michael Catanzaro wrote: > You'll need to manually disable systemd-resolved after upgrade, restore > /etc/resolv.conf from the backup file that will be created during upgrade So the upgrade WILL ignore current F32 state -- systemd-resolved DISABLED + 'my' /etc/resolv.conf -- and enable + overwrite (respectively) each, regardless of whether we're _using_ NetworkManager (afaict it's impossible to completely remove all NM* cruft)? ___ 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
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 9/30/20 9:16 AM, Neal Gompa wrote: > If you're not using NetworkManager, this change has _zero_ impact. perfect. clearly, i've missed or lost the obviousness of that incredibly useful tidbit in this novella :-/ thx! ___ 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
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Reading along, it's _at_best_ unclear what the eventual 'resolution' of this^ is. What _is_ clear is that there's significant disagreement -- which, unfortunately, has at times here become nasty & personal -- about needed vs planned functionality, and, of late, regulatory compliance. And, iiuc, though obviously very much up in the air, this is all relevant to F33 release, coming in weeks? Can someone please clarify, ideally with some level of certainty: If we've F32 systems in place, that do NOT use systemd-resolved &/or NetworkManager, but rather our own/preferred DNS client implementations with systemd-networkd, will a system *upgrade*, from F32 to F33, force/require any changes to those configurations? or will systems be left as-is, and we can expect uninterrupted functionality? which of these proposed systemd-resolved system-wide changes are NON-optional in _usage_? can they _all_ be turned-off/disabled? bottom-line -- how much system breakage of existing infrastructure, if any, should we be planning for with a F32 -> F33 upgrade path? ___ 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
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 9/28/20 11:21 AM, Andrew Lutomirski wrote: > I would have expected NetworkManager to handle this kind of setup just fine. > What went wrong? getting offtopic, but ... a laundry list. including broken routes, missed existing unit-file interface dependencies particularly once bridges get involved, absolute disfunction with setups including shorewall & wireguard, blah blah blah. and, generally, a stubborn, been-there-done-that view that NM has *no place* on my servers &/or workstations. i'm sure _all_ of it was "bandaid-able" with enough monkeying around. simply not worth the effort, cost, and uncertainty; i'd already moved OS/distros to get away from a flaky network stack (among other issues, of course; not the least of which was, ironically, old/dusty systemd version!) ... and intransigent 'policy' decisions that came with it. systemd-networkd with enterprise-grade/fits-my-needs DNS servers/resolvers works. very nicely. fingers-crossed that removing the unwanted/unwelcome cruft remains an easy option. as always, YMMV. ___ 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
Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 9/28/20 11:03 AM, Lennart Poettering wrote: > I have the strong suspicion that the same people who are > able to deploy working DNSSEC client side and are educated enough in > DNSSEC to know what that even means are also capable of replacing that > one symlink in /etc. i'll start with: i'm generally a huge use-systemd-*-whenever-possible bigot. aka, NOT an anti-systemd'er. but, this^ comment, though likely _true_, causes concern for those of us out here, in the peanut gallery. on as Paul Wouters has repeatedly pointed out ... others' use cases are not mine. and statements such as "It's easy to do using resolvectl" make me ... antsy. forcing use of, or switching by (coming) default, to solutions that cause significant breakage to working systems, is bad news. whether or not that breakage can be 'easily' worked around. easy != zero effort / zero cost. my typical 'small-office install' includes local split-horizon bind9 implementation, as well as instances of both NSD4/Unbound, multiple VPN links, and varied routing for IPv4 & IPv6 dns queries, as well as general & specific traffic. internal services/capabilities include mail, DNSSEC and instances of secure DNS (DoT/DoH), geoIP, etc etc. 'large-office' installs are correspondingly _more_ 'convoluted'. that said, it all works. well. (my) users see/use a static /etc/resolv.conf, with, generally, a single nameserver entry. recent experiments (on F32, admittedly -- *not* yet F33) with NetworkManager &/or systemd-resolved here were nightmarish; a seemingly endless array of 'gotchas' ... after trying, and failing, to chase down & completely resolve all the problems, the functional solution i landed on was (1) disable NetworkManager everywhere (yes, causes some current pain with laptops) (2) enable/deploy systemd-networkd everywhere (3) disable systemd-resolved everywhere; reset to own-managed, /etc/resolv.conf (4) disabled DoH settings in all Firefox instances it all works, again. if/until a 'forced switch', &/or new default, works in _our_ use cases -- regardless of whether or not they fit into _others_ limited views -- then that^^ is my default. here's hoping that turning "it" all OFF, without breaking 'the rest' of systemd*, or F33+, remains functionally doable ... off ___ 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
regression: Xen boot entries ask for non-exisiting grub2 module2.mod
on grep PRETTY /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" uname -rm 5.8.7-200.fc32.x86_64 x86_64 with rpm -qa | grep xen xen-4.13.1-4.fc32.x86_64 xen-hypervisor-4.13.1-4.fc32.x86_64 xen-libs-4.13.1-4.fc32.x86_64 xen-licenses-4.13.1-4.fc32.x86_64 xen-runtime-4.13.1-4.fc32.x86_64 rpm -qa | grep grub grub2-common-2.04-21.fc32.noarch grub2-efi-x64-2.04-21.fc32.x86_64 grub2-efi-x64-modules-2.04-21.fc32.noarch grub2-tools-2.04-21.fc32.x86_64 grub2-tools-extra-2.04-21.fc32.x86_64 grub2-tools-minimal-2.04-21.fc32.x86_64 grubby-8.40-40.fc32.x86_64 grubby-deprecated-8.40-40.fc32.x86_64 on boot-to-Xen ... Loading Xen 4.13.1 ... error: ../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found. Loading Linux 5.8.7-200.fc32.x86_64 ... Loading initial ramdisk ... error: ../../grub-core/fs/fshelp.c:257:file `/EFI/fedora/x86_64-efi/module2.mod' not found. Press any key to continue... ... waits 10-20 seconds, then continues 0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0xa14d0018 0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0xa14c7018 0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0xa14a5018 Xen 4.13.1 (XEN) [0011c8b7c914] Xen version 4.13.1 (mockbuild@[unknown]) (gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)) debug=n Tu0 (XEN) [0011cb3cbe4f] Latest ChangeSet: (XEN) [0011cbfaf8f8] build-id: 131db801fd9d8ed1fbc017e12b9a13570043e404 ... to successful boot, xen start, xl list NameID Mem VCPUs State Time(s) Domain-0 0 4016 4 r- 34.8 Xenstore 131 1 -b 0.0 this issue has been raised multiple times https://bodhi.fedoraproject.org/updates/FEDORA-2017-bd36ce6cfd https://bugzilla.redhat.com/show_bug.cgi?id=1486002 https://bugzilla.redhat.com/show_bug.cgi?id=1858364 atm, it remains unresolved where does this correctly need to get addressed? grub2/xen? fedora/upstream? new bug/reopened old? ___ 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
Re: distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?
On 8/7/20 5:57 AM, Petr Pisar wrote:
> I think the build script does not use Perl configuration consistently. It uses
> ldflags value for the linker flags, but it does not use ld value for the
> linker
> exectable:
...
> $ perl -MConfig -E 'say $Config{ldflags}'
> -Wl,-z,relro -Wl,--as-needed -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong
> -L/usr/local/lib
> $ perl -MConfig -E 'say $Config{ld}'
> gcc
double-checking here,
perl -MConfig -E 'say $Config{ldflags}'
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong
-L/usr/local/lib
perl -MConfig -E 'say $Config{ld}'
gcc
> If your /usr/bin/ld is the binutils ld,
it is:
which ld
/usr/bin/ld
ld -v
GNU ld version 2.34-4.fc32
rpm -ql binutils | grep bin/ld
/usr/bin/ld
/usr/bin/ld.bfd
ls -al /usr/bin/ld
lrwxrwxrwx. 1 root root 20 Jul 28 21:59 /usr/bin/ld ->
/etc/alternatives/ld*
ls -al /etc/alternatives/ld
lrwxrwxrwx. 1 root root 15 Jul 28 21:59 /etc/alternatives/ld ->
/usr/bin/ld.bfd*
>
then -fstack-protector-strong is also
> an invalid option for ld (see ld manual page) and it should also fail. I think
> something tricks you.
noted
> It's not intentional, but it's how perl works.
>
> When you build perl, the linker flags are modified by a perl build script and
> built into the perl interpreter. Later when a third-party XS module is built,
> the built-in linker flags are reused. That's because the XS module must be
> binary compatible with the perl interpreter and having the same flags ensures
> it. (Some flags, especially compiler flags, changes ABI.) As a result, the
> third-party module is also built rerlo.
>
> We would like to change it, but perl build script is a giant mess. When I
> asked
> perl authors for explaining the mess, it turned out that they do not fully
> understand it and, more imporatantly, that they do not want to touch it
> all because they fear breaking a compatibility.
>
>> Or likely an issue with the module not correctly dealing with it?
>
> I think that's the case. It should use gcc program for linking.
thx for the comments! I'll share upstream.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?
i'm attempting to build a MaxMind GeopIP2 DB reader perl module MaxMind::DB::Reader::XS ( https://metacpan.org/pod/MaxMind::DB::Reader::XS ) on Fedora 32. the build fails on F32 with Errors: "/usr/bin/ld: unrecognized option '-Wl,-z,relro'" & "Unsupported compile language "C"" ? I've filed a bug at the module upstream uninstallable on Fedora32, errors: "/usr/bin/ld: unrecognized option '-Wl,-z,relro'" & "Unsupported compile language "C"" ? https://github.com/maxmind/MaxMind-DB-Reader-XS/issues/32 the build fails only with Fedora's distro perl, which _includes_ the ldflags perl -V | grep -i " ldflags" ldflags ='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -L/usr/local/lib' but is _successful_ on opensuse, where distro perl's ldflags do NOT include '-Wl,-z,relro', perl -V | grep -i " ldflags" ldflags =' -L/usr/local/lib64 -fstack-protector-strong' Is this^ a problem with Fedora's perl build flags "incorrectly" _including_ relro? I've found/followed some of the perl hardening threads @ Fedora; IIUC, it's intentional ... Or likely an issue with the module not correctly dealing with it? ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Mock package is installed, but 'mock' group is missing; what pkg creates the group?
On 7/13/20 3:20 PM, Jerry James wrote: > On Mon, Jul 13, 2020 at 4:15 PM PGNet Dev wrote: >> i can easily manually create the group, but ... this suggests something's >> missing/broken in my install; I'd like to find/fix it. >> >> if not 'mock' what pkg (re)install creates the mock group? > > The mock-core-configs package is supposed to do that: > > $ rpm -q --scripts mock-core-configs > preinstall scriptlet (using /bin/sh): > # check for existence of mock group, create it if not found > getent group mock > /dev/null || groupadd -f -g 135 -r mock > exit 0 > ... a *re*install of *that* pkg does the trick, rpm -qa mock-core-configs mock-core-configs-32.6-1.fc32.noarch getent group mock (empty) dnf reinstall mock-core-configs getent group mock mock:x:135: so, thx! for that! > Do you have any logs from the F32 install? the installs have been on a VM -- and i've been cleaning house repeatedly as I make progress. all I've still got is this: 2020-07-13T19:18:53Z SUBDEBUG Reinstall: fedora-packager-0.6.0.4-1.fc32.noarch 2020-07-13T19:18:53Z SUBDEBUG Reinstalled: fedora-packager-0.6.0.4-1.fc32.noarch 2020-07-13T19:18:53Z SUBDEBUG Reinstalled: mock-2.3-1.fc32.noarch 2020-07-13T19:29:13Z INFO --- logging initialized --- 2020-07-13T19:31:45Z INFO --- logging initialized --- 2020-07-13T19:32:11Z INFO --- logging initialized --- 2020-07-13T19:32:23Z SUBDEBUG Reinstall: mock-2.3-1.fc32.noarch 2020-07-13T19:32:23Z INFO warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root 2020-07-13T19:32:23Z SUBDEBUG Reinstalled: mock-2.3-1.fc32.noarch 2020-07-13T19:43:12Z INFO --- logging initialized --- 2020-07-13T19:45:04Z INFO --- logging initialized --- 2020-07-13T20:37:00Z INFO --- logging initialized --- 2020-07-13T20:37:54Z INFO --- logging initialized --- 2020-07-13T20:38:01Z INFO --- logging initialized --- 2020-07-13T20:46:04Z INFO --- logging initialized --- 2020-07-13T20:48:04Z INFO --- logging initialized --- 2020-07-13T20:48:14Z SUBDEBUG Reinstall: mock-2.3-1.fc32.noarch 2020-07-13T20:48:14Z INFO warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root 2020-07-13T20:48:14Z SUBDEBUG Reinstalled: mock-2.3-1.fc32.noarch 2020-07-13T20:48:41Z INFO --- logging initialized --- 2020-07-13T20:48:51Z SUBDEBUG Reinstall: mock-2.3-1.fc32.noarch 2020-07-13T20:48:51Z INFO warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root 2020-07-13T20:48:51Z SUBDEBUG Reinstalled: mock-2.3-1.fc32.noarch 2020-07-13T20:49:05Z INFO --- logging initialized --- 2020-07-13T20:49:45Z INFO --- logging initialized --- 2020-07-13T20:49:53Z SUBDEBUG Reinstall: mock-2.3-1.fc32.noarch 2020-07-13T20:49:53Z INFO warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root 2020-07-13T20:49:53Z SUBDEBUG Reinstalled: mock-2.3-1.fc32.noarch 2020-07-13T21:21:38Z INFO --- logging initialized --- 2020-07-13T21:22:35Z INFO --- logging initialized --- 2020-07-13T21:22:56Z SUBDEBUG Installed: freetype-2.10.1-2.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: boost-system-1.69.0-18.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: urw-base35-fonts-common-20170801-14.fc32.noarch 2020-07-13T21:22:57Z SUBDEBUG Installed: nspr-4.25.0-1.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: boost-thread-1.69.0-18.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: boost-chrono-1.69.0-18.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: nss-util-3.53.0-2.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: libjpeg-turbo-2.0.4-3.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: boost-filesystem-1.69.0-18.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: libicu-65.1-2.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: polkit-libs-0.116-7.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: libtalloc-2.3.1-2.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: libX11-xcb-1.6.9-3.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: libICE-1.0.10-3.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: device-mapper-event-libs-1.02.171-1.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: apr-1.7.0-3.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: apr-util-bdb-1.6.1-12.fc32.x86_64 2020-07-13T21:22:57Z SUBDEBUG Installed: apr-util-openssl-1.6.1-12.fc32.x8
Mock package is installed, but 'mock' group is missing; what pkg creates the group?
i've installed a minimal F32 instance building up the rpmbuild env, 'mock' pkg is installed rpm -qa | grep mock mock-core-configs-32.6-1.fc32.noarch mock-2.3-1.fc32.noarch there's _no_ expected 'mock' group installed getent group mock (empty) reinstalling 'mock' warns the group doesn't exist, and fails to create it, dnf reinstall mock Last metadata expiration check: 1:04:38 ago on Mon 13 Jul 2020 12:45:07 PM PDT. Dependencies resolved. PackageArchitecture Version Repository Size Reinstalling: mock noarch 2.3-1.fc32 updates 180 k Transaction Summary Total download size: 180 k Installed size: 555 k Is this ok [y/N]: y Downloading Packages: mock-2.3-1.fc32.noarch.rpm6.8 MB/s | 180 kB 00:00 - Total 516 kB/s | 180 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing: 1/1 Reinstalling : mock-2.3-1.fc32.noarch 1/2 warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root warning: group mock does not exist - using root Cleanup : mock-2.3-1.fc32.noarch 2/2 Running scriptlet: mock-2.3-1.fc32.noarch 2/2 Verifying: mock-2.3-1.fc32.noarch 1/2 Verifying: mock-2.3-1.fc32.noarch 2/2 Reinstalled: mock-2.3-1.fc32.noarch Complete! getent group mock (empty) i can easily manually create the group, but ... this suggests something's missing/broken in my install; I'd like to find/fix it. if not 'mock' what pkg (re)install creates the mock group? ___ 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
Re: incorrect docs for forge macro extension, when using 'unknown' scm source (e.g., git.kernel.org) ?
On 7/10/20 1:26 AM, Nicolas Mailhot wrote: Le jeudi 09 juillet 2020 à 09:40 -0700, PGNet Dev a écrit : I'm working on a spec, pulling source with forgemeta/scm With known/supported scm sources (e.g., github), it works as expected, with no issues. involves writing the lua equivalent of regexpes that contruct the variables forgesetup will use from forgeurl and tag/commit/whatever (you can check in redhat-rpmc-config history how pagure and gitea support was added, they’re the two last supported sources) That something needs to be added/written/worked-around is clear. To do that effectively, I've simply asked > (1) Are there up-to-date/correct docs for 'Extending the macro' ? > > (2) Is there an explcit example for use with 'git.kernel.org' sources? In other circumstances, the someone might be me, but I’m getting fed up with everyone else in the project not doing their part and blaming me for doing things alone. So, right now, very unlikely that I will invest more in Fedora without others doing their parts. I don't know you to 'blame you', and certainly haven't here. If your issue is with others, then perhaps you might take it up with _them_? ___ 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
incorrect docs for forge macro extension, when using 'unknown' scm source (e.g., git.kernel.org) ?
I'm working on a spec, pulling source with forgemeta/scm
With known/supported scm sources (e.g., github), it works as expected, with no
issues.
Atm, I'm trying to pull from a different source,
git.kernel.org
with this 'ofono-test.spec'
%global forgeurl
https://git.kernel.org/pub/scm/network/ofono/ofono.git
%global commit aeeb321a72d0b84c0fe5008dc7c49f0707582ca0
%forgemeta -i -a
Name: ofono
Version: 0
Release: %{dist}
Summary: ofono
License: GPL-2.0
URL: %{forgeurl}
Source:%{forgesource}
BuildRequires: git
%description
ofono
%prep
%forgesetup
%build
%install
%files
%changelog
"build through %prep" stage fails
rpmbuild --clean --verbose -bp ofono-test.spec
Packaging variables read or set by %forgemeta
forgeurl0:
https://git.kernel.org/pub/scm/network/ofono/ofono.git
forgesource0: #/.%{archiveext0}
forgesetupargs0: -c -n %{archivename0}
extractdir0: %{archivename0}
commit0: aeeb321a72d0b84c0fe5008dc7c49f0707582ca0
distprefix0: .%{scm0}aeeb321
dist: .%{scm0}aeeb321.fc32
(snapshot date is either manually supplied or computed once
%{_sourcedir}/%{archivename0}.%{archiveext0} is available)
warning: line 8: Possible unexpanded macro in: Release:
.%{scm0}aeeb321.fc32
error: Bad source: /root/rpmbuild/SOURCES/.%{archiveext0}: No
such file or directory
Not at all clear what the actual problem is. Since it _does_ work with
gitbub/gitlab sources, I'd _guess_ it's a URL/source string format issue ...
Reading at
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Extending_the_macro
states
"locate the latest version of the forgemeta macro (it should be
installed in /usr/lib/rpm/macros.d/macros.forge-srpm by fedora-rpm-macros)"
the package is installed
dnf list --installed fedora-rpm-macros
Installed Packages
fedora-rpm-macros.noarch26-8.fc32@fedora
there's no such file
ls -al /usr/lib/rpm/macros.d/macros.forge-srpm
ls: cannot access '/usr/lib/rpm/macros.d/macros.forge-srpm': No
such file or directory
checking
rpm -ql fedora-rpm-macros
/usr/lib/rpm/macros.d/macros.fedora
and, the file's empty
cat /usr/lib/rpm/macros.d/macros.fedora
# Miscellaneous Fedora-related RPM macros.
# Currently there is nothing here.
(1) Are there up-to-date/correct docs for 'Extending the macro' ?
(2) Is there an explcit example for use with 'git.kernel.org' sources?
___
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
Re: Can we do away with release and changelog bumping?
On 7/6/20 8:27 AM, Björn Persson wrote:
> Florian Weimer wrote:
>> * Björn Persson:
>>
>>> The macro could be defined like this for example:
>>>
>>>%buildtag .%(date +%%s)
>>
>> Using time for synchronization is always a bit iffy.
>
> Well, if somebody manages to build a package twice within a second,
> using two different versions of a compiler ... then they still won't be
> any worse off than they are today. Koji should still not allow it.
>
>>> It would be used in each spec like this:
>>>
>>>Release: 1%{?dist}%{?buildtag}
fwiw, I've just been cobbling together a couple of specs with date tagging for
version mgmt between repos.
once I was pleasantly reminded to double-%% the date formats inside specs, it's
complicated only a bit by the occasional need to redefine %dist after multiple
forgemeta pulls.
otherwise, it's really handy.
currently this, e.g., works nicely 4 me:
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01518639-nginx/nginx.spec
for my workflow,
-- get it working locally with rpmbuild
-- prove it works and is a properly closed build env in mock, locally
-- move local mock result into a local repo
-- push spec/srpm to COPR for build
I can effectively manage 'same' pkg+version, with builds differentiated by time
stamps. (for me, 1 sec min time slice is certainly good enuf!)
entirely possible that my 'kludge' hits an example of "a bit iffy"; hasn't
quite yet, tho ...
___
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
Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
On 7/3/20 2:07 PM, PGNet Dev wrote: > from cmd line, > > copr-cli edit-chroot --packages git > > looks like it should work as well and it does, nicely: ==> 14:26:43 Build 1517366: succeeded ___ 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
Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
On 7/3/20 8:24 AM, PGNet Dev wrote: > git _was_ trivially added to the local mock chroot, for its use, with obvious > success, in the local mock build of the spec. > > COPR uses mock. > > So far, I have not seen how that's to be similarly done for the COPR env. > > Is is possible to, similarly, add git to the COPR mock env? FrostyX @ irc was kind enuf to give this a try -- & found the solution. @ nav to https://copr.fedorainfracloud.org/coprs/pgfed/nginx-mainline/edit_chroot/fedora-32-x86_64/ adding 'git' to Packages: git You can add additional packages to the minimal buildroot of this chroot. These packages will be always present before the build starts. ( from UI, that's 'hidden' behind the "EDIT" button for the select chroot(s). obvious if you know it ... ) seems to solve the problem. he was able to successfully bld my spec ... from cmd line, copr-cli edit-chroot --packages git looks like it should work as well ta, FrostyX! ___ 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
Re: use of 'date' in rpm .spec %define concats add'l str chars?
On 7/3/20 11:22 AM, Paul Howarth wrote: > Remember ugh. well, i certainly will NOW! ;-) > that '%' introduces a macro expansion, so if that's not what > you want, you should escape the '%' as '%%': > > %define _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S ) works perfectly. thx! ___ 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
use of 'date' in rpm .spec %define concats add'l str chars?
on F32,
date +FORMAT,
date +%Y%m%d_%H%M%S
returns
20200703_105351
as expected.
in an rpm .spec, if I define
%define _build_timestamp %( date +%Y%m%d_%H%M%S )
and _use_ %{_build_timestamp) _anywhere_ else in the spec, at exec of any of
rpmbuild/mock build/@COPR etc, it appears as
'20200703_105351OURCE'
?
Simply changing the define to
%define _build_timestamp %( date +%Y%m%d_%H%M%S | head -c 15 )
'fixes' the problem, and use of %{_build_timestamp) correctly returns
'20200703_105351'
Is this a bug in rpmbuild or date? Or a problem in my usage?
___
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
Re: mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
hi, > ... All the above^ is an interesting/informative read. On 7/3/20 2:31 AM, Nicolas Mailhot via devel wrote: > The requester is clearly attempting the second approach. Well, not explicitly. I'm not requesting any _specific_ approach. The goal is simply to 'build it here (locally, via mock), then build it there (remotely, on COPR)'. And have the results be the same. My general question is why what works in _mock_ here, locally, fails to work similarly on COPR. Not just rpmbuild, which I understand _is_ well integrated into my local env, but the supposedly _isolated_, basic mock env. And if it inherently does/can work similarly, what specifically I need to do/configure to get there. On 7/2/20 10:26 PM, Pavel Raiskup wrote: > and it needs to have the internet enabled at that time to > get the contents of %commitX. > > So the alternative local mock command would be: > > mock --buildsrpm --spec nginx.spec --enable-network in both cases, networking _is_ 'on' Here, the mock env is setup as cat /etc/mock/site-defaults.cfg ... config_opts['rpmbuild_networking'] = True config_opts['chroot_additional_packages'] = 'git' ... mock --init and the copr build as, copr-cli create \ --chroot fedora-32-x86_64 \ --multilib off \ --description "x" \ --instructions "x" \ --use-bootstrap on \ --enable-net on \ --unlisted-on-hp on \ On 7/3/20 12:01 AM, Nicolas Mailhot wrote: > You added some processing that depends on the git command (that > forgemeta does not use) but forgot to BuildRequire the package > providing that command. It's _clearly_ already added in my referenced spec: BuildRequires: git On 7/3/20 1:23 AM, Pavel Raiskup wrote: > I'm afraid that for building the src.rpm simply adding git to BuildRequires > will not help. Agreed; it does not. On 7/3/20 12:01 AM, Nicolas Mailhot wrote: > dead stupid (so stupid Let's chalk that up this time to 'lost in translation', shall we? > As stated before forgemeta does not depend on the git (or hg, or svn, > or…) command, it’s a pure URL munger, so it won’t pull in your scm of > choice in the buildroot. > > Presumably your workflow is so git oriented your local setup always has > git installed. I've been working with Fedora for < 2 weeks now; i.e., not much 'baggage' at all. There _is_ no "so oriented" or "always" workflow. ALL of what I'm attempting to do is simply based on new/fresh eyes reading the docs provided, and giving it a whirl. I'll certainly acknowledge the _hope_ that there's something similar to my prior build env's 'Source Services' capability, https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.source_service.html doable here. On 7/2/20 10:26 PM, Pavel Raiskup wrote: > So basically it needs to have the /bin/git installed in the chroot (it is > not by default), git _was_ trivially added to the local mock chroot, for its use, with obvious success, in the local mock build of the spec. COPR uses mock. So far, I have not seen how that's to be similarly done for the COPR env. Is is possible to, similarly, add git to the COPR mock env? ___ 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
mock build results for same .spec build different for local & online/COPR builds -- local OK, @copr FAILS ?
(i'd been discussing this issue with praiskup @ copr-devel/buildsys; he suggested that I bring it here ...) This spec https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516680-nginx/nginx.spec which uses forgemeta to pull multiple SCM sources, and uses some git/bash scripting in %defines, builds locally, on F32, via rpmbuild or mock build, from spec or srpm, with NO error. resulting rpms are installable, usable & pass testing. submitting the _same_ spec to COPR for online build FAILS @, supposedly, similar Mock build Here's a diff https://www.diffchecker.com/izjQYkUF comparing the log output of SUCCESSFUL LOCAL BUILD mock --buildsrpm --spec=~/rpmbuild/SPECS/nginx.spec --sources=~/rpmbuild/SOURCES cat build.log and FAILED COPR BUILD copr-cli build nginx-mainline ~/rpmbuild/SPECS/nginx.spec https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01516674-nginx/builder-live.log.gz The goal is to have the same spec generate the same Mock build, regardless of environment. Why does the COPR build's Mock build stage fail? IIUC, mock builds _should_ be portable between mock envs, at least for the same chroot. Do I need additional prep of the spec prior to submit? Something in my foregemeta/scm usage that's env-dependent? Something else I've missed? Or is there an issue with the Mock build env @ COPR? ___ 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
Re: The future of legacy BIOS support in Fedora.
On 6/30/20 11:38 AM, Tom Seewald wrote: > The primary areas of concern I have about Fedora dropping grub2 and BIOS boot > support are: nicely summarized. > 4. Support documentation for sd-boot > > Would this result in changes to how users access the boot menu, select a boot > entry, or edit the kernel command line, etc? These actions of course aren't > expected to be common but when they are needed it tends to be when a user is > already experiencing problems and is under stress. Therefore if there are > changes, hopefully these will be clearly documented to avoid confusion. Is this proposed dropping of grub only for 'desktop' Fedora? iiuc, server/workstation instances share the same underpinnings? For server/workstation, "access the boot menu, select a boot entry, or edit the kernel command line" are certainly NOT _uncommon_. Very often, particularly when tracking closely with upstream latest releases, they're very often _necessary_. re: sd-boot docs, grub -- for both BIOS & UEFI -- has available encyclopedic & thorough documentation. its configs are also wonderfully portable. including/across the countless other distros that (will) continue to use/support it. *dropping* grub for the next bright-n-shiny seems to make little sense. *adding* "sd-boot" (tbh, i've never come across an instance of it in use. anywhere.), and support *both* -- whether or not it's 'bloat -- doesn't make much sense either. ___ 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
Re: The future of legacy BIOS support in Fedora.
On 6/30/20 8:24 AM, nick...@gmail.com wrote: > I've never tried UEFI in a VM, and I have no idea how stable it is. IME, works well in a variety of hypervisors; atm, my 'exploration' of Fedora32 is running solely in VirtualBox VMs ... booted UEFI. That said, their a lots of providers that have the capability, but do not enable/support UEFI boot. E.g., Linode hosts KVM (and, iiuc, still some Xen), but does _not_ support UEFI boot; as of a few weeks ago, there's no plans/commitment for that changing anytime soon. ___ 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
Re: The future of legacy BIOS support in Fedora.
On 6/30/20 8:07 AM, Jóhann B. Guðmundsson wrote: >>> I think there are many people still install OS in the legacy mode, but >>> I don't really have numbers. I've just started working with Fedora 32 ~ a week ago. Looking at it as a migration option, for imo a lot of _good_ reasons, from current deployed OS/distro for lots of boxes. one end-user data point for consideration: currently, out of ~1K linux boxes in my ecosystem -- a mix of desktop, developer, int & ext production & devel servers -- ~40% are still BIOS only, with no EFI support; others have EFI support in BIOS, but are currently installed in legacy mode. all are running distro up-to-date kernels, with a majority running Kernel:Stable. desktop ENVs are up to date with latest KDE, GNOME & XFCE. those 'legacy' boxes are perfectly serviceable/functional, and will remain in service, regularly maintained, for possibly years to come. mv'ing Fedora to EFI-only anytime soon takes it out of consideration, here anyway. perhaps I'm missing the details, or point, of this. ___ 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
Re: Fwd: %forgemeta support for `git` tasks in checked-out code?
On 6/26/20 9:35 AM, PGNet Dev wrote:
> that said, _can_ such bash-ism be used in "getting" a forge commit value?
nm, pebkac!
%( git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}' )
seems to work.
sry 4 the noise.
___
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
Re: Fwd: %forgemeta support for `git` tasks in checked-out code?
while 'exploring' some of the limits of forge syntax/usage, trying to see
if/how bash expansion might work, i find that:
neither
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%global commit1 git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}'
nor
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%global commit1 $( git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}'
)
yes, i know this^ is not production-ideal ... and that there are other/better
options.
that said, _can_ such bash-ism be used in "getting" a forge commit value?
___
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
Re: Fwd: %forgemeta support for `git` tasks in checked-out code?
hi,
On 6/25/20 11:58 PM, Nicolas Mailhot wrote:
> forgemeta works in release mode, with release archives published over
> http(s). It does not talk at all to source projects using the git
> protocol (and that is intentional, since a lot ot things tooling-side
> do not talk the git protocol and will never talk the git protocol,
> starting with rpm itself, spectool, etc).
noted. not clear initially from reading the docs; this helps. thx!
> git is not the only scm system out there.
(snip)
sure. i'm trying to get forge playing nice with not-included-yet hg sources
atm :-)
> From a pure auditing side
...
> Note that your spec as it stands is inherently unsafe since
...
> The correct auditable way
...
(snip)
yup. and for the moment -- while I'm getting my 'end product' sorted out --
that's intentional, and I'm not concerned with audit trail.
yet.
point taken otherwise.
> So you should have a long list of
> %forgeurlX
that's already changed in my latest ...
> %tagX or %commitX
fair enuf, now that the above is nice-n-clear ...
> and a single %forgemeta -a at the end
was having weird artifacts doing that earlier, so split into
one-per-source-target.
once a forge bug (other thread) gets ironed out, that'll get revisited, too.
> That will change soonish BTW, I’m currently doing final testing on code
> that will use a slightly different syntax:
>
> %forge_urlX
(snip)
that'll get announced ... here?
do you have a _rough_ timeframe for when that'll be consistently
supported/usable in rpmbuild, mock & COPR?
bunch of moving parts to get in sync ...
> Because not making -a the default and emphasising -z in the
> documentation was comfusing users. -z should be a last resort debuging
> help
it was helpful for debug, here. and at my early stage, necessary ...
> not the first thing you look at when packaging multiple sources.
yup
> That will leave you with each individual source unpacked and patched in
> %{_builddir}, and needing a some symlinks between %{_builddir}
> subdirectories to construct a unified source trees, but that’s how
> multisource works deep down in rpm, nothing I invented myself.
that's what i'd naively assumed was to cleanly happen when i'd started with
this multisource spec.
if this cleans that up, then +1 !
> ... have people butcher it to achiever their aims ...
but, that's _our_ job! ;-)
cheers.
___
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
