Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6
Here is a proof-of-concept one-liner (split up a bit for readability purposes):
```fish
#!/usr/bin/fish
function get_dependent_pkgs
dnf -q repoquery --repo=koji --qf='%{sourcerpm}' --whatrequires $argv[1]
end
function parse_names
get_dependent_pkgs | rev | cut -d/ -f1 | cut -d- -f3- | rev
end
# https://src.fedoraproject.org/rpms/fbrnch
function topo_sort_and_sidetag_build
fbrnch parallel --sidetag rawhide (parse_names)
end
```
May an actual proven packager or infrastructure people adapt the three lines
above in a workable program.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)
[…] This is getting out of hand, so I logged straight into the web client. > Ok, I understand what's happening. Your email client doesn't recognize > the in-reply-to option from the url. Exactly; I will enquire and send a bug report. > Why are replying from there instead of using your email client normally? I set this list to send digests instead of individual messages; so, I was using other means to get to the in-reply-to field. > > You can't do it that way. It has to be a header. For example, if you > look at the source of my previous reply to you, there's this header: > In-Reply-To: <1854295.N2a68q8abs@pandora> > So my email client matches that to your email and can link them together. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: tzdata update
Thanks to everybody for the quick response. As you'll see in the ticket thread, the maintainer is now handling the update. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
tzdata update
Greetings, The sole purpose of this thread is to bring attention to https://bugzilla.redhat.com/show_bug.cgi?id=1646930 Unreliable time on the system is a daily annoyance that will be easily fixed by aligning the Fedora version with the upstream's. Could someone ping the package maintainer? Also, a proven packager could just initiate the build. Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Get LLVM's libc++abi into Fedora, BZ1332306
> So what? Why is that a problem? > Does the libc++abi have better performance for exception handling? > Smaller footprint for RTTI? > More new features, such as C++17's std::uncaight_exceptions()? > Just because there's a different low-level C++ runtime library > available doesn't mean that using it makes sense. Fedora is built with > GCC and libstdc++, so swapping those pieces out has potentially large > consequences. > You might think I'm biased as I'm a libstdc++ maintainer, but I'd say > the same thing if somebody was asking about replacing libcxxabi on Mac > OS with libsupc++, or replacing libcxxrt on FreeBSD with libsupc++: > don't do it unless you really know what you're doing, and can isolate > it completely from the rest of the OS. As I wrote in another mail, my main intent was shedding some light into a frozen review request. Nonetheless, thank you for pointing out what to consider when mixing things that were not designed to work together. Googling on the subject quickly leads to one of your writing among the top results [1]; I do not in no way intend to “educate” the libstdc++ maintainer, but if you are still not closely following libc++ development (as implied in [1]), maybe [2] could be of some use. > If adding the package makes it easier for people to create > incompatible builds for Fedora that don't play nicely with the rest of > the OS I don't think it's a good idea. The first use case for the package is not mine, it belongs to Tom Callaway who in the first place wanted and created the package. His review request explains why he did. Then in the comments and in another bugzilla, third parties expressed the same desire to have the package. My needs are modest, I mainly would like to try some stuff on my Fedora box before interacting with people who use platforms where libc++ is the “system default”; the said stuff is not much involved, it does not try to play “with the rest of the OS”. So thanks to Fedora for helping me in that vein, as I am confident Neal Gompa and Tom Callaway will eventually make the package alive. [1] http://stackoverflow.com/questions/14972425/should-i-use-libc-or-libstdc [2] http://lists.llvm.org/pipermail/cfe-dev/2016-July/049814.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Get LLVM's libc++abi into Fedora, BZ1332306
> I'll take on the review, Thank you so much for stepping in, this is mostly appreciated. > but you really should consider becoming > involved in Fedora as a packager, as any packager can review another > packagers packages proposed for inclusion into Fedora. I am a slow learner, but there is some progress. It is by reading some wikis that I learnt about the review process and about who can review a package. Next, I dived into the RPM format and am still stuck there. Hopefully, when the learning is over, I will create some packages, there are a couple of SIGs where I plan to contribute. Once more, thanks for considering the libc++abi. Apologies if my shameless touting for the package was not the most elegant way to put forward the case. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Get LLVM's libc++abi into Fedora, BZ1332306
>> Alas, clang++ now needs to link against the GCC ABI to successfully compile. > what actual problem is caused by that? Please read instead “Alas, clang++ currently needs to link against the GCC ABI to successfully compile.” The problem is that one might want to use libstdc++ (GCC) and libc++ (LLVM) along with GCC ABI and LLVM ABI, respectively. Fedora currently enables the GCC case, but one has to fall back to GCC ABI even when using an LLVM library. > which clang instrumentation tool requires libc++abi? Not an instrumentation in particular, I ran into problems when trying to LD_PRELOAD some instrumented binaries and founding they needed libc++abi. > there are subtle corner cases breaking exception handling: > > https://whatofhow.wordpress.com/2016/03/01/libclibcabi-on-linux/ Blog post amended in the comments. Overall, I am not willing to argue about C++ best coding/debugging practices. I am rather asking if there is any possibility that package review request (BZ1332306) stalled for ages would get some care. Had I been a packager, sure I would try to handle the review process myself, but I am not a packager. It would be nice to have some contributor giving the libc++abi package some time, I am quite sure there are many people who will be very grateful. Thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Get LLVM's libc++abi into Fedora, BZ1332306
> I'm not sure if I follow. Supporting multiple C++ ABIs would make > things more complicated for developers because they now have to figure > out which ABI their project needs and if all the libraries they want to > use are available with the right ABI. From the example in BZ1415512, all libraries are standard, the sources remain the same regardless the compiler to be used. Alas, clang++ now needs to link against the GCC ABI to successfully compile. There are some cases when one needs to try different tools, for instance to take advantage of the LLVM's instrumentation tools which IMHO constitute a plus, not a pain. > > I really don't think we should move in this direction. > Reading the package review request by "spot" and the comments, there is no indication the review stalled because of ABIs worries. But I don't really have a clue in packaging issues; onlooking at the BZ, it stroke me that particular package was not a hard case review-wise. Are there pointers elsewhere indicating the corner cases of introducing another C++ ABI into Fedora? What would be your comments about the situation in Debian+derivatives and Archlinux+derivatives? Both distros have the LLVM ABI and so far, so good for C++ developers. Thanks. > Thanks, > Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Get LLVM's libc++abi into Fedora, BZ1332306
Greetings, The LLVM project has been providing a C++ ABI for a while [1]. A naive user like I'm would presume Fedora easily ships with that, as the saying goes: “Fedora is a developer-friendly distro.” Unfortunately, that isn't the case for this instance and if one is using clang++, they have to link against the GCC's ABI instead of the LLVM's. Elsewhere, there is no such a quirk, see for instance [2] and [3]. Thanks to Tom Callaway, it's now more than 9 months that there is a candidate package for this very purpose [4]. If someone with a pedigree as that of "spot" resorts to saying: “I am waiting on a review for 1332306 in order to get libcxxabi into Fedora. I did not think it would take this long for that to happen.” [5], what a looker-by should think? Is this delay on purpose or is the review that difficult? Could some benefactor packager take over the review so that LLVM+CLANG are not any more like second-citizens in Fedora? Thanks. --- [1] http://libcxx.llvm.org/ [2] https://packages.debian.org/search?keywords=libc%2B%2Babi [3] https://aur.archlinux.org/packages/libc%2B%2Babi/ [4] https://bugzilla.redhat.com/show_bug.cgi?id=1332306 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1415512#c1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
