Re: Build failure due to glib change
On 01/09/2024 23:26, Alexander Ploumistos wrote: I can sort of understand the rationale behind that, but I'd like someone who is more actively involved with C++ to give some advice if this is something I should be reporting to the glib folks, or if I should just change the writable string pointers to read-only in text.cc and (hopefully) be done with it. Change the pointers - you were essentially getting an accidental cast from const char to char but logically speaking if the string is const then advancing by one codepoint doesn't magically stop it being const. The new behaviour of glib is to preserve the constness of the pointer as it advances which seems correct 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: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?
On 07/08/2024 12:54, Richard W.M. Jones wrote: On Wed, Aug 07, 2024 at 01:09:01PM +0200, Vít Ondruch wrote: With new RPM, I hit the limit in two packages: https://koschei.fedoraproject.org/package/rubygem-abrt https://koschei.fedoraproject.org/package/rubygem-pg Is it RPM, or is it "rspec"? Seems to be some sort of Ruby tool. The first one is something I assume the test is doing... Perhaps these ones using deliberately silly paths? https://github.com/voxik/abrt-ruby/blob/5cd42e6cf6024e80cdccdf8c3ba2128f2717ab69/spec/abrt_handler_spec.rb#L122 The second one is less clear - it doesn't seem to be using the %postgresql_tests_run macro to start a postgres server for testing so I assume the ruby tests are starting one themselves but in a directory that has a long enough name that the socket name is too long? 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: unfixed CVE-2024-39929 in exim
On 15/07/2024 16:46, Marius Schwarz wrote: https://bugzilla.redhat.com/show_bug.cgi?id=2297728 Luckily is not a RCE, but we have an unpatched CVE in Exim .. can someone pls poke the right person for it? There was no reaction to the exim accouncement on OSS and to the bugreport. It was only reported yesterday! 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
mapnik soname bump in rawhide
I've updated mapnik in rawhide to 4.0.0 which includes an soname bump. I've rebuilt python-mapnik and opened a PR for viking to fix it to build against mapnik 4 which I believe covers all the downstream users. 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 & AI Survey Now Live Until July 16th
On 01/07/2024 20:07, Aoife Moloney wrote: I would also like to add that we deliberately took a positive tone for this survey as it is far too easy to find (many) negatives for AI (and for good reason!), and we wanted to try to look at the benefits we could get from AI instead if applied properly and wit the best interest of Fedora driving the use of AI in parts of the projects ecosystem. Well I guess if you're only interested in positive responses then we can say the survey design is a success - just a shame that the results will be meaningless. I understand why surveys have to use closed form questions with a fixed set of responses but it should always be possible to opt out of questions and, ideally, to explicitly indicate that you do not agree with any of the proposed responses, otherwise you are artificially restricting the results to the set of concepts that were (either deliberately or subconsciously) in the mind of the survey creator. At the very least the question needs to be changed to not indicate that two answers are required if five are! 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 & AI Survey Now Live Until July 16th
Survey: Please select at most 5 answers User: Selects 2 answers Survey: Please rank all items User: Remembers why they hate surveys and gives up To be clear as there are only two items where I think there is any chance of AI being useful I am unable to rank the others. Tom On 01/07/2024 18:33, Aoife Moloney wrote: Hi folks, Thank you for contributing to our discussion on what kinds of questions are useful for us to ask our community on the subject of AI in the Fedora ecosystem [1]. We've created a short survey [2] based on the questions that were proposed that we feel are general enough for everyone to feel comfortable answering, and from the answer we receive, the council and other governing bodies of the project can start formalising some AI-related focus areas and develop solid guidelines for the use of AI in the project ecosystem. The deadline is July 16th, it shouldn't take more than a few minutes of your time to complete, and I will be sending some reminders between now and the closing date too. A quick reminder that this is not our annual contributors survey, and that survey will be launching soon with a section around AI too. I want to offer an advance apologies for any survey-related fatigue, but when it comes to creating AI guidelines for the project and understanding how our community is doing and feels about the project, this AI survey and the contributor survey is truly the best way to get that feedback and create actionable stuff 'n' things from your direct responses. Kindest regards, Aoife [1] https://discussion.fedoraproject.org/t/ai-survey-questions-what-should-we-be-asking/118338 <https://discussion.fedoraproject.org/t/ai-survey-questions-what-should-we-be-asking/118338> [2] https://fedoraproject.limequery.com/142117?lang=en <https://fedoraproject.limequery.com/142117?lang=en> -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im <http://fedora.im> IRC: amoloney -- 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: 2FA policy for provenpackagers is now active
On 24/06/2024 18:26, Stephen Gallagher wrote: Not really an issue if you have GSSAPI set up on your system. Such as by installing fedora-chromium-config-gssapi (for Chrome/Chromium users) or by using Firefox which is set up for GSSAPI out-of-the-box. I've never seen Firefox use my kerberos ticket, it always asks me to login. That doesn't bother me though because I have my password manager readily available there, unlike at the command line. 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On 20/06/2024 16:34, Simon Farnsworth wrote: For Pentium and Celeron branded processors, v2 also loses Skylake, Icelake, Haswell, Cometlake, Broadwell and others, even when their matching Core branded processors support x86-64v2 or x86-64v3. That means that you lose all Pentium Silver processors, including the latest releases in that line, all Pentium Gold processors released before 2022, and all Celeron processors released before 2020. I have a Celeron N3160 which is a 2016 processor bought by me in 2019 and that reports as v2. 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: Guidance on individual packages requiring x86_64-v2 baseline ?
On 20/06/2024 15:03, Stephen Gallagher wrote: Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes, three) and recommend creation of a Fedora "Hardware Life Extension" Remix that can provide rebuilds of (a subset of) Fedora that they want to run on ancient hardware. It could be something similar to Fedora ELN, where a subset of the main repo that might be useful on old hardware can be rebuilt (though unlike ELN, I suggest that this should be an entirely separate infrastructure not maintained by the Fedora Project). Such a project could then live or die based on willingness to maintain it and stop holding back Fedora as a whole. I definitely think going to v2 would be reasonable bit I tink forcing v3 might be a step too far. While my desktop is v4 and my laptop is v3 I have two other machines at home which are only v2 one of which is only five years old having been built then to replace a 32 bit machine when Fedora was dropping 32 bit x86 support. Having checked a couple of dozen machines at work that are running either F39 or F40 it's roughly a 50/50 split between ones which are v2 and ones with are v3. There are even three v1 machines there though one is redundant and the other two do really need replacing. 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: Spec file using github repo - not tarball
On 21/05/2024 16:37, Dominik Wombacher wrote: I have a case were upstream excludes the test suite from the export [1]. But I want the tests to be part of the package build to validate that everything is fine. So this requires a bit of local git clone and create an own archive file. I can't just grab the archive from the GitHub release in that case. The automatic tar ball URLs on github just do a git archive and are separate to uploaded release artifacts. Just use a URL like: https://github.com/OWNER/PROJECT/archive/REVISION/NAME.tar.gz where tag can be any tag or head or commit hash. More here: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_commit_revision 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: Firefox 126.0 with DBus service
On 15/05/2024 13:06, Michael J Gruber wrote: Is this used by Gnome search unconditionally? I might want to use Gnome but not a background indexer/tracker/search engine. Threw me off back then when KDE introcuced something like that. Go to "Search" in the Gnome settings and you can control which search providers are enabled. 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: Firefox 126.0 with DBus service
On 15/05/2024 09:52, Ian McInerney via devel wrote: Also, don't new enabled-by-default services need approval from either FESCO or the Workstation WG according to the packaging docs (https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/)? I know the page seems to focus on systemd services, but it does mention DBus services in a few place on the page, so I thought it would apply to DBus services that are automatically enabled as well. Only exceptions need approval, and something which meets the criteria above would not need an exception. The main time an exception is needed is for services which listen to the network. 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: 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)
pe of this proposal to only change to `MACAddressPolicy=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 Su
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)
== User Experience == * 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&oldid=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&oldid=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&oldid=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