Re: Spec file using github repo - not tarball
On 08/05/2024 21:36, Kenneth Goldman wrote: Is it possible for a .spec file to clone a github.com repo rather than download a tarball? Can someone link to a working example? No, but github can give you a tar ball for any ref you want so why would you need/want to? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: Testing package version is spec file
On 08/05/2024 18:38, Brad Smith wrote: I help maintain a package where upstream changed the process to generate installed documentation. In version 1.30 and newer, the spec file needs to use process A; in versions older than 1.30 (e.g. 1.29.x, etc) the spec file needs to use process B. I am struggling to find a workable solution to testing the version like this. Why do you need to? When you update the spec file to 1.30 you change it to use the new method surely. Why do you need one spec file that can do both versions? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: Fedora 40 apache now giving errors
On 24/04/2024 02:28, Xose Vazquez Perez wrote: # mkdir /etc/systemd/system/httpd.service.d/ # vi /etc/systemd/system/httpd.service.d/override.conf [Service] ProtectHome=false Better than just opening up whole trees again would be to use ReadWritePaths= to specify which paths should be allowed for writing. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: convert everything to rpmautospec?
On 08/04/2024 14:47, Fabio Valentini wrote: It is already supposed to be default / preferred since this Fedora 38 Change: https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default I find that quite interesting because while I may have read it at the time I had certainly long since forgotten that. The problem I think what that change is that it's essentially about changing policy and getting all packagers to move to a new way of doing things but at a practical level all it did was update some documentation - nothing it in actual provides for outreach or bringing the change to the attention of packagers in any way so it's perhaps not surprising that it seemingly didn't really achieve it's objective leading us to this attempt to try again. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: convert everything to rpmautospec?
On 08/04/2024 10:28, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 08, 2024 at 09:08:19AM +0200, Miroslav Lichvar wrote: On Sun, Apr 07, 2024 at 04:48:03PM +0100, Tom Hughes via devel wrote: -1 for existing packages certainly - none of my git commit logs are written with the expectation that they will double as package changelogs so doing so may break the changelog. Yes, I think rpm changelog is for users of the package and git log is for the maintainers. Most of the time the entries apply to both, but sometimes they don't. This was already answered to some extent, but since it seems to a common misconception, I'll reply here again: %autochangelog is designed to keep the separation between git log and %changelog. Generally, only some git log entries end up with a matching entry in the autogenerated %changelog, see https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html#skipping-changelog-entries. Yes I read the documentation last night after some of the clarifications and I'm much less opposed now and considering trying it out next time there is a new release for one of my packages. I think things might have gone better if things had been phrased as reminding people of how it all worked, and that it is in fact now policy to use it (which had passed me by) rather than coming straight out with threats to use proven packagers which I suspect got people's backs up and led to some of the swift negative responses. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: convert everything to rpmautospec?
On 07/04/2024 16:15, Zbigniew Jędrzejewski-Szmek wrote: I think it's time to switch to rpmautospec completely. Thus, the proposal: - new packages MUST use rpmautospec - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. -1 for existing packages certainly - none of my git commit logs are written with the expectation that they will double as package changelogs so doing so may break the changelog. I don't really want it for new packages either but at least there I would know I needed to use the commit log in that way. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: dmesg restricted to root in Rawhide
On 28/02/2024 10:05, Marcin Juszkiewicz wrote: W dniu 27.02.2024 o 22:27, Justin Forbes pisze: In practice, this isn't that much of a lockdown for most fedora users. We give the default user on a system wheel access which means both 'sudo dmesg' and 'journalctl -k' work as is. You wish... $ id uid=1003(marcin) gid=1006(marcin) groups=1006(marcin),10(wheel),11(cdrom),18(dialout),39(video),63(audio),100(users),135(mock),948(render),960(libvirt),986(wireshark),1003(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ dmesg dmesg: read kernel buffer failed: Operation not permitted $ uname -a Linux puchatek.local 6.8.0-0.rc5.41.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 19 14:19:27 UTC 2024 x86_64 GNU/Linux Which proves what? You did "dmesg" not "sudo dmesg" or "journalctl -k". Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: Question about conditional BuildRequires lines
On 14/02/2024 15:48, Richard W.M. Jones wrote:
On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
On 14/02/2024 14:54, Richard W.M. Jones wrote:
https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
I don't think what Tom is saying there is correct, or is it?
The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not the
requires from the srpm.
However the guidelines whilst not mentioning this case do prohibit
the use of %{_isa} in BRs because it produces incorrect dependencies
in the srpm - the only real difference is that this case give you
a missing dependency rather than a broken one.
I was hoping that people with more experience would comment on the
bug, and they did, so thanks.
The issue we have is that valgrind is simply not a package on RISC-V.
Valgrind requires upstream porting work which is only partially
complete (and IIRC not upstream yet). I don't know any other way to
express this other than using:
As it happens I'm an upstream valgrind developer and yes there
are patches around but they're not merged yet.
I'm not saying I won't take the patch I was just surprised it
was allowed and/or worked and was trying to find out more details
before I did anything.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: Question about conditional BuildRequires lines
On 14/02/2024 14:54, Richard W.M. Jones wrote:
https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
I don't think what Tom is saying there is correct, or is it?
The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not the
requires from the srpm.
However the guidelines whilst not mentioning this case do prohibit
the use of %{_isa} in BRs because it produces incorrect dependencies
in the srpm - the only real difference is that this case give you
a missing dependency rather than a broken one.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: OpenSSL 3.2.1 available in rawhide
On 09/02/2024 13:34, Jarek Prokop wrote: Since the error from the scratch build says "invalid CA certificate" I thought to use some openssl "verification" command, this one seems like I'm on the right path. I have tried more permutations of the command with certificates available in the `spec/ssl/` directory, including using `-untrusted` with various certs, all seem to fail the same. Any idea what's up or how to fix it? As you say it doesn't like the CA certificate: % openssl verify -verbose -CAfile ca-cert.pem server-cert.pem CN=ca_mysql2gem error 79 at 1 depth lookup: invalid CA certificate error server-cert.pem: verification failed That CA certificate doesn't have the CA:TRUE constraint set which might be the problem? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: Figure out what killed an app (rhbz#2253099)
On 31/01/2024 10:08, Milan Crha wrote: I tried to investigate a rawhide bug: https://bugzilla.redhat.com/show_bug.cgi?id=2253099 which is about Evolution being killed "by something". That's the thing, I do not know what killed it, thus even why it had been killed. It's even not killed after certain steps, it's killed "randomly", on various occasions. I did search the internet, but they usually expect the killer is the OOM service, which logs about the action either in the dmesg or in the journal, but in this case there is no sign about whom killed it in either of these logs. The evolution terminal just says: Killed At the end of of the day it means a SIGKILL was sent to the process and that's not something that is logged anywhere as a matter of course so you're reliant on whatever sends it saying so. You're right that OOM is the usual cause so if you've ruled that out you need to think about other things. The problem is that SIGKILL is deliberately a very hard stop that nothing can trap so normal things like using strace or gdb to catch who went it aren't going to work. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: HEADSUP boost and tbb rebuilds starting in a side tag
On 20/01/2024 16:07, Jerry James wrote:
Upstream has this in src/tbb/CMakeLists.txt:
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
set(TBB_PC_NAME tbb)
else()
set(TBB_PC_NAME tbb32)
endif()
That makes the pkgconfig file install as tbb32.pc. I don't know why
upstream is doing that. Maybe so 64-bit and 32-bit installs can
coexist on the same system?
The correct way to do that is to install in /usr/lib{,64}/pkgconfig
instead of /usr/share/pkgconfig I think?
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: Build error with GCC 14, not even a warning in GCC 13
On 16/01/2024 23:49, Richard Shaw wrote: On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin mailto:aleba...@fedoraproject.org>> wrote: Ah, I misread the include path. It's our package that is too old :( https://src.fedoraproject.org/rpms/rapidjson/pull-request/4 <https://src.fedoraproject.org/rpms/rapidjson/pull-request/4> should help. It doesn't look like the pull request has gotten any attention. Perhaps it's time to initiate the non-responsive maintainer process? Right because the other two PRs I've merged in the last couple of weeks, including one today, are not evidence of responsiveness? That PR is on my to look at list but rather obviously it needs more work than the other ones. I'm not really keen on packaging a random git snapshot because there's no way to know how good or bad it is but I realise that due to upstream being a pain it may be necessary here. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: Schedule for Monday's FESCo Meeting (2024-01-15)
On 16/01/2024 10:43, Florian Weimer wrote: We still don't have approval for the toolchain updates that we need for the mass rebuild (notably Changes/GNUToolchainF40). As far as I can see there isn't even a Fesco ticket for it? The fields in https://discussion.fedoraproject.org/t/100414 for ticket numbers are just placeholders and there's nothing in the fesco issue tracker that I can see. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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
License correction for rapidjson
The license for rapidjson has been corrected from: MIT to: MIT and BSD-3-Clause Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 21/12/2023 14:33, Steven A. Falco wrote: On 12/21/23 08:53 AM, Neal Gompa wrote: On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. What would happen on a network where I've set up the DHCP server in my router to map mac addresses to static IP addresses? Sounds like I'd have to disable the feature, at least on my home network. Either that or you would make a one off change to your DHCP server to use the new per-network MAC address instead of the old one. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: Change of cronie and crontabs CIS compliance
On 06/12/2023 11:08, Ondrej Pohorelsky wrote: The only difference is that if you have populated the cron.deny list, after update it gets saved as .rpmsave and cron.allow is created. If the cron.deny is blank, it will get replaced. Also, if you had cron.allow populated before, it will stay this way and blank cron.allow.rpmnew is created. Surely there is one more change though? Namely that users who could previously run crontab to create cron jobs can no longer do so unless they have been added to the cron.allow file. That seems like a breaking change to me? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: old RPM code in my package - safe to remove this bit ?
On 30/11/2023 00:28, Michal Schorm wrote: On Thu, Nov 30, 2023 at 1:19 AM Tom Hughes via devel wrote: It hasn't been needed for a long time. Good, thanks. Off it goes. :) It's just making %license an alias for %doc if your building for a release old enough that %license isn't supported, as detected by checking if %licensedir is defined. Why is it checked through the %licensedir macro, and not the %license VFT instead? If %doc VFT could be used as an actual value for a macro, I'd assume it could be used in conditional too. (to verify whether such VFT exists) Well you said it yourself, that %license is a keyword and not a macro so you probably can't check if it's defined. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ 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: old RPM code in my package - safe to remove this bit ?
On 30/11/2023 00:14, Michal Schorm wrote:
I've stumbled upon this piece of code in my package:
# Define license macro if not present
%{!?_licensedir:%global license %doc}
https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/mariadb.spec#_322
Git blame points out 7 year old commit:
https://src.fedoraproject.org/rpms/mariadb/c/e3d4b2f14e5e0cb7b42b468ffb9de6ff39e3d248?branch=rawhide
The RPM docs says the %license 'Virtual File Attribute' was added in
version 4.11, which has been added to Fedora years before the commit
above:
https://src.fedoraproject.org/rpms/rpm/c/2970ed07c98c8929eca0bdfebda389af5a2ef92d?branch=rawhide
I tried to remove the line and I haven't noticed any differences in
output of "rpm -q -d " and "rpm -q -L " before and after.
I'm not even sure what the line is trying to do - I read it as "under
some condition, create %license global macro with value %doc".
It's just making %license an alias for %doc if your building
for a release old enough that %license isn't supported, as
detected by checking if %licensedir is defined.
It hasn't been needed for a long time.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
___
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: Restore access to torrent-file-editor package
On 24/07/2023 14:40, Leigh Scott wrote: You probably got removed for inactivity, see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UG3UOKBVJLUWZYEHWL52KPMITPEPEBNF/ Looks like it: https://pagure.io/find-inactive-packagers/issue/36 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Minified JS and CSS in Node packages
On 03/07/2023 17:09, Demi Marie Obenour wrote: On 7/3/23 11:59, Tom Hughes wrote: On 03/07/2023 16:41, Demi Marie Obenour wrote: Would it be possible to ensure that Node packages contain only actual source code, as in “the preferred form for making modifications” (quote from GNU GPL, I forget which version)? The simple answer is maybe in principle but in practice it's very hard as numerous previous threads will tell you. The tar balls from the npmjs registry which constitute the released versions of node packages frequently contain such things often without the original source or any of the tooling to build from it. The alternative is packaging from the upstream git but even then, and even if it is well maintained with version tags, there are often huge dependency chains to get all the tools needed to actually do the builds. I thought Fedora policy required shipping actual source code, in which case this alternative is the only option allowed. Yes you're right, and there's long been a question of exactly what constitutes that with javascript packages. When I was packaging and reviewing Node stuff I certainly tried to do so where it was in any way feasible. Minimisers weren't usually too bad - you can always just skip them after all - but once you start dealing with transpilers it can get a lot harder plus you often wind up having to write your own build script because the upstream one is using one of a dozen different Node based tools each of which has hundreds of dependent modules you would need to package. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Minified JS and CSS in Node packages
On 03/07/2023 16:41, Demi Marie Obenour wrote: Would it be possible to ensure that Node packages contain only actual source code, as in “the preferred form for making modifications” (quote from GNU GPL, I forget which version)? The simple answer is maybe in principle but in practice it's very hard as numerous previous threads will tell you. The tar balls from the npmjs registry which constitute the released versions of node packages frequently contain such things often without the original source or any of the tooling to build from it. The alternative is packaging from the upstream git but even then, and even if it is well maintained with version tags, there are often huge dependency chains to get all the tools needed to actually do the builds. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Plans for dhclient / ISC dhcp?
On 30/05/2023 11:57, Florian Weimer wrote: * Richard W. M. Jones: I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd: https://roy.marples.name/projects/dhcpcd systemd-networkd has an integrated DHCP client, hasn't it? It does yes, and it's what I use on most machines. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Plans for dhclient / ISC dhcp?
On 30/05/2023 11:41, Peter Robinson wrote: On Tue, May 30, 2023 at 11:10 AM Richard W.M. Jones wrote: https://github.com/libguestfs/libguestfs/issues/121 We use dhclient to get a DHCP address inside a minimal appliance. To get this out of the way: NetworkManager or systemd are not options. It seems as if the ISC dhcp package has been EOL'd upstream: https://www.isc.org/dhcp/ I wonder what our plans are for this package, such as whether we are recommending moving to dhcpcd: https://roy.marples.name/projects/dhcpcd (we package this already, as does Debian), or another suggested replacement, or if another team is going to maintain the code, or if we will just keep packaging the last ISC version in Fedora? Upstream has replace it with Kea: https://www.isc.org/kea/ That's a server - it doesn't replace the client component. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: It’s time to transform the Fedora devel list into something new
On 25/04/2023 09:40, Florian Weimer wrote: * Jarek Prokop: Personally, I have accounts on many, many Discourse instances, but I don't think there is a single one I read somewhat regularly. I find the mailing list mode and the notifications rather unpredictable. Maybe an alternative client could help (nndiscourse?), but as far as I understand it, there's no real API, so that's kind of hard? I could find an API docs, and I could retreive posts.json from our Fedora instance https://docs.discourse.org/ So the question is, what is a "real API" that you would consider OK? There has to be a login procedure, and it needs to be geared towards alternative clients. We currently have only this: | To become authenticated you will need to create an API Key from the | admin panel. So its seems to be restricted to admin-approved integrations, and is not intended for writing clients. It is possible to allow users to generate their own API keys without any admin involvement but there's no direct web interface to create one - the client has to make a call to /user-api-key/new with certain parameters - full details are here: https://meta.discourse.org/t/user-api-keys-specification/48536 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: How to check if a package is retired?
On 25/04/2023 08:55, Florian Weimer wrote: The xorg-x11-drv-fbturbo is supposed to have been retired (see <https://bugzilla.redhat.com/show_bug.cgi?id=2187060#c4>). How can I check if this is actually the case? A retired packaged should have a commit in srcgit that removes all the contents and adds a dead.package file with a description of the reason for retirement, like: https://src.fedoraproject.org/rpms/npm/c/7304877c50a9a02238cf7a40e269e256090fd001 As far as I can see xorg-x11-drv-fbturbo does not have that and is still live. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: It’s time to transform the Fedora devel list into something new
On 21/04/2023 18:52, Matthew Miller wrote: "Mailing list mode" was a specific thing in earlier versions of Discourse — it sent a notification for every message posted. This is kind of like going to Hyperkitty and saying "subscribe me to all 600 lists". I don't recommend that. Instead, choose specific tags that you want to subscribe to, just as you would subscribe to individual mailing lists. It's still a thing in current versions, it just doesn't seem to be available in the Fedora installation. It also doesn't have to send you everything as you can mute those things you don't want to include. Having to positively opt in to certain tags seems like a terrible idea as you're bound to miss lots of things when people create new tags that you don't even know exist. I'd much rather get everything by default and then opt out of the things I'm not interested in. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: KB layout switching does not work in TB on Rawhide
On 02/03/2023 08:43, Olivier Fourdan wrote: TB still uses Xwayland? By default, yes. If you install thunderbird-wayland then you will get an alternative native Wayland version. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Update of catch to Catch2 v3
On 28/02/2023 11:24, Vitaly Zaitsev via devel wrote: On 24/02/2023 09:42, Tom Hughes wrote: Did you miss the bit where I said you needed to change your BR to catch2-devel unless upstream has v3 support? What about Fedora ELN? catch2-devel is not available there. Nothing to do with me. I don't do ELN. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Update of catch to Catch2 v3
On 24/02/2023 07:48, Vitaly Zaitsev via devel wrote: On 22/02/2023 12:37, Tom Hughes via devel wrote: I have now added catch2 (for Catch2 v2.x) and upgraded the catch package to Catch2 v3.x in rawhide and f38. All my catch-dependent packages are now failing due to the missing catch.hpp header: Did you miss the bit where I said you needed to change your BR to catch2-devel unless upstream has v3 support? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
Update of catch to Catch2 v3
As discussed a few weeks ago the Catch testing framework has a slightly weird naming scheme, namely: * Catch (v1.x, actually a branch in Catch2 repository) * Catch2 v2.x * Catch2 v3.x Since Catch2 was released we have had catch1 and catch packages to support both v1.x and v2.x users. I have now added catch2 (for Catch2 v2.x) and upgraded the catch package to Catch2 v3.x in rawhide and f38. What this means is that if your package uses catch-devel to build that you probably need to update your BuildRequire to catch2-devel when you next build it - unless your upstream supports v3.x of course. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Packages with breaking APIs
On 01/02/2023 11:51, Neal Gompa wrote: On Wed, Feb 1, 2023 at 12:46 PM Benson Muite wrote: For Catch, there was an upgrade from 1 to 2. Similarly for FFTW, the main package uses the name FFTW, but it was FFTW3 before hand. Maybe one could use Catch3 or Catch2v3? Then change names later once more packages use the v3 interface? Normally older versions are broken out into versioned legacy packages and the main package is upgraded. Then reverse dependencies are either upgraded or pinned as needed. Which is what we did for catch before - there is catch1 and catch now. The slight complication/confusion is that the upstream repository is actually called Catch2 now though it's on v3.x but version one is in the same repository, just on a Catch1.x branch. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Packages with breaking APIs
There is already precedent for doing it with catch and I've said that I plan to do it again so I don't know what more you want. Tom On 01/02/2023 10:13, Benson Muite wrote: Packages with breaking APIs between major version changes often keep maintaining the older version for some time after the new version is released. An example is FFTW which has both FFTW (version 3) and FFTW2 (version 2) within Fedora: https://packages.fedoraproject.org/search?query=fftw Is it reasonable to package versions with newer APIs separately? Of particular interest are: i) Catch a) Existing v2.3.10 https://src.fedoraproject.org/rpms/catch b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2165410 ii) MbedTLS a) Existing v2.28.2 https://src.fedoraproject.org/rpms/mbedtls b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2154347 ___ 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 -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Fedora 38 mass rebuild is finished
On 24/01/2023 07:28, Jeff Law wrote: On 1/24/23 00:16, Jakub Jelinek wrote: On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote: I have some packages failed. One of them libtins. Problem is that: error: 'uint32_t' is not a member of 'std'; Is it normal? Is it GCC 13 change? See https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Some libstdc++ headers included in older versions as an implementation detail but no longer do. Including stdint.h will introduce ::uint32_t type among others, but not std::uint32_t, if you use the latter, you need to include . I've got a partial list of packages affected by the ongoing header cleanups in libstdc++: mapnik was affected as well but I fixed it last night. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: valgrind on Fedora
On 16/01/2023 08:52, Gordon Messmer wrote: On 2023-01-16 00:31, Tom Hughes via devel wrote: If that doesn't work then some examples would help, at least if you're getting a partial trace, so that we can get some idea of what component it is not able to unwind. ==29692== 30 bytes in 2 blocks are definitely lost in loss record 917 of 2,602 ==29692== at 0x484386F: malloc (vg_replace_malloc.c:393) ==29692== by 0x14806539: ??? ==29692== by 0x14BA7D87: ??? ==29692== by 0x14BA7DFC: ??? ==29692== by 0x14B86D88: ??? ==29692== by 0x146ED193: ??? ==29692== by 0x1475E205: ??? ==29692== by 0x1475E71A: ??? ==29692== by 0x1475ED49: ??? ==29692== by 0x146EF09F: ??? ==29692== by 0x4A5D0E7: g_type_create_instance (gtype.c:1931) ==29692== by 0x4A42C1F: g_object_new_internal (gobject.c:2228) ==29692== by 0x4A44247: g_object_new_with_properties (gobject.c:2391) ==29692== by 0x4A44FF0: g_object_new (gobject.c:2037) ==29692== by 0x146F5395: ??? ==29692== by 0x145D820C: ??? ==29692== by 0x145E06E3: ??? ==29692== by 0x1276D0: pk_backend_load (pk-backend.c:569) ==29692== by 0x135D1A: pk_engine_load_backend (pk-engine.c:967) ==29692== by 0x119468: main (pk-main.c:219) I suspect this is a result of libraries being opened and closed dynamically - for performance reasons valgrind doesn't resolve names until it prints the trace and if the library in question has been closed by then it will normally be unable to resolve names from it. Try using --keep-debuginfo=yes to make valgrind cache debuginfo for libraries that have been closed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: valgrind on Fedora
On 16/01/2023 08:12, Florian Festi wrote: On 1/16/23 07:10, Gordon Messmer wrote: Does anyone have any hints for improving the information I get from valgrind? Have you installed the debuginfo packages for the packages involved? See man debuginfo-install Making sure debuginfod fetching works should also do it as valgrind has support for that. If that doesn't work then some examples would help, at least if you're getting a partial trace, so that we can get some idea of what component it is not able to unwind. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Shorter Shutdown Timer (System-Wide Change proposal)
On 23/12/2022 11:45, Naheem Zaffar wrote: On Fri, 23 Dec 2022 at 08:26, Vitaly Zaitsev via devel mailto:devel@lists.fedoraproject.org>> wrote: On 23/12/2022 09:20, Mattia Verga via devel wrote: > I know this is way harder, but the right approach would be having a way > to tell systemd what processes can be killed and what other processes > must not be forced off in any case, then display a user friendly message > which inform the user that the system cannot be forced off ATM "because > I'm doing this or that". In the worst case, the user can choose to pull > the plug themselves. I agree. Terminating the PackageKit service while updates are being installed can result in a broken system. Is there a way to be smarter about all this? 1. Set default at 15s or something short. 2. For services known to require longer (older pinephone modem firmware, libvirtd), allow a larger timeout for that specific service only 3. For services that should NOT be terminated have a mechanism for them to not be cut off Despite the title of this change I believe the proposal is only to change the default timeout and a service would still be able to set a different timeout in it's service file. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Shorter Shutdown Timer (System-Wide Change proposal)
On 22/12/2022 19:18, Michael Catanzaro wrote: On Thu, Dec 22 2022 at 10:29:29 AM -0800, Adam Williamson wrote: Could we not go for 30 seconds? Personally I think 30 seconds is way too long for desktop users. But it's a lot better than 2 minutes, so if that's what we settle on, I won't complain. The thing is that it's not really two minutes anyway, it's more like eight minutes because each time the timer expires systemd sends a stronger signal and restarts the timer until it eventually gets to SIGKILL. So in the worst case where a process is stuck in D wait then you get all the way to the SIGKILL phase and then wait two minutes for that before it eventually gives up and continues. At least that is what usually seems to happen when I run into this problem. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Change update
On 07/11/2022 17:46, Miroslav Suchý wrote: 8. After you migrate your SPEC file, please add the string “SPDX” to the entry of the packages’ %changelog. This is the easiest way to detect the migration has been done. The second best option is to add it to the dist-git commit message. What do we do if the SPDX tag is the same as the existing license tag (eg ISC) though? Do we just add a dummy change/commit entry that mentions SPDX to confirm we've reviewed it? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Failed RPM database migrations
On 28/10/2022 13:31, Richard W.M. Jones wrote: On Fri, Oct 28, 2022 at 12:29:30PM +0100, Tom Hughes wrote: The reason it hadn't completed is that rpmdb-migrate.service was enabled on that machine. [was not, I guess?] Yes ;-) Enabling (and starting) that service made it complete. Interesting. The current state of that service is: ○ rpmdb-migrate.service - RPM database migration to /usr Loaded: loaded (/usr/lib/systemd/system/rpmdb-migrate.service; disabled; vendor preset: enabled) Active: inactive (dead) There are no log entries for this service, but my logs only go back to around April which is probably too late to see anything. After starting the service: Oct 28 13:29:33 systemd[1]: Starting rpmdb-migrate.service - RPM database migration to /usr... Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/.migratedb' Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/rpmdb.sqlite-shm' Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/rpmdb.sqlite' Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/rpmdb.sqlite-wal' Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/.rpm.lock' Oct 28 13:29:35 rpmdb_migrate[1722092]: removed directory '/var/lib/rpm' Oct 28 13:29:35 rpmdb_migrate[1722468]: '/var/lib/rpm' -> '../../usr/lib/sysimage/rpm' Oct 28 13:29:35 systemd[1]: rpmdb-migrate.service: Deactivated successfully. Oct 28 13:29:35 systemd[1]: Finished rpmdb-migrate.service - RPM database migration to /usr. Oct 28 13:29:35 systemd[1]: rpmdb-migrate.service: Consumed 2.433s CPU time. ... and the migration has been successful. So at least we know how to fix this. Although it's quite curious that the service was installed and supposed to run but didn't. The idea is that the service is enabled (not sure off hand what is supposed to do that) but not started, so that it runs when you reboot and completes the migration as part of the boot. When it runs it removes /var/lib/rpm/.migratedb which was created by the rpm scripts and hence prevents the service running on future boots as it's no longer needed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Failed RPM database migrations
The reason it hadn't completed is that rpmdb-migrate.service was enabled on that machine. Enabling (and starting) that service made it complete. Tom On 28/10/2022 12:24, Tom Hughes via devel wrote: I have one machine that has failed. It was an upgrade from 35 to 36 done using dnf distro-sync but I have plenty of others done the same way that worked. One difference is that it's a machine that wasn't upgraded until August while other ones were done back in May as a result of which the upgrade was: from rpm-4.17.1-3.fc35.x86_64 to rpm-4.17.1-3.fc36.x86_64 while other machines were more like: from rpm-4.17.0-4.fc35.x86_64 to rpm-4.17.0-10.fc36.x86_64 Tom On 28/10/2022 11:49, Richard W.M. Jones wrote: https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2 https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr https://bugzilla.redhat.com/2042099 The RPM database is supposed to move from /var/lib/rpm to /usr/lib/sysimage/rpm. This was supposed to happen automatically when you upgraded the rpm package from an earlier version to 4.17.0-10.fc36 (Feb-Mar 2022). On several machines it is reported that the migration was only half- completed. The symptoms are that the RPM database is still in /var/lib/rpm (/usr contains symlinks to it). See typical output from failed & successful migrations at the end of the email. So _if_ you have rpm >= 4.17.0-10.fc36 installed: - Do you see the symptom of a failed migration? Or does it appear to be successful? (Or neither case??) - Did you: * Install F37 or Rawhide from scratch? * Upgrade using ordinary dnf update or similar? * Upgrade using dnf system-upgrade? * Some other install/upgrade method? Rich. ** After a failed migration: ** $ ls -la /var/lib/rpm total 339004 drwxr-xr-x. 2 root root 4096 Feb 16 2022 . drwxr-xr-x. 76 root root 4096 Aug 23 13:28 .. -rw-r--r--. 1 root root 0 Oct 18 14:28 .migratedb -rw-r--r--. 1 root root 347095040 Oct 26 16:50 rpmdb.sqlite -rw-r--r--. 1 root root 32768 Oct 27 15:28 rpmdb.sqlite-shm -rw-r--r--. 1 root root 0 Oct 26 16:50 rpmdb.sqlite-wal -rw-r--r--. 1 root root 0 Feb 16 2022 .rpm.lock $ ls -la /usr/lib/sysimage/rpm total 8 drwxr-xr-x. 2 root root 4096 Oct 5 12:05 . drwxr-xr-x. 3 root root 4096 Feb 9 2022 .. lrwxrwxrwx. 1 root root 34 Oct 18 14:28 .migratedb -> ../../../../var/lib/rpm/.migratedb lrwxrwxrwx. 1 root root 36 Oct 18 14:28 rpmdb.sqlite -> ../../../../var/lib/rpm/rpmdb.sqlite lrwxrwxrwx. 1 root root 40 Oct 18 14:28 rpmdb.sqlite-shm -> ../../../../var/lib/rpm/rpmdb.sqlite-shm lrwxrwxrwx. 1 root root 40 Oct 18 14:28 rpmdb.sqlite-wal -> ../../../../var/lib/rpm/rpmdb.sqlite-wal lrwxrwxrwx. 1 root root 33 Oct 18 14:28 .rpm.lock -> ../../../../var/lib/rpm/.rpm.lock ** After a successful migration: ** $ ls -la /var/lib/rpm lrwxrwxrwx. 1 root root 26 Sep 5 13:35 /var/lib/rpm -> ../../usr/lib/sysimage/rpm $ ls -la /usr/lib/sysimage/rpm total 316324 drwxr-xr-x. 2 root root 91 Sep 17 23:03 . drwxr-xr-x. 3 root root 17 Aug 9 14:27 .. -rw-r--r--. 1 root root 323878912 Oct 27 16:12 rpmdb.sqlite -rw-r--r--. 1 root root 32768 Oct 28 10:45 rpmdb.sqlite-shm -rw-r--r--. 1 root root 0 Oct 27 16:12 rpmdb.sqlite-wal -rw-r--r--. 1 root root 0 Sep 5 13:53 .rpm.lock -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Failed RPM database migrations
I have one machine that has failed. It was an upgrade from 35 to 36 done using dnf distro-sync but I have plenty of others done the same way that worked. One difference is that it's a machine that wasn't upgraded until August while other ones were done back in May as a result of which the upgrade was: from rpm-4.17.1-3.fc35.x86_64 to rpm-4.17.1-3.fc36.x86_64 while other machines were more like: from rpm-4.17.0-4.fc35.x86_64 to rpm-4.17.0-10.fc36.x86_64 Tom On 28/10/2022 11:49, Richard W.M. Jones wrote: https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2 https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr https://bugzilla.redhat.com/2042099 The RPM database is supposed to move from /var/lib/rpm to /usr/lib/sysimage/rpm. This was supposed to happen automatically when you upgraded the rpm package from an earlier version to 4.17.0-10.fc36 (Feb-Mar 2022). On several machines it is reported that the migration was only half- completed. The symptoms are that the RPM database is still in /var/lib/rpm (/usr contains symlinks to it). See typical output from failed & successful migrations at the end of the email. So _if_ you have rpm >= 4.17.0-10.fc36 installed: - Do you see the symptom of a failed migration? Or does it appear to be successful? (Or neither case??) - Did you: * Install F37 or Rawhide from scratch? * Upgrade using ordinary dnf update or similar? * Upgrade using dnf system-upgrade? * Some other install/upgrade method? Rich. ** After a failed migration: ** $ ls -la /var/lib/rpm total 339004 drwxr-xr-x. 2 root root 4096 Feb 16 2022 . drwxr-xr-x. 76 root root 4096 Aug 23 13:28 .. -rw-r--r--. 1 root root 0 Oct 18 14:28 .migratedb -rw-r--r--. 1 root root 347095040 Oct 26 16:50 rpmdb.sqlite -rw-r--r--. 1 root root 32768 Oct 27 15:28 rpmdb.sqlite-shm -rw-r--r--. 1 root root 0 Oct 26 16:50 rpmdb.sqlite-wal -rw-r--r--. 1 root root 0 Feb 16 2022 .rpm.lock $ ls -la /usr/lib/sysimage/rpm total 8 drwxr-xr-x. 2 root root 4096 Oct 5 12:05 . drwxr-xr-x. 3 root root 4096 Feb 9 2022 .. lrwxrwxrwx. 1 root root 34 Oct 18 14:28 .migratedb -> ../../../../var/lib/rpm/.migratedb lrwxrwxrwx. 1 root root 36 Oct 18 14:28 rpmdb.sqlite -> ../../../../var/lib/rpm/rpmdb.sqlite lrwxrwxrwx. 1 root root 40 Oct 18 14:28 rpmdb.sqlite-shm -> ../../../../var/lib/rpm/rpmdb.sqlite-shm lrwxrwxrwx. 1 root root 40 Oct 18 14:28 rpmdb.sqlite-wal -> ../../../../var/lib/rpm/rpmdb.sqlite-wal lrwxrwxrwx. 1 root root 33 Oct 18 14:28 .rpm.lock -> ../../../../var/lib/rpm/.rpm.lock ** After a successful migration: ** $ ls -la /var/lib/rpm lrwxrwxrwx. 1 root root 26 Sep 5 13:35 /var/lib/rpm -> ../../usr/lib/sysimage/rpm $ ls -la /usr/lib/sysimage/rpm total 316324 drwxr-xr-x. 2 root root91 Sep 17 23:03 . drwxr-xr-x. 3 root root17 Aug 9 14:27 .. -rw-r--r--. 1 root root 323878912 Oct 27 16:12 rpmdb.sqlite -rw-r--r--. 1 root root 32768 Oct 28 10:45 rpmdb.sqlite-shm -rw-r--r--. 1 root root 0 Oct 27 16:12 rpmdb.sqlite-wal -rw-r--r--. 1 root root 0 Sep 5 13:53 .rpm.lock -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Explicit dependency on systemd-rpm-macros now required?
On 14/09/2022 12:11, Florian Weimer wrote:
I see some new build failures in rawhide related to systemd RPM macros:
Processing files: opencryptoki-3.18.0-4.fc38.s390x
error: File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
error: File must begin with "/": %{_unitdir}/pkcsslotd.service
[…]
RPM build errors:
File must begin with "/": %{_tmpfilesdir}/opencryptoki.conf
File must begin with "/": %{_unitdir}/pkcsslotd.service
Child return code was: 1
EXCEPTION: [Error()]
Is this a package problem (missing dependency on systemd-rpm-macros), or
is this something that should be fixed at the buildroot level?
Guidelines say yes, you do need a BR on that:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: Confused about what to do about a ticket
On 26/08/2022 14:48, Ron Olson wrote: https://bugzilla.redhat.com/show_bug.cgi?id=2114563 was reported against Swift on Rawhide. I fixed the issue and responded on 8/4 that the Koji build was successful, but I got two additional, presumably automated, notes from Ben Cotton and Miro that suggest something else needs to be done. Since this is/was a rawhide build there’s nothing to “fedpkg update” as I recall, so I guess what I’m asking is what should I do to make it clear that Swift is working for Rawhide/F37? I admit I’ve always been kind-of unsure how Rawhide works insofar as I’ve never submitted a “formal update” to it (i.e. the aforementioned “fedpkg update” command). Well it was reported before branching and you fixed it but didn't actually close it so it looks like it is still an active bug and hence got automatically moved to F37 and added as a blocker to the FTBFS bug. If it was fixed before branching, as appears to be the case then the fix is in F37 now so you can just close it NEXTRELEASE. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Bugzilla: You can't ask Lennart Poettering because that account is disabled.
On 02/07/2022 11:35, Marius Schwarz wrote: Am 02.07.22 um 10:37 schrieb Adam Williamson: Probably not, no. Lennart hasn't maintained PA upstream or downstream for a long time. The current downstream maintainer is Wim Taymans (I think). Can we change the defaults for PA inside bugzilla to Wim and transfer the open tickets to him? it does not make sense to have Leonard as default assignee if the accoutn is disabled. Well that is just a matter of who is the main-admin of the package so the package owner can change it. Strictly speaking Lennart is still the main-admin on pulseaudio though Wim is also a committer so would have been cced on the bug if it was a pulseaudio bug. But it isn't a pulseaudio bug, it's a pavucontrol bug, and Wim is not a committer there which is why he isn't cced. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 Proposal: MAC Address Policy none (System-Wide Change)
On 27/06/2022 17:09, Tom Hughes via devel wrote: On 27/06/2022 17:05, Thomas Haller wrote: On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote: Twice now I have had to go and reconfigure my networks after a Fedora upgrade has changed the MAC assignment policy. Interesting. Are you sure it was twice? I thought it changed "only" once in F31 (2019). No it has just changed again in F36 at least for bridges, back to what it was before the previous change I believe. I've had a look through the git log for my DNS and taking one machine as an example: initially - bridge had MAC of 00:b0:c2:02:4c:f3 from member Aug 2015 (F22) - bridge changed to 1a:81:14:46:3c:c7 Jan 2020 (F31) - bridge changed to fe:e3:75:bd:6a:8c May 2022 (F36) - bridge changed back to 1a:81:14:46:3c:c7 Only the first one corresponds to a member, so I think F22 is where persistent addresses were first introduced. I'm not sure what happened in F31 than then got reverted in F36. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 Proposal: MAC Address Policy none (System-Wide Change)
On 27/06/2022 17:05, Thomas Haller wrote: On Mon, 2022-06-27 at 13:09 +0100, Tom Hughes via devel wrote: Twice now I have had to go and reconfigure my networks after a Fedora upgrade has changed the MAC assignment policy. Interesting. Are you sure it was twice? I thought it changed "only" once in F31 (2019). No it has just changed again in F36 at least for bridges, back to what it was before the previous change I believe. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 Proposal: MAC Address Policy none (System-Wide Change)
ACAddressPolicy=none` for the device types where this causes the most issues (bridge/bond/team). == Feedback == This was also discussed on upstream systemd mailing list [https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html here]. The upstream systemd maintainers' opinion is that the current udev behavior is desirable, but accepts that distributions (or network stacks such as NetworkManager) may choose to change the default depending on their needs ([https://lists.freedesktop.org/archives/systemd-devel/2022-May/047943.html reference]). The goal here is to find out what the Fedora community thinks is the most appropriate default. The RHEL-9 bug is [https://bugzilla.redhat.com/show_bug.cgi?id=1921094 [rh#1921094]]. == Benefit to Fedora == Pros: - Consistent behavior with RHEL8 and RHEL9. - Avoid race of udev and the tool that creates the interface. - Bridge and bond interfaces can get the MAC addresses from their first port. In the case of `MACAddressPolicy=none` for a bond (or bridge) the bond will get a MAC related to one of its physical NIC devices. In the case of provisioning new systems (especially in a large datacenter) information about the server can be used to configure the network environment (DHCP, Firewall, etc) before the server is ever even powered on. This does mean that you may have to update your network environment configuration if you replace a NIC (con), but that you won't have to update your network environment configuration if you re-install your server (pro), which is what you'd have to do now with `MACAddressPolicy=persistent`. Cons: - Deviate from upstream systemd. It is desirable that RHEL and Fedora behaves similar. A possible outcome could be the current behavior stays and RHEL 10 would change behavior. On the other hand, different distributions (or even Fedora spins) have different uses and needs. Deviating might be fine. In the same vein, there is also a desire to stay close to upstream systemd behavior. But the uses of systemd project go beyond Fedora/RHEL, so deviating here may also be fine. == Scope == * Proposal owners: The main goal of this request is to generate productive discussion and find the desired behavior. The implementation/changes are either way very simple. * Other developers: Other projects that wish a certain MAC address are welcome to set it for their devices. Including using udev's MACAddressPolicy. * Release engineering: Not needed for this change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == After the change, the MAC address for the affected device types changes. == How To Test == 1) Create a software device two times, for example `ip link add type bridge`. Note that the MAC address is either stable or random, depending on the `MACAddressPolicy=`. 2) Note that if the software device has the MAC address set initially, udev does not change it (`ip link add address aa:aa:aa:aa:aa:aa type bridge`). That depends on `/sys/class/net/$dev/addr_assign_type`. 3) Create a bridge/bond interface without setting the MAC address. Note that if `MACAddressPolicy=none`, the MAC address is random at first. Note that attaching the first port will update the controller's MAC address. On the other hand, with `MACAddressPolicy=persistent`, the MAC address of the controller is fixed and not inherited from the port. 4) Run ip monitor link & while : ; do ip link del xxx ip link add name xxx type dummy \ && ip link set xxx addr aa:00:00:00:00:00 \ && ip link show xxx | grep -q aa:00:00:00:00:00 \ || break done to reproduce the race between a simple tool and udev changing the MAC address. == User Experience == Bond/bridge devices would again get assigned the MAC address of the first NIC added to the device. If we chose to not limit the scope of this change to just bonds/bridges then all software devices would get randomly assigned MAC addresses. == Dependencies == None. == Contingency Plan == If the change is rejected, nothing needs to be done. The change itself will be simple to implement. Contingency deadline: beta freeze Blocks release? No == Documentation == TODO. == Release Notes == -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 proposal: Deprecate openssl1.1 package (System-Wide Change)
On 27/06/2022 10:02, Richard W.M. Jones wrote: On Mon, Jun 27, 2022 at 09:11:29AM +0100, Tom Hughes wrote: On 27/06/2022 08:53, Richard W.M. Jones wrote: On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: Dear Richard, If the only problem is legacy (and unsafe) ciphersuites, loading the legacy provider will solve this problem. Any clues on how to do that? https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers Results unclear. Loading legacy + default doesn't seem to give any errors, but I still see the same errors in the tests. I might be loading these providers in the wrong way however. The code is here: https://github.com/rwmjones/cpython/commits/python-2.7-openssl-3 That looks about right, or at last it looks very similar to what I did elsewhere. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 proposal: Deprecate openssl1.1 package (System-Wide Change)
On 27/06/2022 08:53, Richard W.M. Jones wrote: On Fri, Jun 24, 2022 at 01:20:27PM +0200, Dmitry Belyavskiy wrote: Dear Richard, If the only problem is legacy (and unsafe) ciphersuites, loading the legacy provider will solve this problem. Any clues on how to do that? https://wiki.openssl.org/index.php/OpenSSL_3.0#Providers Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: upstream systemd discussion about MACAddressPolicy for bonds and bridges
On 10/05/2022 14:57, Dusty Mabe wrote: On 5/10/22 02:05, Tom Hughes via devel wrote: On 10/05/2022 03:12, Dusty Mabe wrote: Just wanted to point interested people in the direction of an upstream discussion about how (by default) the MAC address should get set for bond and bridge devices. https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html A few of us were originally going to propose a change to Fedora to change the current behavior back, but it was suggested we take the discussion upstream to hash out the merits there. All I can say is, no, just leave it alone. Having fixed all my machines two years ago when it stopped generating persistent addresses I have just spent this weekend doing it again now that F36 has gone back to them. I'm not aware of any change in behavior in F36, but maybe I missed something. F36 has gone back to using a persistent MAC calculated from the machine ID and bridge name. I'm not sure what F35 was doing but believe me when I say that all my bridges changed MAC on upgrade and they've now gone back to the address they had until late 2019 or early 2020. I don't care what address my bridges have, so long as it is fixed so that DHCP can allocate addresses against it, but I do prefer not to have to fix all my DHCP and DNS every time the policy flip flops and upgrades break my networks! With the current policy you'll get a new MAC every time you re-install a machine. Is that what you want? It doesn't bother me too much as I expect to be reconfiguring things then. The upstream proposal is to make it based on the actual MAC of the NIC(s) again. The problem is which NIC exactly? As I understand it's whatever interface gets added first so may be racy. From that point of view a persistent address seems better. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: upstream systemd discussion about MACAddressPolicy for bonds and bridges
On 10/05/2022 03:12, Dusty Mabe wrote: Just wanted to point interested people in the direction of an upstream discussion about how (by default) the MAC address should get set for bond and bridge devices. https://lists.freedesktop.org/archives/systemd-devel/2022-May/047893.html A few of us were originally going to propose a change to Fedora to change the current behavior back, but it was suggested we take the discussion upstream to hash out the merits there. All I can say is, no, just leave it alone. Having fixed all my machines two years ago when it stopped generating persistent addresses I have just spent this weekend doing it again now that F36 has gone back to them. I don't care what address my bridges have, so long as it is fixed so that DHCP can allocate addresses against it, but I do prefer not to have to fix all my DHCP and DNS every time the policy flip flops and upgrades break my networks! Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 06/04/2022 15:36, Chris Adams wrote: One add to that: just because a system has UEFI doesn't mean it supports all the same boot methods equally. I do a lot of network installs, and early UEFI systems I tried had broken PXE support (not sure when this may have changed, as I then didn't try for a while). Setting up a UEFI PXE boot server is (in my experience) more complicated. UEFI also supports HTTP boot, which is an improvement (the sooner TFTP can die the better), but it's not a widespread (or at least, sometimes not as easy to call). This is certainly why I have a lot of UEFI capable machines using MBR boot because it's only recently that I got network booting to work with UEFI and the install would install as MBR if it was booted from a legacy network book. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 05/04/2022 18:51, Robbie Harwood wrote: Right, you need the EFI partition (EFI System Partition, or ESP). I don't remember what we default those to these days - I usually make about 600M, but I need it larger for testing stuff. The partition scheme also needs to be GPT, not MBR. Once that's all set, the EFI grub2 packages need to be installed, but that's the easy part :) I actually checked that on wikipedia because I wondered if it had to be GPT and it seemed to say MBR was supported? https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Disk_device_compatibility Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 05/04/2022 18:38, Neal Gompa wrote: On Tue, Apr 5, 2022 at 1:31 PM Tom Hughes via devel wrote: On 05/04/2022 15:52, Ben Cotton wrote: * There is no migration story from Legacy BIOS to UEFI - repartitioning effectively mandates a reinstall. As a result, we don’t drop support for existing Legacy BIOS systems yet, just new installations. This is where I have a problem with this, the fact that there is no upgrade path - virtually my entire installed base of Fedora is running legacy BIOS and not being able to upgrade them will be something of a headache. Is it actually true though? You need to be able to find some space for an EFI partition but assuming that can be done is there some other reason you can't migrate from BIOS to UEFI booting? In Fedora Linux default partitioning for all but Server, it is possible to reconfigure existing systems to UEFI. Fedora Server is screwed because they use XFS and you cannot shrink an XFS volume. Fedora < 33 used ext4 by default, and you can do offline shrink and open up space for an ESP. In Fedora >= 33, ext4 is still used for /boot and you can resize that. Alternatively, the Btrfs / can be resized while the system is running to make room for an ESP. I generally do my own partitioning rather than using the default, and all my systems are ext4 so sounds like it's not necessarily impossible. I'm actually looking at stealing swap on some of them, or just growing disks for VMs. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 05/04/2022 15:52, Ben Cotton wrote: * There is no migration story from Legacy BIOS to UEFI - repartitioning effectively mandates a reinstall. As a result, we don’t drop support for existing Legacy BIOS systems yet, just new installations. This is where I have a problem with this, the fact that there is no upgrade path - virtually my entire installed base of Fedora is running legacy BIOS and not being able to upgrade them will be something of a headache. Is it actually true though? You need to be able to find some space for an EFI partition but assuming that can be done is there some other reason you can't migrate from BIOS to UEFI booting? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Landing a larger-than-release change (distrusting SHA-1 signatures)
On 15/03/2022 22:45, Robert Relyea wrote: 1) in fedora 37, provide a policy that turns SHA-1 off. in our testing, we encourage people to run with that policy and write bugs against components. That policy already exists in Fedora 34 and 35 where the FUTURE policy does not allow SHA1 in signature algorithms. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Curl-minimal as default (System-Wide Change proposal)
On 10/03/2022 11:51, Neal Gompa wrote: On Thu, Mar 10, 2022 at 6:49 AM Daniel P. Berrangé wrote: Everyone has their own conflicting idea of what is 'minimal'. There's no nice way to solve this problem in Fedora without curl upstream supporting dlopen modules per protoocol, allowing us to package each protocol independantly. Has anyone asked upstream about that yet? There is a brief discussion at https://github.com/curl/curl/issues/349 where upstream called it an "interesting idea" but it doesn't look like anybody took it on. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Why I get some random notifications from discourse?
On 25/02/2022 19:08, Vít Ondruch wrote: Is that intentional that i get some random notifications from Discourse or what is going on? In past month, I was notified about following topics: * Join us for the EPEL office hours every month [Fedora] epel * Self-intro glaringgibbon [Fedora] introductions * It's #FedoraShareYourScreen week [Fedora] events * Tempted to switch full-time to Fedora, but I got some noob questions [Fedora] introductions And I wonder why? Does Discourse want to be completely muted or what? Yes I was wondering why I seemed to be subscribed to some random things as soon as I signed up... I think I've managed to unsubscribe from them all now after a bit of fiddling but it's not very clear from the emails which rule exactly has triggered them. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Is NetworkManager-wait-online.service necessary by default?
On 24/02/2022 16:28, Tom Hughes wrote: On 24/02/2022 16:25, Cole Robinson wrote: On 2/23/22 5:22 PM, Tom Hughes via devel wrote: On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote: a) change libvirt-daemon-driver-storage Requires:libvirt-daemon-driver-storage-iscsi to Suggests:libvirt-daemon-driver-storage-iscsi, More generally why does installing libvirt neeed to force installation of about ten storage drivers and all their dependencies - why can't the user choose to remove some of the more obscure ones? libvirt has a modularized packaging split. libvirt-daemon-driver-storage pulls in every possible storage driver + lib that libvirt can use. Or you can install libvirt-daemon-driver-storage-XXX individual sub packages to get only the bits your app will use. I was basing what I said on the fact that trying to remove libvirt-daemon-driver-storage-iscsi wanted to remove the whole of libvirt on my machine: Ah but that is mostly auto clean. Though libvirt-daemon-kvm is a dependency as you say and don't I need that to run any kvm based vm? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Is NetworkManager-wait-online.service necessary by default?
On 24/02/2022 16:25, Cole Robinson wrote: On 2/23/22 5:22 PM, Tom Hughes via devel wrote: On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote: a) change libvirt-daemon-driver-storage Requires:libvirt-daemon-driver-storage-iscsi to Suggests:libvirt-daemon-driver-storage-iscsi, More generally why does installing libvirt neeed to force installation of about ten storage drivers and all their dependencies - why can't the user choose to remove some of the more obscure ones? libvirt has a modularized packaging split. libvirt-daemon-driver-storage pulls in every possible storage driver + lib that libvirt can use. Or you can install libvirt-daemon-driver-storage-XXX individual sub packages to get only the bits your app will use. I was basing what I said on the fact that trying to remove libvirt-daemon-driver-storage-iscsi wanted to remove the whole of libvirt on my machine: % sudo dnf erase libvirt-daemon-driver-storage-iscsi* Dependencies resolved. Package Arch Version Repo Size Removing: libvirt-daemon-driver-storage-iscsi x86_64 7.6.0-5.fc35 @updates 24 k libvirt-daemon-driver-storage-iscsi-direct x86_64 7.6.0-5.fc35 @updates 32 k Removing dependent packages: libvirt-daemon-kvm x86_64 7.6.0-5.fc35 @updates 0 vagrant-libvirt noarch 0.4.1-3.fc35 @fedora 229 k Removing unused dependencies: glusterfs-cli x86_64 9.5-1.fc35 @updates 493 k guestfs-tools x86_64 1.47.3-1.fc35 @updates 25 M hexedit x86_64 1.5-2.fc35 @fedora 77 k libacl i686 2.3.1-2.fc35 @fedora 35 k libglusterd0x86_64 9.5-1.fc35 @updates 15 k libguestfs x86_64 1:1.46.2-1.fc35 @updates 3.8 M libguestfs-appliancex86_64 1:1.46.2-1.fc35 @updates 2.3 M libguestfs-xfs x86_64 1:1.46.2-1.fc35 @updates 9 libtpms x86_64 0.9.2-0.20220106gite81d634c27.fc35.0 @updates 986 k libvirt-daemon-driver-interface x86_64 7.6.0-5.fc35 @updates 593 k libvirt-daemon-driver-nodedev x86_64 7.6.0-5.fc35 @updates 650 k libvirt-daemon-driver-nwfilter x86_64 7.6.0-5.fc35 @updates 683 k libvirt-daemon-driver-qemu x86_64 7.6.0-5.fc35 @updates 2.5 M libvirt-daemon-driver-secretx86_64 7.6.0-5.fc35 @updates 585 k libvirt-daemon-driver-storage x86_64 7.6.0-5.fc35 @updates 0 libvirt-daemon-driver-storage-core x86_64 7.6.0-5.fc35 @updates 767 k libvirt-daemon-driver-storage-disk x86_64 7.6.0-5.fc35 @updates 32 k libvirt-daemon-driver-storage-gluster x86_64 7.6.0-5.fc35 @updates 40 k libvirt-daemon-driver-storage-logical x86_64 7.6.0-5.fc35 @updates 32 k libvirt-daemon-driver-storage-mpath x86_64 7.6.0-5.fc35 @updates 16 k libvirt-daemon-driver-storage-rbd x86_64 7.6.0-5.fc35 @updates 44 k libvirt-daemon-driver-storage-scsi x86_64 7.6.0-5.fc35 @updates 24 k libvirt-daemon-driver-storage-sheepdog x86_64 7.6.0-5.fc35 @updates 20 k libvirt-daemon-driver-storage-zfs x86_64 7.6.0-5.fc35 @updates 24 k qemu-kvm-core x86_64 2:6.1.0-14.fc35 @updates 0 rubygem-excon noarch 0.79.0-1.fc35 @fedora 98 k rubygem-fog-corenoarch 2.2.4-2.fc35 @fedora 118 k rubygem-fog-jsonnoarch 1.2.0-7.fc35 @fedora 3.9 k rubygem-fog-libvirt noarch 0.8.0-2.fc35 @fedora 73 k rubygem-fog-xml noarch 0.1.3-7.fc35 @fedora 8.3 k rubygem-formatador noarch 0.2.5-12.fc35 @fedora 9.9 k rubygem-multi_json noarch 1.15.0-3.fc35 @fedora 33 k rubygem-rexml noarch 3.2.5-151.fc35 @fedora 399 k rubygem-ruby-libvirtx86_64 0.7.1-13.fc35 @fedora 288 k superminx86_64 5.3.1-1.fc35 @fedora 1.5 M swtpm x86_64 0.7.0-2.20211109gitb79fd91.fc35 @updates 218 k swtpm-libs x86_64 0.7.0-2.20211109gitb79fd91.fc35 @updates 99 k swtpm-tools x86_64 0.7.0-2.20211109gitb79fd91.fc35 @updates 272 k zerofreex86_64 1.1.1-8.fc35 @fedora 54 k zfs-fusex86_64 0.7.2.2-20.fc35 @fedora 6.0 M Transaction Summary
Re: Is NetworkManager-wait-online.service necessary by default?
On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote: a) change libvirt-daemon-driver-storage Requires:libvirt-daemon-driver-storage-iscsi to Suggests:libvirt-daemon-driver-storage-iscsi, More generally why does installing libvirt neeed to force installation of about ten storage drivers and all their dependencies - why can't the user choose to remove some of the more obscure ones? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On 24/01/2022 12:15, Kaleb Keithley wrote: On Sat, Jan 22, 2022 at 2:28 PM Kaleb Keithley <mailto:kkeit...@redhat.com>> wrote: The long double change is an ABI change, so this is kind of expected. Mass rebuild unfortunately doesn't go according to the dependency graph (and unfortunately it isn't a tree, there are cycles). Indeed. fmt has not been rebuilt, or more accurately, it failed in the mass rebuild. Specifically the ppc64le build failed. see https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199 <https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199> I may have missed the email about this. (Sorry if I have.) Is there an action on someone's part to fix the assembler, or fix the assembly that gcc-12 is emitting on ppc64le that the assembler is puking on? Yes as Jakub said yesterday morning that is https://gcc.gnu.org/PR104172 and he's waiting for a decision from the powerpc backend maintainers on the best fix. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?
On 24/01/2022 00:30, Robert-André Mauchin wrote:
During the installation, all the files are copied, then renamed by rpm
(no idea why it works like this).
Probably so the file is replaced atomically, and you either
have the old or new version but never a partial version.
It works fast in a Mock chroot but incredibly slow on bare metal.
I've done a small test of moving files:
[root@cassini icons]# mkdir test
[root@cassini icons]# for (( i = 0; i < 1; i++ )) do > test/file_$i;
done
[root@cassini icons]# cd test
On host:
time $(for f in *; do mv "$f" "${f%}.txt"; done)
real 2m3,500s
user 0m3,966s
sys 2m0,431s
In nspawn container:
sh-5.1# time $(for f in *; do mv "$f" "${f%}.txt"; done)
real 0m6.702s
user 0m4.237s
sys 0m3.344s
Since papirus-icon-theme contains more than 100,000 (small) files, it is
a problem. One minute of waiting is ok, 20 mn is not.
What can cause this? I read that nspawn virtualizes the file system,
could it be file system related on the host? (I use btrfs btw)
Do you have the nosync plugin enabled in your mock? That
will shim system calls that try and sync to disk and suppress
the actual sync in the name of greater performance.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: gcc-12.0.0-0.4.fc36 in rawhide
On 23/01/2022 10:39, Vitaly Zaitsev via devel wrote: On 14/01/2022 15:31, Jakub Jelinek wrote: gcc 12 snapshot has landed as the system compiler into rawhide today. Another ICE on ppc64le with all packages contains catch2 library. Task: https://koji.fedoraproject.org/koji/taskinfo?taskID=81641415 I've got https://bugzilla.redhat.com/show_bug.cgi?id=2043040 open for that - possibly the same as 2043517. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'
On 21/01/2022 09:29, Tom Hughes via devel wrote: On 21/01/2022 09:08, Richard W.M. Jones wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000 This seems like a compiler bug or a bug in the standard switches being added by RPM on ppc64le. SLOF itself does not appear to add or adjust the -mtune flag. That's not even a ppc64le build, it's an x86_64 build using a cross compiler from the gcc-powerpc64-linux-gnu package - that is actually still 11.2 and hasn't been upgraded to 12 yet. I don't know where -mtune=generic comes from but a normal ppc64le build uses -mcpu=power8 -mtune=power8 as it's defaults. Ah the problem is that -mtune=generic is the x864_64 default which the spec is passing in CFLAGS because you're building on x86_64 but that doesn't work for the ppc64 cross compiler. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'
On 21/01/2022 09:08, Richard W.M. Jones wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000 This seems like a compiler bug or a bug in the standard switches being added by RPM on ppc64le. SLOF itself does not appear to add or adjust the -mtune flag. That's not even a ppc64le build, it's an x86_64 build using a cross compiler from the gcc-powerpc64-linux-gnu package - that is actually still 11.2 and hasn't been upgraded to 12 yet. I don't know where -mtune=generic comes from but a normal ppc64le build uses -mcpu=power8 -mtune=power8 as it's defaults. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Missing ownership /usr/share/locale/ directories
On 01/01/2022 12:01, Fabio Valentini wrote: I'm pretty sure I won't add ownership of /usr/share/locale/mo to literally dozens of packages just so this minor issue is "fixed". I think the filesystem package should create and own it. Surely a symlink from mo to ro would be better so that people can set LANG=ro (the correct code) and get all the translations for Moldovan regardless of whether packages use the old or new code for it. Ideally of course upstreams should be poked to fix their packages to use the correct code. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On 30/12/2021 07:02, Chris Murphy wrote: On Wed, Dec 29, 2021 at 8:19 AM Tom Hughes via devel wrote: I don't see how this is FHS compliant, which in turn would make it non-compliant with Fedora Packaging Guidelines, namely: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_filesystem_layout The FHS describes /usr here: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html#purpose18 as "/usr is shareable, read-only data" which clearly does not apply to a database that changes. In practice it is read-only data, except when software is being installed or updated. The FHS is a PITA sometimes, but it's not advocating for systems that can't be updated or changed.. As I demonstrated later in my email the contents of /var/lib/rpm do change at other times though. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
* symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm` Otherwise, the change should be invisible to users. == Dependencies == * `rpm-ostree` probably should make `/usr/share/rpm` a symlink to `/usr/lib/sysimage/rpm`, rather than the reverse as it is currently. * `PackageKit` might use inotify on `/var/lib/rpm` need to check if it does and whether it should be changed or add the additional path == Contingency Plan == * Contingency mechanism: Revert the change, try again the next Fedora release. * Contingency deadline: Beta freeze * Blocks release? Yes -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)
On 06/12/2021 23:53, Samuel Sieb wrote: On 12/6/21 09:47, Sérgio Basto wrote: On Mon, 2021-12-06 at 12:12 -0500, Matthew Miller wrote: On Mon, Dec 06, 2021 at 11:59:05AM +, Sérgio Basto wrote: Correct me, if I'm wrong, people to avoid put password in every sudo command, modify sudo to not ask password . And this behavior is a big hole of security , if user is compromised, attacker will have root access for free. I imagine some people do that, but it's certainly not the default. well I'm asking if is not a common behavior ? It's not a common behaviour that I've heard of. Some other distros cache the authentication so that you don't have to enter the password again within a certain period of time. That's a nice option. Just like Fedora does you mean? In fact as far as I know it's the upstream default for sudo! Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: cmake on Rawhide is broken
On 03/12/2021 17:48, Simo Sorce wrote:
On Fri, 2021-12-03 at 17:25 +, Tom Hughes via devel wrote:
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
On 03/12/2021 17:41, Miro Hrončok wrote:
The bundled openssl in opae worries me still, but that's not causing
issues in dependency resolution any more.
I think FESCo should create a strict policy on bundling cryptographic
libraries.
Well bundling a binary from upstream is already against policy
so I don't see how that helps.
The problem isn't a lack of policy, it's that the packager didn't
notice those files or didn't realise they weren't allowed.
So the opae-2.0.0 tarball has libcrypto embedded-in what is the process
now ?
This stuff is used for a Python tool that is used to sign some binary,
almost certainly there is absolutely no reason to bundle libcrypto, the
tool should probably be unbundled and turned into a regular python
module opae depends on.
It has an openssl.py that dlopen's the so:
def _find_openssl_so(self, version, *paths):
candidates = list(paths)
crypto = util.find_library('crypto')
if crypto:
candidates.insert(0, crypto)
for c in candidates:
dll = CDLL(c)
So that might already find the system one if you have it
but probably only if you have openssl-devel installed to
get the .so link with no version.
But dropping the binaries and doing a relatively minor
patch to that is likely all that is needed.
Do we know who is the current maintainer?
The changelog seem to imply Intel dropped it into Fedora and never
maintained it after Sep 17 2020 ...
Well src.fpo says trix aka Tom Rix is the maintainer.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: cmake on Rawhide is broken
On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote: On 03/12/2021 17:41, Miro Hrončok wrote: The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more. I think FESCo should create a strict policy on bundling cryptographic libraries. Well bundling a binary from upstream is already against policy so I don't see how that helps. The problem isn't a lack of policy, it's that the packager didn't notice those files or didn't realise they weren't allowed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Trying to take an orphaned package
On 21/11/2021 13:11, Stephen Snow wrote: And I login with my FAS ID and cannot "Take" the package since I am not a packager. So I ask again what steps am I missing here? I want to take over packaging something that is about to be removed from Fedora Linux since it has been orphaned, I have signed the agreements, I have asked to become a packager, and this is actually the second package I am trying to take over. You say you have "asked to become a packager" but what exactly do you mean by that? The official documentation on becoming a packager is here: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ But actually I think the old wiki version is much more useful in explaining how things work, especially if you're not coming at it from the position of submitting a new package: https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444 Basically you need to find somebody to sponsor you as a packager - normally that happens as part of having your first package review but obviously that doesn't work when you want to take over an existing package. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Trying to take an orphaned package
On 21/11/2021 15:01, Stephen Snow wrote: But actually I think the old wiki version is much more useful in explaining how things work, especially if you're not coming at it from the position of submitting a new package: And it tells me to read a document that doesn't apparently exist anymore. That's why I gave a link to the old version from the wiki history before it was replaced by a pointer to the new page. https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444 Basically you need to find somebody to sponsor you as a packager - normally that happens as part of having your first package review but obviously that doesn't work when you want to take over an existing package. So you see what I was talking about so many (years?!?!) ago, then recently too on this list. It is a common thing it seems that once a person steps up to ask for sponsorship something seems to happen. I am struck by the first line of your response "You say you have "asked to become a packager" but what exactly do you mean by that?" Well, quite simply what I stated, but yet I am being questioned about my sincereity and credibility immediately. I wasn't questioning your credibility, I was just confused because there's no formal place to lodge such a request as far as I know other than a review ticket blocking FE-SPONSOR which doesn't apply here. I was worried that you had filed some sort of request somewhere that nobody was looking. So back to what I was trying to say in my conversation here about some tool for assessing the prospective newbies like me who want to help but need a sponsor, I was thinking of an app that tests your knowledge and the discussion went towards a generic test package to show packaging knowledge with, then make sponsoring come easier for sponsors. Because this seems to be really the crux of the matter, trust or lack of it. I'm not aware of any previous discussions. I was just answering the questions you asked in your post today. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Trying to take an orphaned package
On 21/11/2021 16:06, Matthew Miller wrote: On Sun, Nov 21, 2021 at 10:01:00AM -0500, Stephen Snow wrote: Thanks read that back then. But actually I think the old wiki version is much more useful in explaining how things work, especially if you're not coming at it from the position of submitting a new package: And it tells me to read a document that doesn't apparently exist anymore. https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444 That page seems substantially (if not completely?) identical to the current doc at https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/ Ah you're quite right. That was a google fail on my part - the search that I did on "fedora become a packager" grouped that wiki page under the other docs page I mentioned and I didn't notice that wasn't the page the wiki linked to. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: openswan/libreswan VPNs and NetworkManager
Fedora also doesn't shop openswan so a plugin wouldn't be very useful. There does seem to be a plasma-nm-strongswan though, but not one for libreswan that I can see. Also NetworkManager's libreswan plugin used to be called openswan up to version 1.0.0 when it was renamed (libreswan is a fork of openswan) so I suspect the plasma-nm-openswan is really configuring the libreswan plugin now and nmcli may well still accept openswan as an alias I guess? Tom On 02/11/2021 18:16, Mattia Verga via devel wrote: That's the reason of my confusion: Fedora doesn't ship NM plugin for openswan, but ships libreswan and strongswan plugins. Yet, plasma-nm doesn't have an interface to create/manage libreswan or strongswan VPNs, but it has interface for openswan. Creating an openswan VPN connection either in plasma-nm or directly in nmcli seems to work in some way... but how, since there is no plugin? Inviato da ProtonMail mobile Messaggio originale On 2 Nov 2021, 15:23, Petr Pisar < ppi...@redhat.com> ha scritto: V Tue, Nov 02, 2021 at 02:08:58PM +, Mattia Verga via devel napsal(a): > mmm, but if I: > $ nmcli conn add type vpn vpn-type openswan > > it creates a vpn of vpn-type=org.freedesktop.NetworkManager.openswan, > while if I: > $ nmcli conn add type vpn vpn-type libreswan > > it creates a vpn-type=org.freedesktop.NetworkManager.libreswan > > Do you mean that both are using the same implementation even if they > seem to point to different plugins? > No. I think each plugin uses a different implementation. I made few mistakes in my previous reply and I explained them later. I'm sorry. -- Petr ___ 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 <https://docs.fedoraproject.org/en-US/project/code-of-conduct>/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org <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 <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 -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Considering ExcludeArch: %{ix86} for webkit2gtk3
On 22/10/2021 00:25, Michael Catanzaro wrote: Hi, I'm having trouble building webkit2gtk3-2.34.1 for i686 in rawhide. An example build failure [1] looks like: /usr/bin/ld.gold: fatal error: lib/libwebkit2gtk-4.0.so.37.55.4: mmap: failed to allocate 2108254132 bytes for output file: Cannot allocate memory Any ideas? I don't believe the builder is actually running out of memory because I'm using %limit_build and because a normal OOM almost always results in a SIGKILL. This issue seems to occur reliably (I tried three builds, it died three times) and only affects rawhide and only i686. F35 is fine and all other architectures are fine. An OOM is when the total memory usage of the system builds up over time. What has happened here is that the linker has tried to allocate 2Gb at once as a single chunk and the kernel was unable to do that. Is there a reason for using gold? Maybe the default bfd linker would manage to use less memory? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: protobuf 3.18.1 update coming to rawhide
On 18/10/2021 15:55, Adrian Reber wrote: Because of missing dependencies we had to disable the Java bindings which breaks the build of: 1. osmpbf Problem: package protobuf-java-3.14.0-6.fc35.noarch conflicts with protobuf-compiler > 3.14.0 provided by protobuf-compiler-3.18.1-1.fc36.x86_64 I've dropped the java bindings from osmpbf which should fix this. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: leap from f22 to f34 fairytale
On 11/10/2021 13:48, JT wrote: Nice. I did an update from F26-F33 last year doing one version at time instead of jumping more than one version... and had no major issues. I wonder how far back its possible to start from and walk through the version updates. I recently did F15-F34 though I did do it two versions at a time for the most part. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Updating sources file using fedpkg
On 17/06/2021 12:57, Ewoud Kohl van Wijngaarden wrote: After that, I'm looking for a command to update the sources file with new checksums so I can run: fedpkg new-sources I could not find such a command so until now I've been using sha512sum manually, but there must be a better way :) Well that will work for a local build but as it won't upload them to the lookaside it won't work in koji. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 15/06/2021 22:54, Neal Gompa wrote: On Tue, Jun 15, 2021 at 5:50 PM Fabio Valentini wrote: Different question: How is the runtime CPU feature detection / dispatch support in glibc coming along? Shouldn't this "work" by now? No idea, good question, though! If you mean feature level based loading of shared libraries via hwcaps then it is supposed to be supported in 2.33 which is in F34. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
On 08/06/2021 14:51, Stephen Gallagher wrote: I was thinking about suggesting a similar PAM module to convert existing hashes, but I suspect that we'd be coming up against some issues with security policy and separation of actions. Right now, I expect that SELinux permits PAM processes to have read-only access to /etc/shadow, but such a change would necessitate read/write access, which is riskier. It's also why PAM has separate activities for authentication, authorization and password-change. Surely it has to allow write as well because any authentication can already prompt for a password change if the password is expired? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: RPM build errors: Illegal char '@' (0x40) in: @2.15.0@
On 12/05/2021 09:22, Sandro Mani wrote: Provides: libimagequant = 2.15.0-1.fc35 libimagequant(x86-64) = 2.15.0-1.fc35 libimagequant.so.0()(64bit) Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgomp.so.1()(64bit) libgomp.so.1(GOMP_1.0)(64bit) libgomp.so.1(GOMP_4.0)(64bit) libgomp.so.1(OMP_1.0)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libm.so.6(GLIBC_2.27)(64bit) libm.so.6(GLIBC_2.29)(64bit) rtld(GNU_HASH) Processing files: libimagequant-devel-2.15.0-1.fc35.x86_64 error: Illegal char '@' (0x40) in: @2.15.0@ Provides: libimagequant-devel = 2.15.0-1.fc35 libimagequant-devel(x86-64) = 2.15.0-1.fc35 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: /usr/bin/pkg-config libimagequant.so.0()(64bit) RPM build errors: Illegal char '@' (0x40) in: @2.15.0@ Child return code was: 1 2.15.0 is the version of the package. Any ideas where this one comes from? Apparently not from elfdeps: Already reported and fixed upstream I think: https://github.com/ImageOptim/libimagequant/issues/54 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: How to handle pull request with git?
On 14/04/2021 14:28, Mark Wielaard wrote: I added the following line to my .git/config at the end of the [remote "origin"] section to be able to pull it: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* Then git pulled and checkout pr/4, made the changes, committed them and pushed them back, hoping that would update the pr. Is there anywhere that works? I don't think even github allows you to push back to the generated head for the PR like that. If the person who opened the PR allowed it then you can push to their original branch to update the PR - no idea if pagure supports that. Possibly src.fpo should reject pushes to the PR heads to avoid this kind of accident though. But it didn't, apparently I created a new origin/pr/4 branch, which I am now unable to delete because: $ git push origin --delete pr/4 remote: Branch deletion is not allowed remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw' remote: All changes have been rejected To ssh://pkgs.fedoraproject.org/rpms/valgrind ! [remote rejected] pr/4 (pre-receive hook declined) error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/valgrind' What did I do wrong and how do I fix this? You pushed a branch into source git which is bad as hey can't be deleted. I believe in principle you can ask an admin to delete it so long as no builds have been done from it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: questions about "Fedora Localization Statistics"
On 06/04/2021 16:19, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Apr 06, 2021 at 03:21:26PM +0100, Tom Hughes wrote: Specifically those numbers are from the languagePopulation elements in the most recent CLDR release. The data for DE in PL in CLDR specifically references a source: http://en.wikipedia.org/wiki/German_minority_in_Poland;>regional-official in part of Opole Voivodeship; in Poland 325 schools with primary instr in German, estimate 37000 students. Real figure probably higher. Though the numbers on that page don't get near the 7 million that is being claimed. Yeah, that seems widely off. Wikipedia says "0.38%" which is in approximate agreement with "0.5%" that I cited above. I wonder how good the data is for other territories. There's a big chart of the data, with links for reporting bugs here: https://unicode-org.github.io/cldr-staging/charts/38/supplemental/territory_language_information.html Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: questions about "Fedora Localization Statistics"
On 06/04/2021 15:16, Tom Hughes wrote: On 06/04/2021 14:47, Zbigniew Jędrzejewski-Szmek wrote: I'm looking at https://languages.stg.fedoraproject.org/territories/pl/, and it says: be (0.58 %) csb official_regional (0.13 %) de official_regional (19 %) en (33 %) lt official_regional (0.021 %) pl official (96 %) ru (18 %) sli (0.031 %) szl (1.3 %) uk (0.39 %) I think it's be good to order those items by percentage, rather than alphabetically. But my question is: what are those numbers supposed to _mean_? As the page says the data comes from CLDR and that is documented here: https://unicode.org/reports/tr35/tr35-info.html#Supplemental_Territory_Information Specifically those numbers are from the languagePopulation elements in the most recent CLDR release. The data for DE in PL in CLDR specifically references a source: uri="http://en.wikipedia.org/wiki/German_minority_in_Poland;>regional-official in part of Opole Voivodeship; in Poland 325 schools with primary instr in German, estimate 37000 students. Real figure probably higher. Though the numbers on that page don't get near the 7 million that is being claimed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: questions about "Fedora Localization Statistics"
On 06/04/2021 14:47, Zbigniew Jędrzejewski-Szmek wrote: I'm looking at https://languages.stg.fedoraproject.org/territories/pl/, and it says: be (0.58 %) csb official_regional (0.13 %) de official_regional (19 %) en (33 %) lt official_regional (0.021 %) pl official (96 %) ru (18 %) sli (0.031 %) szl (1.3 %) uk (0.39 %) I think it's be good to order those items by percentage, rather than alphabetically. But my question is: what are those numbers supposed to _mean_? As the page says the data comes from CLDR and that is documented here: https://unicode.org/reports/tr35/tr35-info.html#Supplemental_Territory_Information Specifically those numbers are from the languagePopulation elements in the most recent CLDR release. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Multiple snapshots and versioning
On 29/03/2021 11:32, Fabio Valentini wrote: There are two examples of how to work around this issue: - The ruby package bundles a bunch of gems in addition to the Ruby interpreter, and while some of the gem subpackages have different versions, there's only *one* Release tag in the whole package, and it never gets reset to 0 so the upgrade path for all subpackages works out fine. - The rust package ships the rust compiler and some tools (cargo, rustfmt, rls), and they have different "upstream" versions, but since they are never exposed to the user, these are ignored in Fedora, and just inherit the main version of the package, i.e. the version of the Rust compiler itself. There's also what nodejs does where the npm subpackage has the npm version but the nodejs version and release combined are used as the release for the subpackage, for example: nodejs-14.16.0-1.fc33.x86_64 npm-6.14.11-1.14.16.0.1.fc33.x86_64 That ensures that npm has the "correct" version but also that it will also be upgraded when nodejs upgrades. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: FYI: IETF deprecates TLS 1.0 + 1.1
On 25/03/2021 09:59, Marius Schwarz wrote: the IETF has now deprecated TLS 1.0 and 1.1 . https://datatracker.ietf.org/doc/rfc8996/ Do we plan an official Old-TLS-Deactivation date or do gnutls and openssl decide when it's time to deactivate them? They were removed from the default crypto policy in Fedora 33: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Starting raid-check.timer renders system unusable
On 21/03/2021 17:52, Jonathan Dieter wrote: There is a workaround: disabling raid-check.timer, but, if you can't boot due to this bug, you have to boot into single-user mode (which requires a root password to have been set). Adding systemd.mask=raid-check.timer to the kernel command line when booting is another way to get past the hang. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Heads Up: Update to proj-8.0.0 in F35 and F34
On 07/03/2021 17:53, Sandro Mani wrote: On 07.03.21 16:30, Kevin Kofler via devel wrote: Sandro Mani wrote: I'll rebuild the following dependent packages: gdal merkaartor FYI, your merkaartor build failed because merkaartor depends on gdal (it is used to import external reference data such as OGD in file formats that are not natively supported), so you need to rebuild gdal first and have the rebuilt gdal in the buildroot for merkaartor. Yep, I'll iterate the process as necessary until all dependencies resolve. I'm working on a fix for mapnik and will take care of that and it's dependencies once I've managed to backport the work-in-progress patch for the new API from upstream. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: sssd: No %post/%preun/%postun?!?
On 25/02/2021 13:58, Richard Shaw wrote: On Thu, Feb 25, 2021 at 7:39 AM Tom Hughes <mailto:t...@compton.nu>> wrote: On 25/02/2021 13:13, Richard Shaw wrote: > Per the packaging guidelines these don't seem to be optional: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd <https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd> > <https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd <https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd>> Indeed they're not optional, but they're also not missing as a glance a the spec file confirms: https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_931 <https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_931> Ahh, I never thought to look past %files :) Separate package, but I got a similar daemon-reload warning for unbound-libs, but it was for a timer unit, which are not mentioned in the packaging guidelines. Warning: The unit file, source configuration file or drop-ins of unbound-anchor.timer changed on disk. Run 'systemctl daemon-reload' to reload units. You'll get it for literally everything that uses the macros to try and restart itself if the update has changed the unit definition in any way because the restart is done before the reload so the new unit definition is not loaded yet. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: sssd: No %post/%preun/%postun?!?
On 25/02/2021 13:13, Richard Shaw wrote: Per the packaging guidelines these don't seem to be optional: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd <https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd> Indeed they're not optional, but they're also not missing as a glance a the spec file confirms: https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_931 Additionally, at a minimum systemctl daemon-reload should be run. It looks like there is some sort of default behavior but it's not correct. Warning: The unit file, source configuration file or drop-ins of sssd-kcm.socket changed on disk. Run 'systemctl daemon-reload' to reload units. Warning: The unit file, source configuration file or drop-ins of sssd-kcm.service changed on disk. Run 'systemctl daemon-reload' to reload units. What you are seeing there is RHBZ#1614751 in action. Looking at my dnf rpm log, this seems to have been going on for quite some time and I can't believe I'm the first to notice... You're not, and after 2.5 years it is finally about to be fixed. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Help wanted: Multiple packages with different ver-rel from one spec
On 04/02/2021 19:48, Miro Hrončok wrote: So the ver-rels are: main: 1.2.3-1.fc34 foo: 7.8.9-1.2.3^1.fc34 Once the base_release is bumped: main: 1.2.3-2.fc34 foo: 7.8.9-1.2.3^2.fc34 And once the main version is bumped without foo, base_release back to 1: main: 1.2.4-1.fc34 foo: 7.8.9-1.2.4^1.fc34 Yes this is how nodejs/npm work - the npm package is built from the nodejs source but has it's own version to the package version is done as: -.. So currently in F33 you have: nodejs-14.15.4-1.fc33.x86_64 npm-6.14.10-1.14.15.4.1.fc33.x86_64 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Boost 1.75.0 in rawhide, with soname change
On 29/01/2021 15:53, Jonathan Wakely wrote: On 29/01/21 16:47 +0100, Miro Hrončok wrote: On 25. 01. 21 11:00, Jonathan Wakely wrote: Tom Rodgers completed the Boost 1.75.0 build for the change https://fedoraproject.org/wiki/Changes/F34Boost175 and I've rebuilt most of the packages that depend on it... Hello. I now see a strange build failure on a package that is not listed here, because it doe snot require boost on runtime, only build time. python-pynest2d FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1922297 I see deprecation warnings like: CAUTION: Boost.Geometry in Boost 1.73 deprecates support for C++03 and will require C++14 from Boost 1.75 onwards. And than I see a lot of errors. Is it possible that the errors are relevant to that deprecation? The line is suspiciously in future tense, but this laready is Boost 1.75, right? Yes, Boost.Geometry in 1.75.0 requires C++14, the warning is ... broken. In more than one way. Just changing the compile flags will likely fix it - it did for wagyu which failed with the same error in the mass rebuild. I notice that it didn't get picked up in the boost update because it looks like wagyu didn't get rebuild - presumably because it's a header only library and you only rebuilt the things that wind up with an soname dependency? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: hotplug headphone detection in pipewire? (was: Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change))
On 14/01/2021 11:45, Felix Schwarz wrote: I switched a desktop F33 machine from pulseaudio to pipewire and it seems to work fine at a quick glance: $ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing --enablerepo=updates-testing $ systemctl --user enable pipewire pipewire-pulse Now I have the problem when I re-plug my headphones (old-fashioned headphone jack) that I don't see the headphones as output device via "pactl list sinks" (neither via pavucontrol, gnome's audio settings, ...). There's an upstream ticket that may be related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/533 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 29/12/2020 01:41, Luya Tshimbalanga wrote: I was trying it with Bose QC35 headphones. It was 0.3.18 and as I say it was showing up as a device but with no node that I could route audio to. Maybe an extra step is required for that Bose QC35. Try to forget that device and reconnect. That configuration you attached still seems to be missing the extra "-e bluez5" on the pipewire-media-session line? or is the comment there wrong when it says that is required? I haven't needed to put "-e bluez5" as Galaxy Buds+ worked without extra configuration on a first try. I had another play with it and I can confirm that I now have bluetooth working - it does work out of the box but has a habit of switching back to the on board sound for new audio streams unless you add that "-e bluez5" argument. What doesn't work at all, and this is likely what was causing my problems before, is fast user switching. That doesn't work with traditional pulseaudio for bluetooth but you can work around that by disabling the bluetooth modules in .config/pulse/default.pa for all bar one user if you are happy only using bluetooth for a single user. With pipewire not only does it not work for bluetooth, it doesn't work for the on board sound either - you have to stop the pipewire service for one user before switching to the other one or it can't use the sound card as the other instance still has it open. I did try and use the (not shipped in Fedora) system service units for pipewire but I couldn't get them to work. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 27/12/2020 20:07, Luya Tshimbalanga wrote: On 2020-12-21 3:31 a.m., Tom Hughes via devel wrote: On 20/11/2020 16:26, Ben Cotton wrote: < - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. I was unable to get this to work. Works with Galaxy Buds+ as highlighted below: I was trying it with Bose QC35 headphones. The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager. Which version of pipewire was used on your system? Pipewire 0.3.18 enabled a bluetooth headphone i.e. Galaxy Buds+ with issue related to resuming for the reopened lid of a laptop. Workaround is with the command for terminal "systemctl --user restart pipewire.service pipewire-pulse.service". See attached pipewire.conf with include bleuz5 enabled by default. It was 0.3.18 and as I say it was showing up as a device but with no node that I could route audio to. That configuration you attached still seems to be missing the extra "-e bluez5" on the pipewire-media-session line? or is the comment there wrong when it says that is required? The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you switch to a different desktop to something because once I started a second session things got horribly confused and I wound up with one desktop where audio worked and one where it didn't work at all. No issue on my desktop running Rawhide. Maybe some issues are user error like using old version of pipewire. Update your system and make sure pipewire version is 0.3.18 whose pipewire-pulseaudio properly handle dependencies. Should you see Steam from RPM Fusion being removed, grab the latest version from their Koji page which fixes the problem. I don't use steam so it's nothing to do with that. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 20/11/2020 16:26, Ben Cotton wrote: == Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default. So I tried this in F33 with the packages from updates-testing and I'm afraid to say it didn't end well... Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify: - patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x) As pactl was removed by the switch I couldn't test this. - gnome-control-center: check the audio tab, check the volume sliders and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch. This worked initially, but see later. - pavucontrol: check volumes in the input devices tabs and check the microphone volumes Didn't test this. - firefox: check out a website with audio/video such as youtube and verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111). Didn't test this. - rhythmbox: check if playback works as expected This worked initially, but see later. - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. I was unable to get this to work. The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager. After that my headphones who show up as a device in pw-cli but not as a target I could send sound to. The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you switch to a different desktop to something because once I started a second session things got horribly confused and I wound up with one desktop where audio worked and one where it didn't work at all. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
