Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
> Jiri Konecny writes: > Also a question, is kickstart command for RDP requirement for you? Or > is inst.rdp (replacement of inst.vnc) enough to work with? We are > trying to find out if we can drop the kickstart command. I don't particularly care about how the functionality gets activated; in my case it's not something that would need to come in though the kickstart file. However, I could see situations where it would be useful to have that specified in the kickstart file, such as a hypothetical deployment system. It might, for example, want to direct anaconda to send the display to an appropriate place that could be proxied or recorded. That location might be complicated or variable and not necessarily something that could be baked into the boot media or typed in at boot time. - 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: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
> Jiri Konecny writes: > Hi, the only change should be that you will change "vnc --connect" > with the new API we will provide and also use RDP as your client > instead of VNC. Thanks. I don't particularly care about VNC itself; I just wanted to make sure that it was known that someone does use "--connect" to do a "client-initiated" display connection. Off topic, I know, but what I really wish existed was some kind of deployment console. Early in the kickstart process, the machine being installed would contact a server, pass hardware info and wait. The server would pass back the rest of the kickstart file (after potentially getting admin input) and the installation would continue. Output would be logged in a way that the server can present to the admin, and potentially the graphical (or perhaps the text) UI could be passed through. Years ago I had hacked something implementing a little of this which just worked in %pre but it ended up being less useful than the system I use now. And really, I don't think that deployments like mine (maybe a couple hundred machines) are very common so there's probably no point. But it's an interesting problem to think about. - 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: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
> Aoife Moloney writes: > === VNC switch to RDP for remote GUI installations === I'm curious how my usual install workflow will be affected by this change. I use the kickstart "vnc --connect" option extensively in my workflow; I may have a bunch of installs running in parallel, and they just connect and display when they are ready. I use vinagre as the vnc client. It's not a huge thing; I could come up with another workflow but that's the one I've used since before Fedora existed. The installs are fully automated and the display connection is only used so that I can see the progress and potentially interact with a machine if it encounters a problem. I guess in the worst case I could just do the install blind and ssh in if something takes too long. - 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
Orphaning xu4
For many years I have maintained xu4 (https://xu4.sourceforge.net/, https://src.fedoraproject.org/rpms/xu4/), an open source engine which can run the freely available Ultima IV game files. When the original code was subsumed into the ScummVM engine, I was conflicted about what should be done with the package, but now there is a new upstream who is further developing the code in a separate direction from what ScummVM is doing. Unfortunately that new upstream has added a number of new dependencies, including a custom scripting language (Boron) and I simply have not had time to track down all of these dependencies and get them added to the distribution. Upstream appears to fundamentally disagree with the concept of unbundling in any case and I don't really feel like fighting that battle, so I feel it's best to simply let the outdated package I have been maintaining exit the distribution. However, if someone wants to pick it up, it's there for the taking. - 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: Proven to be sickened
So I've been in this situation, both on the receiving end of nasty flames because I dared touch someone else's package and having duplicated work because I didn't check before trying to update something. > Michael J Gruber writes: > So, due to me following my package (notmuch) The idea is that it's really the community's package, but you have indicated that you will take a primary role. That doesn't mean that nobody else will ever touch the package. Communication is encouraged, of course. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity > ... and get a reject because someone thought that pushing directly > without asking or at least notifying the maintainer would be in order: This is collaborative maintenance. Occasionally you get ninja'd. It happens. Certainly it's annoying when it happens but it's not evidence that anyone did anything wrong. If there is something wrong with the work of the maintainer who got there before you did, then you can always push a revert, bump and build your own copy. And of course have a discussion with them. If there isn't anything wrong with the work of the other maintainer, then I guess I don't understand. They did something in an honest attempt to save you the trouble and because of unfortunate timing they didn't actually save you any trouble. But you aren't in a different position than if they hadn't tried to help. (Excluding the time it took to start this discussion, of course.) > I am sick of this. Really. I am so sick of this way of stomping on > each others' feet. I can only say that the best thing to do in this situation is to say "thanks; would you mind sending me a note on [IRC|Matrix|email] in the future so we don't duplicate effort?" and move on. Surely it's not worth strong emotions. > It's made worse by failing automated notifications, of course. Not > from pagure about the push nor from koji about the build nor from > bodhi about the update. Now that is a true issue, and perhaps the real underlying issue here. If you invested time that you didn't need to invest because you didn't receive a notification that the work had already been done, then that is problematic. And yes, it would be incredibly beneficial to collaboration if that were fixed, if only because it would help to prevent situations such as the one under discussion. But please don't take that out on the person who had no motivation other than to help you out. - 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: Packaging web extension native part and shared directory ownership
> Robert Marcano via devel writes: > I seriously don't know how gnome-browser-connector [1] has ownership > of: > /usr/lib64/mozilla/native-messaging-hosts > and not have conflict problems with mozilla-filesystem at install > time, maybe because they usually get installed at the same time with > the system installer. As long as the directories have the same ownership and permissions, there is no conflict. Multiple packages owning a single directory is not uncommon, and the case is covered in the packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership " To be specific, you do not need to require a package for the sole fact that it happens to own a directory that your package places files in. If your package already requires that package for other reasons, then your package should not also own that directory. " (Yes, the grammar there isn't the best.) - 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: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide
> Sandro writes: > That aside, having the document linked in the packaging guidelines is > a big step towards letting packagers know of its existence. I just wanted to point out that the packaging guidelines have pointed users to the document for quite some time (early 2019) in this section: https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/#_macros_providing_compiler_and_linker_flags Of course the process for getting guidelines updated has changed significantly since the documents were living in the wiki; anyone can submit a PR and thanks to the effort of the docs team, even the "Edit this page" link lets you fork, edit and send a PR for a page. I added more comments in the original ticket: https://pagure.io/packaging-committee/issue/743#comment-876365. The gist is that processes have changed to make things much easier, but the ultimate decision as to whether these things actually live in the packaging guidelines or not is entirely up to Florian. Any such move necessarily adds some complexity and extra work - 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: Unannounced soname bump: libotf
> Gary Buhrmaster writes:
> I have found that using something like libfoo.so.X{,.*} in the %files
> directive can be a useful reminder (enforcer) to reduce such surprises
> (that particular glob presumes semantic versioning, and that minor and
> patch level updates do not require rebuilds, but that is true much of
> the time).
In fact, excessively wide globbing here is explicitly discouraged by the
packaging guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files
Looking at the current spec, it uses "%{_libdir}/*.so.*"; had it
followed this guideline, I believe this issue would not have occurred.
- 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: Tenacity
> stan via devel writes: > As they say in the BUILDING.md file, > though, fedora lacks wxWidgets 3.1.5 or greater. That stops the > configuration, cmake -G Ninja -S . -B build when it errors out. That's odd; as far as I can see, F36 has 3.1.5 and F37 has 3.2.1. - 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: Karma for OpenSSL needed
> Ewoud Kohl van Wijngaarden writes: > Right now you can't test them since they haven't been migrated to > testing yet. You can download the packages directly from koji. From the relevant update page, you can clock the "Builds" tab which will give you a link. You can down exactly the packages you need from there. > Feels a bit like blindly bypassing the tests, right? Obviously you shouldn't give karma without actually testing, but you are in ho way prevented from doing so by the current state. It's just more convenient to wait until the build is pushed to testing and then out to the mirrors. - 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
[EPEL-devel] EPEL and the new distribution-related macros
Quite recently a few macros were added to fedora-release: %dist_vendor, %dist_name, %dist_home_url and %dist_bug_report_url. These will eventually be documented in the Fedora packaging guidelines and you can see the initial PR at https://pagure.io/packaging-committee/pull-request/1198 I was considering how this interacts with EPEL. If these macros are not added to RHEL then EPEL could just define them with EPEL-appropriate values and all is well. But if they are added to RHEL, EPEL will need to decide if the values used by Red Hat (or whatever base distribution is being used to build) are appropriate. And if not, is it appropriate for EPEL to override the RHEL values? (This was done back in the EPEL6 days so there is precedent but that was a long time ago.) - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Fedora-legal-list] Re: Fedora adoption of SPDX ids and changes to packaging guidelines
> Jilayne Lovejoy writes: > https://pagure.io/packaging-committee/pull-request/1142 > Can someone merge that PR on Tuesday evening or Wednesday morning (US > time)? I will be watching the PR and can merge it when it's done, but feel free to ping me. - J< ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
How much free space in /var is required for upgrades?
So I went to do a dnf system-upgrade from F35 to F36 on a test machine, as part of my usual testing. In the middle of the process, it appears that /var filled up and that left the system in an unfortunate state. Surprisingly (to me) it did boot with a random mix of F35 and F36 packages and even though it's a throwaway test box, I wanted to play around with fixing it a bit and trying to understand why it ran out of space instead of just reinstalling. Turns out that "dnf --releasever 36 --nogpgcheck remove --duplicates" was able to effectively everything in the system, and while running this /var filled up again. When that happened, dnf couldn't even be aborted; I had to kill -9. The culprit is the write-ahead log, /var/lib/rpm/rpmdb.sqlite-wal. I resized /var and reran, and by the end of the process had grown to over 9GB: -rw-r--r--. 1 root root 9124576392 May 13 13:11 rpmdb.sqlite-wal Of course it immediately went to 0 once the transaction completed, though rpmdb.sqlite went from: -rw-r--r--. 1 root root 281739264 May 11 14:24 rpmdb.sqlite to -rw-r--r--. 1 root root 730648576 May 13 13:15 rpmdb.sqlite which seems... odd for what's effectively just reinstalling the existing package set. Anyway, obviously the solution is to make sure that /var is "big enough" before you do a system upgrade. And we do have warnings about filesystems being too small, but nothing about needing an extra 10GB for this. Certainly my case might be somewhat pathological and it was good that in the end I was able to get the system back into a useful state without wiping it. But in the end I wonder: 1) Is it really expected that the wal file will grow to that size? 2) Is there anything to be done to reduce the size of the log? 3) Is there any better way to handle a lack of space in /var during an RPM transaction? 4) Can we estimate how large the file will grow, and refuse to start a system upgrade if there is not enough space? Certainly we already do this to some degree, but it seems that the estimate of the required space is a bit too small. - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
> Ben Cotton writes: > == Make UEFI a hardware requirement for new Fedora installations on > platforms that support it (x86_64). My problem here is that I have real, useful hardware which has always run Fedora that I would like to continue using. But it's just old enough (purchased in 2011) and doesn't support UEFI at all. These machines are repurposed computational servers and work perfectly well to do things like provide some public Fedora mirrors. > Like the already accepted Fedora 37 change to retire ARMv7 support, > the hardware targeted tends to be rather underpowered by today’s > standards, and the world has moved on from it. I know there is this tendency to dismiss anything that's old as useless, and 20 years ago, a decade-old machine wasn't something you probably wanted to use. But the rate of progress has slowed down, and a Xeon X5670 with 96GB of memory and a pile of disk just isn't a piece of garbage. I know I'll have to toss it out eventually, but I'd hope to do that when it either fails or is actually no longer useful. I understand that this isn't going to be how the primary user experience is directed. I can deal with having to jump through hoops to get a machine installed. But it would be kind of sad if my alternatives are to use another distro or toss the stuff in the trash. (There would be a certain irony in not being able to run Fedora to provide a Fedora mirror.) For those who might be curious, the systems are Supermicro 6026TT-HTRF machines with four nodes in 2U. I have three, so twelve machines in total. The machines have X8DTT-HF+ motherboards. I actually have older hardware than that around and still in use (all Supermicro), but oddly some of it actually has an EFI option. - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
> Brandon Nielsen writes: > I would like to see the forge macros removed from the guidelines if > development truly has ceased. I would like to get into them and at least see what needs to change but... the internal implementation is somewhat baroque and my time is severely limited. I think there is good stuff there but I don't know how much work would be required to salvage it. One problem is that at least I thought that significant portions of the Go tooling relied on it, and there's no alternative that has any kind of automation. - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
> Gary Buhrmaster writes: > I have occasionally conjectured that there should be a "last gasp" > version of some core package released into updates for a version going > unsupported that drops a file into /etc/motd.d that is, essentially: I've thought about it as well, but I still wonder good it would really do. For a random example, I run a full Fedora mirror including the archive module. There is a number of hosts hosts still pulling repodata for Fedora 7 and one lone host that checks for updates for Fedora Core 5 that will obviously never come. People will update when they want, or not. Plus force-modifying MOTD, or doing anything that's so invasive that someone is guaranteed to notice, is pretty antisocial. At best anything that you would use to do updates (like dnf or one of the graphical applications) could complain about the release being EOL, and I suspect that some of them already do. That's really the only proper way to do this. - 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: RFC: Reduce number of packages that are built for i686
> Robbie Harwood writes:
> Fabio Valentini writes:
>> Since it's not practical to modify almost all Fedora packages to add
>> "ExcludeArch: %{ix86}" to them, we'd probably need a different
>> machanism for this.
> Is it really not? This seems the easiest way to go about it, honestly
> - just have it be permitted for maintainers to opt their stuff out of
> building on x86 and let the problem take care of itself recursively.
I have to say that it would be nicer if building for i686 were opt-in
instead of opt-out. Just figure out what we really need to build to
support the few things we want to support, let maintainers build
additional things if they want to do so, and have a mechanism for asking
someone to add an i686 build.
Basically not much different from EPEL.
- 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 on the list, report it:
https://pagure.io/fedora-infrastructure
[Fedora-legal-list] Re: ttyp0 font license
> Richard Fontana writes: > I am not sure if this should be acceptable for Fedora. My concern is > that the "UW" naming prohibition is unreasonably restrictive. Does > anyone have thoughts on this? Naming can be difficult, but I believe we've long accepted clauses forcing renaming. A license saying "don't use our name in your new name" seems reasonable even if your name is just a few letters (like "IBM" or "UW"). It is technically restricting a freedom but not in any way that seems meaningful. Where I think it gets sticky is if a license were to prevent renaming, or maybe to specify the name to be used for modified versions. A more difficult corner case would be something like "must not start with the letter 'a'" or "must sort higher alphabetically". - J< ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: RFC: generating openssl3 packages from openssl spec
> Troy Dawson writes: > If I remember right, the spec file name needs to be in the format > .spec Thus, the spec file needs to be > openssl3.spec, and thus you aren't really renaming it. :) Yes, assuming that EPEL doesn't deviate: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_file_naming I believe various tools will make the assumption that the specfile is named accordingly. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Freeze Break Request: fix bugzilla query limited results in review-stats
That looks like a lot of change for what should be a one-line change. Did some unrelated commit sneak in? - J< ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Fedora-legal-list] Re: Consider adding MVT License 1.0 to list of allowed/good licenses
>> Therefore, the goal of this license is to prohibit the use of MVT >> (and any other software licensed the same) for the purpose of >> adversarial forensics. That sounds like a field-of-use restriction. I can't imagine how such a license can be free under the usual definitions. For the misspellings of the word "individual", I filed https://github.com/mvt-project/mvt/issues/70 " 3.0. Consensual Use Restriction Use of Covered Software or of a Larger Work is permitted provided that the Data Owner must explicitly consent to the procedure, free from any form of coercion, and must be fully informed about the nature of the procedure, its privacy implications, and any data retention and disposal policy. " For context: " 1.16. "Device Owner" (or "Device Owners") means an individal or a legal entity with legal ownership of an electronic device which is being analysed through the use of Covered Software or a Larger Work, or from which Data was extracted for subsequent analysis. 1.17. "Data Owner" (or "Data Owners") means an individial or group of individuals who made use of the electronic device from which Data that is extracted and/or analyzed originated. "Data Owner" might or might not differ from "Device Owner". " ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 32 System-Wide Change proposal: Annobin Used By Bodhi
> "BC" == Ben Cotton writes: BC> Use the annocheck program from the annobin package to BC> produce an analysis of the security hardening of a compiled package BC> when reviewing a Bodhi update. While I don't disagree with running annocheck at some point in the build process, _only_ doing things in bodhi can be problematic for packagers. The issue is that you can build and test and have others test and be ready to submit an update, only to be stopped by some additional testing that you had no idea you needed to take extra steps to duplicate locally. Personally I'd prefer to do this in a brp script. Those run near the end of the build process, can output things into the build log which can be checked easily (even by anything which can look at koji, which I suppose would include bodhi) and could, if it were desired, fail the build entirely, notifying packagers of policy violations as early as possible instead of after waiting for a real koji build and bodhi processing. All this would take is a shell wrapper, a small tweak in redhat-rpm-config, and getting annocheck into the buildroot. Things to note: 1. You need the annocheck (or rather the annobin-annocheck package) in the buildroot. It doesn't appear to have additional dependencies which aren't already in the buildroot and the package is minimal, so this probably isn't a huge issue. 2. It's easy to disable brp scripts, which can be good or bad depending on whether you want them to implement hard policy. But it is also easy to find packages which disable them by grepping specfiles, and if the script is written to always output something then you can just grep the build log for evidence that it ran. 3. People get rather annoyed if builds start failing because of additional policy checks. This is of course mitigated somewhat by #2 above. Generally what we've done in the past is add the checks in some advisory mode and then turn bad things into failures after a release. - 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
Re: Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0
> "AI" == Artur Iwicki writes:
AI> I imagine the reason is that this allows us to add new
AI> architectures to FPC and do some trial-and-error builds of FPC
AI> without affecting dependent packages - if FPC itself used
AI> %{fpc_arches}, then adding new architectures to FPC would require
AI> updating fpc-rpm-macros, and that would make all dependent packages
AI> fail to build, since the new-arch builds would fail with "Package
AI> not found: fpc" until we got FPC available on those.
fpc could simply use something like:
ExclusiveArch: %{fpc_arches} aarch64
to trial a new architecture without having to update fpc-rpm-macros.
- 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
Re: django-pytest vs pytest-django
> "DM" == David Moreau-Simard writes: DM> I don't have the bandwidth to take care of pytest-django right now. DM> Would it be acceptable to propose a new package without %check until DM> it gets packaged ? It's OK to disable tests you can't run because they have additional dependencies which aren't in the distribution, though certainly the alternative of packaging that dependency and running all of the tests is preferable. - J< ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Old changelog entries removal
> "MM" == Matthew Miller writes: MM> Whether or not it's documented policy (and I can't remember or find MM> anything either), many packages have the practice of trimming very MM> old entries. You can't always do this. I tried to purge changelog entries from a package older than 2010 and was not permitted to do so: https://src.fedoraproject.org/rpms/cyrus-imapd/c/4672136ce3276859bc1971075a87a30a47f9995b?branch=master All I could figure was that the person who originally developed the packages back before 2006 had objected that their changelog entries had been removed. There might even have been some kind of agreement between them and Red Hat which of course isn't documented anywhere, and shouldn't apply to Fedora anyway. So I'd certainly love it if there was a distro-wide policy about this, with a requirement that weird exceptional cases like this be documented publicly. There is also valid discussion to be had about giving credit, and whether changelog entries are a valid way of accomplishing that. (I would argue that they aren't and that the SCM history should be sufficient, but I personally don't care if my name is in the credits or not.) - 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
Re: Defining the future of the packager workflow in Fedora
> "C" == Christopher writes: C> With version-controlled package sources, changelogs in SPEC seem so C> obsolete to me. They are already problematic today when they conflict C> due to changes in multiple branches. It's important to note that the RPM changelog is rather a different thing from a list of commits made to the specfile. If I went and re-indented the spec, that would of course get a commit message but has no relevance to the end user and should not result in a changelog entry. Often I make several commits to the spec, and then update the %changelog section with a summary of user-relevant changes only when I'm ready to bump the release. It seems that generating %changelog from git commits would require something like magic tags in the commit messages, which seems like something of a pain. - 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
Re: Regression in 5.1.20: Reading long directory fails
> "JBF" == J Bruce Fields writes: JBF> Those readdir changes were client-side, right? Based on that I'd JBF> been assuming a client bug, but maybe it'd be worth getting a full JBF> packet capture of the readdir reply to make sure it's legit. I have been working with bcodding on IRC for the past couple of days on this. Fortunately I was able to come up with way to fill up a directory in such a way that it will fail with certainty and as a bonus doesn't include any user data so I can feel OK about sharing packet captures. I have a capture alongside a kernel trace of the problematic operation in https://www.math.uh.edu/~tibbs/nfs/. Not that I can particularly tell anything useful from that, but bcodding says that it seems to point to some issue in sunrpc. And because I can easily reproduce this and I was able to do a bisect: 2c94b8eca1a26cd46010d6e73a23da5f2e93a19d is the first bad commit commit 2c94b8eca1a26cd46010d6e73a23da5f2e93a19d Author: Chuck Lever Date: Mon Feb 11 11:25:41 2019 -0500 SUNRPC: Use au_rslack when computing reply buffer size au_rslack is significantly smaller than (au_cslack << 2). Using that value results in smaller receive buffers. In some cases this eliminates an extra segment in Reply chunks (RPC/RDMA). Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker :04 04 d4d1ce2fbe0035c5bd9df976b8c448df85dcb505 7011a792dfe72ff9cd70d66e45d353f3d7817e3e M net But of course, I can't say whether this is the actual bad commit or whether it just introduced a behavior change which alters the conditions under which the problem appears. And just to make sure that the blame doesn't lie with the old RHEL7 kernel, I rsynced over the problematic directory to a machine running something slightly more modern (5.1.11, which I know I need to update, but it's already set up to do kerberised NFS) and the same problem exists, though the directory listing does fail at a different place. - J<
Re: [Test-Announce] Fedora 31 Beta Freeze
> "CM" == Chris Murphy writes: CM> But anyway, I did laugh a bit out loud at 23:45 UTC because *of CM> course* there are many other totally unambiguous times to choose CM> from instead. Some of the best comedy is pointing out the obvious. If we're going to bikeshed it, I'll vote for two minutes to midnight. - 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
Re: Regression in 5.1.20: Reading long directory fails
I asked the XFS folks who mentioned that the issues with 64 bit inodes are old, constrained to larger filesystems than what I'm using, not an issue with nfsv4, and not present on anything but 32bit clients with old userspace. In any case, I have been experimenting a bit and somehow the issue seems to be related to exporting with sec=krb5i:krb5p or sec=krb5i. If I export with just sec=krb5p, things magically begin to work. So basically: [root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts 7685 nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0 (unmount, then re-export with krb5i on the server) [root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts ls: reading directory '/home/tester': Input/output error 5623 nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5i,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0 (umount, then re-export with krb5i:krb5p on the server) [root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts ls: reading directory '/home/tester': Input/output error 5623 nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5i,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0 (umount, switch back to plain krb5p) [root@ld00 ~]# ls -l ~tester|wc -l; grep tester /proc/mounts 7685 nas00:/export/misc-00/tester /home/tester nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=172.21.84.191,local_lock=none,addr=172.21.86.77 0 0 Sometimes the number of files it lists before it fails changes (and in this case has been as small as a few hundred) but I don't know what causes it to change. Anyway, I hope this helps to pinpoint the problem. I now have a really easy way to reproduce this without having to kick people off of the server, and if the successes aren't just some kind of false positives then I guess I also have a workaround. I'm still at a loss as to why a revert of the readdir changes makes any difference at all here. - J<
Re: Regression in 5.1.20: Reading long directory fails
> "WW" == Wolfgang Walter writes: WW> What filesystem do you use on the server? xfs? Yeah, it's XFS. WW> If yes, does it use 64bit inodes (or started to use them)? These filesystems aren't super old, and were all created with the default RHEL7 options. I'm not sure how to check that 64 bit inodes are being used, though. xfs_info says: meta-data=/dev/mapper/nas-faculty--08 isize=256agcount=4, agsize=3276800 blks = sectsz=512 attr=2, projid32bit=1 = crc=0finobt=0 spinodes=0 data = bsize=4096 blocks=13107200, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal bsize=4096 blocks=6400, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 WW> Do you set a fsid when you export the filesystem? I have never done so on any server. And note that the servers are basically unchanged for quite some time, while the problem I'm having is new. I want to find some server-related cause for this but so far I haven't been able to do so. It seems my best option now seems to be to migrate all data off of this server and then wipe, reinstall and see if the problem reoccurs. - J<
Re: Regression in 5.1.20: Reading long directory fails
> "JLT" == Jason L Tibbitts writes: JLT> Certainly a server reboot, or maybe even just JLT> unmounting and remounting the filesystem or copying the data to JLT> another filesystem would tell me that. In any case, as soon as I JLT> am able to mess with that server, I'll know more. Rebooting the server did not make any difference, and now more users are seeing the problem. At this point I'm in a state where NFS simply isn't reliable at all, and I'm not sure what to do. If Centos 8 were out, I'd work on moving to that just so that the server was a little more modern. (Currently the server is Centos 7.) I guess I could try using Fedora, or installing one of the upstream kernels, just in case this has to do with some interaction between the client and the old RHEL7 kernel. I do have a packet capture of a directory listing that fails with EIO, but I'm not sure if it's safe to simply post it, and I'm not sure what tshark options would be useful in decoding it. I do know that I can rsync one of the problematic directories to a different server (running the same kernel) and it doesn't have the same problem. What I'll try next is rsyncing to a different filesystem on the same server, but again I'll have to wait until people log off to do proper testing. - J<
[EPEL-devel] Re: Koschei enablement for EPEL 8
> "SJS" == Stephen John Smoogen writes: SJS> Can koschei be limited to a single architecture or does it need to SJS> build against all targets? I am worried about the number of s390 SJS> builds we may be adding. Currently it only does builds for aarch64, ppc64le and x86_64, so it does at least know how to avoid building on everything. In addition, it is pretty good about not submitting jobs without plenty of idle builders to handle them. Back when it was first being deployed, koschei did swam the s390x builders but that was fixed. And these days, s390x isn't really our slowest architecture. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Regression in 5.1.20: Reading long directory fails
> "BF" == J Bruce Fields writes: BF> Looks like that's db531db951f950b8 upstream. (Do you know if it's BF> reproduceable upstream as well?) Yes, it's reproducible up in the 5.3.0 RCs as well. However, while trying to do some further bisecting I ran into an odd problem. Now kernels which were previously working (i.e. 5.1.19 and older) are returning errors, but at a different file count. This only gives me more questions. And so, just to be absolutely sure that there isn't some weird server issue involved, I'm going to try to schedule a reboot of the relevant server. BF> Maybe it depends on having names of the right length to place some BF> bit of xdr on a boundary. I wonder if it'd be possible to reproduce BF> just by varying the name lengths randomly till you hit it. I know I can't reproduce with loads of short names, and with relatively long names as well (using sha256sum as filename generator). BF> No clever debugging ideas off the top of my head, I'm afraid. I BF> might start by patching the kernel or doing some tracing to figure BF> out exactly where that EIO is being generated? If I had any idea how to do that, I happily would. I'm certainly willing to learn. At least I can run strace to see where ls bombs: getdents64(5, 0x7fc13afaf040, 262144) = -1 EIO (Input/output error) bcodding on IRC mentioned that is a rather large count. Does make me wonder if the server is weirding out and sending the client bogus data. Certainly a server reboot, or maybe even just unmounting and remounting the filesystem or copying the data to another filesystem would tell me that. In any case, as soon as I am able to mess with that server, I'll know more. _ J<
Re: Regression in 5.1.20: Reading long directory fails
I now have another user reporting the same failure of readdir on a long directory which showed up in 5.1.20 and was traced to 3536b79ba75ba44b9ac1a9f1634f2e833bbb735c. I'm not sure what to do to get more traction besides reposting and adding some addresses to the CC list. If there is any information I can provide which might help to get to the bottom of this, please let me know. To recap: 5.1.20 introduced a regression reading some large directories. In this case, the directory should have 7800 files or so in it: [root@ld00 ~]# ls -l ~dblecher|wc -l ls: reading directory '/home/dblecher': Input/output error 1844 [root@ld00 ~]# cat /proc/version Linux version 5.1.20-300.fc30.x86_64 (mockbu...@bkernel04.phx2.fedoraproject.org) (gcc version 9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)) #1 SMP Fri Jul 26 15:03:11 UTC 2019 (The server is a Centos 7 machine running kernel 3.10.0-957.12.2.el7.x86_64.) Building a kernel which reverts commit 3536b79ba75ba44b9ac1a9f1634f2e833bbb735c: Revert "NFS: readdirplus optimization by cache mechanism" (memleak) fixes the issue, but of course that revert was fixing a real issue so I'm not sure what to do. I can trivially reproduce this by simply trying to list the problematic directories but I'm not sure how to construct such a directory; simply creating 1 files doesn't cause the problem for me. I am willing to test patches and can build my own kernels, and I'm happy to provide any debugging information you might require. Unfortunately I don't know enough to dig in and figure out for myself what's going wrong. I did file https://bugzilla.redhat.com/show_bug.cgi?id=1740954 just to have this in a bug tracker somewhere. I'm happy to file one somewhere else if that would help. - J<
Re: What does this koji error mean?
> "C" == Christopher writes: C> BuildError: package thrift is C> blocked for tag f32-updates-candidate C> (https://koji.fedoraproject.org/koji/taskinfo?taskID=37187038) It means that thrift has been blocked in koji. The usual reason for this is that the package has been retired, and the block is what actually removes the last-build version of package from the distribution. Looking in git I see that the package was retired 12 days ago (https://src.fedoraproject.org/rpms/thrift/c/3f15a694dbea566c94faff611bfcb8c87572c552?branch=master), and a revert was committed twelve hours ago. A ticket to unretire it was also filed (https://pagure.io/releng/issue/8634) but that doesn't seem to have been processed yet. ἐπιθυμία:~❯ koji list-pkgs --show-blocked --tag f32|grep thrift thrift f32 releng [BLOCKED] - 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
[EPEL-devel] Re: Fedora EPEL 8 updates-testing report
> "PW" == Phil Wyett writes:
PW> The '.1' should go before the %{?dist} tag in this case so to not
PW> confuse as the outputted 'el8.1' does.
This is not true:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_you_need_to_change_an_old_branch_without_rebuilding_the_others
And in addition, the Release: tag must be an integer unless it is
capturing additional upstream versioning information such as prereleases
or snapshots:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_simple_versioning
and
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning
I'm not aware of any EPEL-specific exceptions to those.
- J<
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Let's revisit the FTBFS policy
> "GH" == Gerald Henriksen writes: GH> On the other hand, unbuildable packages could be viewed as a GH> security risk. I mentioned security explicitly in my message. Just not in the portion you quoted. GH> If you can't just fix the security issue and rebuild, but instead GH> have to also fix the issue(s) that prevent the package from GH> rebuilding this could cause delays in getting a security update out. I mean, nothing currently guarantees that security fixes go out in a timely manner, for all sorts of reasons. If we're going to get serious about reducing that time, I would think there's a more productive way to do that than dumping all FTBFS packages because they _might_ one day have a security issue that needs fixing. But yes, certainly dump all that have open security bugs. - 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
Re: RFC: Drop lz4-static
> "DS" == David Sommerseth writes: DS> As I can see it, there is little benefit of removing lz4-static. Isn't that entirely the decision of those maintaining the package? It's still completely reasonable if they want to remove it for no other reason than it eliminates ten lines from the specfile. The question was whether there is any pressing reason to refrain from removing it. - 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
Re: Let's revisit the FTBFS policy
> "FW" == Florian Weimer writes: FW> Debian treats FTBFS bugs as release-critical. They either have to FW> be fixed, or the package gets removed from the release. However, FW> this is not an automated process. Of course, Debian works on a slightly different release schedule, so it's not exactly a direct comparison. FW> I wonder if something similar could work for Fedora: The package FW> would remain available in rawhide, but would be removed from the FW> release composes. That's an interesting option, I suppose. In part I think it depends on just why some people have been upset over the recent orphaning. Is it the removal from the distribution, the shock of having the project say "we don't want this package any longer", the fact that user's won't be able to access the package any longer, the annoyance with process for getting the package into the distribution if it's fixed, or something else? (Certainly those aren't mutually exclusive and the true answer is more complicated and differs between people.) Technical solutions to some of these are possible, though I don't know how feasible they would be. Procedural solutions (such as making it easier for such packages to get back into the distribution) could also help. FW> In the end, someone has to fix the packages eventually, and the FW> package maintainers are probably best qualified to deal with that. FW> If they lack the resources for that, it points to a much more FW> significant problem that needs solving separately, I think. Yes, this is fundamental. - 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
Re: Let's revisit the FTBFS policy
> "MH" == Miro Hrončok writes: MH> If we stop here, the current "setting to ASSIGNED to stop this" MH> remains a problem. Let's think about why this is perceived as a problem. The maintainer has performed an affirmative act that shows they noticed. Can't we just accept that as some statement of intent and stop bugging them at that point? Further emails have utility only as periodic reminders, and experience has shown that we can't predict whether those would be perceived positively or negatively. Certainly the _real_ problem here (that the packages fail to build) isn't solved by continuing to send bug spam mail. And similarly, we should spend time to evaluate why that is perceived as a problem. If a package is installable and works, certainly it meets some acceptability criteria for packages in the distribution and fails others. So let's list a few (not a comprehensive list, I'm sure): 1. Can end users install and use the package properly? 2. Does the package have unresolved security issues which would prevent end users from using it safely? 3. Does the package somehow prevent progress or cause additional maintenance burden elsewhere in Fedora? 4. Can those packages be consumed by those who want to modify or rebuild them locally? I think the last two points are often missed in the discussion. If someone keeps having to maintain some old compatibility package because packages which use it can't be rebuilt for a new version, then that's a problem (but it's an issue that goes beyond FTBFS). Still, people who maintain such compatibility packages should still be able to drop them, under the doctrine that nobody can force them to maintain them. And then point #1 would fail, which we all agree should force the removal of a package. And if someone goes to check out a package from git or grabs an SRPM and finds that they can't actually build it, even after spending time setting up a proper build environment (which I know isn't terribly difficult, but still), then that's not great. I know I do this all the time, but maybe that's atypical. It still looks a bit sloppy in any case. I do think our duty to people who want to do that goes beyond simply complying with licenses and handing out source. So in summary, I guess I mostly support allowing packages which can't be rebuilt to stay in the distribution as long as they actually work and aren't causing maintenance burden elsewhere (which needs input from the release engineering folks and such as to whether these things waste their time). But I do think that everyone who advocates for that position needs to consider the negatives. These things do have nonzero impact even if it's not immediately obvious. And everyone needs to be aware that unbuildable packages are more prone to being removed pretty much as soon as they impede work elsewhere in the distribution. - 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
Re: Rolling out Phase I of rawhide package gating
> "NG" == Neal Gompa writes: NG> You just set localpkg_gpgcheck=1 in /etc/dnf/dnf.conf NG> That said, you probably don't want to do that, since most downloaded NG> packages aren't signed... I think that the ideal behavior would be to always check, but warn/prompt for unsigned packages or those with signature failures. Certainly it's better to verify as much as possible as often as possible. - 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
Re: dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot
>>>>> "MH" == Miro Hrončok writes: MH> https://src.fedoraproject.org/rpms/ima-evm-utils/c/5c9e2a91303d801bd828ad63bd8fe3ea2bab3e17?branch=master MH> This updated soname version from libimaevm.so.0 to libimaevm.so.1. Note that it also added a dependency on the tss2 package. That's small and doesn't have unexpected dependencies (just openssl) so it's not a huge deal, but... it's a sign of just how easy it is for these dependency chains to grow unchecked. Fortunately rpm-sign-libs isn't part of the buildroot. - J< MH> There was no announcement and no coordination. MH> -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok MH> ___ devel mailing list MH> -- devel@lists.fedoraproject.org To unsubscribe send an email to MH> devel-le...@lists.fedoraproject.org Fedora Code of Conduct: MH> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List MH> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines MH> List Archives: MH> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Jason L Tibbitts III - j...@tib.bs - 713/743-3486 - 660PGH System Manager: University of Houston Mathematics ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: s390x rawhide issues?
> "TC" == Tom Callaway writes: TC> One of my packages (alienarena) fails to build in rawhide on s390x TC> (and only that arch), but the build log shows it never even TC> starts. Does it fail repeatably? This error is known but as far as I know it's always been transient. It only seems to crop up when the s390x builders are very loaded. - 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
Re: Rolling out Phase I of rawhide package gating
> "FW" == Florian Weimer writes: FW> At one point, there was a verified hash chain from the https:// FW> metalink service, to the repository metadata, down to individual FW> packages. Any tampering was detected then. I understand that the metalink contains enough information to verify the returnes repomd.xml files, but I guess I don't really know if there's enough data to chase that down to the checksum of every file that's ever expected to be on a mirror. If it is, then great, though signatures still have value because there are other ways to get RPMs than letting dnf hit the mirror network. - 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
Re: Rolling out Phase I of rawhide package gating
> "KF" == Kevin Fenzi writes: KF> * If you use metalinks, rpm signatures are just gravy on top, in the KF> end you are still just trusing SSL CA's. Only if you trust every mirror to always serve authentic content. - 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
Re: Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module
> "SG" == Stephen Gallagher writes:
SG> Do any tools exist to simplify the conversion to MDB? Can this be
SG> automated?
I'd like to know this as well. It's always better to provide tools or
extremely clear and detailed instructions, because it's not safe to
assume that people know how to do this kind of thing even if they are
running an LDAP server.
I don't particularly have a problem with being forced to enable some
compatibility option after an OS upgrade in advance of functionality
actually being deprecated and not able to be used at all. The latter
gets you into a pretty bad "no way out" situation. ("You should have
read the release notes! Hope you have backups.") It's still better to
get this kind of thing documented as well as possible.
- 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
Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages
> "PM" == Panu Matilainen writes: PM> So a big +1 for sysusers in sub-packages + file trigger to handle PM> running systemd-sysusers. It solves more problems than the current PM> sysusers-proposal and in a far more elegant way at that. It's great that you agree. That leaves all of the details. What's the simplest way to accomplish this in a way that's easy for packagers to use? Is there any way for RPM to do this internally? I would really like to avoid this becoming a bunch of extra boilerplate in the relevant packages, or rather, for this conversion to result in a net reduction of boilerplate. Can the subpackage generation be reasonably hidden behind macros? Or is it possible to use a mechanism similar to the way debuginfo packages are generated to automatically define the subpackages when necessary? A related question is whether there are any cases where multiple packages (from different SRPMs) which don't depend on each other but all depend on the same user being created. Our current methods handle this well enough (all of the packages just create the user) but that probably won't work in any scheme using sysusers. The way to handle that seems relatively obvious (just have a separate SRPM that creates the user upon which the other packages can depend) but I don't know if it's a case that would need to be documented. - 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
Re: Guidelines for scriptlets modifying %config(noreplace) files
> "JN" == Jamie Nguyen writes: JN> I couldn't find clear packaging policy on this. The guidelines [0] JN> talk about %config(noreplace) vs %config, but /etc/named.conf is JN> installed as a "noreplace" file. I don't think there's a guideline about this. %config and %config(noreplace) are simply flags that tell RPM what to do when the packaged version of a file differs from what's on disk and has no bearing on scriptlets. And note that the only guideline which could be meaningful is "don't modify config files in scriptlets", because RPM will simply overwrite the file on disk with what is in the package (perhaps keeping a backup) if the file isn't marked %config(noreplace). The only applicable guidelines are the general ones from the updates policy: Updates within a single Fedora version must not break user systems, and disruptive updates must be restricted to updates between distro versions. But always note that sometimes not breaking systems requires modifying a configuration file. - 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
Re: findbugs-contrib building on i686 builders despite ExcludeArch
> "RF" == Richard Fearn writes: RF> According to RF> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures: >> If a Fedora package does not successfully compile, build or work on >> an architecture, then those architectures should be listed in the >> spec in ExcludeArch. Sure, but also just a small bit further down the document is https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unported_dependencies which tells you what to do if you have a noarch package that has dependencies which are not present on all architectures. This involves some rather odd magic in koji, and so what is in the guidelines is the best information that we've been able to extract from releng and the koji source code. Can you try the ExclusiveArch: method shown in the example, keeping in mind that you must explicitly list "noarch" at the end? Of course, a successful build isn't a guarantee because the build host you get may be completely random. What we'd like to know is if someone finds a failure using the recommended method (which would imply that we need to get something fixed or find another way to accomplish this). - 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
Re: [Fedora-packaging] Re: HEADS UP: Source File Verification
> "JO" == Joe Orton writes: JO> In the historic CVS-based build system which predated what we now JO> use, we could do GPG key verification at the time of downloading and JO> importing a new tarball. You're right; tmz dug up a copy of the old Makefile.common file: https://tmz.fedorapeople.org/tmp/Makefile.common I believe this is simply functionality that wasn't duplicated into fedpkg (or rpkg or whatever) when we stopped using Makefiles. It would certainly be useful to have it implemented and is worth someone opening a ticket. And in any case, it's still perfectly valid to check signatures at package %prep time. Imagine I'm building from an srpm that I've unpacked, or have grabbed the spec and run spectool -g. Why not have the specfile check the signatures at that point? Doing it there doesn't preclude doing it at some other step as well, and it's not as if this is all that computationally expensive these days. - 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
Re: are the ppc64le builders healthy?
> "TS" == Tom Stellard writes: TS> Are these updated builders only used for f30? It appears that there are 29 PPC64le builders configured currently: https://koji.fedoraproject.org/koji/hosts?start=80=enabled=name They don't all have the same "capacity" rating. TS> Because I'm still getting builders with 4 CPU/ 10GB RAM/2GB swap on TS> rawhide. I imagine that there is some randomness in play. The build you list ran on buildvm-ppc64le-21.ppc.fedoraproject.org which has a capacity rating of 2.0. Some of the builders have a rating of 4.0. (Which I guess doesn't correspond to the increase in core count, but I don't know how it's calculated.) - 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
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
> "FW" == Florian Weimer writes: FW> ELF multilib DSOs inside RPMs result in code deduplication, FW> affecting container image size. I think it's important to quantify this kind of thing. I think we can all agree that there is very little benefit to duplicating every single library, so extra space usage would come only from libraries which meet all of: * Compiling with AVX2 (or whatever) provides benefit * Special runtime detection code isn't included * Function multiversioning or the fancy target_clones attribute isn't used And by implementing the latter two, the set can shrink. So, really, how much space are we really talking about here? FW> Currently, there is no dynamic loader FW> support for selecting an AVX2 baseline. Fixing this requires FW> complete agreement among all involved parties what the actual CPU FW> requirements are (currently, not even glibc and GCC agree what FW> “haswell” means, the closest we have to an AVX2 baseline). But FW> similar fixes are required for any baseline update. I have a hard time believing that solving that would be somehow less preferable than either making Fedora unusable on a whole class of hardware or splitting off a completely new architecture. - 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
Re: are the ppc64le builders healthy?
> "KK" == Kaleb Keithley writes: KK> I built the latest ceph-14 (14.2.2) on rawhide successfully two days KK> ago. Two different builds on f30 built or are building fine on KK> x86_64, i686, and aarch64, but failed with different errors on KK> ppc64le at different places in the build. One looks like it ran out KK> of space in the file system. The other may have been OOM killed (?). There was just a bit of talk about this in IRC. The issue seems to be that the CPU count of the PPC64le builders was bumped from 4 to 12, but the amount of memory was unchanged at 10GB RAM/2GB swap. This could potentially cause resource exhaustion. Seems they've now been bumped to 22GB of RAM, which should help with OOM issues but probably not with disk space issues. - 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
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
> "JLT" == Jason L Tibbitts writes: JLT> And, let's see, I'd have to toss out five desktops (which isn't too JLT> bad, I guess) I was wrong. It would be 36 desktops. Being charitable requires me to assume this was proposed without adequate consideration of just how much hardware is involved 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
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
> "BC" == Ben Cotton writes: BC> * Other developers: Other developers may have to adjust test suites BC> which expect exact floating point results, and correct linking with BC> libatomic. They will also have to upgrade their x86-64 BC> machines to something that can execute AVX2 instructions. [...] BC> == Upgrade/compatibility impact == BC> Fedora installations on systems with CPUs which are not able to BC> execute AVX2 instructions will not be able to upgrade. Wow. I understand progress, but I have to say that it's not really cool to toss this bomb out there without some more detailed breakdown of the impact. For my part, I try to keep my equipment relatively up to date but I don't want to throw something away if it's still perfectly useful. And, let's see, I'd have to toss out five desktops (which isn't too bad, I guess) and probably forty perfectly functional servers, some of which aren't really even all that old. Heck, a dozen computational servers would be on the block. Even requiring avx would force me to toss a pretty big pile of stuff. Basically, this would force me to use something other than Fedora. I'd have no choice, since it wouldn't work. I don't want to be that guy with the 20mhz 386 that still wants others to make sure his stuff works, but still, this seems like it's going more than just a bit too far. - 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
Re: Vim and spec template
> "ZD" == Zdenek Dohnal writes: ZD> Converted to spaces now. Well I appreciate that, but my point is that it's really personal preference. ZD> It is designed for user to run rpmdev-bumpspec ZD> .spec, so the tool will supply correct format of changelog ZD> entry and increment the release. That seems to be rather abstruse. I mean, by default vim can already add a proper changelog entry directly (assuming you're not doing anything "interesting" with Version: and Release:). It doesn't seem logical to present an invalid specfile by default and then force someone to run an external tool to make it valid. If an external step is always required, wouldn't it make more sense to have that step be the initial copying of the user's preferred template into place? - 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
Re: Self Introduction: Dee'Kej (looking for sponsor)
Welcome back to Fedora. I've clicked the necessary sponsorship buttons. - 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
Re: Vim and spec template
> "ZD" == Zdenek Dohnal writes:
ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful
ZD> for Vim to do:
ZD> - when you open new file with .spec suffix, Vim will get you basic
ZD> spec file structure?
Personally I have always found that behavior annoying. If I open a new
file, I expect that the file would be empty. If I want a template, I
can copy one. Editing a new HTML file doesn't bring up a template for
HTML files, for example.
The spec template used isn't something I ever want anyway. It uses tabs
instead of spaces and uses them in a way that implies that indentation
is somehow required. And it includes a default release tag of
"0%{?dist}" which isn't permitted by the packaging guidelines.
(Releases start at one except when packaging prerelease software, and are
never exactly zero.)
Best to leave it to the packager to choose their own template, or to
allow somehow who wants templating behavior to configure templating in a
general way.
- 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
Re: Discussion around app retirements and categorizations by the CPE team
> "FW" == Florian Weimer writes: FW> I strongly doubt this will be true indefinitely. I expect things FW> will change pretty quickly once partners can access and file bugs in FW> the other bug tracker. This is interesting in light of the fact that one reason given for not enabling Pagure issues for src.fedoraproject.org was because there was benefit in keeping bugs in bugzilla alongside the RHEL bugs. - 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
Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
> "MH" == Miro Hrončok writes: MH> Are my assumptions correct? Yes, unless some major changes happened of which I was not aware, you cannot have any package name in EPEL7 (including a source package) which duplicates a package name in RHEL7 _on a particular architecture_. (There are limited-arch packages as described at https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages). In the cases you mention, I do believe you would need new source package repositories to avoid the conflict. Note that creating these does not require a package review as long as they are named properly. - J< ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages
> "VO" == Vít Ondruch writes: VO> I just wonder what is the point of: VO> https://github.com/systemd/systemd/blob/b0ca726/src/core/macros.systemd.in#L122 I guess it just saves packagers from having to call systemd-sysusers properly. You include the configuration file in the source package and that macro basically just expands it into the spec. VO> Why should the file be stored on the FS, when it is expanded during VO> build time (if I understand the scriptlet correctly). Well you could just bypass the macro and call systemd-sysusers yourself with the raw data as part of the command. I don't see anything that requires the file to exist in the filesystem at runtime. Personally I do think the subpackage method has merit, but hiding it behind macros (if we want that) would probably be complex. But debuginfo/debugsource packages are done that way so it should be possible. - 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
[EPEL-devel] Re: policycoreutils-python, audit-libs-python required for certbot for CentOS7 in need of updating
The issues you show don't appear to have anything to do with EPEL. The certbot package simply requires /usr/sbin/restorecon and /usr/sbin/semanage; yum isn't able to install those because it appears that there is some problem with the base (Centos) repositories. Please make sure that you are able to update your system and install policycoreutils-python and audit-libs-python on their own without errors. (Of course the issue might already have cleared itself up by the time you try.) If you are, then you should be able to install certbot. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: HEADS UP: DynamicBuildRequires are available
> "MC" == Michael Cronenworth writes: MC> Yes, something would have to be invented, and I guess that's why no MC> one replied. Well I replied, bit I'm behind on email so... MC> However, the data exists it is just not available in a standard, MC> parsable format. And that was really my question: what data exists and what format is it in? Honestly, I don't know; that's why I'm asking. There's a lot that could be done, and it doesn't have to be perfect. (Certainly it's better if it misses things because you can always just add them as regular BuildRequires:, but it's tougher to deal with things added erroneously.) This can easily be offloaded to a separate tool; RPM only cares about the output. - 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
Re: HEADS UP: DynamicBuildRequires are available
> "MC" == Michael Cronenworth writes: MC> Any long term plans to support C/C++ apps? Depends on what you mean by "support", really. Really there's just a new spec section that gets run and it just needs to echo a list of build dependencies. That's really all this does; the existing Rust support just hides the script within %cargo_generate_buildrequires. (Honestly I'm disappointed that the macro doesn't emit the %generate_buildrequires line as well; the pattern used by Rust currently builds in the assumption that the generator will be a shell script.) If there are more general methods for extracting build dependencies from various build systems which can be stuffed into macros, then by all means we should be adding them. MC> I know those are all over the map with regards to build tools, but MC> maybe cmake/meson could be supported? Well, how do those list build dependencies? How would you extract them and convert them to package names (or something else which is provided by the target packages)? - 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
Re: Langpacks and the packages needed to display/input a language
> "JP" == Jens-Ulrik Petersen writes: JP> Jason, can you explain in more details (bug report is also fine) how JP> exactly you are installing? I install a generic minimal system via kickstart (booted using the Server PXE images and using the Everything repositories) and then after the reboot, ansible runs (via ansible-pull) and installs whatever is needed for the type of system it's configured to be. JP> (Because for both Workstation/Silverblue, and Server I believe, we JP> install fonts and input methods for Korean (and other langs like JP> Japanese) by default anyway It would really surprise me if a kickstart file with nothing listed under %packages installed a Korean input method. JP> Perhaps you are installing the KDE Spin? which comes without much JP> i18n support preinstalled I believe. No spins are involved; just a plain kickstart file pointed at the full repository. JP> One can also just try `dnf -n install langpacks-ko` to check what JP> fonts (and input method) would be pulled in, and you are free to JP> remove langpacks-ko anyway. Yes, though it's simpler to me to just pull the dependencies out of the langpacks specfile as I'm doing now. Unfortunately that means I have to periodically recheck if, for example, the recommended font set for Gujarati happens to change in the future. It's not an undue burden but it was nice to be able to rely on installing @gujarati-support as was the case pre-F30. JP> I am wondering how you reached 3GB - the Noto CJK fonts we now ship JP> are not small on disk - that might be a part of the problem perhaps. Well, as I wrote previously, it's things like the Libreoffice help files and the Tesseract recognition data which get pulled in via Supplements:. These can be quite large. And some of the size difference is certainly unrelated to this issue. (I was installing a total of twelve langpacks but I should probably be installing even more.) - 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
Langpacks and the packages needed to display/input a language
I noticed that my F30 installs are coming out far larger than my F29 installs (by 3GB or so) and did some digging into why. With F30 we switched away from having groups named like "korean-support" that you could install to get input methods and fonts needed to display a language and instead we have metapackages named like "langpacks-ko". These metapackages have (generally) weak dependencies on the fonts and input methods as before. But other packages have reverse weak dependencies on the langpacks, which causes far more to get pulled in than was previously installed. For example, each libreoffice langpack has a "supplements" weak reverse dependency on the base "langpacks" metapackage. All of this seems fine, but my original goal was to be able to properly display, and perhaps input, various languages. But now I get translations and help files and such as well. Not just for libreoffice, but for eclipse, glibc, all of KDE as well. And I also get autocorrection rules, spelling dictionaries, hyphenation rules, and terreract OCR recognition data as well. Some of those aren't small, and the end result is that I need to bump up the size of / quite a bit. Note that turning off install_weak_deps is not an option because for most of the langpacks, _all_ of the langpack are weak. (Some do have hard font dependencies, and I'm not sure if this inconsistency is intentional.) So it seems we lost the simple "here are our suggested Korean fonts and an input method" and instead the only thing you can say is "I want everything possible to be available in Korean". Is there any way to improve the granularity here? Perhaps by having "light" and "heavy" langpacks, or splitting them by usage (translations versus simple display of text)? For now I guess I will simply extract the list of fonts and input methods I want from the langpack specfile and stop installing the actual langpack packages. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Fail2ban-users] Escalating ban times
> "AC" == Amir Caspi writes: AC> Escalating bantime is a feature in v0.11. Unfortunately not AC> available in v0.10 or earlier. I have some locally updated Fedora packages for Fedora which I use here; the feature works well. I use the following settings: bantime = 6m bantime.increment = true bantime.multipliers = 1 1 10 100 1000 1 10 findtime = 1h maxretry = 5 This is probably far more generous than most sites would want to use, but I have a few hundred SSH/SFTP users and some of them are very prone to mistyping their passwords. Basically, five failures gets you a six minute ban. Five more failures gets you... another six minute ban. Then it goes to 60 minutes and bumps by 10x for each ban after that. AC> I'm working to implement this looping jail on my CentOS 7 + fail2ban AC> 0.9.7 system and will post back here once I get a working setup. AC> (Note that CentOS package maintainers do have v0.10 available AC> through COPR: AC> https://bugzilla.redhat.com/show_bug.cgi?id=1588026#c6) I don't think it would be terribly difficult to build my packages for EPEL7, but I know it won't work as is because I use a particular more modern packaging feature. I will see about whether I can get that into EPEL proper and if the Fedora module system ends up being supported there, we could do a module with the current development version. Of course, things would be simplified significantly if there was an actual 0.11 release. - J< ___ Fail2ban-users mailing list Fail2ban-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fail2ban-users
Re: [Fail2ban-users] Fwd: Escalating ban times
> "M" == Mike writes: M> It would be nice to have some kind of shared attack list we could M> use, like DNSRBL. blocklist.de publishes several. fail2ban already has support for reporting your bans to them; see the documentation in the default jail.conf. You just need to get an API key from the blocklist.de site to set things up. That is one nice feature that denyhosts has; any host running it can communicate with a server and coordinate blocking with all other hosts who do the same. Originally that server was proprietary but since the API is public someone else ended up writing their own server. Sadly denyhosts went somewhat moribund and I lost track of it. Technically there probably isn't much from stopping fail2ban from using the same server software in some way if someone wanted to write the code. Though I'm not sure if fail2ban has any way to pull a set of addresses to block from an external source. - J< ___ Fail2ban-users mailing list Fail2ban-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fail2ban-users
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
> "PM" == Panu Matilainen writes: PM> Note that rpm doesn't support parallel zstd compression, and while PM> it does for xz, that's not even utilized in Fedora. Doing parallel xz compression has a surprising cost in compression ratio which gets worse as the thread count increases (because it just splits the input into independent blocks and compresses them separately). I did start on a feature to have it enabled but then abandoned that after realizing that it didn't really work as I'd hoped. That said, I do wonder how difficult it would be to do parallel zstd compression/decompression within RPM. If it were possible then that might help to obviate some of the downsides. PM> To me the sweet spot between compression efficiency and speed seems PM> closer to 10 than 19 - yes at a minor loss in space but huge speedup PM> in both compress and decompress times. One problem is that I don't think anyone wants to see any quantifiable regression in overall package size. Spins still struggle to fit within fixed media sizes as the package set grows ever larger. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal: Switch RPMs to zstd compression
> "BC" == Ben Cotton writes: BC> * The change requires setting a new compression algorithm in rpm BC> macros. Then a mass rebuild of all packages is required. Technically there is no harm if a mass rebuild is not done; there will simply be no benefit for packages which aren't rebuilt. Certainly the change should be made in advance of the mass rebuild, assuming we're going to do one. BC> * The recommended compression level is 19. The builds will take BC> longer, but the additional compression time is negligible in the BC> total build time and it pays off in better compression ratio than xz BC> lvl2 has. That seems different than other results I've seen. According to the wikipedia page (https://en.wikipedia.org/wiki/Zstandard) and the references therein, Ubuntu found that zstd level 19 was faster but with poorer compression when compared with xz level 2 (which is the same level that we use now). I'm not super familiar with zstd but the data presented also implies that multithreaded compression is available and at no loss to package size (unlike parallel xz). But looking at the RPM source, I don't see that the thread count can be specified for zstdio as it can be with xzio (as in setting %_binary_payload to "w2T16.xzdio"). If I'm understanding this correctly, it would be really nice of threaded zstd compression (and decompression) were possible and supported. Finally, note that as far as I can tell, this will render RHEL7 and older unable to decompress Fedora RPMs. RPM 4.14 seems to be required. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: miniz: a soname bump and a license change
> "PP" == Petr Pisar writes: PP> I'm going to rebase miniz in Rawhide from 1.15_r4 to PP> 2.1.0. Thanks for doing this; it allows me to unbundle miniz from prusa-slicer, at least in rawhide. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Fedora-legal-list] Licenses for AGG
Just wanted to double check the proper License: tag for the following license file. I believe it should be "Copyright only or BSD", but our page for Copyright only doesn't use exactly the same text and the plethora of BSD licenses is always fun. This software (and a bunch of other things) has been bundled into a different piece of software and has never been individually listed, I'm trying to fix that now. Note also that the software authors seem to have lost control of their domain so the URL is not valid. - J< The Anti-Grain Geometry Project A high quality rendering engine for C++ http://antigrain.com Anti-Grain Geometry has dual licensing model. The Modified BSD License was first added in version v2.4 just for convenience. It is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. It's well proven and recognizable. See http://www.fsf.org/licensing/licenses/index_html#ModifiedBSD for details. Note that the Modified BSD license DOES NOT restrict your rights if you choose the Anti-Grain Geometry Public License. Anti-Grain Geometry Public License Anti-Grain Geometry - Version 2.4 Copyright (C) 2002-2005 Maxim Shemanarev (McSeem) Permission to copy, use, modify, sell and distribute this software is granted provided this copyright notice appears in all copies. This software is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose. Modified BSD License Anti-Grain Geometry - Version 2.4 Copyright (C) 2002-2005 Maxim Shemanarev (McSeem) Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ___ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Re: if to fork Amanda
> "CH" == Chris Hassell writes: CH> Most build systems these days recommend building entirely as a CH> normal user (even Debian?) and the chown-and-other-ops are done with CH> careful setuid privileges given to the build system. CH> RPM and rpmbuild have been doing it that way for years. Technically RPM doesn't even do that; none of the package build process is ever done as root. The proper ownership of the files is stored as package metadata which gets applied when the package is installed. The ownership of the files at build time is immaterial. We (Fedora and by extension RHEL) used to patch things so that the Amanda makefile wouldn't try to call chown/chgrp. Now we pass BINARY_OWNER and SETUID_GROUP to the makefile with the current user info so that those calls do nothing (which saves us from having to maintain a patch). - J<
Re: Package with open and closed dual license
> "AT" == Andrew Toskin writes: AT> I'm looking specifically into VeraCrypt, the open-source fork from AT> TrueCrypt. Has the situation which has kept VeraCrypt out of Fedora previously been changed? See this, for example: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XF5GFHQ6FF7GTDDOYFFU4EZICOWMQW7Z/#TIRNFOQXXRM4IBC4OA3FJCDJIAFC2FGN - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: amanda client on leap 15 system, ie systemd
> "BC" == Cuttler, Brian R (HEALTH) writes: BC> Can anyone provide the files I need, give hints on what I'm doing BC> wrong or help in some other way? I don't believe Amanda upstream ships systemd unit files, so you would need to provide them yourself. Perhaps look at the files Fedora ships, which can be seen at https://src.fedoraproject.org/rpms/amanda/tree/master Look for the various service and socket files. amanda.socket and amanda@.service are the main ones, providing socket activation for the regular non-kerberized daemon over TCP. There are other unit files for using kerberos and running over UDP. You may of course need to edit the user, group and any paths as appropriate. - J<
Re: How to install a mountpoint directory from an rpm?
> "DH" == David Howells writes: DH> I'm not entirely clear how I should go about requesting FPC DH> approval. It says it is preferable that a ticket be filed in the DH> packaging committee pagure - do they mean to raise an issue, do you DH> know? Just file a ticket: https://pagure.io/packaging-committee/new_issue That's it, really. Personally I wouldn't be particularly happy with "/afs" if it were a new thing, but I'm not sure it's worth fighting with that much history. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposed Fedora packaging guideline: More Go packaging
I wish this message wasn't crossposted everywhere, but I don't want to lose any discussion by trimming the CC list. Sorry if replies generate bounces for some. > "nm" == nicolas mailhot writes: nm> And the forge macros are now available since nm> redhat-rpm-config-73-1.fc28 (I had missed the push due to upstream nm> renaming the file). Heartfelt thanks to Jason Tibbitts ! Please don't forget to let me know when it's time to start thinking about pushing this down to F27. And maybe F26. And as far as I can tell it should work with only minor modification in EPEL7 (via epel-rpm-macros). I don't know about EPEL6, but we really should look at it given some of the other discussions about specfile compatibility. Some packagers wouldn't ever use it if it doesn't work everywhere. Finally, we should also talk about whether there is any integration or automation possible between fedpkg and specfiles configured with these macros. - J< ___ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
Re: Proposed Fedora packaging guideline: More Go packaging
> "nm" == nicolas mailhot writes: nm> I don't know about EPEL6, but we use it as-is in EL7 and it works nm> just as well (except maybe for the %autosetup bits but IIRC that's nm> autosetup which is broken in EL7). I had ported autosetup to EPEL6 and then at the next release the macros showed up (without any discussion) in base RHEL6. So they should be there. I'm not entirely sure what's actually broken about %autosetup in EL7, though; I hadn't heard about breakage before this. epel-rpm-macros could conceivably carry %epel_autosetup or something which contains fixes. I mostly understand the internals of %autosetup so maybe there's something I can do. nm> Maybe it also works in EPEL 6 but I've never tried it. I guess it nm> depends mostly on the level of lua support in EL6 rpm and nm> rpm-related tools now the forge macro code is lua only. I think it would be worth a try. In my experience not all that much has changed in the Lua interfaces since RHEL6 and even RHEL5. (EL5 just didn't have sources and patches in the Lua namespace.) nm> For my part I doubt I'll ever use it in EL6 since I did it for Go nm> and the EL6 Go stack is really too old for a merge to be nm> interesting. Well, sure, Go on EL6 is probably out but these macros were at least presented as being far more general, and I'm sure there are plenty of EPEL6 packages which could benefit. Potential anything that packages a git snapshot of something. nm> I'm afraid my knowledge of recent fedpkg enhancements is too sparse nm> to be of any use there. Though I'm not opposed to the idea at all. It's just worth a brainstorm, I think. I can imagine that loads of people would love it if fedpkg could just auto-bump the bits necessary to update a package to today's git head or some specific commit or something like that. Before we didn't really have a good standard way to format a spec when you're using a checkout. Now Doesn't necessarily have to start in fedpkg, either. A standalone utility for doing a couple of things like that could be useful as a prototype. - J< ___ golang mailing list -- golang@lists.fedoraproject.org To unsubscribe send an email to golang-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
> "LP" == Lennart Poettering writes: LP> Yes it is. But so is rngd afaik? The software isn't exclusive to any particular architecture, though it may of course have different sources of entropy on different architectures. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Updating/rebuilding of coin-or packages
> "AT" == Antonio Trande writes: AT> Is it correct tagging an absolute path with %doc? Yes, it's fine; that just sets the flag that tells RPM "this file/directory contains documentation". That's not really any different than, say, using %config to set the "this is a configuration file" flag. It's when you use %doc on a relative path that the magic bit of copying things from %_builddir into %buildroot/%_docdir occurs. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Sphinx and xindy
> "JJ" == Jerry James writes:
JJ> Somebody out there has been involved with past attempts to build
JJ> xindy. Please, I would like to make progress on this so I can get
JJ> back to building the coq stack's new versions. Which package used
JJ> to contain xindy?
It is/was part of texlive-base. Look at line 20 of the texlive-base
spec:
# Not ppc64, not s390x, not aarch64 due to lack of clisp
# code SIGSEGV's on armv7hl
%global xindy_arches empty
JJ> How does one attempt to build it?
Just set that define appropriately. It was disabled in
ac0adc86c6ee1f2559e4313f210b828778388999 because I guess there's some
sort of circular build dependency and I guess it never got turned back
on again. Before that it was set to:
%global xindy_arches %{ix86} x86_64
And before acf14dee9c90d6f8b775adc0c1c5151d7df28642 that included arm:
%global xindy_arches %{arm} %{ix86} x86_64
To go back further you have to go back to the texlive package before
-base was split out.
My suggestion? Package it as an entirely separate package to avoid any
kind of circular build dependency. Call it xindy or texlive-xindy; I've
no preference.
- J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Can we maybe reduce the set of packages we install by default a bit?
> "LP" == Lennart Poettering writes: LP> That's not true anymore. There's a kernel compile time option now LP> for that in CONFIG_RANDOM_TRUST_CPU=y. And yes, the Fedora kernel LP> sets that since a while. Isn't this arch-dependent? config RANDOM_TRUST_CPU bool "Trust the CPU manufacturer to initialize Linux's CRNG" depends on X86 || S390 || PPC default n Not sure what happens on ARM but I think it would need to be considered. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Backporting fuse3 and fuse3-libs rpms to EPEL
> "DD" == David Dykstra writes: DD> Does this also imply a new fuse3 package in pagure & bodhi? Or DD> could it still be part of the fuse package but have a separate DD> fuse3.spec? It would have to be a separate package repository and receive separate updates. It is not possible for a source package in EPEL to have the same name as a source package in RHEL, even if the build products (binary RPMs) have different names. Note that a package review is not required to create a package repository named "fuse3" (or "fuse3.7" or whatever) when the "fuse" package repository already exists. See https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process When running fedpkg request-repo, use the --exception flag. - J< ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Package Naming Guildelines for compat-lua packages
> "RS" == Robert Scheck writes: RS> wouldn't it have been a clever alternative to use lua52-* rather a RS> quite unspecific "compat-lua-" to be really similar with your RS> python2/3 example? I made a similar suggestion in the packaging committee ticket. "compat-" is nonspecific and goes against the naming conventions already in the guidelines. While it's true that we have some compat-\* packages in Fedora, it shouldn't be perpetuated and certainly shouldn't be made the basis for a new Lua naming scheme. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Anitya not working again?
> "RM" == Robert-André Mauchin writes: RM> Since our float of Golang packages is severely out of date, I was RM> expecting a load of new messages from Bugzilla. I don't believe it notifies when the project is first added. It should notify when the project is next updated. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages
> "MH" == Miro Hrončok writes: MH> You realize that once it is maintained by the group, nobody else is MH> going to take it? When the stewardship SIG maintains a package, it should be for the sole purpose of keeping it around just long enough to avoid serious disruption that would be caused by that package being removed from the distribution. The SIG shouldn't be maintaining things indefinitely and should always give the expectation that the packages _will_ be retired (not just orphaned again) unless someone picks them up. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Fail2ban-users] Experimenting with bantime.increment
I've been doing a little experimentation with the support for successively increasing ban times in the current 0.11 codebase and had a few observations and a question. In an actionban, seems to always expand to the base bantime setting. But if I expand , I see something like: BanTicket: ip=36.67.106.106 time=1553724387.566927 bantime=3000 bancount=3 #attempts=4 matches=[... Interestingly, if bancount is 1, will show bantime=None. Is there any way to just get to show the actual time of the ban? I keep getting this error in the logs: 2019-03-27 17:16:43,472 fail2ban.observer [26876]: INFO[sshd] Found 190.248.138.82, bad - 2019-03-27 17:16:43, 1 # -> 2.0 2019-03-27 17:16:43,472 fail2ban.observer [26876]: ERROR '>=' not supported between instances of 'NoneType' and 'int' Not sure where it's coming from, though. I don't think I've ever seen an address banned for the minimum time; the observer seems to immediately bump the ban time up to the next increment. But that might be because by now this machine has already seen most addresses which are going to probe it. When I set bantime.rndtime, it appears that non-integer values get passed on to ipset which causes failures: exec: ipset add f2b-sshd 138.97.64.22 timeout 1874.0727681174424 -exist stderr: "ipset v6.38: Syntax error: '1874.0727681174424' is invalid as number" - J< ___ Fail2ban-users mailing list Fail2ban-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fail2ban-users
Re: Fork a 119MB pagure project to updating monitoring?
> "JC" == Jeremy Cline writes: JC> The effort would be a 1-2 line change in the-new-hotness, and JC> distributing the config to each package repository (some proven JC> packager could do this easily). Well that seems easy enough. We still need the repo for the bugzilla assignee override thing, but that's fine. One thing at a time. I can certainly drop commits into the repositories if that's what's needed. We would need to define the name and contents of the file, and the default state for when the file is not present (to perhaps avoid touching every repository). It might also be nice to know what on earth monitoring means for a module or a container, since the fedora-scm-requests has data for them but I don't understand what point it has. We would also need to change the admin tool which is generating these files. I think it would speed up its operation a good bit to not have to mess with this ever-growing repository, so that is a positive. (Especially since the tool does no local caching and so does a full clone each time it processes an SCM request). And fedpkg request-repo would need to drop the --monitor option as it would have no effect. So I guess it's more than just a couple of lines that need to change, but everything outside of the initial new-hotness change and the monitoring file commits could come later. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fork a 119MB pagure project to updating monitoring?
> "KF" == Kevin Fenzi writes: KF> Well, I find it unfortunate, does that count? :) It is unfortunate, but note that it's unfortunate simply because of our procedures. Certainly it would be nice if the functionality for making new branches and changing monitoring and some bugzilla settings were integrated directly into src.fp.o; I won't argue against that. However, that doesn't mean that changing those settings couldn't be accomplished via some means other than a PR. Possibilities I can think of include: * Doing this via tickets in a manner similar to how branches are requested. This would require teaching the ticket processing tools how to perform the operation, and writing some tool to submit the request. Kind of a lot of overhead for a rare operation. * Just storing this information in the package repository. I've never understood why the system can't just extract this information from git. I suspect there must be some reason related to security or resources consumption which prevents services from having a shallow git clone around from which to grab information like this, but I'm not sure. * Letting people just file a ticket and ask for what they want and having the admins would take care of it by editing the repo. This would require a separate ticket instance or more programming because the tools currently auto-close any ticket they don't understand. Anyway, everything is just a simple matter of programming. Does the effort required outweigh the annoyance of users having to occasionally (rarely) submit PRs against a repo that's of nontrivial size? I don't know. Are there any other benefits besides making things a little easier? Would having this somehow increase the uptake of monitoring? - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
> "AP" == Andreas Piesk writes: AP> Hello list, i'm trying to get cyrus-imapd 3.0.9 (testet 3.0.8 too) AP> running on latest arch linux. Here's the configure summary: AP> External dependencies: ldap: no openssl: yes zlib: yes pcre: yes AP> #6 0x7fc4aa385050 re_acquire_state_context (libc.so.6) AP> #7 0x7fc4aa3907d4 re_compile_internal (libc.so.6) AP> #8 0x7fc4aa391511 regcomp (libc.so.6) You have pcre enabled but you are calling glibc regex functions. You may wish to double check that you are linking properly. Fedora went through a similar issue a while back when --Wl,--as-needed was added to the default set of compiler flags, which caused subtle variations in the link order. The end result was that Fedora picked up a set of pcre patches similar to what some other distros have to avoid duplicating the glibc symbol names. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Sphinx and xindy
> "MH" == Miro Hrončok writes: MH> There should be a configuration option that disbales xindly. Does MH> the documentation build with it? Since xindy isn't really something that can be relied upon, is it possible (or reasonable) to do this globally in our sphinx packages? Even when it was enabled, it was architecture-limited which would force that limitation to propagate down to potentially anything that used sphinx. (xindy is written in LISP and builds with clisp. There's a certain irony in that Jerry is also a maintainer of clisp.) I do think that the disabling of xindy was supposed to be only temporary so I think it could be re-enabled, but having it off probably makes texlive maintenance easier. The proper solution, I guess, is to fix clisp to work on s390x and then fix whatever issues prevent xindy from being enabled all the time. I think it would help to remove it from texlive-base entirely and let it stand on its own. That way issues with it wouldn't prevent texlive-base from building. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> This doesn't sound convincing at all. I was not attempting to be convincing. ZJ> We *know* that people miss announcements all the time. Dropping ZJ> epochs would introduce yet another case where a "magical" step is ZJ> needed at a specific time. Personally I don't see it as being excessive. Plus... if you're running rawhide you do already have to deal with this, when it's done accidentally. I believe a proposal to do it in a coordinated fashion actually helps the situation. ZJ> We need to remember that dropping epochs also impacts any package ZJ> which uses Requires/BuildRequires/Recommends/Conflicts/Obsoletes on ZJ> the package dropping the epoch. Yes, that was covered in previous discussion. ZJ> All those will require periodic rebuilds. The problem is that those ZJ> things don't necessarily follow the cadence of Fedora releases. Yes, all of these are confounded by epochs currently. I believe that after the epochs have been removed, the situation is actually better than it is now. ZJ> The proposal to drop epochs sounds like a step that is problematic and ZJ> causes extra work now and ongoing for third-party packagers. Personally I just don't see the problem. I'm not saying that it has nonzero cost, but I don't see it as being major. ZJ> And the problem that it solves is niche. The cost of the solution ZJ> doesn't seem justified. I wonder how the existing RPM-based distros which allow epochs to go away between releases handle this. Aren't we the last one that doesn't? - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases
> "VO" == Vít Ondruch writes: VO> In this case, if DNF said something like "you have installed VO> foo-1:1.0, but there is available foo-0:2.0" it would give me VO> hint. From the start it would be annoying, but once we would reach VO> the point 4, I would, at least, know that I should do distrosync or VO> something. Under the proposal I put forward: 1. No releases except for rawhide would ever be affected by this, assuming that users upgrade using supported methods. 2. Rawhide users would need to do this exactly once per cycle, on an announced date. So you would know that you should do distrosync because that would be announced. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Allowing Epoch to be reset between releases
> "MH" == Miro Hrončok writes: MH> One thing to consider here is other packages that have Requires MH> etc. on something like "foo > 1:1.2", so if it is automated, this MH> part needs to be automated as well. Indeed. And of course this breaks any such dependency outside of Fedora as well. (Either in COPR repositories, RPMFusion, or local packages.) I should have mentioned this as a potential downside, since it was part of previous discussions. MH> If we do this, we might have a "flag day" but not automated for all MH> 756 packages, but opt in. Sure, maybe at first. Stage it in over a couple of releases if necessary, or having a couple of flag days. Though it's not quite as many if you exclude the Epoch: 0 ones. (Though I recall that there is some subtlety between Epoch: 0 and no epoch at all.) But that's an implementation detail; the fundamental question is whether there is any general support for dropping epochs, and more specifically if FESCo would accept it on principle. And I can understand why they may not, because while epochs are annoying, we've certainly been living with them for quite some time. MH> Aka we create a window on rawhide, and packagers would sign up for MH> this, we announce the window, let them do it, and we close the MH> window... ? The issue is that if a compose happens while the window is open, we have more than one rawhide update where distro-sync is needed. I think it's worth spending a bit of effort to minimize the issues for those running rawhide. MH> However I'm not sure it's worth the effort. Yes, that's basically the problem. History has shown that we can live with epochs. But even if it's a limited effort, it would be nice to give packagers who want to get rid of epochs a way to do so. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Allowing Epoch to be reset between releases (Was: On not bumping the epoch in ceph-14, f30 and f31/rawhide)
> "MH" == Miro Hrončok writes: MH> On 08. 03. 19 21:16, Neal Gompa wrote: >> I really wish we'd allow Epochs to be reset on distribution upgrades. >> With dnf distro-sync (which is used by system-upgrade) Epochs don't >> really matter and upgrades work as intended anyway... MH> Let's do a Fedora change? Coordinate with FPC? We (FPC) have talked about this before but I don't think it's really up to FPC. The change process isn't really the right way to do it, either, since this is really a policy revision. I just think FESCo needs to decide whether or not it would like to relax the policy, and if so, how. Here are the relevant points as I see them (unless I'm forgetting something): * dnf system-upgrade generally handles versions going backward without issue. The specific case of epoch being reset is not an issue. * dnf upgrade would not handle this, causing problems for those running rawhide or using unsupported methods of upgrading between releases. * Those running rawhide would have to run distro-sync in order to upgrade (which would of course reset any locally built updated packages and such). They would have to do this every time any installed package drops epoch. * Those using an unsupported method of upgrading would need to incorporate distro-sync. * Dropping epoch outside of rawhide would generally be bad. * Koji and the compose process do handle things "going backwards", as this has happened multiple times in the past without things dying. What's important there is which version was most recently tagged. * Bodhi shouldn't be involved here as this would be restricted to rawhide. Personally I'm in support of relaxing the restriction in some form, but I prefer a single "drop Epoch: day" where epochs in rawhide are _automatically_ removed and the packages rebuilt. This gives a single point in time where rawhide users need to do a distro-sync in order to properly track updates. Allowing epochs to be dropped without coordination seems to me to be a burden on rawhide users, but I don't think a single flag day would be problematic. I would expect the first flag day to be busy. I see 756 Epoch: tags currently, though 161 are set to 0 for whatever reason. Afterwards I would expect no more than a small number of packages per cycle to acquire Epoch: tags. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help remove scriptlets from the kernel?
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> kernel-install already calls depmod (from ZJ> /usr/lib/kernel/install.d/50-depmod.install). I'm not sure that's sufficient. Packages can install modules at any time and I believe depmod needs to be called when this happens. Thus the kernel packages need a file trigger on the /lib/modules/XXX directory that they own. Either that or something at a different level needs to be responsible for calling depmod for things installed under /lib/module. The depmod call in kernel-install is really somewhat redundant, though I don't think calling depmod is particularly slow so it probably doesn't much matter. - J< ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Help remove scriptlets from the kernel?
> "JLT" == Jason L Tibbitts writes: JLT> One fun thing is that I have no idea how file triggers interact JLT> with packages which are installed multiple times. I now know: it works the way I hope it does, so the scriptlets I suggested for auto-running depmod should work properly. As a bonus, I think it would slightly simplify third party kernel module packages. - J< ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Help remove scriptlets from the kernel?
> "LA" == Laura Abbott writes:
LA> The kernel uses a few scriptlets at the moment which will need to be
LA> cleaned up, most likely replaced with file triggers.
I have some experience converting things to file triggers had a quick
look. It seems we have the following:
The main kernel package messes with /etc/sysconfig/kernel to change
DEFAULTKERNEL in %post and has a %posttrans package to call
/sbin/kernel-install.
The devel packages do some magic with hardlink calls (set up by
%kernel_devel_post).
The modules and modules-extra packages have scriptlets to call depmod
(set up by %kernel_modules_post and %kernel_modules_extra_post).
These are all buried in multiple layers of macros, so getting rid of any
of this is probably a nice thing regardless of any other reasons
scriptlets are problematic.
One fun thing is that I have no idea how file triggers interact with
packages which are installed multiple times. If it works like I think
it does, each kernel package (or maybe kernel-core package) would have
something like:
%transfiletriggerin -n kernel-core -- /lib/modules/%{KVERREL}/
/sbin/depmod -a %{KVERREL}
%transfiletriggerpostun -n kernel-core -- /lib/modules/%{KVERREL}/
/sbin/depmod -a %{KVERREL}
The modules packages could then drop their scriptlets. These might need
the variant magic or whatnot.
I don't really know about the hardlink calls; it would be trivial for
something to call hardlink on /usr/src/kernels but optimizing that is
more difficult.
I would think that the bootloader package or systemd-udev would be the
proper place to put a trigger that calls kernel-install.
I don't really understand the modification of /etc/sysconfig/kernel.
In any case, it does seem that there's plenty of opportunity for useful
cleanup here.
- J<
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: Cyrus IMAP in the next Debian
> "PV" == Paul van der Vlis writes: PV> Somebody has packaged Cyrus version 3.08, but there are problems PV> with some of the Cassandane tests. It may be useful to see how Fedora handles Cassandane as part of its build process. I did a lot of work to get things functioning and get patches pushed back upstream to make it easier to run Cassandane as part of our package build process. A fair bit of work to get things working better on our less-common architectures is also in there. That said, we do still have to disable a few Cassandane tests for various reasons. The Fedora specfile (https://src.fedoraproject.org/rpms/cyrus-imapd/raw/master/f/cyrus-imapd.spec) has explanations and information about each disabled test. Search for "Run the Cassandane test suite". PV> I think it would be good if there would be more contact between the PV> Cyrus Debian developers and the Cyrus IMAP community. I have always find the Cyrus developers to be helpful. Nobody had to put me in contact with them; I just filed tickets and asked questions here and on IRC. - J< Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: F30 Self-Contained Change proposal: MongoDB Removal
> "JH" == John Harris writes: JH> For what reason is SSPL considered non-free? As I see, it's JH> essentially a GPL incompatible AGPL license. It's been pretty well covered throughout this whole debacle, but here's the most recent announcement from Fedora Legal: https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/IQIOBOGWJ247JGKX2WD6N27TZNZZNM6C/ This information is also included in the Licensing section of the Fedora wiki: https://fedoraproject.org/wiki/Licensing/SSPL - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
