F38 updates stuck in pending
If anyone reading this email has special powers to get some of the week old F38 updates unstuck from pending, please click the magic button. đ An example of such an update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ef0e8e36fc Thanks, -- Bojan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Orphaning packages
On 30/06/2023 00:09, crissdell wrote: Hi, i'm really interested in maintaining this rpms, jdns and git-subrepo, but i'm not an packager yet, I really appreciate if someone is willing to mentor me, I dont want to mess it up. https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Announcing fmt library soversion bump
The side tag has been merged: https://bodhi.fedoraproject.org/updates/FEDORA-2023-4e8e736635 FTBFS (final): arbor (not related to fmt, some tests failed on s390x) CuraEngine bout++ cachelib dolphin-emu folly mangohud (not related to fmt) wasmedge watchman FTI issues will be generated automatically after the next Rawhide compose. Maintainers of these packages can build fixed versions to Rawhide directly without using any side tags. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Orphaning packages (was LibreOffice packages)
Bastien Nocera wrote: > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, > as I am transferred to another team. So Red Hat is essentially killing all work on desktop packages, not just on LibreOffice? Also considering that several of those packages are libraries that cannot just be put on Flathub as LibreOffice can (which was their excuse for terminating all work on LibreOffice packaging). With the layoff and the destruction of the position of the Fedora Program Manager, the termination of public RHEL source releases, and this move, Red Hat is really turning into an unfriendly company, and I really have to wonder whether Fedora is going to be of any use to me in the long run. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Multithreaded check-files script
> Nicholas Frizzell writes: > Has anyone investigated making use of multithreading for check-files > previously? I'm not sure multithreading is all that meaningful for that script; it's really quite simple, after all. It runs find to get a list of files, sorts it, and diffs that against the list of files from stdin (which gets sorted first). I suppose the sort of stdin could theoretically be done in parallel with the find run, but I'm not sure I see any other simple optimizations that could be done. I guess if you have hundreds of thousands of files then those sort calls could take some more significant amount of time, but my understanding is that sort already parallelizes automatically (up to 8 CPUs). What is actually taking up the time here? - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Intent to retire OpenCOLLADA
Richard Shaw wrote: > If anyone wants to take it over let me know otherwise I plan to retire > early next week. The right thing to do here is to orphan it, not retire it directly. It will be retired if nobody picks it up, but if somebody wants to pick it up, it saves them the unnecessary bureaucracy of unretiring the package. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Is there a chance to phase out `/lib64` directory?
Carlos O'Donell wrote: > And assembling those sysroots is not straight forward. The easiest way is to unpack a live image. If you are targeting an Arch- based or similar distro, you will probably get away with just unpacking the image, because it installs development files by default. But if you are targeting Fedora or a similar distro, you will probably want to compose a custom live image with a bunch of -devel packages. (You can also try to install packages within the sysroot, but if you are cross-compiling to a different architecture, that is not straightforward, you either need to use host tools and point them to the sysroot, or to use CPU emulation to run the tools within the sysroot, or as a last resort to unpack package contents manually.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!
Seems missing a greeter package, i do not have a fc38 machine, could you try: dnf in lightdm-gtk and test again? On 2023/6/30 8:25, André Verwijs wrote: only getting this: https://i.postimg.cc/5ySKnGdw/lightdm-test-mode.webp ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 -- chaoran ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!
only getting this: https://i.postimg.cc/5ySKnGdw/lightdm-test-mode.webp ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Red Hat & Fedora -- largely stepping out of this ecosystem
Hey! On Thu, 2023-06-29 at 19:12 +0200, Paolo Bonzini wrote: > > > > On 6/26/23 18:47, Jeff Law wrote: > > > > What Red Hat has done may be technically legal and perhaps good > > > > for > > > > its business. > > > > Something I'm having trouble with is Red Hat's position that > > you can choose to be a customer or to exercise your rights > > under the GPL, but you cannot be both. > > The thing is, many people are learning this only now, because things > indeed have become tougher for people who prepare the RHEL rebuilds, > but > this is not new. _Nothing_ in the service agreement or in any other > legal document has changed since last week, the exact same terms > have > been applicable to the extended-support branches since the beginning > of > RHEL. In fact, as Frank pointed out elsewhere, this is something > that > other companies have been doing for decades as well. > In my opinion, people haven't complained about service agreements because, till recent changes, RHEL sources were available publicly. The only important contract was the open-source license of the software. Now we have both the license of the software and the service agreement. > For all the people that are complaining only now that the free beer > part > is taken away, I can't help thinking that it's a bit disingenuous to > make it about "free as in freedom", when that clause has existed > forever. What do you mean by "free beer part"? Isn't open-source software free of charge? Does anybody pay for it? The question is if RHEL software is still open-source or closed-source. At least if I look at the OSI's [1] definition of Open Source, the situation isn't clear to me. > > (As an aside, the service agreement also mentions that any open > source > license overrides the service agreement if needed. So by definition > this might be void but it certainly is not a GPL violation). > Yeah, it's hard to say which rules of service agreement are overwriten by software licenses. Especially that there are quite a few licenses shipped with the distribution. Cheers, Piotr [1] OSI Open Source Definition Introduction Open source doesnât just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: 1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. 4. Integrity of The Authorâs Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of âpatch filesâ with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. 7. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. 8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the programâs being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the programâs license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. 9. License
Multithreaded check-files script
When building an rpm package for larger projects, one of the stages that I've noticed seems to take a fair amount of time to complete is the check-files script, which appears to run single-threaded. Has anyone investigated making use of multithreading for check-files previously? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
On Thu, 2023-06-29 at 22:00 +0200, Simon de Vlieger wrote: > > Also, for understanding I've been diving through the kickstart > repositories to define a common base set and interdependencies. I've > graphed out the kickstart files and their relationships here: > https://supakeen.fedorapeople.org/kickstart-graph.png it seems to have > found some includes to kickstarts which no longer exist in the repositories! That is entirely possible. There may be some kickstarts in there that aren't actually *used* for anything any more. Don't get me wrong, this stuff could definitely get improved, but it is important to understand exactly how the current mess works before you set about fixing it. :D -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Orphaning packages
Hi, i'm really interested in maintaining this rpms, jdns and git-subrepo, but i'm not an packager yet, I really appreciate if someone is willing to mentor me, I dont want to mess it up. Thanks for your time Sincerely Cristian Delgado --- Original Message --- On Friday, June 23rd, 2023 at 1:53 AM, Vitaly Zaitsev via devel wrote: > Hello. > > I orphaned the following packages: > > rpms/axc > rpms/git-subrepo > rpms/jdns > rpms/maddy > rpms/mdns > rpms/pidgin-groupchat-typing-notifications > rpms/pidgin-privacy-please > rpms/pidgin-toobars > rpms/psi > rpms/psi-plus > rpms/purple-discord > rpms/purple-googlechat > rpms/purple-libsteam > rpms/purple-lurch > rpms/purple-matrix > rpms/purple-plugin_pack > rpms/purple-skypeweb > rpms/python-wloc > rpms/python-networkmanager > rpms/python-pytelegrambotapi > rpms/python-emoji > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: 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: UW-IMAP
W dniu 29.06.2023 o 16:27, David Both pisze: I also spent about 4 days trying to get Dovecot to work with SendMail in a test VM setup. I'm either missing one or more important bits or its just too complex for me. None of the docs I have found anywhere has a complete start-to-finish picture. Jan Wildeboer wrote nice set of steps for Postfix + Dovecot combo. With SPF, DKIM etc. https://jan.wildeboer.net/2022/08/Email-0-The-Journey-2022/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Retiring pvs-sbcl
I intend to retire the pvs-sbcl package soon. First, it depends on sbcl, which has failed to build for so long that it is on the list of packages to be retired in August. (See https://src.fedoraproject.org/rpms/sbcl/pull-request/1.) Second, the current version of pvs-sbcl (7.1) does not build successfully with the latest sbcl version. There has been a lot of git activity since 2020, when 7.1 was released, so I tried building with git HEAD. That is when I discovered that git HEAD now downloads a bunch of Lisp libraries during the build. I could download them in advance and include them as Sources, but ... Third, pvs-sbcl by itself is not useful for why3 (the only Fedora package that has ever required it). There are a bunch of NASA libraries that are necessary for it to be useful. We have never been able to package the NASA libraries due to license issues. (Some years ago, I spearheaded an effort to track down all of the contributors to the NASA libraries and get them to agree to a permissive license. I got quite a few people to sign on, but was never able to reach them all.) For that reason, the why3 package has not required pvs-sbcl for some years now. If any of you formal methods afficionados want to take over maintaining pvs-sbcl, let me know. Otherwise I will retire it next week. I'm starting to feel like my job as a Fedora packager is to kill off software that I once worked on. First XEmacs, now PVS. Sigh. Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On Tue, Jun 13, 2023 at 6:03âŻAM Tomas Hrnciar wrote: > If you'd like to build a package after we already rebuilt it, you should be > able to build it in the side tag via: > > on branch rawhide: > $ fedpkg build --target=f39-python > $ koji wait-repo f39-python --build I'm trying to help by fixing packages I maintain that failed to build on the first attempt. However, I'm having some issues with Cython generating incorrect code. The most recent example is the python-pytest-cython package, which fails because Cython generates code that accesses the use_tracing field of _PyCFrame. That field was removed in python 3.12. There are a couple of other packages that have issues with the representation of a long object. In python 3.11 and before, we had: struct _longobject { PyObject_VAR_HEAD digit ob_digit[1]; }; In python 3.12, we have: typedef struct _PyLongValue { uintptr_t lv_tag; /* Number of digits, sign and flags */ digit ob_digit[1]; } _PyLongValue; struct _longobject { PyObject_HEAD _PyLongValue long_value; }; The Cython package in the side tag has this in Includes/cpython/longintrepr.pxd: ctypedef class __builtin__.py_long [object PyLongObject]: cdef digit* ob_digit which is incorrect for python 3.12. I think I'm stuck until Cython has been updated for python 3.12. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
Once the portables will be built in f37, the repacked binary in f37 and in f38 (39...)will be identical. Rpms have some additional value - split to subpakcages, few symlinks due to system integration, system tzdata, system crypto binding and so on. On Thu, 29 Jun 2023 at 22:20, Tom Stellard wrote: > > On 6/29/23 13:07, Jiri Vanek wrote: > > nn. You were right. There are going to be two separated packages. > > Portable, built once in oldest live, and "normal" which is going to > > repack them for all and shipp them. > > My apologise for typo in last second change: > > https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=681794&oldid=681791 > > > > narrowed. > > > > Ok, that makes sense now. > > My next question is what is the difference between the > java-xy-openjdk-portable package > that is built on f37 and the repacked java-xy-openjdk package that is shipped > on f38. > Are the bits inside the package exactly the same? > > -Tom > > > On Thu, 29 Jun 2023 at 21:16, Tom Stellard wrote: > >> > >> On 6/29/23 11:06, Jiri Vanek wrote: > >>> Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several > >>> time in the proposal. Still the > >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > >>> adjusted > >>> > >> > >> OK, I see. I thought there were going to be two different packages. > >> java-xy-openjdk-portable > >> and java-xy-openjdk. Where java-xy-openjdk is the one that gets shipped > >> in Fedora and > >> java-xy-openjdk-portable lives only in the side-tags. > >> > >> -Tom > >> > >>> Tahnx! > >>> > >>> On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: > > On 6/29/23 09:52, Jiri Vanek wrote: > > Hi Tom! > > > > Thanx a lot of for input. Although I did my bes with the tagging, it > > will be learning on the go. > > I had adapted > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > as you suggested. It is great improvement. > > > > Thanks, this looks better. > > For step 5. should the first mention of java-xy-openjdk-portable actually > be java-xy-openjdk ? Same question for step 7. > > -Tom > > > Especially the config, I was not aware about. That woudl indeed help a > > lot. > > The usage of pernament tag is someging I have to learn, but is > > moreover necessary for proper srpm rebuil. > > > > TYVM! > > J. > > > > On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > >> > >> On 6/26/23 09:21, Aoife Moloney wrote: > >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > >>> > >>> 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 == > >>> > >>> This is the last step in > >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > >>> effort. JDKs in fedora are already static, and we repack portable > >>> tarballs into RPMs. Currently, the portable tarball is built for each > >>> Fedora and EPEL version. Goal here is to build each JDK > >>> (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in > >>> all live Fedoras. If jdk is buitl in epel, it will be built in oldest > >>> possible epel and repacked in newer live epels. > >>> > >>> > >>> == Owner == > >>> * Name: [[User:jvanek| Jiri Vanek]] > >>> > >>> * Email: jva...@redhat.com > >>> > >>> > >>> == Detailed Description == > >>> > >>> As described in > >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > >>> during last year, packaging of JDKs had changed dramatically. As > >>> described in the same wiki page and in individual sub changes and > >>> devel threads, the primary reason for this is to lower maintenance and > >>> still keep Fedora Java friendly. > >>> > >>> * In the first system wide change, we have changed the JDKs to build > >>> properly as standalone, portable JDK - the way JDK is supposed to be > >>> built. I repeat, we spent ten years by patching JDK to become properly > >>> dynamic against system libs, and all patches went upstream, but this > >>> has become a fight which can not be won. > >>> > >>> * As a second step we introduced portable RPMs, which do not have any > >>> system integration, only build JDK and pack the final tarball in RPM > >>> for Fedora use. > >>> > >>> * In third step - without any noise, just verified with fesco - > >>> https://pagure.io/fesco/issue/2907 - we stopped building J
Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
On 6/29/23 10:42, Kevin Fenzi wrote: On Thu, Jun 29, 2023 at 10:14:31AM -0700, Tom Stellard wrote: On 6/29/23 09:52, Jiri Vanek wrote: Hi Tom! Thanx a lot of for input. Although I did my bes with the tagging, it will be learning on the go. I had adapted https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution as you suggested. It is great improvement. Thanks, this looks better. For step 5. should the first mention of java-xy-openjdk-portable actually be java-xy-openjdk ? Same question for step 7. I don't think the fixed sidetag idea will work. (Unless you are planning on doing something different with rawhide). Bodhi won't let you make an update from a non sidetag tag, so you would have to tag them into fN-updates-candidate, but then they would go one by one into rawhide and not be tested/gated as a unit. What the difference between a fixed side-tag and a normal side-tag from bodhi's perspective? -Tom But of course we could do fixed tags for stable releases and have a sidetag flow for rawhide, but that might make things more confusing. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
On 6/29/23 13:07, Jiri Vanek wrote: nn. You were right. There are going to be two separated packages. Portable, built once in oldest live, and "normal" which is going to repack them for all and shipp them. My apologise for typo in last second change: https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=681794&oldid=681791 narrowed. Ok, that makes sense now. My next question is what is the difference between the java-xy-openjdk-portable package that is built on f37 and the repacked java-xy-openjdk package that is shipped on f38. Are the bits inside the package exactly the same? -Tom On Thu, 29 Jun 2023 at 21:16, Tom Stellard wrote: On 6/29/23 11:06, Jiri Vanek wrote: Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several time in the proposal. Still the https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution adjusted OK, I see. I thought there were going to be two different packages. java-xy-openjdk-portable and java-xy-openjdk. Where java-xy-openjdk is the one that gets shipped in Fedora and java-xy-openjdk-portable lives only in the side-tags. -Tom Tahnx! On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: On 6/29/23 09:52, Jiri Vanek wrote: Hi Tom! Thanx a lot of for input. Although I did my bes with the tagging, it will be learning on the go. I had adapted https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution as you suggested. It is great improvement. Thanks, this looks better. For step 5. should the first mention of java-xy-openjdk-portable actually be java-xy-openjdk ? Same question for step 7. -Tom Especially the config, I was not aware about. That woudl indeed help a lot. The usage of pernament tag is someging I have to learn, but is moreover necessary for proper srpm rebuil. TYVM! J. On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: On 6/26/23 09:21, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) 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 == This is the last step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs effort. JDKs in fedora are already static, and we repack portable tarballs into RPMs. Currently, the portable tarball is built for each Fedora and EPEL version. Goal here is to build each JDK (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in all live Fedoras. If jdk is buitl in epel, it will be built in oldest possible epel and repacked in newer live epels. == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed dramatically. As described in the same wiki page and in individual sub changes and devel threads, the primary reason for this is to lower maintenance and still keep Fedora Java friendly. * In the first system wide change, we have changed the JDKs to build properly as standalone, portable JDK - the way JDK is supposed to be built. I repeat, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went upstream, but this has become a fight which can not be won. * As a second step we introduced portable RPMs, which do not have any system integration, only build JDK and pack the final tarball in RPM for Fedora use. * In third step - without any noise, just verified with fesco - https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully integrated RPMs. Instead of this, normal RPMs BUildRequire portable RPMs and just unpack it, and repack it. Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in oldest live Fedora, and repack everywhere. java-latest-openjdk, which contains latests STS JDK - currently 20, soon briefly 21 and a bit after 22... If we would built java-latest-openjdk in oldest live EPEL - epel8 now, we have verified, that such repacked JDKs works fine, however repack from epel seem to not be acceptable, thus ajva-latest-openjdk will be built twice - one in oldest live fedora, and once in oldest live epel. Build forme oldest possible epel will be repacked to that one or newer epels, and build from oldest live fedroa to all fedoras. === theoretical tagging solution === 1. request side tags for all releases 2. build the actual Java in the side tag for the oldest thing Could you use the real package name here. I think that will make it easier to understand. You can still put 'actual Java' in parens or something. 3. tag the result ot (2) to all side tags from (1)
Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
nn. You were right. There are going to be two separated packages. Portable, built once in oldest live, and "normal" which is going to repack them for all and shipp them. My apologise for typo in last second change: https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=681794&oldid=681791 narrowed. On Thu, 29 Jun 2023 at 21:16, Tom Stellard wrote: > > On 6/29/23 11:06, Jiri Vanek wrote: > > Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several > > time in the proposal. Still the > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > adjusted > > > > OK, I see. I thought there were going to be two different packages. > java-xy-openjdk-portable > and java-xy-openjdk. Where java-xy-openjdk is the one that gets shipped in > Fedora and > java-xy-openjdk-portable lives only in the side-tags. > > -Tom > > > Tahnx! > > > > On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: > >> > >> On 6/29/23 09:52, Jiri Vanek wrote: > >>> Hi Tom! > >>> > >>> Thanx a lot of for input. Although I did my bes with the tagging, it > >>> will be learning on the go. > >>> I had adapted > >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > >>> as you suggested. It is great improvement. > >>> > >> > >> Thanks, this looks better. > >> > >> For step 5. should the first mention of java-xy-openjdk-portable actually > >> be java-xy-openjdk ? Same question for step 7. > >> > >> -Tom > >> > >>> Especially the config, I was not aware about. That woudl indeed help a > >>> lot. > >>> The usage of pernament tag is someging I have to learn, but is > >>> moreover necessary for proper srpm rebuil. > >>> > >>> TYVM! > >>>J. > >>> > >>> On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > > On 6/26/23 09:21, Aoife Moloney wrote: > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > > > > 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 == > > > > This is the last step in > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > > effort. JDKs in fedora are already static, and we repack portable > > tarballs into RPMs. Currently, the portable tarball is built for each > > Fedora and EPEL version. Goal here is to build each JDK > > (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in > > all live Fedoras. If jdk is buitl in epel, it will be built in oldest > > possible epel and repacked in newer live epels. > > > > > > == Owner == > > * Name: [[User:jvanek| Jiri Vanek]] > > > > * Email: jva...@redhat.com > > > > > > == Detailed Description == > > > > As described in > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > > during last year, packaging of JDKs had changed dramatically. As > > described in the same wiki page and in individual sub changes and > > devel threads, the primary reason for this is to lower maintenance and > > still keep Fedora Java friendly. > > > > * In the first system wide change, we have changed the JDKs to build > > properly as standalone, portable JDK - the way JDK is supposed to be > > built. I repeat, we spent ten years by patching JDK to become properly > > dynamic against system libs, and all patches went upstream, but this > > has become a fight which can not be won. > > > > * As a second step we introduced portable RPMs, which do not have any > > system integration, only build JDK and pack the final tarball in RPM > > for Fedora use. > > > > * In third step - without any noise, just verified with fesco - > > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully > > integrated RPMs. Instead of this, normal RPMs BUildRequire portable > > RPMs and just unpack it, and repack it. > > > > Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in > > oldest live Fedora, and repack everywhere. java-latest-openjdk, which > > contains latests STS JDK - currently 20, soon briefly 21 and a bit > > after 22... If we would built java-latest-openjdk in oldest live EPEL > > - epel8 now, we have verified, that such repacked JDKs works fine, > > however repack from epel seem to not be acceptable, thus > > ajva-latest-openjdk will be built twice - one in oldest live fedora, > > and once in oldest live epel. Build forme oldest possible epel will be > > repacked to that one or newer epels, and build from oldest live fedroa > > to all fedoras. > >
Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
On 6/28/23 17:06, Adam Williamson wrote: On Wed, 2023-06-28 at 13:01 +0200, OndĆej Budai wrote: I already answered you here: https://pagure.io/fedora-workstation/issue/384#comment-862709 TL;DR: Let's figure this out when we are migrating other artifacts. For now, the blueprint will be empty/minimal. Thanks a lot for engaging with the feedback. However, I'm not convinced by that answer, and I would prefer to follow up here; I suspect feedback to an issue in the workstation tracker might well not be captured in the Change process. I think the points discussed in the ticket (layering/inheritance, and package removals) are critical and they need an answer to be figured out *before* we start switching Fedora live images to be built with a different tool. I don't see how it can be good for Fedora if we have *some* live images built with livemedia-creator and *some* live images built with Image Builder - but if we start converting images without figuring out what to do about layering and package exclusions, that's exactly what we risk. We do really kinda need inheritance to maintain the live image definitions sensibly. (Also, a related point Neal didn't mention: we share some elements of configuration between the live images and the aarch64 disk images, since both are defined by kickstarts in the fedora-kickstarts repo.) And we really need package exclusions to keep some images to a sensible size. We don't necessarily need these things to be completely implemented in order to switch Workstation over, I don't think, but I think we should at least have a *plan* for them. And ideally a timeframe. Hey Adam, I've made a beginning with starting to track work ongoing on building Fedora within the projects that make up image builder. It's far from complete (I'm still backfilling with previous relevant issues and creating new issues) but it will give a bit better insight into options being considered and work being done to improve support for Fedora: https://github.com/orgs/osbuild/projects/3 I'm still working on making the plan more concrete but I think it's definitely feasible to, as a followup (likely for Fedora 40) allow blueprints to define excludes. Still working on things related to inheritance, there's two ways of going about it. One is a direct support for including blueprint snippet(s) in other blueprints (this would be non-standard for the current TOML format that the languages are in). The other is more a mitigation and it would be to make it so that all current kickstarts can be defined without inheritance and then to later work that into a form where inheritance is brought back in. Also, for understanding I've been diving through the kickstart repositories to define a common base set and interdependencies. I've graphed out the kickstart files and their relationships here: https://supakeen.fedorapeople.org/kickstart-graph.png it seems to have found some includes to kickstarts which no longer exist in the repositories! Regards, Simon ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
On 2023-06-29 09:42, Adam Williamson wrote: On Thu, 2023-06-29 at 02:22 -0400, Neal Gompa wrote: And since Lorax (which is what we use for live and ARM images) requires Anaconda to understand the target system to install, it couldn't be used for creating these images either because that requires teaching Anaconda about Apple Silicon Macs. Hmm, well, why don't we do that? It knows/knew about PPC Macs and Intel Macs, after all... This is planned, see https://pagure.io/fedora-asahi/project/issue/9 and https://pagure.io/fedora-asahi/project/issue/10. It's worth noting that these systems boot _very_ differently from standard aarch64 machines (see https://github.com/AsahiLinux/docs/wiki/Open-OS-Ecosystem-on-Apple-Silicon-Macs for details). Cheers Davide ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
Yes, 14 days would be fine. Sehr gut. -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. â Linus Torvalds * On Thu, 29 Jun 2023, Peter Boy wrote: Date: Thu, 29 Jun 2023 14:53:20 From: Peter Boy Reply-To: Development discussions related to Fedora To: David Both , Development discussions related to Fedora Subject: Re: UW-IMAP Am 29.06.2023 um 18:15 schrieb David Both : @Peter Boy: I would truly appreciate your step-by-step guide. That would be incredibly helpful. I'm sure I can figure out connecting it with SendMail. There is lots of information out there but - as I said - it needs some work. If you make it CC-by-SA it should be unencumbered and I will be sure to attribute that section to you. With your guide I would gladly use Dovecot. I do have a deadline. Do you have an estimate of when you might finish the translation? I know a little German from uni but not nearly enough to do a translation. Danke und guten Tag. -- Das klingt schon mal gut. Well, Iâm quite flexible at the moment. Maybe I have to prepare some contribution to FLOCK, just in case a proposal would get accepted. Itâs quite comfortable for me to do it in the next 14 days. If thatâs OK for your deadline. Otherwise I would reorganize my planning a bit more. Generally itâs not so much work using DeepL and some fine-tuning. But I would like to update the text slightly and do a final test - just to be sure (and I have to do that anyway for the planned tutorial). And CC-by-SA is OK for me (I just donât remember what we sign with FAS account). Peter -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
On 6/29/23 11:06, Jiri Vanek wrote: Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several time in the proposal. Still the https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution adjusted OK, I see. I thought there were going to be two different packages. java-xy-openjdk-portable and java-xy-openjdk. Where java-xy-openjdk is the one that gets shipped in Fedora and java-xy-openjdk-portable lives only in the side-tags. -Tom Tahnx! On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: On 6/29/23 09:52, Jiri Vanek wrote: Hi Tom! Thanx a lot of for input. Although I did my bes with the tagging, it will be learning on the go. I had adapted https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution as you suggested. It is great improvement. Thanks, this looks better. For step 5. should the first mention of java-xy-openjdk-portable actually be java-xy-openjdk ? Same question for step 7. -Tom Especially the config, I was not aware about. That woudl indeed help a lot. The usage of pernament tag is someging I have to learn, but is moreover necessary for proper srpm rebuil. TYVM! J. On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: On 6/26/23 09:21, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) 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 == This is the last step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs effort. JDKs in fedora are already static, and we repack portable tarballs into RPMs. Currently, the portable tarball is built for each Fedora and EPEL version. Goal here is to build each JDK (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in all live Fedoras. If jdk is buitl in epel, it will be built in oldest possible epel and repacked in newer live epels. == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed dramatically. As described in the same wiki page and in individual sub changes and devel threads, the primary reason for this is to lower maintenance and still keep Fedora Java friendly. * In the first system wide change, we have changed the JDKs to build properly as standalone, portable JDK - the way JDK is supposed to be built. I repeat, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went upstream, but this has become a fight which can not be won. * As a second step we introduced portable RPMs, which do not have any system integration, only build JDK and pack the final tarball in RPM for Fedora use. * In third step - without any noise, just verified with fesco - https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully integrated RPMs. Instead of this, normal RPMs BUildRequire portable RPMs and just unpack it, and repack it. Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in oldest live Fedora, and repack everywhere. java-latest-openjdk, which contains latests STS JDK - currently 20, soon briefly 21 and a bit after 22... If we would built java-latest-openjdk in oldest live EPEL - epel8 now, we have verified, that such repacked JDKs works fine, however repack from epel seem to not be acceptable, thus ajva-latest-openjdk will be built twice - one in oldest live fedora, and once in oldest live epel. Build forme oldest possible epel will be repacked to that one or newer epels, and build from oldest live fedroa to all fedoras. === theoretical tagging solution === 1. request side tags for all releases 2. build the actual Java in the side tag for the oldest thing Could you use the real package name here. I think that will make it easier to understand. You can still put 'actual Java' in parens or something. 3. tag the result ot (2) to all side tags from (1) 4. waitrepo them 5. build the repacked java packages in all the side tags from (1) Same thing here, can you use the real package name. 6. untag the result of (2) from all the side tags from (1) 7. ship bodhi updates from side tags OR retag the builds to candidate tags (and delete the side tags) The build from (2) will be eventually garbage collected. To prevent that, it might be re-tagged regularly. This is where releng might be able to help by creating a long lived tag to tag this into for preserving. Yes, we could make a 'fN-openjdk' tag and mark it protected... that part would be easy enough. I think this process could be improved if the side-tags in 1. are pe
Re: Orphaning packages (was LibreOffice packages)
On 2023-06-29 18:09, Bastien Nocera wrote: Do you want to pick up the rest of the libimobiledevice stack as well? That's ifuse, libplist, libusbmuxd and usbmuxd. I've just picked these up, thanks! Will work together with Neal on this stack as part of the Fedora Asahi SIG. Cheers Davide ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
> Am 29.06.2023 um 18:15 schrieb David Both : > > @Peter Boy: > > I would truly appreciate your step-by-step guide. That would be > incredibly helpful. I'm sure I can figure out connecting it with > SendMail. There is lots of information out there but - as I said - it > needs some work. > > If you make it CC-by-SA it should be unencumbered and I will be sure to > attribute that section to you. With your guide I would gladly use > Dovecot. > > I do have a deadline. Do you have an estimate of when you might finish > the translation? > > I know a little German from uni but not nearly enough to do a > translation. > > Danke und guten Tag. > > -- Das klingt schon mal gut. Well, Iâm quite flexible at the moment. Maybe I have to prepare some contribution to FLOCK, just in case a proposal would get accepted. Itâs quite comfortable for me to do it in the next 14 days. If thatâs OK for your deadline. Otherwise I would reorganize my planning a bit more. Generally itâs not so much work using DeepL and some fine-tuning. But I would like to update the text slightly and do a final test - just to be sure (and I have to do that anyway for the planned tutorial). And CC-by-SA is OK for me (I just donât remember what we sign with FAS account). Peter -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
Hi Kevin! I'm unabel to answer that. First release will be a bit experiemntal for sure. But final target is sure - to persist the underlying portables and to enable srpm rebuild as comfortably as possible. As far rawhide itself, as it is unreleased distro, if no other paths will remain, rawhide may remian self building. Aka using protbales from rawhide to buidl rawhide's rpms. Thax! On Thu, 29 Jun 2023 at 19:43, Kevin Fenzi wrote: > > On Thu, Jun 29, 2023 at 10:14:31AM -0700, Tom Stellard wrote: > > On 6/29/23 09:52, Jiri Vanek wrote: > > > Hi Tom! > > > > > > Thanx a lot of for input. Although I did my bes with the tagging, it > > > will be learning on the go. > > > I had adapted > > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > > as you suggested. It is great improvement. > > > > > > > Thanks, this looks better. > > > > For step 5. should the first mention of java-xy-openjdk-portable actually > > be java-xy-openjdk ? Same question for step 7. > > I don't think the fixed sidetag idea will work. (Unless you are planning > on doing something different with rawhide). > > Bodhi won't let you make an update from a non sidetag tag, so you would > have to tag them into fN-updates-candidate, but then they would go one > by one into rawhide and not be tested/gated as a unit. > > But of course we could do fixed tags for stable releases and have a > sidetag flow for rawhide, but that might make things more confusing. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several time in the proposal. Still the https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution adjusted Tahnx! On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: > > On 6/29/23 09:52, Jiri Vanek wrote: > > Hi Tom! > > > > Thanx a lot of for input. Although I did my bes with the tagging, it > > will be learning on the go. > > I had adapted > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > as you suggested. It is great improvement. > > > > Thanks, this looks better. > > For step 5. should the first mention of java-xy-openjdk-portable actually > be java-xy-openjdk ? Same question for step 7. > > -Tom > > > Especially the config, I was not aware about. That woudl indeed help a lot. > > The usage of pernament tag is someging I have to learn, but is > > moreover necessary for proper srpm rebuil. > > > > TYVM! > > J. > > > > On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > >> > >> On 6/26/23 09:21, Aoife Moloney wrote: > >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > >>> > >>> 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 == > >>> > >>> This is the last step in > >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > >>> effort. JDKs in fedora are already static, and we repack portable > >>> tarballs into RPMs. Currently, the portable tarball is built for each > >>> Fedora and EPEL version. Goal here is to build each JDK > >>> (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in > >>> all live Fedoras. If jdk is buitl in epel, it will be built in oldest > >>> possible epel and repacked in newer live epels. > >>> > >>> > >>> == Owner == > >>> * Name: [[User:jvanek| Jiri Vanek]] > >>> > >>> * Email: jva...@redhat.com > >>> > >>> > >>> == Detailed Description == > >>> > >>> As described in > >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > >>> during last year, packaging of JDKs had changed dramatically. As > >>> described in the same wiki page and in individual sub changes and > >>> devel threads, the primary reason for this is to lower maintenance and > >>> still keep Fedora Java friendly. > >>> > >>> * In the first system wide change, we have changed the JDKs to build > >>> properly as standalone, portable JDK - the way JDK is supposed to be > >>> built. I repeat, we spent ten years by patching JDK to become properly > >>> dynamic against system libs, and all patches went upstream, but this > >>> has become a fight which can not be won. > >>> > >>> * As a second step we introduced portable RPMs, which do not have any > >>> system integration, only build JDK and pack the final tarball in RPM > >>> for Fedora use. > >>> > >>> * In third step - without any noise, just verified with fesco - > >>> https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully > >>> integrated RPMs. Instead of this, normal RPMs BUildRequire portable > >>> RPMs and just unpack it, and repack it. > >>> > >>> Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in > >>> oldest live Fedora, and repack everywhere. java-latest-openjdk, which > >>> contains latests STS JDK - currently 20, soon briefly 21 and a bit > >>> after 22... If we would built java-latest-openjdk in oldest live EPEL > >>> - epel8 now, we have verified, that such repacked JDKs works fine, > >>> however repack from epel seem to not be acceptable, thus > >>> ajva-latest-openjdk will be built twice - one in oldest live fedora, > >>> and once in oldest live epel. Build forme oldest possible epel will be > >>> repacked to that one or newer epels, and build from oldest live fedroa > >>> to all fedoras. > >>> > >>> === theoretical tagging solution === > >>> > >>> 1. request side tags for all releases > >>> 2. build the actual Java in the side tag for the oldest thing > >> > >> Could you use the real package name here. I think that will make it easier > >> to understand. You can still put 'actual Java' in parens or something. > >> > >>> 3. tag the result ot (2) to all side tags from (1) > >>> 4. waitrepo them > >>> 5. build the repacked java packages in all the side tags from (1) > >> > >> Same thing here, can you use the real package name. > >> > >>> 6. untag the result of (2) from all the side tags from (1) > >>> 7. ship bodhi updates from side tags OR retag the builds to candidate > >>> tags > >>>(and delete the side tags) > >>> > >>> The build from (2) will be eventually garbage collected. To prevent that, > >>> it > >>> might be re-tagged regularly. This is where releng
Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
On Thu, Jun 29, 2023 at 10:14:31AM -0700, Tom Stellard wrote: > On 6/29/23 09:52, Jiri Vanek wrote: > > Hi Tom! > > > > Thanx a lot of for input. Although I did my bes with the tagging, it > > will be learning on the go. > > I had adapted > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > as you suggested. It is great improvement. > > > > Thanks, this looks better. > > For step 5. should the first mention of java-xy-openjdk-portable actually > be java-xy-openjdk ? Same question for step 7. I don't think the fixed sidetag idea will work. (Unless you are planning on doing something different with rawhide). Bodhi won't let you make an update from a non sidetag tag, so you would have to tag them into fN-updates-candidate, but then they would go one by one into rawhide and not be tested/gated as a unit. But of course we could do fixed tags for stable releases and have a sidetag flow for rawhide, but that might make things more confusing. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Red Hat & Fedora -- largely stepping out of this ecosystem
On Thu, Jun 29, 2023 at 6:41âŻPM Todd Zullinger wrote: > Carlos O'Donell wrote: > > On 6/26/23 18:47, Jeff Law wrote: > >> What Red Hat has done may be technically legal and perhaps good for > >> its business. However, to me it's ethically unconscionable. Those > >> who know me know I'm not an zealot, but I do have a baseline set of > >> ethical values and Red Hat crossed that line. > > > > Why is it ethically unconscionable? There is a lot of confusion around > > what has happened and why. What you are saying, and what actually > happened > > don't line up in my mind :-) > > Something I'm having trouble with is Red Hat's position that > you can choose to be a customer or to exercise your rights > under the GPL, but you cannot be both. > > Receiving GPL software doesn't give you the right to receive support for it. It never did, and never will. If that you were in capacity to enforce any developer that ever provided you a specific version of a software to give you all future version that you would need in the future, that would contradict fundamental rights: "You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist." [1] Or said the other way around, the fact that Red Hat gives you a binary, and the sources associated with it doesn't oblige Red Hat to give support for it nor any future modified version of it. This support obligation is only tight to the support contract you may have with Red Hat which it may choose to cancel in any conditions that it sees fit (in accordance to the said contract). The rupture of this contract does not deprive you from your rights on the previously received binaries/sources in any way. [1] https://www.gnu.org/philosophy/free-sw.en.html#redistribute > I don't know how to view that as anything other than > sacrificing the spirit of F/OSS to help the books. > I am sympathetic to the odd/difficult nature of running a > business based on F/OSS. Until now I thought Red Hat was > doing it pretty well. > > I thought Jeff's message was well written. I am still > struggling with whether I should take the same path. :( > > -- > Todd > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: 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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
On 6/29/23 09:52, Jiri Vanek wrote: Hi Tom! Thanx a lot of for input. Although I did my bes with the tagging, it will be learning on the go. I had adapted https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution as you suggested. It is great improvement. Thanks, this looks better. For step 5. should the first mention of java-xy-openjdk-portable actually be java-xy-openjdk ? Same question for step 7. -Tom Especially the config, I was not aware about. That woudl indeed help a lot. The usage of pernament tag is someging I have to learn, but is moreover necessary for proper srpm rebuil. TYVM! J. On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: On 6/26/23 09:21, Aoife Moloney wrote: https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) 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 == This is the last step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs effort. JDKs in fedora are already static, and we repack portable tarballs into RPMs. Currently, the portable tarball is built for each Fedora and EPEL version. Goal here is to build each JDK (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in all live Fedoras. If jdk is buitl in epel, it will be built in oldest possible epel and repacked in newer live epels. == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jva...@redhat.com == Detailed Description == As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed dramatically. As described in the same wiki page and in individual sub changes and devel threads, the primary reason for this is to lower maintenance and still keep Fedora Java friendly. * In the first system wide change, we have changed the JDKs to build properly as standalone, portable JDK - the way JDK is supposed to be built. I repeat, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went upstream, but this has become a fight which can not be won. * As a second step we introduced portable RPMs, which do not have any system integration, only build JDK and pack the final tarball in RPM for Fedora use. * In third step - without any noise, just verified with fesco - https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully integrated RPMs. Instead of this, normal RPMs BUildRequire portable RPMs and just unpack it, and repack it. Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in oldest live Fedora, and repack everywhere. java-latest-openjdk, which contains latests STS JDK - currently 20, soon briefly 21 and a bit after 22... If we would built java-latest-openjdk in oldest live EPEL - epel8 now, we have verified, that such repacked JDKs works fine, however repack from epel seem to not be acceptable, thus ajva-latest-openjdk will be built twice - one in oldest live fedora, and once in oldest live epel. Build forme oldest possible epel will be repacked to that one or newer epels, and build from oldest live fedroa to all fedoras. === theoretical tagging solution === 1. request side tags for all releases 2. build the actual Java in the side tag for the oldest thing Could you use the real package name here. I think that will make it easier to understand. You can still put 'actual Java' in parens or something. 3. tag the result ot (2) to all side tags from (1) 4. waitrepo them 5. build the repacked java packages in all the side tags from (1) Same thing here, can you use the real package name. 6. untag the result of (2) from all the side tags from (1) 7. ship bodhi updates from side tags OR retag the builds to candidate tags (and delete the side tags) The build from (2) will be eventually garbage collected. To prevent that, it might be re-tagged regularly. This is where releng might be able to help by creating a long lived tag to tag this into for preserving. Yes, we could make a 'fN-openjdk' tag and mark it protected... that part would be easy enough. I think this process could be improved if the side-tags in 1. are permanent side-tags, and step 6 is skipped. That would make it easier to rebuild the packages from step 5 if needed. Also, can you put a config file in the dist-git repos to tell fedpkg which target to build against? I thought I remembered seeing that feature in the past. If so, then you could configure the dist-gits for the repacked javas to automatically build from those side-tags, which I think would be a lot easier for package maintainers and may help make automated rebuilds possible. -Tom including portable srpms in release (improving
Re: Red Hat & Fedora -- largely stepping out of this ecosystem
On 6/26/23 18:47, Jeff Law wrote: What Red Hat has done may be technically legal and perhaps good for its business. Something I'm having trouble with is Red Hat's position that you can choose to be a customer or to exercise your rights under the GPL, but you cannot be both. The thing is, many people are learning this only now, because things indeed have become tougher for people who prepare the RHEL rebuilds, but this is not new. _Nothing_ in the service agreement or in any other legal document has changed since last week, the exact same terms have been applicable to the extended-support branches since the beginning of RHEL. In fact, as Frank pointed out elsewhere, this is something that other companies have been doing for decades as well. For all the people that are complaining only now that the free beer part is taken away, I can't help thinking that it's a bit disingenuous to make it about "free as in freedom", when that clause has existed forever. (As an aside, the service agreement also mentions that any open source license overrides the service agreement if needed. So by definition this might be void but it certainly is not a GPL violation). Paolo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
Hi Tom! Thanx a lot of for input. Although I did my bes with the tagging, it will be learning on the go. I had adapted https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution as you suggested. It is great improvement. Especially the config, I was not aware about. That woudl indeed help a lot. The usage of pernament tag is someging I have to learn, but is moreover necessary for proper srpm rebuil. TYVM! J. On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > > On 6/26/23 09:21, Aoife Moloney wrote: > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > > > > 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 == > > > > This is the last step in > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > > effort. JDKs in fedora are already static, and we repack portable > > tarballs into RPMs. Currently, the portable tarball is built for each > > Fedora and EPEL version. Goal here is to build each JDK > > (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in > > all live Fedoras. If jdk is buitl in epel, it will be built in oldest > > possible epel and repacked in newer live epels. > > > > > > == Owner == > > * Name: [[User:jvanek| Jiri Vanek]] > > > > * Email: jva...@redhat.com > > > > > > == Detailed Description == > > > > As described in > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > > during last year, packaging of JDKs had changed dramatically. As > > described in the same wiki page and in individual sub changes and > > devel threads, the primary reason for this is to lower maintenance and > > still keep Fedora Java friendly. > > > > * In the first system wide change, we have changed the JDKs to build > > properly as standalone, portable JDK - the way JDK is supposed to be > > built. I repeat, we spent ten years by patching JDK to become properly > > dynamic against system libs, and all patches went upstream, but this > > has become a fight which can not be won. > > > > * As a second step we introduced portable RPMs, which do not have any > > system integration, only build JDK and pack the final tarball in RPM > > for Fedora use. > > > > * In third step - without any noise, just verified with fesco - > > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully > > integrated RPMs. Instead of this, normal RPMs BUildRequire portable > > RPMs and just unpack it, and repack it. > > > > Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in > > oldest live Fedora, and repack everywhere. java-latest-openjdk, which > > contains latests STS JDK - currently 20, soon briefly 21 and a bit > > after 22... If we would built java-latest-openjdk in oldest live EPEL > > - epel8 now, we have verified, that such repacked JDKs works fine, > > however repack from epel seem to not be acceptable, thus > > ajva-latest-openjdk will be built twice - one in oldest live fedora, > > and once in oldest live epel. Build forme oldest possible epel will be > > repacked to that one or newer epels, and build from oldest live fedroa > > to all fedoras. > > > > === theoretical tagging solution === > > > >1. request side tags for all releases > >2. build the actual Java in the side tag for the oldest thing > > Could you use the real package name here. I think that will make it easier > to understand. You can still put 'actual Java' in parens or something. > > >3. tag the result ot (2) to all side tags from (1) > >4. waitrepo them > >5. build the repacked java packages in all the side tags from (1) > > Same thing here, can you use the real package name. > > >6. untag the result of (2) from all the side tags from (1) > >7. ship bodhi updates from side tags OR retag the builds to candidate > > tags > > (and delete the side tags) > > > > The build from (2) will be eventually garbage collected. To prevent that, it > > might be re-tagged regularly. This is where releng might be able to help by > > creating a long lived tag to tag this into for preserving. > > > > Yes, we could make a 'fN-openjdk' tag and mark it protected... that part > > would be easy enough. > > > > I think this process could be improved if the side-tags in 1. are permanent > side-tags, > and step 6 is skipped. That would make it easier to rebuild the packages from > step 5 if needed. > > Also, can you put a config file in the dist-git repos to tell fedpkg which > target > to build against? I thought I remembered seeing that feature in the past. > If so, > then you could configure the dist-gits for the repacked javas to > automatically build > from those side-tags, which I think would be a lot easier for pack
Re: Red Hat & Fedora -- largely stepping out of this ecosystem
Carlos O'Donell wrote: > On 6/26/23 18:47, Jeff Law wrote: >> What Red Hat has done may be technically legal and perhaps good for >> its business. However, to me it's ethically unconscionable. Those >> who know me know I'm not an zealot, but I do have a baseline set of >> ethical values and Red Hat crossed that line. > > Why is it ethically unconscionable? There is a lot of confusion around > what has happened and why. What you are saying, and what actually happened > don't line up in my mind :-) Something I'm having trouble with is Red Hat's position that you can choose to be a customer or to exercise your rights under the GPL, but you cannot be both. I don't know how to view that as anything other than sacrificing the spirit of F/OSS to help the books. I am sympathetic to the odd/difficult nature of running a business based on F/OSS. Until now I thought Red Hat was doing it pretty well. I thought Jeff's message was well written. I am still struggling with whether I should take the same path. :( -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
@Peter Boy: I would truly appreciate your step-by-step guide. That would be incredibly helpful. I'm sure I can figure out connecting it with SendMail. There is lots of information out there but - as I said - it needs some work. If you make it CC-by-SA it should be unencumbered and I will be sure to attribute that section to you. With your guide I would gladly use Dovecot. I do have a deadline. Do you have an estimate of when you might finish the translation? I know a little German from uni but not nearly enough to do a translation. Danke und guten Tag. -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. â Linus Torvalds * On Thu, 29 Jun 2023, Peter Boy wrote: Date: Thu, 29 Jun 2023 11:38:42 From: Peter Boy Reply-To: Development discussions related to Fedora To: David Both , Development discussions related to Fedora Subject: Re: UW-IMAP Hi, Am 29.06.2023 um 16:27 schrieb David Both : ... I also spent about 4 days trying to get Dovecot to work with SendMail in a test VM setup. I'm either missing one or more important bits or its just too complex for me. None of the docs I have found anywhere has a complete start-to-finish picture. I find no accurate list of here's exactly what needs to be in place and configured in this way to make it work. The docs I find are incomplete because they assume much about my knowledge or just skip parts that are needed. Others are just plain wrong after trying them. Just in case you decide for dovecot (which would be preferable, IMHO), I could contribute a step-by-step guide to create a workable configuration of dovecot (it is Part of a solution for a rather full-fledged mail service). However, the instructions use Postfix, not Sendmail. But because the connection runs via milter, the replacement with Sendmail should not be a difficult. At the moment everything is (still) in German. But I have to translate it anyway, because I want to create a tutorial for Fedora Server from it. [1] http://www.both.org/?page_id=1183 What a coincidence, actually found this in my ePub library (though still unread, sorry :-) ). -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)
On 29. 06. 23 17:57, Carlos O'Donell wrote: On 6/29/23 00:44, Miro HronÄok wrote: On 29. 06. 23 0:31, Carlos O'Donell wrote: Can we allow users to create a minimal installation by hand, while still complying with PEP-615 for default installs? The size savings for a minimal container that is UTC-only would be quite valuable for Fedora minimal containers. Yes, but see the rest of my email. Just for clarity, and 3-way-communication: (a) You are concerned about the UTC case failing today. I am. It seems that without tzdata, we cannot even use UTC in Python. (b) You would like to see an upstream patch to python to detect missing tzdata and report something like: ZoneInfoNotInstalledError: 'No time zone information installed on the system, you can only use UTC' Yes. (c) You would like to ensure UTC works even without tzdata installed. Indeed. (d) You don't want to carry a downstream patch, but you would be OK with a backported upstream patch? I don't. Probably OK, depending on the size of it, but I don't expect this to be super complex. Does that match your expectations? All 4 points match my expectations 100%, but I also have another one: (e) The Python Maint team currently has no capacity to drive this upstream in the Fedora 39 development cycle. We are in the middle of the Python 3.12 rebase. -- Miro HronÄok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Orphaning packages (was LibreOffice packages)
Do you want to pick up the rest of the libimobiledevice stack as well? That's ifuse, libplist, libusbmuxd and usbmuxd. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Red Hat & Fedora -- largely stepping out of this ecosystem
Am 29.06.23 um 17:49 schrieb Carlos O'Donell: On 6/26/23 18:47, Jeff Law wrote: What Red Hat has done may be technically legal and perhaps good for its business. However, to me it's ethically unconscionable. Those who know me know I'm not an zealot, but I do have a baseline set of ethical values and Red Hat crossed that line. Why is it ethically unconscionable? There is a lot of confusion around what has happened and why. What you are saying, and what actually happened don't line up in my mind :-) Well, lets start just (and that alone is reprehensible) with untrue sentences that just miscredited the open EL-community (open EL-community == all without RH and RH customers). Its just a slap in the face of contributers, EPEL maintainers (non @redhat.com owners) and so on ... This is just done to have a bigger gap in the reasoning argumentation. This is FUD tactic and dignityless for RH. They have reasonable arguments to do what they do, but the "style" is ethically unconscionable. -- Leon ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Orphaning packages (was LibreOffice packages)
On Thu, 29 Jun 2023 at 10:48, Bastien Nocera wrote: > Hello, > > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, > as I am transferred to another team. > > 1. Thank you for all the work you have done on these and other packages in Fedora. The Bluetooth stack is not easy. 2. Thank you for announcing this early and allowing a quick transfer. 3. Good luck with the new team, they are lucky to have you. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Change Proposal: Allow Removal of tzdata (System-Wide)
On 6/28/23 19:54, Michael Catanzaro wrote: > Because Recommends and Supplements are installed by default, we need > to be careful and use them sparingly, only when it really makes sense > for some package to be pulled in for almost all users of another > package. Thus far, Fedora and RHEL have done a good job of this, > primarily because we were very late to the weak dep party and have > had much more time to learn best practices and much less time to > screw up. This is in contrast to some other distros where it's common > for users to disable weak deps to avoid "bloat." We don't ever want > our Recommends/Supplements to be considered bloat. (That's what > Suggests/Enhances is for. :) And since they're not bloat, they should > be respected when building most non-minimal images. I agree. Do you consider the removal of tzdata to be a valuable use of Recommends? It is my opinion that glibc should Recommends: tzdata because it frees up an optional ~8MiB of zoneinfo that will never be used by UTC-only microservice workloads. It is a further refinement of having really small containers with LANG=C.UTF-8/C and TZ=UTC. Some spec files will need BuildRequires: tzdata, because their %check and testsuite run needs it. In addition to this we should continue to adopt Fedora CI and test the results as required in an installed scenario (with or without tzdata as your package might need to test). -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Orphaning packages (was LibreOffice packages)
I've picked up low-memory-monitor On 6/29/23 08:46, Neal Gompa wrote: On Thu, Jun 29, 2023 at 10:48âŻAM Bastien Nocera wrote: Hello, As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team. While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining. Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd I've picked up libimobiledevice as I need it for Fedora Asahi work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Change Proposal: Allow Removal of tzdata (System-Wide)
On 6/29/23 00:44, Miro HronÄok wrote: > On 29. 06. 23 0:31, Carlos O'Donell wrote: >> Can we allow users to create a minimal installation by hand, while still >> complying >> with PEP-615 for default installs? >> >> The size savings for a minimal container that is UTC-only would be quite >> valuable >> for Fedora minimal containers. > Yes, but see the rest of my email. > Just for clarity, and 3-way-communication: (a) You are concerned about the UTC case failing today. (b) You would like to see an upstream patch to python to detect missing tzdata and report something like: ZoneInfoNotInstalledError: 'No time zone information installed on the system, you can only use UTC' (c) You would like to ensure UTC works even without tzdata installed. (d) You don't want to carry a downstream patch, but you would be OK with a backported upstream patch? Does that match your expectations? -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Is there a chance to phase out `/lib64` directory?
On 6/27/23 20:21, Kevin Kofler via devel wrote: > Practical cross-compilation to a completely different architecture needs > sysroots anyway. That way, one can also easily target a different > distribution on a different (or even the same) architecture, not just Fedora > on a different architecture. +100 And assembling those sysroots is not straight forward. -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Red Hat & Fedora -- largely stepping out of this ecosystem
On 6/26/23 18:47, Jeff Law wrote: > What Red Hat has done may be technically legal and perhaps good for > its business. However, to me it's ethically unconscionable. Those > who know me know I'm not an zealot, but I do have a baseline set of > ethical values and Red Hat crossed that line. Why is it ethically unconscionable? There is a lot of confusion around what has happened and why. What you are saying, and what actually happened don't line up in my mind :-) -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Orphaning packages (was LibreOffice packages)
On Thu, Jun 29, 2023 at 10:48âŻAM Bastien Nocera wrote: > > Hello, > > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, as > I am transferred to another team. > > While it's possible that some of the maintenance will stay with me in the new > team, I've not yet been told which team I would be joining. > > Here is a list of Fedora packages which I maintained or co-maintained which I > won't be able to contribute to anymore: > apfs-fuse > bluez > codespell > eosrei-emojione-fonts > geocode-glib > gnome-bluetooth > gnome-epub-thumbnailer > gnome-kra-ora-thumbnailer > gnome-user-share > gom > grilo > grilo-plugins > ifuse > iio-sensor-proxy > libfprint > libglib-testing > libimobiledevice > libpeas > libplist > libportal > libusbmuxd > low-memory-monitor > malcontent > power-profiles-daemon > sloccount > switcheroo-control > totem > totem-pl-parser > umockdev > usbmuxd > I've picked up libimobiledevice as I need it for Fedora Asahi work. -- çćźăŻăă€ăäžă€ïŒ/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
Hi, > Am 29.06.2023 um 16:27 schrieb David Both : > > ... > I also spent about 4 days trying to get Dovecot to work with SendMail in > a test VM setup. I'm either missing one or more important bits or its > just too complex for me. None of the docs I have found anywhere has a > complete start-to-finish picture. I find no accurate list of here's > exactly what needs to be in place and configured in this way to make it > work. The docs I find are incomplete because they assume much about my > knowledge or just skip parts that are needed. Others are just plain > wrong after trying them. Just in case you decide for dovecot (which would be preferable, IMHO), I could contribute a step-by-step guide to create a workable configuration of dovecot (it is Part of a solution for a rather full-fledged mail service). However, the instructions use Postfix, not Sendmail. But because the connection runs via milter, the replacement with Sendmail should not be a difficult. At the moment everything is (still) in German. But I have to translate it anyway, because I want to create a tutorial for Fedora Server from it. > > [1] http://www.both.org/?page_id=1183 What a coincidence, actually found this in my ePub library (though still unread, sorry :-) ). -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
Update: Apparently, this problem doesn't exist on new install/liveusb because dejavu is not installed so I found out that on my system I have VLC which has a dependency on dejavu.. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: F36 Change: Default To Noto Fonts (System-Wide Change proposal)
Thanks everyone for this work. I would like to point to a problem with the current config regarding Arabic font. For Arabic text, The dejavu sans is still being displayed in many webpages in firefox instead of the noto sans. However, when switching the system language to arabic, firefox correctly displays noto sans arabic which is huge improvment. But if the system/gnome language is set to english, dejavu is frequently used to display some arabic texts in firefox The problem with dejavu sans for Arabic is being incredibly ugly and borderline unreadable when bolded. For example: -at fedoraproject.org/ar most text exhibit this problem, firefox is using dejavu to render arabic instead of noto sans when the system/gnome language is english -Youtube video titles -Most text at podcast.google.com -Wikipedia.org DOESN'T seem to suffer from this problem, It displays noto sans arabic regardless whether the system language is Arabic or English. (TLDR: this is the desired behavior) Picture example of the problem: where the first pic shows FFx rendering the text using noto, the second pic it's using dejavu for arabic. https://imgur.com/a/x97tCp9 Is this solvable? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
On Thu, Jun 29, 2023 at 10:27:49AM -0400, David Both wrote: > I also spent about 4 days trying to get Dovecot to work with SendMail in > a test VM setup. I'm either missing one or more important bits or its > just too complex for me. I've been running a dovecot + sendmail setup on Fedora for over 15 years. Of the two, sendmail (or rather, making it robust against incoming spam) has proven to be a far greater ongoing headache; dovecot has pretty much JustWorked(tm). At the end of the day the only coordination between dovecot and sendmail (+procmail) is ensuring they both are set up to use the same place for the users' mail spool. So I'm curious as to the problems you're running into with dovecot specifically, and I may be able to help. (I switched from UW-IMAP to dovecot to facilitate a migration to Maildir) - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libra.chat) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 packages (was LibreOffice packages)
Hello, As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team. While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining. Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd Regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
Hello, David. On Thursday, 29 June 2023 at 14:57, David Both wrote: > I have noticed that uw-imap is no longer in the Fedora repo and that the > last was F33. I like it far better than the other options because it is > the IMAP server that best "does one things and does it well." It also > requires the least amount of configuration and it just works so it also > meets the KISS test. > > I am willing to take it on to fix the problems that prevent it being > properly built and to ensure that it continues to be available for > future Fedora releases. > > I can take the F33 RPM, and a couple libs from F33, install them on F38 > and it works very well. So I know that much. Hopefully it will be as > simple as getting it to build and packaging it. Fedora packaging and runtime environment have evolved significantly since F33, but I wouldn't expect getting it to build on modern Fedora to be too difficult. Most issues will probably come from GCC being more strict. You should make it follow system crypto policy, too. > My objectives are in sequence: > > 1. Fork uw-imap and give it a new name. I would keep the current > "provides" as uw-mail for compatibility. You can also contact the original authors and ask if you can take over maintenance. :) > 2. Get it to build and install along with xinetd which is still > required for it. > > 3. Migrate it to systemd as quickly as possible. 3a. Port to OpenSSL 3 as quickly as possible. > 4. Learn a lot! > > 5. Don't change anything else unless absolutely necessary. That means no > new "features." > > 6. Fix any newly encountered bugs. > > 7. Build a small team to keep it going in the future. Sounds like a great plan. Good luck! [...] > I am looking at the github repo, but is it the best/most recent? I will > try to figure out how to take that over and will go from there. There's a repo on GitHub with the latest sources and Fedora's patches applied on top: https://github.com/uw-imap/imap . Are you referring to this one? It looks like the official website was last available between Oct 28th, 2019 and Dec 22nd, 2019. This is the last functional capture at archive.org: https://web.archive.org/web/20191028114408/http://www.washington.edu/imap/ Reaching out to maintainers in other distros might be worthwile, too. Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
OK - I had no idea about any of that drama. I did find Panda IMAP and a couple others. I also spent about 4 days trying to get Dovecot to work with SendMail in a test VM setup. I'm either missing one or more important bits or its just too complex for me. None of the docs I have found anywhere has a complete start-to-finish picture. I find no accurate list of here's exactly what needs to be in place and configured in this way to make it work. The docs I find are incomplete because they assume much about my knowledge or just skip parts that are needed. Others are just plain wrong after trying them. I know I don't have a lot of cruft to get in the way because I can use the last snapshot before I started trying to install IMAP. Although I am trying to do this for my own SendMail server, I am also trying to find a simple IMAP server I can use for the email chapters in the next edition of my books[1], "Using and Administering Linux." That's why I really want something easy and simple. I've also looked at Courier as it seems a simple AIO but that's not part of any current Fedora repo. I might check it out in more detail for my book. Anyway - thanks for the responses. I appreciate knowing that history. [1] http://www.both.org/?page_id=1183 -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. â Linus Torvalds * On Thu, 29 Jun 2023, Nico Kadel-Garcia wrote: Date: Thu, 29 Jun 2023 09:42:13 From: Nico Kadel-Garcia Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Subject: Re: UW-IMAP On Thu, Jun 29, 2023 at 9:18âŻAM Marcin Juszkiewicz wrote: W dniu 29.06.2023 o 14:57, David Both pisze: I have noticed that uw-imap is no longer in the Fedora repo and that the last was F33. I like it far better than the other options because it is the IMAP server that best "does one things and does it well." It also requires the least amount of configuration and it just works so it also meets the KISS test. UW IMAP development ended in 2008. Development of Panda IMAP (successor) ended in 2012 when Mark Crispin died. https://github.com/jonabbey/panda-imap holds complete public history. I would rather go Dovecot rather than revive 11 years old project. Did setup of it once, about 10 years, and it serves my private mail since then. uw-imap got pretty weird, with Mark Crispin getting very, very upset and accusing people of stealing his university's code if they merely *pointed to* off-shore repositories where SSL patches were published and could be legally imported without running into US export laws. He had SSL hooks which he refused to publish, except for his university's internal use. The arguments got *weird*, and heated, and some of us were very grateful to be able to switch to dovecot and avoid the issues. David, have you tried dovecot as a "simple IMAP server"? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
I took care of lensfun, which was not quite as much fun as it sounds: https://src.fedoraproject.org/rpms/lensfun/pull-request/4 Could use a pair of critical python packager eyeballs, though ;-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!
> Fedora 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL.. after last > update > don't know how to fix it > > please fix / test / update ... It works fine here. I haven't updated lightdm since f38 release so I doubt the issue is caused by lightdm. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
On Thu, Jun 29, 2023 at 9:18âŻAM Marcin Juszkiewicz wrote: > > W dniu 29.06.2023 o 14:57, David Both pisze: > > I have noticed that uw-imap is no longer in the Fedora repo and that the > > last was F33. I like it far better than the other options because it is > > the IMAP server that best "does one things and does it well." It also > > requires the least amount of configuration and it just works so it also > > meets the KISS test. > > UW IMAP development ended in 2008. Development of Panda IMAP (successor) > ended in 2012 when Mark Crispin died. > > https://github.com/jonabbey/panda-imap holds complete public history. > > I would rather go Dovecot rather than revive 11 years old project. Did > setup of it once, about 10 years, and it serves my private mail since then. uw-imap got pretty weird, with Mark Crispin getting very, very upset and accusing people of stealing his university's code if they merely *pointed to* off-shore repositories where SSL patches were published and could be legally imported without running into US export laws. He had SSL hooks which he refused to publish, except for his university's internal use. The arguments got *weird*, and heated, and some of us were very grateful to be able to switch to dovecot and avoid the issues. David, have you tried dovecot as a "simple IMAP server"? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!
Any more details? Anything interesting inside /var/log/lightdm? A.FI. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: UW-IMAP
W dniu 29.06.2023 o 14:57, David Both pisze: I have noticed that uw-imap is no longer in the Fedora repo and that the last was F33. I like it far better than the other options because it is the IMAP server that best "does one things and does it well." It also requires the least amount of configuration and it just works so it also meets the KISS test. UW IMAP development ended in 2008. Development of Panda IMAP (successor) ended in 2012 when Mark Crispin died. https://github.com/jonabbey/panda-imap holds complete public history. I would rather go Dovecot rather than revive 11 years old project. Did setup of it once, about 10 years, and it serves my private mail since then. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!
Fedora 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL.. after last update don't know how to fix it please fix / test / update ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
UW-IMAP
I have noticed that uw-imap is no longer in the Fedora repo and that the last was F33. I like it far better than the other options because it is the IMAP server that best "does one things and does it well." It also requires the least amount of configuration and it just works so it also meets the KISS test. I am willing to take it on to fix the problems that prevent it being properly built and to ensure that it continues to be available for future Fedora releases. I can take the F33 RPM, and a couple libs from F33, install them on F38 and it works very well. So I know that much. Hopefully it will be as simple as getting it to build and packaging it. My objectives are in sequence: 1. Fork uw-imap and give it a new name. I would keep the current "provides" as uw-mail for compatibility. 2. Get it to build and install along with xinetd which is still required for it. 3. Migrate it to systemd as quickly as possible. 4. Learn a lot! 5. Don't change anything else unless absolutely necessary. That means no new "features." 6. Fix any newly encountered bugs. 7. Build a small team to keep it going in the future. If anyone has an interest in being part of the small team, please let me know. If you have any information at all about the specific problems that currently keep it from being built, please let me know what those are and any thoughts you might have about that. I am looking at the github repo, but is it the best/most recent? I will try to figure out how to take that over and will go from there. Any comments, pointers, and suggestions are welcome. Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. â Linus Torvalds * ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
liborc (Apache ORC) soname bump in Rawhide
Hi, Apache ORC 1.9.0 has been released. I believe it is the case that only libarrow (Apache Arrow) and by extension, ceph consume liborc, and I am the maintainer of both libarrow and ceph. (My repoqueries don't show anything using liborc or liborc-devel.) I will be rebasing liborc to 1.9.0 shortly. -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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
Intent to retire OpenCOLLADA
For anyone who didn't see discussion on the list OpenCOLLADA upstream hasn't seen a commit since 2018 and no one has stepped up to port it to pcre2. I tried to convert it to use the bundled pcre as a stop gap to keep it going a bit further but it installs the library instead of building statically. Anyone good with CMake could fix this but at this point I think it's just time to retire it. If anyone wants to take it over let me know otherwise I plan to retire early next week. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Red Hat & Fedora -- largely stepping out of this ecosystem
> I have no illusions that this message is going to change anything at Red > Hat. It's not really for us as community members to identify a business path and that is a convenience factor that we typically rely upon to work on things that begin as experimental and a learning path only to grow into something more reliable and service-ready. > First a bit of background. I came to Red Hat via the Cygnus > acquisition. My combined service spanned nearly 30 years. During that > time I had the opportunity to be involved in the formation of Fedora, > strategic planning for RHEL while at the same time being able to spend > much of my time on optimizing compilers. > Thank you for your contributions over the years and for continuing to do work at such a low level. It helps the rest of us stay focused on delivering a great experience to users knowing that the subsystems we rely upon are not going to fail us and that they deliver the best performance possible. > -- > What Red Hat has done recently is depressing, but not a huge surprise to > me. Red Hat struggled repeatedly with how to deal with "the clones". [. . .] > Arguments for protecting the bits were > met with something like "if that's what we need to do to be successful, > then we're failing to provide real value". > I disagree that this is "protecting the bits. The bits are equally available to all and that's how we do what we do in this Fedora community. I see it as more of a hard nudge from the comfortable nest of a basic rebuild to determine a pathway forward as a clone. This is not a bad time to do it. As we move towards more immutable systems and the use of container-based workloads in production - it's time to ask after whether or not we should deemphasize these paths forward. This probably sounds bizarre coming from someone who works hard to preserve the cloud edition experience side by side with the immutable FCOS and IOT editions, but I recognize that there are places for both and that the sun will eventually set. Furthermore, the CentOS Stream process is stabilizing and consistent with the goals of the community. I was at devconf.cz recently and I sat down with Tomas and Nikolas from the Packit team to really dig in to how I can make packit and copr work for more rapid development and how I can ensure that my builds are consistent with the goals of both the upstream and downstream communities. In my experience with the CentOS community, I have spent countless hours helping users taint the very kernel they declare they want to preserve to get the results that are already built into the CentOS Stream experience. I think, just like Mike McGrath and probably a lot of people, that this is the best code base to expose and that we should be, as a community, determining how to roll forward. Sure there will be requirements for freezing support, but there are mechanisms for this already - os-build will give you a resource for experimentation. There are package manifests to ensure consistency between states, but just generally, users push forward with the systems they don't purchase support to run. I am not saying there aren't reasons to freeze updates, etc. There are, but as CentOS Stream _is_ RHEL in it's next form it is also representative of where RH would like the community to be. If we as a community care about our evolution, then the clones should care about it as well. If Red Hat as a sponsor identifies that the bar is better set at CentOS Stream it is more a statement on where they believe that CI/CD and Quality Engineering has set the bar for user stability. > Back in 2002 or 2003 when we were trying to figure out how to salvage > the ill-fated "Red Hat Community Linux Project" resulting in what we now > know as Fedora, one of the key concepts that we pushed to the > executive team at Red Hat was that it was strategically important for > both Fedora Exactly! And projects like Fedora ELN that Stephen Gallagher, et. al., have dedicated themselves to supporting are only bringing it closer. > I've been a Fedora user since before FC1. I run Fedora on my laptop. I was not as much a part of the division as you were, but I was there as a community member and contributor. I was out in the field though, putting it on systems that replaced routing for T1 lines with Fractional T1s and DSL that eventually turned my business users into Red Hat customers. I get the appeal of a strong union between the two. > That will change across the board this summer. [. . .] I don't see the change, on the contrary, I see a more unified community rallying around the special interests of the clones similar to the way the Hyperscale SIG unifies the more advanced requirements of fail-only architectures in CentOS Stream right now. Those same contributors to the Hyperscale SIG are also supporting work on Fedora Asahi and Fedora ELN just as fast! ( I am looking at you Davide and Neal). I am b
Fedora rawhide compose report: 20230629.n.0 changes
OLD: Fedora-Rawhide-20230628.n.2 NEW: Fedora-Rawhide-20230629.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 3 Dropped packages:4 Upgraded packages: 16 Downgraded packages: 0 Size of added packages: 269.26 KiB Size of dropped packages:121.87 MiB Size of upgraded packages: 5.24 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 69.40 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230629.n.0.x86_64.vagrant-libvirt.box Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230629.n.0.iso Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230629.n.0.x86_64.vagrant-virtualbox.box = DROPPED IMAGES = = ADDED PACKAGES = Package: rust-gix-features-0.30.0-1.fc39 Summary: Integrate various capabilities using compile-time feature flags RPMs:rust-gix-features+cache-efficiency-debug-devel rust-gix-features+crc32-devel rust-gix-features+default-devel rust-gix-features+document-features-devel rust-gix-features+fast-sha1-devel rust-gix-features+fs-walkdir-parallel-devel rust-gix-features+io-pipe-devel rust-gix-features+once_cell-devel rust-gix-features+parallel-devel rust-gix-features+progress-devel rust-gix-features+progress-unit-bytes-devel rust-gix-features+progress-unit-human-numbers-devel rust-gix-features+rustsha1-devel rust-gix-features+walkdir-devel rust-gix-features+zlib-devel rust-gix-features+zlib-ng-compat-devel rust-gix-features+zlib-ng-devel rust-gix-features+zlib-rust-backend-devel rust-gix-features+zlib-stock-devel rust-gix-features-devel Size:213.28 KiB Package: rust-gix-quote-0.4.4-1.fc39 Summary: Deal with various quotations used by git RPMs:rust-gix-quote+default-devel rust-gix-quote-devel Size:29.14 KiB Package: rust-symlink-0.1.0-1.fc39 Summary: Create symlinks in a cross-platform manner RPMs:rust-symlink+default-devel rust-symlink-devel Size:26.84 KiB = DROPPED PACKAGES = Package: golang-github-flynn-shlex-0-0.14.20190625git3f9db97.fc38 Summary: Simple lexer for Go RPMs:golang-github-flynn-shlex-devel Size:16.71 KiB Package: golang-github-jimstudt-http-authentication-0-0.10.20190702git3eca13d.fc38 Summary: Go implementation of RFC 2617 HTTP Authentication RPMs:golang-github-jimstudt-http-authentication-devel Size:58.56 KiB Package: matreshka-20.1-13.fc38 Summary: Set of Ada libraries to help to develop information systems RPMs:matreshka matreshka-amf matreshka-amf-dd matreshka-amf-dd-devel matreshka-amf-devel matreshka-amf-mofext matreshka-amf-mofext-devel matreshka-amf-ocl matreshka-amf-ocl-devel matreshka-amf-uml matreshka-amf-uml-devel matreshka-amf-utp matreshka-amf-utp-devel matreshka-devel matreshka-fastcgi matreshka-fastcgi-devel matreshka-servlet-devel matreshka-servlet-lib matreshka-soap-core matreshka-soap-core-devel matreshka-soap-wsse matreshka-soap-wsse-devel matreshka-spikedog-api-devel matreshka-spikedog-api-lib matreshka-spikedog-awsd matreshka-spikedog-awsd-devel matreshka-spikedog-core-devel matreshka-spikedog-core-lib matreshka-sql-core matreshka-sql-core-devel matreshka-sql-mysql matreshka-sql-mysql-devel matreshka-sql-postgresql matreshka-sql-postgresql-devel matreshka-sql-sqlite matreshka-sql-sqlite-devel matreshka-xml matreshka-xml-devel Size:121.66 MiB Package: python-martian-0.15-19.fc38 Summary: A library to grok configuration from Python code RPMs:python3-martian Size:137.00 KiB = UPGRADED PACKAGES = Package: awscli-1.27.163-1.fc39 Old package: awscli-1.27.162-1.fc39 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.32 MiB Size change: 453 B Changelog: * Wed Jun 28 2023 Gwyn Ciesla - 1.27.163-1 - 1.27.163 Package: gap-pkg-profiling-2.5.3-1.fc39 Old package: gap-pkg-profiling-2.5.2-2.fc38 Summary: Line by line profiling and code coverage for GAP RPMs: gap-pkg-profiling gap-pkg-profiling-doc Size: 526.83 KiB Size change: -1006 B Changelog: * Wed Jun 28 2023 Jerry James - 2.5.3-1 - Version 2.5.3 Package: golang-github-cloudflare-cfssl-1.6.4-1.fc39 Old package: golang-github-cloudflare-cfssl-1.6.1-3.fc38 Summary: CFSSL: Cloudflare's PKI and TLS toolkit RPMs: golang-github-cloudflare-cfssl golang-github-cloudflare-cfssl-devel Size: 100.53 MiB Size change: 210.61 KiB Changelog: * Wed Jun 28 2023 Mikel Olasagasti Uranga - 1.6.4-1 - Update to 1.6.4 - Closes rhbz#2121928 rhbz#2163108 Package: google-compute-engine-guest-configs-20230626.00-1.fc39 Old package: google-compute-engine-guest-configs-20230526.00-3.fc39 Summary: Google Compute Engine guest environment tools RPMs: google-compute-engine-guest-co
Re: Announcing fmt library soversion bump
Dne 28. 06. 23 v 23:39 Kalev Lember napsal(a): On Wed, Jun 28, 2023 at 8:03âŻPM Vitaly Zaitsev via devel wrote: FTBFS: 0ad arbor CuraEngine bout++ cachelib dolphin-emu folly freeopcua gerbera luxcorerender mangohud wasmedge watchman I fixed 0ad from that list and built it in the side tag. I think I will merge this side tag without fmt9 compatibility package tomorrow. Why? Now that you've already done all the work of adding the compatibility package, why drop it and break all of the unbuilt packages in rawhide? I don't think any of the packages from the list are release blocking, but it just seems antisocial for rawhide users to break packages they might be using, especially if it's no extra work for you at this point. This don't necessarily breaks Rawhide users. It just won't let them update some packages. The only question is if the packages gets fixed eventually. VĂt Another thing that comes in my mind is that there is the ongoing python rebuild in f39-python and your rebuilt package set probably intersects with it. Would be good to let Miro know what packages they need to rebuild again once your fmt tag is merged. -- Kalev ___ 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 OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Towards enabling rpm sysusers integration
On 6/28/23 17:15, Lennart Poettering wrote: On Di, 27.06.23 12:04, Panu Matilainen (pmati...@redhat.com) wrote: On 6/22/23 19:55, Steve Grubb wrote: https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format I would caution against this whole proposal. Not that I'm against it, but just saying be careful doing it. People often forget about our security concerns. Currently, shadow-utils has about 400 places which generate audit events during the managing of system and user accounts. libuser (I saw the deprecation email) has 55 places where it sends audit events managing accounts. There is a 10 year old (or more) standard published here: https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Account-Lifecycle-Events If %pre getent, useradd, and groupadd are being replaced by something, that something needs to conform to the expected security safeguards that currently exist. It needs to match the kind of events and the format that currently exists. Looking at the systemd-sysusers source [1], it seems to do exactly zero audit logging. So there's a bit of work to do on that front... last time I looked auditd is started later than systemd-sysusers. Hence not sure if sysusers would actually generate audit messages that auditd could pick them up. For the rpm integration, "started later" is irrelevant as the user/group creation takes place during rpm transactions. In general though: people who care about audit need to send us patches for this, if this matters to them. I don't think anyone in systemd upstream wil work on this on their own. Didn't imply any particular party, just that there's work to do. Both rpm and systemd would like to see systemd-sysusers used for user/group creation but audit requirement prevents that. Who should do the work? Guess there's a bit of a Mexican stand-off here :D The rpm integration doesn't technically require systemd-sysusers, we can write a script that calls useradd/groupadd instead. So for us it becomes a choice between writing that script or adding audit support to systemd-sysusers. Writing a script based on sysusers.generate-pre.sh may well be less work and would benefit the non-systemd audiences of rpm at the same time. We'll see. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Is there a chance to phase out `/lib64` directory?
On Wed, Jun 28, 2023 at 3:22âŻAM Kevin Kofler via devel wrote: > > Kalev Lember wrote: > > I would like to have a layout similar to what Debian is doing, so that > > shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64 > > would be a legacy symlink pointing to it. > > That layout is NOT compliant with the FHS. > > Which is particularly hilarious as Debian has long refused to use > /usr/libexec (despite GNU having had it for ages, and Debian's refusal has > in turn lead several upstreams to not or poorly support it and abuse > /usr/lib or other directories for its purpose instead) because it was > purportedly against the FHS (it seems they have never noticed that the > clause that allows lib64 and lib32 does not actually require the suffix to > be a number, "exec" is a perfectly fine suffix, so libexec is just another > lib64/lib32-type directory), but was very fast to add an exception for this > new entirely non-standard layout. (The FHS requires the arch-specific libdir > variants to be suffixed sibling directories of lib, NOT subdirectories.) In RISCV lands things look like this: [..] #define STARTFILE_PREFIX_SPEC \ "/lib" XLEN_SPEC "/" ABI_SPEC "/ "\ "/usr/lib" XLEN_SPEC "/" ABI_SPEC "/ "\ [..] Linker default search paths: [..] SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64/lp64d") SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64") SEARCH_DIR("=/usr/riscv64-redhat-linux/lib6464/lp64d") SEARCH_DIR("=/usr/lib6464/lp64d") SEARCH_DIR("=/usr/lib64") SEARCH_DIR("=/usr/local/lib64/lp64d") SEARCH_DIR("=/usr/local/lib64") SEARCH_DIR("=/lib64/lp64d") SEARCH_DIR("=/lib64") SEARCH_DIR("=/usr/lib64/lp64d") SEARCH_DIR("=/usr/riscv64-redhat-linux/lib") SEARCH_DIR("=/usr/local/lib") SEARCH_DIR("=/lib") SEARCH_DIR("=/usr/lib") [..] By default the expectation is to find libraries under ABI subdirectory, e.g. /usr/lib64/lp64d In Fedora/RISCV /usr/lib64/lp64d is a symlink back to /usr/lib64 From glibc: [..] This program interpreter self-identifies as: /lib/ld-linux-riscv64-lp64d.so.1 Shared library search path: (libraries located via /etc/ld.so.cache) /lib64/lp64d (system search path) /usr/lib64/lp64d (system search path) [..] david > > > That kind of layout would make it much easier to do cross compilation > > because you could just take the whole /usr/lib/another-host-triplet/ > > directory from another architecture without it interfering with the host > > libraries and use it for cross compilation purposes. > > Practical cross-compilation to a completely different architecture needs > sysroots anyway. That way, one can also easily target a different > distribution on a different (or even the same) architecture, not just Fedora > on a different architecture. > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: 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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
On Thu, 2023-06-29 at 02:22 -0400, Neal Gompa wrote: > And since Lorax (which is what we use > for live and ARM images) requires Anaconda to understand the target > system to install, it couldn't be used for creating these images > either because that requires teaching Anaconda about Apple Silicon > Macs. Hmm, well, why don't we do that? It knows/knew about PPC Macs and Intel Macs, after all... -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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