Fedora Developer Portal May update
Hi all, I just pushed new Fedora Developer Portal release with changes from May, it should become available in an hour, or until it properly propagates through all the servers. This release saw following updates: * Update .NET docs for .NET 7 EOL https://github.com/developer-portal/content/pull/540 * [Rust] Expand section about cargo + crate dependencies https://github.com/developer-portal/content/pull/539 Thanks to the contributors. If you find any problems or have an enhancement, feel free to submit an PR or an issue on https://github.com/developer-portal/content Regards, Jarek Prokop -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Review request: mruby
On 4/17/24 11:38 AM, Marián Konček wrote:
Nice catch, using it and removing the line "conf.enable_debug" makes
the build use the proper flags. However, I still don't know how to
tell Rake to add a `-Wl,-soname,...` option to each .so separately.
Check out `build_config/default.rb`. It has a lot of commented out
options, one of those is config.linker. You can copy that over and
adjust for Fedora.
Copying a bit of the following linker options into the host-shared.rb
target, I get the -Wl,-z,relro etc from LDFLAGS in. However if something
more is needed I do not know, but you can easily append more flags.
~~~
# Linker settings
conf.linker do |linker|
linker.command = ENV['LD'] || 'gcc'
linker.flags = ENV['LDFLAGS']
linker.link_options = %Q[%{flags} -o "%{outfile}" %{objs} %{libs}]
end
~~~
I'd also note that `readelf --dynamic` for any binary gives: `Shared
library: [/builddir/build/BUILD/mruby-3.3.0/build/host/lib/libmruby.so]`
and the solib has no NAME section on it.
It seems that for the host-shared config, `config.archiver` seems like
the correct place for appending flags for .so files, since it is using GCC.
I spent some time with it, but so far I was unable to fully build
everything properly with also the `-soname`. I got to libmruby_core.so,
but then it started complaining for other artifacts. Probably the -L and
-l options also need adjustments in the linker when it comes to paths
after fixing the path.
It'll likely need more convincing. It seems it is doing a lot in
absolute paths, almost everywhere with everything, including soname data.
To be more in line with the guidelines WRT to the -soname option.
On 16. 4. 2024 18:11, Jarek Prokop wrote:
On 4/16/24 4:16 PM, Marián Konček wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=2275294
I applied downstream changes which build a shared object (upstream
provides no way of doing so, only a static library).
Upstream provides many ways to compile to many targets including
using solibs, have a look:
https://github.com/mruby/mruby/tree/3.3.0/build_config
One can even write it themselves if the upstream ones doesn't cater
to one's needs of their goal.
Definitions in that directory can be referred to in MRUBY_CONFIG
variable used in rake command as the filename without the extension,
for example to build a shared library:`rake MRUBY_CONFIG=host-shared
all `
Though in my small tests some adjustment for the upstream code would
be needed to have it respect Fedora {C,CXX,LD}FLAGS properly, but I
might've missed something.
Regards,
Jarek
--
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Review request: mruby
On 4/16/24 4:16 PM, Marián Konček wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=2275294
I applied downstream changes which build a shared object (upstream
provides no way of doing so, only a static library).
Upstream provides many ways to compile to many targets including using
solibs, have a look:
https://github.com/mruby/mruby/tree/3.3.0/build_config
One can even write it themselves if the upstream ones doesn't cater to
one's needs of their goal.
Definitions in that directory can be referred to in MRUBY_CONFIG
variable used in rake command as the filename without the extension, for
example to build a shared library:`rake MRUBY_CONFIG=host-shared all `
Though in my small tests some adjustment for the upstream code would be
needed to have it respect Fedora {C,CXX,LD}FLAGS properly, but I
might've missed something.
Regards,
Jarek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: do we need CONFIG_UPROBES=y in our kernels?
On 2/12/24 7:15 PM, Marius Schwarz wrote: Hi, I excuse myself if this has been already discussed, bastion ML server was blacklisted (has been removed btw). Short summary(for details use the source link): In a german developer blog article was the topic raised, that with uprobes enabled, userland apps can i.e. circumvent tls security(and other protections), by telling the kernel to probe the function calls with the uprobes api. As this enables i.e. the hosting system of a vm or container, to track activity inside the container, trust is lost i.e. from customer to hoster. To be fair, you need to be root on the host to do this, but as it "wasn't possible before", and it is "now" ( out in a greater public ), it tends to create trust issues, just for being there*. If I am reading this correctly, if I have a VM that's being hosted on a host kernel that has uprobes capabilities and a malicious actor with root access is controlling the host kernel, does it matter what options is the guest using if the host can simply utilize their uprobes? This hypothetical malicious hoster could also just use their own custom kernel if they were relying on Fedora's kernel. And if they are this malicious, they also can just break into your containers via regular container tools. IMO containers are at no level a reliable security sandbox without additional safeguards, this goes both for host and guest. Regards, Jarek As this only works with uprobes enabled and has no use case besides a developer debugging apps, the question is: Do we need this for all others out there enabled by default? If noone can name an app/lib that needs this outside of the C* development process, a change proposal would be wise. maybe adding a kernel boot argument switch? Source: http://blog.fefe.de/?ts=9b3a23b2 *) You may not have a clue, what security auditors tell you about "a vulnerability & it's just there, but inexploitable". I had a case 2 weeks ago, about a missing patch for the ssh-agent CVE vulnerability in fedora's openssh. Trust me, it will create trouble the more the topic is discussed in the pubic. Best regards, Marius Schwarz -- -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 2/9/24 10:26, Dmitry Belyavskiy wrote: Dear Yaakov, On Fri, Feb 9, 2024 at 4:51 AM Yaakov Selkowitz wrote: On Thu, 2024-02-08 at 20:37 +0100, Sahana Prasad wrote: > Hello everyone, > OpenSSL 3.2.1 is now available in rawhide [1]. > There are no API/ABI changes in comparison with the last version in > rawhide > (3.1.4). > This version (3.2.0 onwards) supports PQ algorithms that can be > loaded > through > the OQS provider. > A few tests that needed some downstream tweaks have been disabled and > being > worked on. > Other than this issue [2] upstream, we did not see any new > failures/breakages. > > If you observe any new issues with this new version, kindly report a > bug. Would this be related to openssl 3.2.1? https://koji.fedoraproject.org/koji/taskinfo?taskID=113198856 The tests pass locally in mock with openssl 3.1.4. I can imagine the situation where upgrading to 3.2 could cause this failure but the logs are too vague. Could you please provide more details (e.g. openssl low-level diagnostics) or even better a minimal reproducer for diagnostics? Hi, I am not that well versed in openssl but I think I got it quite minimal, as I can reproduce the error message using `openssl` command itself. And I confirmed, at least locally, that the error started happening once I introduce Openssl 3.2.1 into buildroot, whether that's all to that story, I do not know. As a result I have ruled out mariadb version update as the cause. rubygem-mysql2 has a few tests that test SSL connection. Keys and certs are in upstream: https://github.com/brianmario/mysql2/tree/master/spec/ssl However, we regenerate all certificates using `gen_certs.sh`: https://github.com/brianmario/mysql2/blob/master/spec/ssl/gen_certs.sh In our repo: https://src.fedoraproject.org/rpms/rubygem-mysql2/blob/rawhide/f/rubygem-mysql2.spec#_94 Above the line in the file I linked from Fedora set CN to localhost as we expect connecting through that host. Now, with the certs regenerated in mock I execute following: ``` $ openssl verify -CAfile ca-cert.pem client-cert.pem CN=ca_mysql2gem error 79 at 1 depth lookup: invalid CA certificate error client-cert.pem: verification failed ``` 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? Regards, Jarek Prokop As for now we don't see any significant regressions in our downstream tests. -- Dmitry Belyavskiy-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
January 2024 Fedora Developer Portal release
Hi all, I have just pushed a new years' release of Fedora Developer Portal. It's minor, a thanks to the contributors that helped with reviews/fixes nonetheless. Revitalize web-app section about Rails. (#498) * https://developer.fedoraproject.org/start/sw/web-app/rails.html mention nodenv for installing nodejs (#514) * https://developer.fedoraproject.org/start/sw/web-app/rails.html postgresql/about.md and -> end typo (#519) * https://developer.fedoraproject.org/tech/database/postgresql/about.html Regards, Jarek Prokop -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: ARM PAC on koji vs COPR
On 1/4/24 16:10, Jarek Prokop wrote:
On 1/4/24 10:47, Florian Weimer wrote:
* Jarek Prokop:
This spawns a few questions for me:
1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
defaults,
I see default CFLAGS contain `-mbranch-protection=standard` and the
flag with pac-ret seems to be appended to libruby.so in the case of
the upstream fix [2].
>From what I understand, it shouldn't cause problems to have these 2
flags at the same time on the correct compilation artifacts, is that
correct?
I wouldn't use both flags at the same time because the meaning is
unclear. Is BTI still enabled if you do that?
Not sure how I would check that.
By compiling on an ARM machine, duh!
Compiling with file test.c like this:
~~~
$ cat test.c
#include
#include
int main() {
printf("%d", __ARM_FEATURE_BTI_DEFAULT);
printf("%d", __ARM_FEATURE_PAC_DEFAULT);
return 0;
}
$ gcc -mbranch-protection=standard -mbranch-protection=pac-ret test.c
test.c: In function ‘main’:
test.c:5:18: error: ‘__ARM_FEATURE_BTI_DEFAULT’ undeclared (first use in
this function)
5 | printf("%d", __ARM_FEATURE_BTI_DEFAULT);
| ^
test.c:5:18: note: each undeclared identifier is reported only once for
each function it appears in
~~~
So it seems anything related to BTI gets actually skipped in the
upstream Context.S file, since their only option is for `=pac-ret`.
And for completenes, same file, but with =standard:
~~~
$ gcc -mbranch-protection=standard test.c
$ ./a.out
11
~~~
tl;dr No, it doesn't seem to remain enabled if this double definition is
done.
Thanks,
Jarek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: ARM PAC on koji vs COPR
On 1/4/24 10:47, Florian Weimer wrote: * Jarek Prokop: This spawns a few questions for me: 1. Since [1] the `-mbranch-protection=pac-ret` is needed in both CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora defaults, I see default CFLAGS contain `-mbranch-protection=standard` and the flag with pac-ret seems to be appended to libruby.so in the case of the upstream fix [2]. From what I understand, it shouldn't cause problems to have these 2 flags at the same time on the correct compilation artifacts, is that correct? I wouldn't use both flags at the same time because the meaning is unclear. Is BTI still enabled if you do that? Not sure how I would check that. But `-mbranch-protection=standard` should currently be BTI+PAC: "standard turns on all types of branch protection. Currently standard implies pac-ret+bti." -- https://developer.arm.com/documentation/102433/0200/Applying-these-techniques-to-real-code Whether we end up with generated code that's also BTI is not certain. In any case it actually seems like we want to not use that configure branch at all for now, as we can use just =standard and achieve better effect than with the uncertain result of the combined flags that is happening now. and if I understand the text correctly, we on Fedora with that =standard do not actually therefore need =pac-ret for the -mbranch-protection flag. Digging deeper in Arm's documentation regarding this, it seems the generated assembly is actually reasonably compatible across CPU variants, or well... has the ability to be if it is handwritten Can't you put -mbranch-protection=standard into ASFLAGS? We probably can, and it might be the way to go for Fedora Ruby based on the mentioned ARM developer article. At least for the moment. I'll inspect and see. The check is a bit weird: diff --git a/configure.ac b/configure.ac index 9286946fc15f4..18b4247991d42 100644 --- a/configure.ac +++ b/configure.ac @@ -830,7 +830,10 @@ AS_IF([test "$GCC" = yes], [ AS_FOR(option, opt, [-mbranch-protection=pac-ret -msign-return-address=all], [ RUBY_TRY_CFLAGS(option, [branch_protection=yes], [branch_protection=no]) AS_IF([test "x$branch_protection" = xyes], [ +# C compiler and assembler must be consistent for -mbranch-protection +# since they both check `__ARM_FEATURE_PAC_DEFAULT` definition. RUBY_APPEND_OPTION(XCFLAGS, option) +RUBY_APPEND_OPTION(ASFLAGS, option) break ]) ]) <https://github.com/ruby/ruby/commit/1f89a670381859d1c1d1c640359f169b6db6759c.patch> The reliable way to do this would be to compile a C file and check whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case, define a *different* macro for use in the assembler implementation. This way, you don't need to care about the exact name of the option. That does sound better, I'll do some exploring for this. Thanks for taking a look. 2. Since files compiled with `-mbranch-protection=pac-ret` seem to end up in the .so library and Ruby binary extensions link against that solib, do the binary extensions also have to be compiled with that exact option? It depends on how fiber handling is implemented. If fiber switching relies on code in header files or that is statically linked into Ruby extensions, then yes, these extensions will need to be compiled with PAC support as well. But I expect that this isn't the case, but haven't checked it. The relevant code should be in the Ruby DSO only and be linked dynamically. That seems to be our case, we do not ship static artifacts to link against AFAICT. It also seems unlikely that many C extensions would be aware of fiber switching, but I haven't checked that, either. Quickly grepping through sources suggests that if extensions are aware of fiber switching, they are doing it through the Ruby C-api that has responsible code in the DSO. So I can probably scratch that concern off of my list. 3. If we do not fix this bug in Ruby 3.3.0 but wait with this for 3.3.1 where the fix will most probably land, will we by effect exclude a subset of ARM CPUs, that actually have the PAC capability, for that in-between period? I think you should fix this with a backport. It's going to impact quite a few users. 4. Why do koji and copr have CPU flag set that differs so much? Is our koji infra OK? It's different machines, so they are expect to have different capabilities. This isn't even aarch64-specific. I see. I didn't know how much different actually which was answered by other people here. 5. Why does it fail on copr and does not fail on koji? It seems the paca/pacg have to be present and set on the CPU flags for the segfaults to occur. PAC is not process-switched on Linux. If it is turned on at the kernel/hypervisor level, it's currently impossible to turn off. This is not someth
ARM PAC on koji vs COPR
Hi, recently Ruby 3.3 was released, we have noticed a failure to build on COPR's aarch64: https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/ https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/builder-live.log.gz But we do not observe these failures on koji (see e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=111230891 ) What i have observed is that the hw_info.log reports different flags, visually I'd say koji has half the CPU flags, despite koji reporting to be the equal CPU model Neoverse-N1 of the vendor ID of ARM as does copr report. More details regarding the failures: According to upstream bug report [0] the culprit is change introducing PAC/BTI support in some arm64 assembly [1] and the fix to no longer have Ruby segfault is including `ASFLAGS=-mbranch-protection=pac-ret` [2] in addition to the same flag in XCFLAGS. This spawns a few questions for me: 1. Since [1] the `-mbranch-protection=pac-ret` is needed in both CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora defaults, I see default CFLAGS contain `-mbranch-protection=standard` and the flag with pac-ret seems to be appended to libruby.so in the case of the upstream fix [2]. From what I understand, it shouldn't cause problems to have these 2 flags at the same time on the correct compilation artifacts, is that correct? 2. Since files compiled with `-mbranch-protection=pac-ret` seem to end up in the .so library and Ruby binary extensions link against that solib, do the binary extensions also have to be compiled with that exact option? 3. If we do not fix this bug in Ruby 3.3.0 but wait with this for 3.3.1 where the fix will most probably land, will we by effect exclude a subset of ARM CPUs, that actually have the PAC capability, for that in-between period? 4. Why do koji and copr have CPU flag set that differs so much? Is our koji infra OK? 5. Why does it fail on copr and does not fail on koji? It seems the paca/pacg have to be present and set on the CPU flags for the segfaults to occur. I tried answering the last question when reading on that in kernel docs [3], but I can't say I understand the text 100%. Thanks, Jarek Prokop [0] https://bugs.ruby-lang.org/issues/20085 [1] https://github.com/ruby/ruby/pull/9306 [2] https://github.com/ruby/ruby/pull/9371 [3] https://www.kernel.org/doc/html/v6.4/arm64/pointer-authentication.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Developer Portal Holiday Release
Hi, we have new Fedora Developer Portal release. This is most probably the last release of 2023. In no particular order: Update rails.md to use packaged rbenv (#492) * https://developer.fedoraproject.org/start/sw/web-app/rails.html Remove cassandra from the database section. (#500) * https://developer.fedoraproject.org/tech/database/cassandra/about.html Update information about GOPROXY, GOSUMDB, GOTOOLCHAIN (#491) * https://developer.fedoraproject.org/tech/languages/go/go-installation.html Haskell platform page was deprecated upstream, Fedora still provides it. (#497) * https://developer.fedoraproject.org/tech/languages/haskell/haskell-installation.html Introduce sections for rustup in Further reading section of Rust. (#499) * https://developer.fedoraproject.org/tech/languages/rust/further-reading.html Fix the content for /etc/sudoers for passwordless nfsd setup in vagrant. (#496) * https://developer.fedoraproject.org/tools/vagrant/vagrant-nfs.html Thanks to all the keen eyes reporting outdated content and of course thanks to all the community contributors that take the time to update it. Happy holidays, Jarek Prokop -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Developer Portal November 2023 release
Hi all, an update for the Fedora Developer Portal is here and soon to be available after the servers sync the changes. * Add Fedora Specifc Notes For Golang Page PR#487 https://developer.fedoraproject.org/tech/languages/go/go-installation.html * Fix GJS yaml to make it visible on the website PR#457 https://developer.fedoraproject.org/tech/languages/gjs/gjs-installation.html * Revert "Align virtualenv advice for FastAPI with Django/Flask (#425)" PR#450 https://developer.fedoraproject.org/tech/languages/python/fastapi-installation.html * Improving the latexpdf section on sphinx.md PR#488 https://developer.fedoraproject.org/tech/languages/python/sphinx.html * Update Ruby installation guide for rbenv PR#489 https://developer.fedoraproject.org/tech/languages/ruby/ruby-installation.html Thanks to all the contributors that help keep the content up-to-date. Feedback on these changes and more welcome as an email reply or on the bug tracker https://github.com/developer-portal/content/issues . Regards, Jarek Prokop ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Developer Portal August 2023 release
Hi all, new Fedora Developer content was released. Changes: Remove Atom from web-app, the IDE was sunset ( https://github.com/developer-portal/content/pull/480 ): * https://developer.fedoraproject.org/start/sw/web-app/about.html Update the source repofile for MongoDB and undeprecate it as it is now installable ( https://github.com/developer-portal/content/pull/484 ): * https://developer.fedoraproject.org/tech/database/mongodb/about.html Dune build system section for OCaml ( https://github.com/developer-portal/content/pull/473 ): * https://developer.fedoraproject.org/tech/languages/ocaml/dune.html * https://developer.fedoraproject.org/tech/languages/ocaml/ocaml-installation.html Add required LaTeX package dependencies for the latexpdf target of sphinx ( https://github.com/developer-portal/content/pull/474 ): * https://developer.fedoraproject.org/tech/languages/python/sphinx.html Update Ruby pages and simplify rbenv installation instructions ( https://github.com/developer-portal/content/pull/478 ): * https://developer.fedoraproject.org/tech/languages/ruby/gems-installation.html * https://developer.fedoraproject.org/tech/languages/ruby/ruby-installation.html Also the PR https://github.com/developer-portal/content/pull/482 was incorporated into these Ruby changes. Remove sqlite-jdbc connector mention as it is no longer available in Fedora ( https://github.com/developer-portal/content/pull/479 ): * https://developer.fedoraproject.org/tech/database/sqlite/about.html Thanks to all the contributors that helped with the update. Feedback on these changes and more welcome as a reply on https://github.com/developer-portal/content/issues . Regards, Jarek Prokop ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Orphaning rubygem-protobuf
Hi, I have orphaned rubygem-protobuf. It used to be required by rubygem-cucumber-messages, but the package dropped its dependency on rubygem-protobuf. Regards, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)
On 5/9/23 21:27, DJ Delorie wrote:
Jarek Prokop writes:
Are the libffi/rebuilt packages available anywhere for us to
experiment with?
MPB uses COPR, so..
"before"
builds:https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4.checker/
"after" builds:https://copr.fedorainfracloud.org/coprs/djdelorie/libffi-3.4.4/
Great! Thanks for the links, I've done manual testing with the reproducer:
~~~
require 'fiddle/closure'
require 'fiddle/struct'
Fiddle::Closure.new(Fiddle::TYPE_VOID, [])
fork { }
GC.start
~~~
And with the copr build of libffi 3.4.4-3 , Ruby indeed no longer
crashes on this code.
We have a reasonably reliable reproducer in Ruby [0] (also included in
commit message [1]), but it is not executed as part of test suite,
Yes, fork-without-exec case is a known "that should never have worked"
case that only happens to work when your closure's backing store is also
forked, which file-based mappings are *not*. You need either really old
(rwx mmap, which security disables) or really new (static trampolines,
which are r-x/rw- mmap'ed) libffi to support that. Hopefully that means
your reproducers should not reproduce with the new libffi.
Moreover, rebuild with current Ruby specfiles won't tell you much as
we commented out the tests [2] to have less flaky builds. I'd
recommend uncommenting the lines and run 5 to 10 builds (or just run
any of the 2 reproducers).
Well, if you comment out the tests, I have no way of knowing I broke
anything, so have to rely on posting Change Requests and letting you let
me know ;-)
And it is great to see :)
Not saying you did anything wrong; if you have tests that pass or fail
depending on system configurations outside your control, it's difficult
to reliably test what you want to test. I'm just saying that when you
disable tests, automated processes have no insight into those failures.
We are aware of this downside :/, we worked with relevant upstream, but
a proper fix on the side of rubygem-fiddle would require nontrivial rewrite.
(rubygem-ffi conversely has a closure pool that, AFAICT, prevents the
issue altogether.)
This was a long-running issue (read: spanning a few Fedora releases) and
doing a rebuild 10 times to have 1 not segfault and go through the rest
of the pipeline just for a teeny version rebase got really tiring.
Thanks,
Jarek Prokop___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: F39 Proposal: LIBFFI34 static trampolines (System-Wide Change)
On 5/8/23 15:50, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/LIBFFI34_static_trampolines This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Libffi is currently configured to use dynamic trampolines, which require some source of memory which is both writable and executable. This is an obvious security issue, and selinux and system defaults have made it more and more difficult to safely provide this memory to libffi clients. With this change, libffi will be configured to use static trampolines, which do not require such memory, and will not pose those security and administrative risks. == Owner == * Name: [[User:djdelorie| DJ Delorie]] * Email:d...@redhat.com == Detailed Description == The change itself is simple - libffi will no longer be configured with --disable-exec-static-tramp, which changes how closures are generated. Closures, and libffi, are used in many interpreted languages. There are about 145 packages that depend, directly or indirectly, on libffi. I ran the Mass Prebuilder. Of those 145, 10 already FTBFS, and 1 saw a new failure. The Mass PreBuilder has indicated that cjs (Javascript Bindings for Cinnamon) will fail to build with static trampolines. We debugged this a bit and noted that cjs's upstream seems to be behind the gjs upstream (the gjs package builds OK) it tracks, and is missing at least two closure-related changes (although simply adding those two changes proved nontrivial). Are the libffi/rebuilt packages available anywhere for us to experiment with? We have a reasonably reliable reproducer in Ruby [0] (also included in commit message [1]), but it is not executed as part of test suite, Moreover, rebuild with current Ruby specfiles won't tell you much as we commented out the tests [2] to have less flaky builds. I'd recommend uncommenting the lines and run 5 to 10 builds (or just run any of the 2 reproducers). Regards, Jarek Prokop [0] https://bugzilla.redhat.com/show_bug.cgi?id=2040380#c5 [1] https://src.fedoraproject.org/rpms/ruby/c/c2026da1750e6d0cc70c7370a0840628bbbfa965?branch=9e39fd242a58a5ab286d5da0d54130a669c8a9ec [2] https://src.fedoraproject.org/rpms/ruby/blob/9e39fd242a58a5ab286d5da0d54130a669c8a9ec/f/ruby.spec#_998___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 4/21/23 23:20, Florian Weimer wrote: * Matthew Miller: Big threads are … bad, actually --- When we have something to talk about, it tends to explode into a big thread. The thing in January with FESCo’s frame pointers decision (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RNJZUX3ZI34DIX6E4PVDKYQWCOFDQ4UY/#RNJZUX3ZI34DIX6E4PVDKYQWCOFDQ4UY) is a good example of things going badly. Most of the conversation was under the subject “Schedule for Tuesday's FESCo Meeting (2023-01-03)”, because everything started as a reply to that. That’s pretty easy to overlook. It’s possible for replies to change the subject when replying, but that can’t be done retroactively, and then isn’t consistent (and it breaks threading in Gmail, too). Then, things got rather hostile, making it hard to have a reasonable conversation about the issues (both technical and procedural). And then, things went in circles without adding anything new. This could have all gone a lot better. You brought up fairly concrete examples, but I don't see how the platform matters in those cases. Someone would need to shut down or delete (parts of) conversations more or less arbitrarily, even if they are not actively harmful as such, simply because they create too much work for others to follow. Surely that's not something you are willing to do? For lists that are active, the split is confusing — when should something be on the packaging list rather than devel? What happens when something is related to both Cloud and Server, or Workstation and KDE? One can post to both lists, but if someone replies and isn’t subscribed to both, the conversation gets split. Do Fedora mailing lists reject mail from non-members, and redirect follow-ups? If they do that, that's the first thing you could fix. Then such discussions no longer would get split. Not just Fedora --- There’s a big trend towards Discourse in open source projects overall. Python and Gnome have both migrated entirely from their mailing lists. Ansible is working on it. Plus, there’s Rust, Kubernetes, Nextcloud, Flathub, Grafana, Home Assistant, KDE, and I’m sure many others. All these instances are isolated. It's not possible to cross-post. This makes cross-project collaboration increasingly difficult because instead of Cc:ing another list, perhaps with a summary of the discussion so far, you have to create a completely new topic somewhere else, and then someone has to copy over summaries manually. (If I recall correctly, that currently doesn't work well with Fedora lists because they reject posts from non-members.) 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? For a post, there is create, update, delete, retrieve and even list the latest. IMHO that's as CRUD as one can be :D. So, there is even a REST API? At least retrieval can go unauthenticated... Regards, jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 4/21/23 20:44, Matthew Miller wrote: On Fri, Apr 21, 2023 at 07:39:17PM +0200, Jaroslav Prokop wrote: I am, luckily, not paid to read forums with no threading. IMO, a stream of posts with mentions of previous posts is not threading. Threading begins and ends on new topic posts AFAICT on discourse. It's not presented as a tree, but there _are_ threads of replies. Heh, sounds like a fun side project to try to transform it into a tree structure. If you want to make Jonathan Corbet happy, make that tree structure be then served via NNTP. :) Sounds like a challenge! I'll put it on my personal project backlog ;) Example:https://discussion.fedoraproject.org/t/future-of-encryption-in-fedora-desktop-variants/80397/83?replies_to_post_number=83 Finally, noticed what it does, it made me a bit confused as the first response was the same as in the "global" flow of the topic, but the message under it changed. I think that it should be better visible that they are actually replies. It seems to hide other replies and only show those that are part of the "thread". Do they accept RFEs? :) They do -- post athttps://meta.discourse.org/. I think enhancing the visibility after I expand replies for the posts in the "thread" would be better. This particular thing could possibly be done via a theme component (see https://meta.discourse.org/t/about-the-theme-component-category/232731), which is a kind of lightweight plugin for the client-side. (These are very easy to install into a given site, unlike weightier server-side plugins.) Or maybe even just some CSS. What exactly did you have in mind? I think it is a bug in UI/UX. I click "replies", I see *something* changed in the layout, but I have trouble identifying what exactly. Visually, if there are more than 2 or even 1 reply, then I just see with peripheral vision something had changed, but when I look closer I have trouble seeing a difference, IOW, I have trouble identifying what I did when I clicked the button. Either moving the replies a bit to a side or maybe adding something more visual, like a blue stripe on the threaded replies would be helpful IMO. I can play around with the plugin, see what feels how, and come back to Discourse with suggestions, thanks for the resources! (Firstly I'll have to confirm with a more "vanilla" install, to see if the problem might be my default dark mode environment Discourse switched into, that's a problem for monday me though :) ) Regards, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
(although we might feed them from Discourse rather than the other way around). Other lists which are patches, commit messages, and other automations might stick around for a while — but really might be better served by a log aggregation and analysis system or something else. Other teams who want to keep mailing lists can, but I’d like to move those too, and eventually I think we’ll want to shut them down too — or perhaps convert them to announcement lists. Next steps -- I know this is a big change. I’ve been thinking of writing this message for a long time. I’d really like to convince everyone that it’s the right thing — or at least, an acceptable one. I'll be convinced once I see it all. What about specific decisions related to my proposal? For each: Because altering the Changes process is a FESCo decision, I’ll file a ticket about that shortly. FESCo moving their own other conversations is, of course, also a FESCo decision. Assuming the first moves forward, I will create the general #devel tag (or other name we come up with) when I create the #change-proposal tag. Moving the packaging list is a Packaging Committee decision. Automated posts can be moved at any time. I can work with the people who own the generation of those reports to figure out a good answer for each. The outcome for other team lists is up to each team. And, I think shutting down devel overall is ultimately a Fedora Council decision. For right now, though: let’s discuss — on the list! As a person in my early 20s, I hate how everything is becoming web centric and no one can convince me to feel otherwise. While I am hearing from varying people around me, how it must be bad using email, it provides client-side filtering unparalleled by any platform that I used in the past. I enjoyed Fedora being on mailing lists, nothing ever came close to the threading of emails. I was not getting lost in threads of conversation while still being under the umbrella topic, no need to open who knows how many links to read all tangents. Regards, Jarek Prokop Software Engineer – Core Services Apps, Ruby RH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 depend on a .so.X in RPM specs?
Interesting situation. On 3/6/23 12:49, Ewoud Kohl van Wijngaarden wrote: While rubygem-openscap is retired in Fedora, the Foreman project still packages it. For context: rubygem-openscap can load libopenscap.so.8 and libopenscap.so.25 through FFI. Today we depend on a specific version, but every time it's bumped we go through a verification to see if the SO version hasn't been bumped. A bit of a tangent first. This sounds like it could be checked via a "simple" FFI load check in %check section, in ruby, something like: ~~~ require 'ffi' module Check extend FFI::Library ffi_lib 'libopenscap.so.25' end ~~~ This will throw an exception if the .so is not available. At first I started with a trivial Requires: libopenscap.so.25 but that pulls in both openscap for i686 and x86_64. Directly depending on libopenscap.so.25()(64bit) feels wrong, so what is the correct approach here? Is there some helper macro here? There are *some*, but nothing universal it seems. JFTR other packages that require libs like this are (and make use of some _isa macros): cross-gcc.spec ghdl.spec glib2.spec julia.spec libreoffice.spec redhat-lsb.spec systemd.spec asahi-installer.spec You can grep through all specfiles using this tar: https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz I'd recommend reading the systemd and Julia files as inspiration, those 2 seem to be doing what you are speaking of. tl;dr those spec files indicate you need to conditionally depend on both, depending on whether it is 32 or 64bit build. Technically speaking I think it should depend on what rubygem-ffi can load, but on x86_64 that's probably 64 bit only. However, this is a bit out of my knowledge area. This could, in theory, be checked in the %check section of the package as I indicated above, if you add the same to BuildRequires, even if it won't help if openscap changes the .so version. Regards, Jarek For completeness, the discussion started in a PR: https://github.com/theforeman/foreman-packaging/pull/9051___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Developer Portal content update for January 2023
Hi all, we have new year, new merged PRs, therefore I made a new build and pushed new release. Give it a moment to propagate. You can preview the changes using this URL before the prod release propagates: https://developer.stg.fedoraproject.org/ Notable changes: * Update .NET docs for .NET 7 release, #471 * https://developer.fedoraproject.org/tech/languages/csharp/dotnet-installation.html * https://developer.fedoraproject.org/tech/languages/dotnet/dotnet-ide.html * https://developer.fedoraproject.org/tech/languages/dotnet/dotnetcore.html * Replace RLS with rust-analyzer as prefered language server for rust, #466 * https://developer.fedoraproject.org/tech/languages/rust/further-reading.html * Update vagrant-libvirt.md, #467 * https://developer.fedoraproject.org/tools/vagrant/vagrant-libvirt.html Minor changes: * Minor spelling correction, #462 * https://developer.fedoraproject.org/start/sw/web-app/about.html * Gtk C -- remove packages absent in recent Fedoras in the install step, #464 * https://developer.fedoraproject.org/tech/languages/c/gtk.html Contributions are always welcome: https://github.com/developer-portal/content Following pages contain deprecated instructions and will be removed soon unless they are updated to work with modern Fedora: https://developer.fedoraproject.org/tech/database/mongodb/about.html https://developer.fedoraproject.org/tech/database/cassandra/about.html https://developer.fedoraproject.org/tech/languages/groovy/groovy-installation.html Thanks, Jarek Prokop ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
Hi, first off, sorry if my write-up seemed a bit harsh, this was the last time I am trying to respond to a change proposal late at night :). On 12/6/22 14:14, Siddhesh Poyarekar wrote: On Mon, Dec 5, 2022 at 7:35 PM Jaroslav Prokop wrote: Default C and C++ compiler flags to build packages in Fedora currently includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of some functions in glibc, thus providing some mitigation against buffer overflows. Since glibc 2.34 and GCC 12, there has been a new fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage of this mitigation. The core change to bring in this mitigation is to change the default build flags in `redhat-rpm-config` so that packages build by default with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`) that do not interact well with `_FORTIFY_SOURCE` and will also need a workaround to downgrade fortification to level 2. The change will also include this override. How come systemd gets an exception? If it is a security option, it should be enabled everywhere. It's an unfortunate (although hopefully temporary) exclusion, see this issue for more context: https://github.com/systemd/systemd/issues/22801 In summary, systemd uses malloc_usable_size in a way that it's discouraged, which results in behaviour that's undefined by the standard, which is now caught out by the compiler. We're hoping to convince the systemd community to fix this so that we can actually build it with fortification. I do not see benefit in a security change that ignores PID 1 process, Do you mean that factually or rhetorically? I've shared statistics of improvement in the proposal, surely improvements to packages like bash, sudo and coreutils would count for something :) If the feature, on the GCC side, is not 100% done. How do I tell a difference of a bug with the _FORTIFY_SOURCE which I will ignore and a bug with my package? _FORTIFY_SOURCE=3 has been enabled on OpenSUSE for nearly a year. If it causes a crash in your package, it's extremely likely that your package has a bug. This is interesting to know. I was not aware of this as I do not follow other distributions closely. I would have appreciated seeing this noted on the proposal. I then know I can compare spec files / build results with the relevant counterparts if it works for them but not for us. I do not have the knowledge or the time to be able to say that GCC generated the wrong machine code and therefore it is not a bug with my package. If my program was not complaining before the change and is now complaining with the change, I am opting out of the change, and filing a bug against GCC on Fedora. I assume that by the package providing the exception, packagers get to choose themselves and we do not need to go through FESCO to disable a security feature? I think they should have to, but that's something for FESCO to decide. _FORTIFY_SOURCE is not a new feature, the new level is just better at catching bugs. Significantly better. To this point, including and opt-out mechanism is IMO reasonable. Even including a "reference" to the opt out mechanism of the current _FORTIFY_SOURCE level, should it be the same, is valuable. == Benefit to Fedora == [https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing Analysis of packages] in Fedora rawhide indicate that the improvement of mitigation coverage is on average over 2.4x, in some cases protecting more than half of the fortified glibc calls in the target application. This change will thus harden Fedora to a significant extent, thus making it a more secure distribution out of the box. 1) Is there some complete source for all these findings? If google sheets cannot handle all the "raw data" as noted in the comment, maybe it is the wrong medium. I've literally posted the raw data in the sheets, please take a look. Ah, I was starting to get mixed up the sheet pages. The "Raw data - All x86_64" include the sentence "Note: Summary data since Google sheets didn't like the raw data". Other raw data variants seem to be correctly "raw". 2) What does *anything* on that google sheet mean. I have managed to figure out, from the article, that bos and bdos correspond to level 2 and 3 of _FORTIFY_SOURCE. However, total of /.*/? Violated accesses? Segfaults? Then followed by "Sum of total". For rubygem-ffi, this reaches into hundreds while "bdos" is 2. That is the only sum I can make, with the data provided. I am no wiser from looking at it, what do the data mean? I've mentioned this in the article, but it's a compile-time statistic of the number of success of __builtin_object_size vs __builtin_dynamic_object_size, using the fortify-metrics plugin: https://github.com/siddhesh/fortify-metrics The numbers you should be looking at are the "coverage" columns, which tells you what percentage of the calls were successful. For rubygem-ffi, the fortification is
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On 12/6/22 10:08, Richard W.M. Jones wrote: On Tue, Dec 06, 2022 at 08:59:03AM +, Richard W.M. Jones wrote: I don't believe the proposal is that everyone *has* to use this (or at least, I hope not). Even existing _FORTIFY_SOURCE=2 is optional. I'd like to know what the problems are that affect systemd however. It's mentioned in this document: https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#2__better_fortification_coverage _FORTIFY_SOURCE=3 revealed another pattern. Applications such as systemd used malloc_usable_size to determine available space in objects and then used the residual space. The glibc manual discourages this type of usage, dictating that malloc_usable_size is for diagnostic purposes only. But applications use the function as a hack to avoid reallocating buffers when there is space in the underlying malloc chunk. The implementation of malloc_usable_size needs to be fixed to return the allocated object size instead of the chunk size in non-diagnostic use. Alternatively, another solution is to deprecate the function. But that is a topic for discussion by the glibc community. Rich. Thanks for sharing. I missed that one. Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Policy on supporting old and external software packages and compat RPMS
On 12/5/22 14:57, Peter Robinson wrote: On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel wrote: On 05/12/2022 12:39, Terry Barnaby wrote: I am wondering what Fedora's policy is on depreciated old shared libraries and particularly compat RPM's ? Fedora is a bleeding edge distribution. If you need old versions, you should try CentOS or RHEL. Being leading edge doesn't mean those usecases aren't relevant, one is not mutually exclusive to the other, especially when it comes to things like FPGAs etc. We still have myriad of VM orchestrating solutions (libvirt, vagrant, gnome-boxes, and probably others I forgot). There shouldn't be a problem spinning up a graphical environment of CentOS 7, getting EPEL and then using the tool. Maybe the tool would work using the `toolbox` utility using last known good Fedora version for the tool. That is just my wild guess however. This is sometimes the tax for being "too" modern. If the vendor does not want to support Fedora, we can't be held accountable to fully support their solution. Does the software work? Yes? That is great! If not, well… we can't do much without the source code under nice FOSS license, can we. Regards, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Developer Portal update
On 10/11/22 20:15, Jarek Prokop wrote: Hi all, Fedora Developer Portal has a new update, it should be visible in a few hours. Most notable changes: Website: * The "Edit this page" and "Report an issue" buttons spawn a new tab instead of redirecting now. Updates: * https://developer.fedoraproject.org/tech/languages/python/fastapi-installation.html * https://developer.fedoraproject.org/tools/vagrant/vagrant-libvirt.html * https://developer.fedoraproject.org/deployment/openshift/about.html Old new pages: (They were written some time back, but due to incorrect yaml in the heading they never showed up correctly) * https://developer.fedoraproject.org/tech/languages/gjs/gjs-installation.html * https://developer.fedoraproject.org/tech/languages/groovy/groovy-installation.html Flatpak installation fixups: * https://developer.fedoraproject.org/tech/languages/dotnet/dotnet-ide.html * https://developer.fedoraproject.org/start/hw/arduino/about.html New feature, deprecation for the following pages, unless an update to these pages is made they will be deleted in 6 months: (Notified fedora-devel, see [1]) * https://developer.fedoraproject.org/tech/database/cassandra/about.html * https://developer.fedoraproject.org/tech/database/mongodb/about.html * MongoDB page got an update with the deprecation, since some commands were using the `sudo service ...` command * https://developer.fedoraproject.org/tech/languages/groovy/groovy-installation.html Please allow for a few hours since this email for these changes to propagate onto the servers. Feedback on these changes and more welcome by email or on https://github.com/developer-portal/content . Regards, Jarek Prokop [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/N3VCUO7KB72GBTEIE5DDLQDY7RQDOF7F/ s/developer.stg.fedoraproject/developer.fedoraproject/g *Sigh*, sorry, I forgot to change the links to point to production and not staging... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Developer Portal update
Hi all, Fedora Developer Portal has a new update, it should be visible in a few hours. Most notable changes: Website: * The "Edit this page" and "Report an issue" buttons spawn a new tab instead of redirecting now. Updates: * https://developer.stg.fedoraproject.org/tech/languages/python/fastapi-installation.html * https://developer.stg.fedoraproject.org/tools/vagrant/vagrant-libvirt.html * https://developer.stg.fedoraproject.org/deployment/openshift/about.html Old new pages: (They were written some time back, but due to incorrect yaml in the heading they never showed up correctly) * https://developer.stg.fedoraproject.org/tech/languages/gjs/gjs-installation.html * https://developer.stg.fedoraproject.org/tech/languages/groovy/groovy-installation.html Flatpak installation fixups: * https://developer.stg.fedoraproject.org/tech/languages/dotnet/dotnet-ide.html * https://developer.stg.fedoraproject.org/start/hw/arduino/about.html New feature, deprecation for the following pages, unless an update to these pages is made they will be deleted in 6 months: (Notified fedora-devel, see [1]) * https://developer.stg.fedoraproject.org/tech/database/cassandra/about.html * https://developer.stg.fedoraproject.org/tech/database/mongodb/about.html * MongoDB page got an update with the deprecation, since some commands were using the `sudo service ...` command * https://developer.stg.fedoraproject.org/tech/languages/groovy/groovy-installation.html Please allow for a few hours since this email for these changes to propagate onto the servers. Feedback on these changes and more welcome by email or on https://github.com/developer-portal/content . Regards, Jarek Prokop [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/N3VCUO7KB72GBTEIE5DDLQDY7RQDOF7F/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Fedora Developer Portal] Call for Contributors for deprecated pages
Hi all, Fedora Developer Portal contains information various information on technologies that require update from time to time to work with current Fedoras. We have identified a few pages that require updating as they contain old information, outdated (or unsupported) versions of the technology or steps that just don't work anymore on current Fedora (such as installing packages not available in Fedora anymore). If there will be no action for 6 months (=~ Fedora release timeframe), the page will be removed completely from the website. You can spot such pages by a yellow box starting with "This page is deprecated!". tl;dr We need help updating the following pages to contain up-to-date steps/information: * Groovy language page https://github.com/developer-portal/content/blob/master/tech/languages/groovy/groovy-installation.md * Cassandra Database https://github.com/developer-portal/content/blob/master/tech/database/cassandra/about.md * MongoDB database https://github.com/developer-portal/content/blob/master/tech/database/mongodb/about.md The content sources live in this repo: https://github.com/developer-portal/content Thanks, Jarek Prokop ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Hi, Usually for Rawhide updates CLOSED RAWHIDE + add NVR into `fixed in version` if only Rawhide fixes that bug (e.g., a new software version), that should be enough. But it seems auto updates can take care of the tickets if you specify the bugs via the `Resolves: rhbz#1234` references as noted by Vít. A webpage… Depends what you plan on doing, I use this if I am unsure in the bug status workflow: https://docs.fedoraproject.org/en-US/package-maintainers/bug_status/ Regards, Jarek On 8/26/22 16:28, Ron Olson wrote: Thanks for the info, I did just that. Do you or anyone knows if there is a webpage that describes how to handle Rawhide updates specifically? I haven’t found anything useful about what to do in this particular situation. Ron On 26 Aug 2022, at 9:04, Tom Hughes wrote: 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 todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: KOJI Rawhide error: "Empty %files file ...../debugsourcefiles.list"
Hi,
We have noticed the same issue when we wanted to do a scratch build of
Ruby https://koji.fedoraproject.org/koji/taskinfo?taskID=90003939 .
If someone manages to reproduce it, my colleague created this patch for
the script that could be worth trying out:
https://gist.github.com/pvalena/8fe7899ca8ee6cd52c0db17d322503a4
To the failure itself,
The file is empty, simply because something inside the debuginfo RPM
scripts segfaulted. From the logs of your build:
```
+ /usr/bin/find-debuginfo -j6 --strict-build-id -m -i --build-id-seed
8.0.30-1.fc37 --unique-debug-suffix -8.0.30-1.fc37.x86_64
--unique-debug-src-base community-mysql-8.0.30-1.fc37.x86_64 --run-dwz
--dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S
debugsourcefiles.list /builddir/build/BUILD/mysql-8.0.30
/usr/bin/find-debuginfo: line 431: 653188 Done find "$RPM_BUILD_ROOT" !
-path "${debugdir}/*.debug" -type f \( -perm -0100 -or -perm -0010 -or
-perm -0001 \) -print
653189 | LC_ALL=C sort
653190 Segmentation fault (core dumped) | file -N -f -
653191 | sed -n -e 's/^\(.*\):[ ]*.*ELF.*,
not stripped.*/\1/p'
653192 | xargs --no-run-if-empty stat -c '%h
%D_%i %n'
653193 | while read nlinks inum f; do
if [ $nlinks -gt 1 ]; then
var=seen_$inum; if test -n "${!var}"; then
echo "$inum $f" >> "$temp/linked"; continue;
else
read "$var" < <(echo 1);
fi;
fi; echo "$nlinks $inum $f" >> "$temp/primary";
done
find: 'debug': No such file or directory
```
This is also the case of Ruby, it started happening after the mass rebuild.
Regards,
--
Jarek Prokop
Associate Software Engineer
Core Services - Apps
Red Hat
On 7/26/22 11:48, Michal Schorm wrote:
Hi,
I've just started (scratch-)building MySQL 8.0.30. (package 'community-mysql').
And the build on Rawhide failed with an error message, I haven't seen before:
"
Processing files: community-mysql-debugsource-8.0.30-1.fc37.x86_64
error: Empty %files file
/builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
RPM build errors:
Empty %files file /builddir/build/BUILD/mysql-8.0.30/debugsourcefiles.list
Child return code was: 1
"
Here is the build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=90072976
The issue appeared on every architecture.
A build from the same sources for F35 (scratch-)builds fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=90073173
--
Does this error ring a bell to anyone?
Since the RPM debug-stuff is automatically generated and the package
builds fine for F35, I assume it's a KOJI issue rather than the
package issue.
I'll submit scratch builds for F36 & F37 in a moment.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: New Fedora Developer Portal release
Hi, On 6/17/22 22:39, Ron Olson wrote: Hi, how would I go about adding a page for Swift under Languages and Databases? I looked at "Create a new Project" but I couldn't how to create a page that would fall under that section. First of all, I recommend checkout out our documentation regarding contributing: https://developer-portal.github.io/ Namely this section might be of interested to your case: https://developer-portal.github.io/doc/structure.html#page If you'd prefer some example in how to make a new page, take a look at the PR for new Julia pages: https://github.com/developer-portal/content/pull/439 If you want to check out how it looks, check out DEVELOPMENT.md which contains information related to running the site locally: https://github.com/developer-portal/website/blob/master/DEVELOPMENT.md Jarek Ron On Fri, Jun 17, 2022 at 12:04 PM Jarek Prokop wrote: Hi all, I have pushed new update for Fedora Developer Portal. New content should be available in the coming hour or 2 with the following changes and updates. New: Julia installation page: * https://developer.fedoraproject.org/tech/languages/julia/julia-installation.html Update go package installation instructions as they were outdated: * https://developer.fedoraproject.org/tech/languages/go/go-packages.html * https://developer.fedoraproject.org/tech/languages/go/go-programs.html Update Java sections: * https://developer.fedoraproject.org/tech/languages/java/java-build-tools-installation.html * https://developer.fedoraproject.org/tech/languages/java/java-installation.html Update list of available Pythons in Fedora: * https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html Regards, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
New Fedora Developer Portal release
Hi all, I have pushed new update for Fedora Developer Portal. New content should be available in the coming hour or 2 with the following changes and updates. New: Julia installation page: * https://developer.fedoraproject.org/tech/languages/julia/julia-installation.html Update go package installation instructions as they were outdated: * https://developer.fedoraproject.org/tech/languages/go/go-packages.html * https://developer.fedoraproject.org/tech/languages/go/go-programs.html Update Java sections: * https://developer.fedoraproject.org/tech/languages/java/java-build-tools-installation.html * https://developer.fedoraproject.org/tech/languages/java/java-installation.html Update list of available Pythons in Fedora: * https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html Regards, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
New Fedora Developer Portal release
Hi all, I have just pushed a new minor update for Fedora Developer Portal, it is mostly replacing `dnf install` with flatpak counterparts on orphaned packages (namely arduino and eclipse packages): * https://developer.fedoraproject.org/start/hw/arduino/about.html * https://developer.fedoraproject.org/tech/languages/dotnet/dotnet-ide.html * https://developer.fedoraproject.org/tools/eclipse/about.html Thanks, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Developer Portal update
Forgot to reply to devel :) On 4/5/22 22:54, Jaroslav Prokop wrote: On 4/5/22 13:23, Ben Beasley wrote: Thanks for updating these pages. I noticed that the Flask and Django pages have language like: Fedora includes a |python3-flask| package that you can install and import. However, unless you are developing or packaging an application for Fedora, it is more useful to install Flask as a third-party package inside a /virtual environment/. This will keep your project separate from your system, giving you more freedom in choosing additional libraries and their versions, and easing collaboration with people who aren’t using Fedora yet. which, I think is reasonable; for better or worse, this is how Python-based web development is conventionally done in practice. It might be worthwhile to use similar language on the FastAPI page. Currently, the page recommends a virtualenv, but doesn’t mention that there is a python3-fastapi package in Fedora too. Thanks for the feedback! If would find time to write this up, feel free to contribute initial PR into the content [0] repo. I already submitted an issue [1] to make sure it is tracked. Regards Jarek [0] https://github.com/developer-portal/content/ [1] https://github.com/developer-portal/content/issues/424___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Fedora Developer Portal update
Hello, overdue update has just been pushed to release and will be available soon on the website. Most notable changes: * Introduce Lua installation [0] * Python FastAPI installation [1] * Configuring RubyGems through .gemrc [2] * Document usage of qemu sessions in Vagrant [3] * Long overdue update of IRC links to point to Libera [4] [0] https://developer.fedoraproject.org/tech/languages/lua/lua_installation.html [1] https://developer.fedoraproject.org/tech/languages/python/fastapi-installation.html [2] https://developer.fedoraproject.org/tech/languages/ruby/gems-installation.html [3] https://developer.fedoraproject.org/tools/vagrant/vagrant-libvirt.html [4] https://developer.fedoraproject.org/deployment/secondary_architectures/powerpc.html [4] https://developer.fedoraproject.org/deployment/secondary_architectures/s390.html [4] https://developer.fedoraproject.org/tech/languages/python/python-sig.html Regards, Jarek Prokop --- Fedora IRC: jackorp ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Review swap
Hi, I have a few rubygem packages that need a (re-)review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010263 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010313 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2010350 Thanks, Jarek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Fedora Developer Portal Update
Hello, Fedora Developer Portal just got an update. Notable changes: * Added Redis page [1] * Added Fortran page [2] * Added Virtualization pages [3] Any feedback is welcome! [1] https://developer.fedoraproject.org/tech/database/redis/about.html [2] https://developer.fedoraproject.org/tech/languages/fortran/fortran-installation.html [3] https://developer.fedoraproject.org/tools/virtualization/about.html Regards, Jarek Prokop Intern, Red Hat Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
