Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Fri, Jul 07, 2023 at 16:15:14 -0500, Michael Catanzaro wrote: The local collection is a bit of a hole, but I like your suggestion to put a short time limit on that. Perhaps we can collect for something like one hour locally, then delete if the user has not consented to upload before then. Something like that. I think that would be an improvement. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 19:53:12 -0500, Michael Catanzaro wrote: Well this change proposal is for Fedora Workstation specifically. That's in the title. :) I would envision installing eos-event-recorder-daemon via a Recommends: from the gnome-control-center and gnome-initial-setup packages (and probably also by adding it to the workstation-product comps group), so if you don't have gnome-initial-setup or gnome-control-center installed, you wouldn't get in on upgrade. I'm not sure whether I want to amend this level of detail into the change proposal in case we might want to change the specifics of how it gets installed, but that's just to give you an idea of what I'm thinking currently. Certainly the metrics components should not be installed for non-GNOME users as part of this change proposal. Is there going to be a recommended way to not accidentally install this stuff? I'm guessing the least work (for Fedora) would be to black list the key packages in the repo files. Making available a package that conflicts with them could be done, but it could accidentally get removed during and --allowerasing change. But this might be easier when doing installs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 14:32:04 -0500, Michael Catanzaro wrote: On Thu, Jul 6 2023 at 08:19:07 PM +0200, Vitaly Zaitsev via devel wrote: All telemetry collection MUST be an opt-in feature (disabled by default). I'm strongly against enabling it by default. As explained in the proposal document, we know that opt-in metrics are not very useful because few users would opt in, and these users would not be representative of Fedora users as a whole. We are not interested in opt-in metrics. This strongly suggests that most people would prefer not to provide metrics. But what is hoped that they won't mind it enough to turn things off. I'm not a fan of doing this, but people can reasonably argue it is for the greater good or that most people are misevaluating the trade offs of their data being used to improve things for them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Thu, Jul 06, 2023 at 20:17:27 -0500, Michael Catanzaro wrote: Remember, for avoidance of doubt, we will NEVER enable telemetry upload without the user's consent, which is indicated by either (a) not flipping the telemetry switch in gnome-initial-setup to the off position, or (b) flipping the telemetry switch in gnome-control-center to the on position. (The telemetry might be enabled *locally only* for users who upgrade from previous versions of Fedora Workstation and who therefore have not seen the consent switch, but the data will never be uploaded to Fedora. And upgraded users will see the switch default to off rather than on, so it really will be opt-in for upgraded users.) Note that collecting the data by default increases the harm if someone accidentally enables telemetry and then notices the issue after data is reported. Is there going to be some time limit on the data that is stored and not uploaded yet? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads up - squashfs-tools prelease in rawhide
On Thu, Feb 23, 2023 at 10:36:17 -0600, Bruno Wolff III wrote: Phillip is really close to releasing 4.6 and I want to get some testing in rawhide before that happens. If we do find a problem, it will be easier on him if we find it before the release. I ran a test script that tests the features we mostly use, so I'm not expecting any problems. 4.6 is out now and has been built for rawhide. Since we are past beta already, I'm not going to put it into other Fedora releases until after F38 has been released. ___ 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
Heads up - squashfs-tools prelease in rawhide
Phillip is really close to releasing 4.6 and I want to get some testing in rawhide before that happens. If we do find a problem, it will be easier on him if we find it before the release. I ran a test script that tests the features we mostly use, so I'm not expecting any problems. ___ 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: Proposal: dnf should offer to update all of the dependencies of any package installed or updated
On Fri, Jan 27, 2023 at 18:43:56 -0800, Gordon Messmer wrote: Second, I'd like to suggest that in the future, at least in Fedora, for any "install" or "update" operation that dnf performs, dnf's default behavior should be checking all of the direct and indirect dependencies of the packages being installed (or updated) and updating any dependencies which have updates available. Does anyone else have any opinions on the subject? Should I simply file a bug against dnf proposing this behavior? If there is a problem with not uodating dependencies when you do an install or an update on selected packages, the packages dependencies are not properly defined. I think the case where you don't want to keep the full system up to date, but a selective update or install causes problems as well is pretty rare. I think it might be reasonable to have an option that requests doing a recursive update. I would consider this to be a low priority feature request that has to compete with all of the other work being done on dnf, rather than a bug. I don't work on dnf and the people that do might feel differently. ___ 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: Take the Fedora Annual Contributor Survey 2022
On Thu, Jun 02, 2022 at 12:33:55 +0200, Aleksandra Fedorova wrote: Hello, everyone, Please participate in the Fedora Annual Contributor Survey 2022! * https://fedoraproject.limequery.com/2022 The survey is anonymous, it has 44 questions targeting Fedora contributors of all kinds and asks about your default choices of applications and services. It would be nice if it worked without javascript. ___ 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: Today's rawhide compose is taking a long time to fully sync
On Fri, Apr 01, 2022 at 10:06:35 -0700, Kevin Fenzi wrote: Short version: We updated to koji 1.28.0 yesterday. It has a bug in it where it writes out signed rpms as mode 0600, which prevents our sync process from syncing those things. The compose finished and tried to sync, but of course failed on all those newly built packages. :( I am working now to fix the affected signed rpms, and then we are going to run new composes. Thanks for the explanation and work to get things working again. ___ 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
Today's rawhide compose is taking a long time to fully sync
Today's rawhide compose is taking a long time to sync on the primary mirrors. It has been a mix of the update from the 28th and the one for today for at least a couple hours. That is much longer than normal. Did something fail part way through? ___ 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: Package downgrades on upgrade from F35 to F36 + categorized list
On Thu, Mar 24, 2022 at 21:06:44 +0100, Fabio Valentini wrote: On Thu, Mar 24, 2022 at 8:57 PM Bruno Wolff III wrote: I don't really understand what you're saying here. Unless your update is blocked by something else that is not "stable" yet *and* you don't (or cannot) use a buildroot override, there is *zero* reason not to submit updates during a freeze. They will be pushed to "testing" as usual, they will just not be pushed to "stable" until ~a day after the F36 beta (or final) is GO. I didn't want the updates to go to f34 or f35 before they went to f36 (or at least close to when they would be in updates for f36). I could have submitted it for f36 and not f34 or f35. ___ 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: Package downgrades on upgrade from F35 to F36 + categorized list
On Thu, Mar 24, 2022 at 10:58:17 -0700, Adam Williamson wrote: On Thu, 2022-03-24 at 18:52 +0100, Ralf Corsépius wrote: > If it was the latter, I couldn't find it in your message. Sorry. It's actually quite simple: There are dozens if not hundreds of unpushed updates pending due to the release freeze, which will be released at the very moment the freeze will be lifted. This is a statement of a well-known fact, which you have stated before. It doesn't seem to have any purpose. I will note, that I recognized this issue and am delaying doing some updates for f34 and f35 until after the f36 beta freeze is lifted. These aren't urgent updates so it is not a big deal. If it is desired not to have a lot of downgrades for beta or final it might be useful to publicise to packagers that for low priority updates it is preferred that they delay updates during beta and/or final freezes. ___ 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: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Wed, Mar 09, 2022 at 19:58:30 -, Leigh Scott wrote: On Wed, Mar 09, 2022 at 09:06:01 -0600, Chris Adams That is a very poor excuse for a slip, why would any one need it? That is specified in the release criteria. I believe the rational is covered there if you are really interested. In this case it would have had people doing an upgrade to test things, downgrading firefox, and that breaks profiles. So shipping an old firefox wouldn't have been a good idea. I think firefox is the only browser that comes with Workstation, so not including it was going to be undesireable. Why not add an ExcludeArch to fix? As I stated in my followup things were a bit more complicated as the main i686 issue was in gcc. Firefox needed a new gcc to be built with a fix, so excludearch for firefox wouldn't have helped. Using excludearch for gcc would have had reprocussions and I don't see how that would have been practical. ___ 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: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Wed, Mar 09, 2022 at 12:23:41 -0600, Bruno Wolff III wrote: On Wed, Mar 09, 2022 at 09:06:01 -0600, The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches. It is actually more complicated than I remembered. Firefox needed a gcc fix, but gcc building is blocked on an i686 issue. And the delay in getting that fix combined with the long time for doing a gcc build is seemingly going to result in a slip because a firefox downgrade (from the f35 version) would cause problems for some testers. ___ 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: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Wed, Mar 09, 2022 at 09:06:01 -0600, Chris Adams wrote: So I guess this is the part I don't really understand (and I guess why I don't see this proposal as a "win") - how is i686 painful to package maintainers for non-delivered packages? Maybe I'm just missing something, but what causes issues? The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches. ___ 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: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, Mar 07, 2022 at 15:04:21 -0500, Robbie Harwood wrote: Fabio Valentini writes: For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit. Would it be possible to have package foo's x86_64 build produce a foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an important use case, but keeping the whole arch machinery around for it seems like overkill - just having the packages that are relevant for it build 32-bit variants as a special case seems a lot cleaner. If cross building is used, that might cut down the buildrequires issue. You might eventually be able to just have this for packages required by wine and steam for i686. ___ 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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
On Wed, Feb 09, 2022 at 17:44:35 +, "Daniel P. Berrangé" wrote: Using API tokens over username/password is a good thing from a security POV, but as you say, the process of creating the token and getting it over to the client is horribly user unfriendly. That depends on ypur threat model. If you aren't using third party apps, this doesn't provide much security benefit. For Fedora people are generally going to be using apps provided by Fedora, so not trusting them with your Fedora credentials seems pointless. Though that is from the perspective of someone who treats Fedora and Red Hat as being in the same security domain. That might not be the model that Red Hat employees take. For them Fedora might be considered a third party. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: PostgreSQL 14 (Self-Contained Change proposal)
It looks like qt3, kdb and pgadmin3 still need to be rebuilt after the recent build of postgresql 14.1 in rawhide, because they depend on libpq.so.private13-5()(64bit). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Thu, Dec 30, 2021 at 12:19:14 +0100, Vitaly Zaitsev via devel wrote: On 30/12/2021 09:21, Chris Murphy wrote: CPU is proprietary, the firmware is proprietary. Guess we can't trust our computers? RISC-V. RISC-V isn't the answer. It is an ISA (with varients), not a computer. A RISC-V based computer has the same issues as other computers. Computers can be trusted to some extent, because useful, hard to detect misexecution is hard outside of some special instructions (such as random number generators). You can purchase computers today without proprietary firmware in key areas. (Essentially you can limit proprietary firmware to denial of service attacks.) Look into Raptor Computering Services Blackbird or Talos 2 power 9 based systems if you are interested. These are not cheap consumer machines; so they aren't for everyone. You can go lower down the stack and use free computer implementations. For example Microwatt is a power ISA implementation for FPGAs. You still have to worry about trusting FPGAs, but you can do more about that than you can with proprietary computers. Bunny Huang has written about trusting FPGAs as part of his precursor project. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Tue, Dec 28, 2021 at 14:51:35 +0100, Kevin Kofler via devel wrote: Can we trust the security code submitted by a Huawei employee to not contain hidden government-developed backdoors? (Basically the same question as for the existing NSA SELinux code…) I think that same question could be asked of all of us. I don't see that his contributions need extra scrutiny because he claims to work for Huawei. Though they might because they are security related. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Tue, Dec 28, 2021 at 14:45:59 +0100, Kevin Kofler via devel wrote: But there is the inherent assumption there that the set of software released by Fedora is identical to the set of software the user trusts. In practice, those sets will, sure, be overlapping (non-disjoint), but still distinct (non-identical). And I think they will differ sufficiently for it to be an issue. I can tell you, I trust icecat a lot more than I trust firefox. But even that isn't black and white. This proposal divides software into good and not good categories. That really doesn't match how I use software. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: DIGLIM (System-Wide Change proposal)
On Thu, Dec 16, 2021 at 17:27:29 -0500, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/DIGLIM More specifically, it will make a system running Fedora attestable without the need of using dedicated remote attestation protocols. In fact, the assertion that a system is running a specific set of software will be implicitly implied by the ability of that system to correctly respond to the other peer in the TLS handshake protocol. This could be achieved with widely available software such as the Apache web server, the tpm2 openssl engine and a browser. Also [//keylime.dev/ Keylime], a Red Hat-based solution for remote attestation, could make use of the proposed scheme. This doesn't seem very useful for the vast majority of people. The software set is going to change pretty often via updates and it will vary from user to user based on what they have installed. It might make sense in a case where you have a lot of machines you want to ensure are set up identically. I mostly interact with my machines remotely via ssh, not tls. ssh provides a way to attest I am connecting to the expected machine already. Tampering is prevented by encrypting the disk. It will also make Fedora able to detect tampering of its components at a more privileged level, the kernel, without the interference of user space programs. Once tampering has been detected, the actions of the altered component are prevented before that component gets the chance to perform any action. Fedora could be configured to also allow the usage of components provided by the user, if he wishes to do so (DIGLIM has a tool to build custom digest lists). Does this work with code that is run by an interpreter? If not, it doesn't seem to make sense to not check interpreted code, while making users jump through hoops to run compiled code. Having to sign code to run it is going to be way too much work for many Fedora users. I think doing test builds of packages would be a nightmare since the "make" (or similar system) for packages is not going to be setup to stop part way through and sign code. As far as I can tell, the threat model this is trying to protect against is not one that I care about. Threats that I think would find worth addressing, if it can be done practically, are evil maid attacks (both capturing the disk encryption password during boot and my password when logging in locally) and being able to easily run software that is limited to just some of my rights, instead of all of them. SELinux can help with the latter, but it isn't easy to set up custom sandboxes for software. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: PostgreSQL 14 (Self-Contained Change proposal)
On Thu, Nov 25, 2021 at 16:52:59 -0500, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PostgreSQL_14 == Summary == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 13 to version 14 in the non-modular (main) builds. == Feedback == I'm all for it. I have been running PGDG Red Hat binaries for 14 for about 2 months on a RHEL machine at work and have not seen any issues. When it gets into Rawhide, I'll be testing it on a work desktop where I use Postgres to analyze data for some work tasks. There isn't any feature in this release that I am personally really looking forward to, but there are some performance related ones that could provide some immediate benefit. I do like being on the latest release in case something new I want to do would benefit from it. ___ 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: update F34 - f35 postgresql module issue
On Sat, Oct 23, 2021 at 23:40:25 +0200, Peter Boy wrote: Fedora 35 comes obviously without Postgres module 9.6. Unfortunately, the release change set doesn’t mention that. We need a clear indication and warning of this. That might be because 9.6 gets its last update in about two weeks. This means that it will be unsupported for most of the lifetime of F35. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Retired Packages (Self-Contained Change proposal)
On Thu, Oct 07, 2021 at 18:23:00 +0200, Miro Hrončok wrote: On 07. 10. 21 17:45, Ben Cotton wrote: * We suggest users to remove packages that are no longer maintained and may contain security vulnerabilities. This makes perfect sense. * We make sure that archaic packages do not break upgrade between two versions of Fedora. When are you supposed to run remove-retired-packages? If you run remove-retired-packages after the upgrade, you already managed to upgrade and nothing is broken, no? If the upgrade was done with distro-sync with deletes allowed, then the upgrade would have removed blocking packages. If just upgrade was used then the retired packages might have blocked upgrading some packages. Instead of checking retired packages, people might be better off running dnf list --extras to get a list of installed packages that aren't in any current repo they are using. ___ 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: Orphaned packages looking for new maintainers
On Mon, Sep 20, 2021 at 18:16:17 +0200, Jonathan Schleifer wrote: Am 20.09.21 um 13:31 schrieb Miro Hrončok: 0ad ignatenkobrain, orphan, pwalter 1 weeks ago I would be interested in becoming a (co)maintainer for this, but would need sponsorship. I think I have something working now, and took ownership. I was able to build it in a scratch build and it seemed to work in very limited testing. I have started builds for rawhide and f35. f33 and f34 will need to stay separate unless a conditional is added around the fix for python3.10. (I think that will be easy.) I'd prefer not to be the primary person responsible for this package, as there are probably others that are in contact with the community and will catch issues I'd miss. I just cared enough to research how to fix the spidermonkey/python3.10 issue. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Tue, Sep 21, 2021 at 17:44:07 -0500, Bruno Wolff III wrote: So it looks like, one way or another the mozjs78 stuff will need to get patched after the source gets extracted in the build step. I found the reference to how to patch mozjs78 in 0ad. You need to have your patch file drop off a patch file in libraries/source/spidermonkey and patch libraries/source/spidermonkey/patch.sh to apply your patch during the build. There are a number of ways that python is invoked and in a fair number of places. So changing them all to use python3.9 is going to be a pain. And I still don't know if that will really fix things since the build requires python-devel and python-setuptools, though a comment suggests that it should be possible to get things to work without them. python2 is also required, but I think that was fixed and the buildrequires was left by mistake. It may make more sense to use the fixes from the system mozjs78 for python3.10. But since the versions of mozjs are different, that path will need extra work as well. ___ 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: Orphaned packages looking for new maintainers
On Tue, Sep 21, 2021 at 16:06:24 -0500, Bruno Wolff III wrote: I thought of that. I tried some naive ways to do that without success. I'm not sure if any extra python packages are needed. Probably not, but if so it won't work since those will be for 3.10. There doesn't seem to be a standard way to have an unversioned python call run 3.9. It might be worth trying a build requires for python3.9 and creating a symlink from /usr/bin/python to it during set up. I'll try that in a scratch build tonight and see if that works. This didn't work. The build process can't create /usr/bin/python. Also some other python packages are used in tests in the mozjs78 part of the build. I don't know if those will automatically will get skipped if the required packages aren't installed or if they will be manually need to be disabled. So it looks like, one way or another the mozjs78 stuff will need to get patched after the source gets extracted in the build step. ___ 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: Orphaned packages looking for new maintainers
On Tue, Sep 21, 2021 at 23:03:12 +0200, Miro Hrončok wrote: On 21. 09. 21 19:19, Bruno Wolff III wrote: If there is no Python version runtime dependency there, you could temporaily use the python3.9 package to build the bundled mozjs78. I thought of that. I tried some naive ways to do that without success. I'm not sure if any extra python packages are needed. Probably not, but if so it won't work since those will be for 3.10. There doesn't seem to be a standard way to have an unversioned python call run 3.9. It might be worth trying a build requires for python3.9 and creating a symlink from /usr/bin/python to it during set up. I'll try that in a scratch build tonight and see if that works. Another approach would be to find references to /usr/bin/python in the mozjs build and change them to run 3.9. This is still tricky since you can't use the normal patch process as the mozjs source is not unpacked until in the build part of the process. ___ 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: Orphaned packages looking for new maintainers
On Mon, Sep 20, 2021 at 18:16:17 +0200, Jonathan Schleifer wrote: Am 20.09.21 um 13:31 schrieb Miro Hrončok: 0ad ignatenkobrain, orphan, pwalter 1 weeks ago I would be interested in becoming a (co)maintainer for this, but would need sponsorship. The main issue now is figuring out how to get the bundled mozjs78 to build under python3.10. You can get examples from the system mozjs78 which was fixed, but isn't the same minor version. Also patching the bundled copy is tricky since it needs to get done after patches are normally applied. I found some comments about that in an upstream bug where Timothy Pearson was trying to get it to build on ppc64le a few years ago. ___ 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: Announcing fmt library soversion bump
On Tue, Jul 06, 2021 at 18:13:45 +0200, Miro Hrončok wrote: On 06. 07. 21 17:13, Zbigniew Jędrzejewski-Szmek wrote: This is Python 3.10 related. https://docs.python.org/3.10/whatsnew/3.10.html#removed "Remove deprecated aliases to Collections Abstract Base Classes from the collections module." E.g. use collections.abc.Sequence instead of collections.Sequence. collections.Sequence was deprecated from Python 3.7. Well the fix looks simple enough but it's the bundled spidermonkey that needs to be patched and it's gziped inside of the 0ad archive with a separate patching mechanism. BLEH. I started looking into this yesterday… The attached patch moves past the import errors, and cuts the warning noise to a manageable level. Maybe it'll be useful as a start for someone. The build still fails with: AttributeError: module 'sysconfig' has no attribute '_get_default_scheme'. Did you mean: 'get_default_scheme'? That is still Python 3.10 relevant. The "private" sysconfig._get_default_scheme function has been made public (and hence has a new name, without the leading underscore). Since it was private, this is not considered as a breaking change. No code outside of Python standard library should have used it 路 The system mozjs78 got fixed to build with python 3.10 and the changes needed for that might be helpful even though 0ad uses a different release of mozjs78 than the one used for system. P.S. 0ad just got orphaned because of this issue still being unfixed. ___ 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: Any recent changes to the arm builders?
On Sat, Aug 14, 2021 at 09:19:55 -0700, Kevin Fenzi wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1920183 basically OOM kills kojid, which restarts kojid, which restarts the build, which kills kojid, etc... I've tried all kinds of things here, but haven't been able to find any way to make it work. Arm folks can't duplicate it on non koji builders. I suspect the number of people using lpae on 32bit arm is... low. We could just go back to non lpae, but that breaks building some other packages (llvm fails to build for example). If you disabled over commit, would that end up having better failures when there wasn't enough memory? ___ 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: IceCat build error: no matching function for call to ‘ArrayEnd(uint8_t [])’
On Wed, Aug 04, 2021 at 05:08:40 -0500, Bruno Wolff III wrote: On Tue, Aug 03, 2021 at 12:51:41 +0200, "Antonio T. sagitter" wrote: Hi all. I need help for failed builds of IceCat bacause of this error (in x86_64 and i386 architectures only): Thanks for working on that. The last good icecat in rawhide doesn't work with the latest glibc. Because I use icecat a lot I'm holding back glibc and a bunch of packages that depend on the newer glibc. icecat-78.13.0-0.1.rh1.fc35.x86_64 finished building successfully this morning but it still is broken (tabs crash) with glibc 2.34-1.fc35, but works with glibc 2.33.9000-43.fc35. ___ 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: IceCat build error: no matching function for call to ‘ArrayEnd(uint8_t [])’
On Tue, Aug 03, 2021 at 12:51:41 +0200, "Antonio T. sagitter" wrote: Hi all. I need help for failed builds of IceCat bacause of this error (in x86_64 and i386 architectures only): Thanks for working on that. The last good icecat in rawhide doesn't work with the latest glibc. Because I use icecat a lot I'm holding back glibc and a bunch of packages that depend on the newer glibc. If others want to do this until it gets fixed, you can add the repo: baseurl=https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20210724.n.0/compose/Everything/x86_64/os/ Then after upgrading rawhide, run dnf downgrade glibc. This will downgrade a lot of packages, but icecat will work. Eventually the 20210724.n.0 repo will be deleted, but hopefully things will be back to normal before then. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: squashfs-tools being updated in rawhide
The upstream fix looks good and squashfs-tools-4.5-2 has the patch and is in today's rawhide compose. There will be a minor point release for squashfs-tools in the near future with the fix. But phillip is waiting a short bit to see if any other problems get discovered before making a new release. There was one minor security issue noted in the release notes, so I will be looking at getting this into f34 and f35 eventually. The issue is with unsquashing untrusted squashfs images potentially writing files in unexpected locations, so I think we can wait a short bit to see if there are issues with the new version before getting it into f34 and f33. ___ 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: squashfs-tools being updated in rawhide
On Fri, Jul 23, 2021 at 02:20:50 -0500, Bruno Wolff III wrote: Phillip released 4.5 which has some new functionallity, some clean up and some bug fixes. It looks like he worked pretty hard on it for I had a successfull build after tonight's compose started, so the earliest it will show up in rawhide is Saturday morning (in the US), assuming no one off rawhide composes. The CI script failed. I'm not sure if this will block it from rawhide composes or not. So it might be a bit longer before it shows up. The issue appears to be all zero fragments being truncated. So it probably won't actually break test composes. ___ 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
squashfs-tools being updated in rawhide
Phillip released 4.5 which has some new functionallity, some clean up and some bug fixes. It looks like he worked pretty hard on it for about the last 6 months. I don't think that the new functionallity will break any of our normal stuff, but if something breaks that uses it, that would be a good possibility to check out. The man pages are currently still out of date, but you can use the program's help to get up to date documentation. I had a successfull build after tonight's compose started, so the earliest it will show up in rawhide is Saturday morning (in the US), assuming no one off rawhide composes. You can currently get a summary of changes at: https://github.com/plougher/squashfs-tools/blob/master/CHANGES ___ 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: The Javapocalypse is Monday
I knew that a bunch of java stuff was going away, but I am not sure what the impact of that is going to be. Is there a feature page or similar that summarizes what the effect we be? I have one package that produces a java program using ant that I like to be able to keep building somehow. There is also an OCaml package I help maintain, that is used in an old game that I doubt gets much use these days and I wouldn't be too sad if that went away. Is there a recommendation to move to maven? Is there anything like the old gcc based java compiler that could be used? Is there still going to be a java runtime? I spend a lot of time using the former as a passtime game and would miss it if it wasn't in Fedora any more. ___ 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: Take the new Annual Fedora Contributor Survey
On Thu, Jun 03, 2021 at 21:34:22 +0200, Miro Hrončok wrote: On 03. 06. 21 20:29, Matthew Miller wrote: On Thu, Jun 03, 2021 at 01:00:23PM -0500, Bruno Wolff III wrote: Given that badges are being handed out, it is clear the survey is not anonymous. When the survey is complete, you get a non-personalized link which will let you get the badge. It might be theoretically possible to correlate this by IP address from logs, but I don't think any one actually has access to both the LimeSurvey web logs and ours. Also by time. If you are concerned about privacy, save the link and use it to claim the badge later (after some randomized/secret amount of time). My issue was more with the claim about being anonymous, rather than how to try to advise people on how to try to respond while making it hard to be identified. I doubt that many people here care whether their replies are anonymous or not for this survey. I think people doing surveys throw that text in by rote because they think it helps response rate. When I see survey requests using that text my first thought is that the person requesting the participation is either incompetent or intentionally lying and I probably shouldn't respond to the request. I think people requesting surveys should either make no privacy related comment or one that indicates what their practice will be. Instead of saying the responses are anonymous, they might say they are confidential or that they will be published without identity being explicitly included or whatever the practice is. While many people on this list will understand that surveys are not really anonymous unless the responses are simple and special care is taken in how you interact with the survey, that isn't true in general. And I think survey requesters should be held to a higher bar in properly informing people about the privacy aspects of their surveys. ___ 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: Take the new Annual Fedora Contributor Survey
On Wed, Jun 02, 2021 at 18:14:50 +0200, Aleksandra Fedorova wrote: Hello, everyone, Please participate in the Annual Fedora Contributor Survey 2021! * https://fedoraproject.limequery.com/2021 The survey is anonymous, it has 44 questions and It is targeting Fedora contributors of all kinds and asks about your default choices of applications and services. Given that badges are being handed out, it is clear the survey is not anonymous. People that do surveys love to claim they are anonymous when they aren't, to increase the response. When you are collecting detailed information from someone it is hard to prevent the person from being identified by that data even if you don't collect their identity directly. If you have people authenticate or send out links to the survey that are customised per person (perhaps to prevent someone from filling out the survey repeatedly) then the survey is clearly not anonymous. Even if you don't do that, web server logs can often reveal who the responders are. In my opinion it is best to state what you are actually doing with regards to privacy rather than simplify it and make a statement that is clearly false. In this cases you might have said that you were not going to store the identity along side the responses. Even claiming you wouldn't try to find out who the responders were probably wouldn't have been true without caveats. (For example if someone used the survey to make a serious sounding death threat, you very likely would make some attempt to find out who made it.) ___ 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: mesa 21.0.0-rc3 making rawhide really unstable?
On Wed, Feb 17, 2021 at 07:35:20 -0600, Bruno Wolff III wrote: Is their going to be an updated build soon? I tried to build rc4 (which looks to be what was released), but I need to figure out how to get both x86_64 and i686 rpms built when using fedpkg local. If there isn't going to be an update for a while, I'll spend time figuring that out. I was able to use scratch-build on the srpm created by fedpkg local in order to get i686 rpms for testing. However, I had the same problem, so an updated build is unlikely to fix whatever my problem is. ___ 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: mesa 21.0.0-rc3 making rawhide really unstable?
On Fri, Feb 05, 2021 at 16:17:12 +1000, David Airlie wrote: Has anyone got a backtrace they could put in a bug? I'm not seeing a crash with X.org here in my test VMs. I have only had problems with wine so far. But I use xfce and lightdm and they seem to work. I filed bug 1924933 for the wine issue, but the error messages didn't look like they would help much. Is their going to be an updated build soon? I tried to build rc4 (which looks to be what was released), but I need to figure out how to get both x86_64 and i686 rpms built when using fedpkg local. If there isn't going to be an update for a while, I'll spend time figuring that out. When I want to use wine, I just downgrade to mesa 20 and things work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: What to do with - in release tag?
On Wed, Nov 11, 2020 at 16:53:26 +0100,
Vitaly Zaitsev via devel wrote:
On 11.11.2020 16:09, Bruno Wolff III wrote:
If not, should I replace the - with a . in the version or should I
move git.1 into the release. This is the first tag using this naming
pattern, so I don't know the next tag will sort properly if I keep
it in the version.
Version: 4.4
Release 1.git1%{?dist}
There already was a 4.4 release and the package is currently a post
release snapshot and has a release of 2.20200513gitc570c61%{dist}.
So in this case I think I want 3.git1%{?dist} to follow your suggestion?
Thanks.
___
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
What to do with - in release tag?
I looked at https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/ and didn't see dashes specifically covered. In my case, squashfs-tools has a new upstream release tagged 4.4-git.1 . I'm guessing that using 4.4-git.1 as the version would be at least confusing and might be prohibitted. Should I do that? If not, should I replace the - with a . in the version or should I move git.1 into the release. This is the first tag using this naming pattern, so I don't know the next tag will sort properly if I keep it in the version. ___ 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: Release criteria proposal: first boot experience
On Wed, Sep 02, 2020 at 00:12:34 -0600, Chris Murphy wrote: No user creation in Workstation Live, for a long time. First user is created by GNOME Initial Setup. Root user is not enabled. I was using the XFCE spin, so that might be different. ___ 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: Release criteria proposal: first boot experience
On Tue, Sep 01, 2020 at 22:09:57 -0600, Chris Murphy wrote: On Tue, Sep 1, 2020 at 8:16 PM John M. Harris Jr wrote: You're using net installer? The Live doesn't have user configuration in the installer. I did some live installs last week of rawhide and was able to create one user account in the installer. You need to do either that or set up root. Though you can do both. It might be different in F33. ___ 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: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal
On Tue, Jul 07, 2020 at 15:16:22 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PostgreSQL_13 == Summary == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 12 to version 13 in the non-modular (main) builds. They are going to release 13beta3 on Thursday, so we aren't going to see a 13 release until very close to Fedora 33's release. ___ 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: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal
On Tue, Jul 07, 2020 at 15:16:22 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PostgreSQL_13 == Summary == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 12 to version 13 in the non-modular (main) builds. While I like to have the latest postgresql available for my use, it seems pretty aggressive to try to get postgresql 13 into F33. Using the beta versions is a pain because the catalog will often change right up to release and you need to dump and reload or run a conversion on your data with each update. So this won't be practical to put in rawhide until it is released. While the release might be done soon, postgresql releases often end up happening in October. ___ 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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)
On Thu, May 21, 2020 at 18:46:14 -0400, Dennis Payne wrote: The reason for the crashing on startup is that it is not loading the font. I have fixes for this out. Even though this currently just affects rawhide, I have fixed builds for f31 and f32 as well, so if a font file moves a simple rebuild will fix things. ___ 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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)
On Fri, May 22, 2020 at 09:56:48 -0500, Bruno Wolff III wrote: On Fri, May 22, 2020 at 09:03:31 -0500, Bruno Wolff III wrote: I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a number of years ago. I found a source rpm that has the 2.3.67 tarball in it. It looks reasonable. https://ftp.lysator.liu.se/pub/opensuse/repositories/games/openSUSE_Tumbleweed/src/vulture-2.3.67-4.130.src.rpm I have a local copy for now. My feeling is that one will have better luck with that tarball, than with the 2.4 source that got archived. I reopend a bug requesting an upgrade for vulture. ___ 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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)
On Fri, May 22, 2020 at 09:56:48 -0500, Bruno Wolff III wrote: On Fri, May 22, 2020 at 09:03:31 -0500, Bruno Wolff III wrote: I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a number of years ago. The version I saw should have been 2.3.67. So the 2.4 community addition would have been a sucessor to that from about 3 to 4 years later. ___ 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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)
On Fri, May 22, 2020 at 09:03:31 -0500, Bruno Wolff III wrote: I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a number of years ago. There is some source code archived at: https://archive.org/details/VultureForNetHackCommunityEdition2.4 It doesn't have as much coverage as 3.67. I haven't verified that this is the modified nethack code. If it is unmodified, then it's useless for vulture. The build instructions seemed to be for nethack and so might turn out not to be very useful. This was archived in 2017 and probably is from no earlier than 2015. Steam still seems to to the package and a slash'em version as well. They are supposed to come with source if you get them, but I don't know if it will be really usable. I'm not getting a Steam account to check out what is there. (When I get proprietory games, they are DRM free from GoG.) ___ 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: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)
Copying me directory was a good idea to get my attention. Fedora list mail goes to another folder and it is easy for me to miss stuff, though I was planning to double check this thread for objections before doing a retire. On Thu, May 21, 2020 at 18:46:14 -0400, Dennis Payne wrote: The reason for the crashing on startup is that it is not loading the font. /usr/games/vultureseye/fonts/VeraSe.ttf -> /usr/share/fonts/bitstream- vera/VeraSe.ttf /usr/share/fonts/bitstream-vera/VeraSe.ttf does not exist. /usr/share/fonts/bitstream-vera-serif-fonts/VeraSe.ttf Thanks for doing this. I wasn't sure how to get to specific threads in gdb and wasn't sure what the error was. I fixed this issue for several other games and can do it for nethack-vulture pretty easily now that I know what the problem is. Updating the link allows it to start. I'm against losing games. So I'd rather keep the current version at the moment. When I get a chance I'll look into new versions of the program. I'm against losing games as well, but don't find the time to do as good a job on the ones I maintain, as I should. Even getting Vulture's Eye up to 3.67 is going to take more work than I can commit to any time soon. That uses a pretty old version of nethack. While it will likely never be up to date again, since Vulture's Eye upstream looks like it might be dead now, it would be nice to get it closer. I found some indications the game was commercialized on Steam and was probably getting updates as recently as 2017. The code license would allow anyone who had gotten a binary to get source, but the developer wasn't making it generally available. I'm not even sure I can find my 3.67 copy any more. And I have not seen any mention of anyone providing source later than that. If you want to be added as a co-maintainer or take over the package, I'm fine with that. A decision should be made before f33 branches, if there is enough interest to keep it around in spite of its support shortcommings. I'll get the font issue fixed and do new builds for f31, f32 and rawhide. It's a sort of generic fix to work around problems caused by a change in f32's font packaging. A temporary fix was added for f32, but is not going to be kept for f33. The idea is for a simple rebuild to be able to deal with changes in font paths. I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a number of years ago. ___ 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 33 System-Wide Change proposal: Sqlite RpmDB – fedora-review
On Wed, May 20, 2020 at 11:31:37 -0400, Neal Gompa wrote: On Wed, May 20, 2020 at 11:06 AM Zbigniew Jędrzejewski-Szmek wrote: I'm seeing this when running fedora-review: $ fedora-review -b 1838033 INFO: Processing bugzilla bug: 1838033 ... INFO: Installing built package(s) warning: Found bdb Packages database while attempting sqlite backend: using bdb backend. I got this on a machine I can't reboot right now and I ran rpm --rebuilddb which appears to have switched the database over. At least I stopped getting the messages when running dnf. ___ 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
Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)
The current nethack-vultures uses a very old version of nethack. It is bundled because a customized version is used to support the isometric view. There exists source for a slight more recent version, but it is still very old. The upstream web site is now dead and they weren't very good about publishing source. So I can't get code from just a few years ago. At this point, I don't think it is worth the work to support this different UI for nethack. If someone else wants to take it over, I'm fine with that. The latest version I was able to find was 3.67. I don't seem to have a copy of that, but old Debian releases probably have it. When I last looked at it, going from the current Fedora version to 3.67 was a substantial amount of work. The current version is crashing on start up, so even keeping the status quo needs some work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
On Wed, May 13, 2020 at 13:32:19 +0200, Bohdan Khomutskyi wrote: For optimization of the SquashFS, I will work on requesting the support of the required functionality in the Pungi compose build software. Note that squashfs-tools 4.4 just went into rawhide a couple of days ago. By default it does reproducible builds and this might affect performance since the files need to be added in a consistent order. This probably increases the wall clock time when creating images. I wouldn't expect it to have much affect on reading data from images, but you might see some changes. ___ 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
4.4+ squashfs-tools in rawhide
I finally built 4.4 for rawhide. We already had back-ported zstd, but this gives us reproducible builds and a few other things. I'm noting this here, because squashfs-tools is used for some important stuff and in the case it breaks something I wanted people to know that it might be due to this update. I did run the squash / unsquash tests successfully, so I'm not expecting anything to break. I'm currently not planning on doing builds for f31 or f32. But will consider it if there is demand. ___ 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: CPE Git Forge Decision
On Mon, Apr 06, 2020 at 16:02:34 +0100, Leigh Griffin wrote: Our stakeholder and engagement point as a team is Fedora Council. If you have issues with how this was handled from a relationship perspective then please take that up with the Council. We have engaged with fesco in the past at the request of Council and will engage with them in the future in a similar manner. I think this is a good idea. While it is clear a lot of people participating in this discussion don't like what or how things happened. We can't each decide how things are going to be or we will have a lot of conflicting action plans. Further arguing with Leigh doesn't seem likely to be very productive. Given the tone of some of the replies, Leigh has been surprisingly gracious in continuing to engage on this mailing list. We should be taking this up with the council to see what is possible and how we might proceed forward. ___ 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: CPE Git Forge Decision
On Wed, Apr 01, 2020 at 17:21:14 -0400, Paul Frields wrote: That statement rings hollow for me, when Github is arguably the single biggest vendor of open source in the world, no part of itself is open source, and thanks to its pervasiveness, open source has won the war of how development should work. I care more about free software than open source. Github, at least in the past, didn't really encourage free software and a lot of stuff hosted there didn't have a clear license. Github is a problem, because it seems to be benefitting from network effects to pressure people to create accounts there. I was very happy when Pagure was announced, because it seemed that there would be a competitor that should at least do well amoung people who cared about free software. Hopefully that still happens, but this change will probably kill some of the momentum. Github certainly does some good things and isn't currently a bad actor, but I don't think they are really in the free software camp. ___ 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: CPE Git Forge Decision
On Wed, Apr 01, 2020 at 12:39:21 +0200, Florian Weimer wrote: * Bruno Wolff, III: RHEL is a special case, as CENTOS provides a free drop in replacement and switching from CENTOS to Fedora shouldn't be much work. Is there other proprietary software at the OS level or above, that is used for Fedora infrastructure? The Bugzilla fork running on bugzilla.redhat.com? <https://bugzilla.redhat.com/show_bug.cgi?id=478886> That was an interesting read. It sounds like corners were cut under the assumption that there would be no desire to share the code. Specifically code and config were mixed together and the config can't be released. ___ 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: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 13:08:05 -0400, Matthew Miller wrote: We did communicate as the very top line of our gathered requirements that open source is essential to our community and central to our feedback. I'm not trying to be soft on that. Let's just not do purity-test level assessments and instead focus on our goals. The response from CPE made it sound like they just counted requirements rather than evalutating how important each requirement was to each group. Perhaps that was not intended, but that's they way it sounds. I think that being able to theorectically switch from hosted to self-hosted in short order (like in a month), should have been a deal breaking requirement from Fedora in case something at Gitlab changed that prevented using their hosted service. That implies having access to the source (capable of running our instance) with a free license and regular exports of the data in our hands. It doesn't sound like that is a requirement from the response provided by CPE. Because of switching costs, this is likely to prevent us from going back to Pagure if it does develop a vibrant independent community. That would be unfortunate. ___ 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: The Git forge decision (was CPE Weekly: 2020-03-28)
On Tue, Mar 31, 2020 at 10:33:46 -0400, Matthew Miller wrote: I understand the attachment we have as a project to Pagure -- someone in our community made it, after all, and lots of others have made direct and indirect contributions. I feel that too! But, we all know that it needs significant development work for scaling, stability, and features. It's more than that. While the community edition of gitlab (assuming we don't get stuck with the proprietary version) is technically open source, the main fork is run by Gitlab who have a conflict of interest in adding features that compete with their enterprise edition. If it comes down to needing a change they don't want to add, then we need to be willing to maintain a fork or switch to something else. While this is true for a lesser amount for using any free software, there normally isn't the same incentive for most projects to reject enhancements submitted back upstream. ___ 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: CPE Git Forge Decision
On Tue, Mar 31, 2020 at 12:55:39 +0200, Tomasz Torcz wrote: Being self-hosted is a nice goal, but not important enough. There are parts of Fedora infrastructure which are not using Fedora, but other distributions like RHEL. We seem to have not problem in using proprietary SAAS solutions for critical stuff. RHEL is a special case, as CENTOS provides a free drop in replacement and switching from CENTOS to Fedora shouldn't be much work. Is there other proprietary software at the OS level or above, that is used for Fedora infrastructure? I truly envy Debian and their ability to dogfood, running their infra on Debian. With minor exception: although they self-host GitLab, it seems to be different than their distribution packages. I think the difference is the support window for Fedora. In a way CENTOS is an LTS version of Fedora. ___ 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: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 15:30:20 -0400, Neal Gompa wrote: I barely remember plague (it was going away when I started as a packager). Plague was free software, but the build system for Fedora Core was not. That and Plague were both replaced with Koji in 2007. It was a great day, indeed. Thanks for the correction, as it was a long time ago and apparently either misremembered or confused plague with the proprietary part long ago. ___ 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: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 14:42:33 -0400, Alex Scheel wrote: Have you tried to use Pagure as a development based git forge? And not just as a dist-git hosting location? It needs a lot of help! More than the current resources provide. I've used the PR features a bit in a dist-git context. I tried to see if we could use it for my group at work, but somebody had already set up gitlab for another group and we ended up re-using their work instead. The reasons why are well documented in Pagure's issue tracker. I have contributed to the the issue list, but not for a while. If that's something you value, feel free to contribute to Pagure upstream. It's hard for me to keep up with packing now, so it is hard to do much more than report issues and test fixes. But Pagure can't compete with Gitlab as a development forge in its current state. There are other public git forges that behave better than Pagure: - SourceHut - Gitea - ... So I don't think this actually has as much value as you think. Perhaps. SourceHut does look like it is really free. I'd be a little worried about something happening to the founder if I was reliant on them for improvements. Gitea also seems to be really free and seems to be community based. I don't know how well either works or how sustainable their development is. But they do seem to be alternatives that are really free, unlike gitlab. And to be clear: there's a difference between a Fedora-sponsored Development forge and a new git forge for dist-git. A lot of this discussion has conflated these two cases. I mostly care about it releasing the former role (pagure.io) and don't care much about the latter role (s.fp.o). I think it is a project that is valuable for Red Hat to sponsor, but apparently the decision makers there don't think so. I'm still disapointed in this decision. One of the reasons I got involved with Fedora instead of other distributions way back, was that they were working on getting rid of plague and replacing it with free software. (It was gone by the time I was a packager, so I never used it.) ___ 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: The Git forge decision (was CPE Weekly: 2020-03-28)
On Mon, Mar 30, 2020 at 17:20:04 +0100, Leigh Griffin wrote: On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann wrote: We are trying to reduce the total ownership of the team to allow us to provide value on initiatives that are requested of us by our stakeholders. Pagure has value beyond Fedora and RedHat. In some ways it has more value than Fedora the OS, because there are less free options in the git forge space. (Gitlab isn't usably free as is. It would need a real fork to get out from under the sponsor's conflicts of interest.) I would have expected the council to consider this an important project worth pursuing on its own, not just for running part of Fedora's infrastructure. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
On Mon, Mar 09, 2020 at 18:11:32 +0100, Fabio Valentini wrote: On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III wrote: I'm also not sure how you would detect that from the package metadata ... query all packages for their file contents, and then show conflicts when two packages own the same file, but do not explicitly Conflict? I think that's probably too simplistic ... I don't think that practice is banned currently, but it would probably cut down on mistakes if it were. Having two sources of truth that are supposed to be identical, makes it easy for people to make a mistake. ___ 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: Reducing broken dependencies in fedora (32) repositories
On Fri, Mar 06, 2020 at 21:35:52 +0100, Fabio Valentini wrote: Hi all, With the fedora 32 release drawing near, it might be a good time to check if any of your packages still have broken dependencies in the fedora 32 (+testing) repositories. I've been working on just the thing you need: Is there interest in also reporting packages that should be conflicting but aren't? These are annoying because they fail after the transaction is set and have to be manually dealt with. For example: Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /usr/bin/slideshow from install of racket-7.4-2.fc32.x86_64 conflicts with file from package batik-slideshow-1.11-3.fc32.noarch file /usr/share/man/fr/man1/blackbox.1.gz from install of blackbox-0.76-1.fc33.x86_64 conflicts with file from package man-pages-fr-3.70-20.fc32.noarch file /usr/share/man/fr/man1/bsetroot.1.gz from install of blackbox-0.76-1.fc33.x86_64 conflicts with file from package man-pages-fr-3.70-20.fc32.noarch ___ 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: How to deal with large number of bugs related to the, "multiple definition of..." issue
On Mon, Feb 17, 2020 at 21:32:30 +, Ronaldo Mercado wrote: I would like to see an example package where you experience this problem. In my case, greyhounds was the normal case. raidem was the enum should have been a typedef case. For greyhounds, I didn't make an exception in the include file, but rather added definitions to the main unit to reserve the space (and changed the include file to add extern to the definitions). This didn't result in a conflict, so I'm guessing it was a correct way to do this. If it wasn't, I'd like to know? ___ 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: How to deal with large number of bugs related to the, "multiple definition of..." issue
On Sun, Feb 16, 2020 at 07:24:10 -0600, Richard Shaw wrote: So I have several FTBFS bugs most likely from the new gcc being more pedantic. I understand the bug at a high level but I think it would be nice if someone who really understood it could perhaps document strategies for figuring out how to find the right file that needs to be updated and how. The most common fix I used was, using "extern" in all but one place. The was also an odd case where the original developers used an enum to define constants and it needed to be a typedef, not an instance of the enum. (I don't know why they didn't use "define" to define the constants.) ___ 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: Any issues booting Rawhide kernel-5.6.0-0.rc0.git1.2.fc32.x86_64?
On Thu, Feb 06, 2020 at 07:32:09 -0600, Bruno Wolff III wrote: 5.6.0-0.rc0.git2.1.fc32.x86_64 works. If last nights rawhide compose finishes successfully this morning, there should be a working kernel in the repo. The nodebug repo hasn't been updated since the work around was implemented, so right now you can't get a good one there either. You can get a good kernel from koji though. The compose failed, but there is now a working kernel in the nodebug repo. ___ 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: Any issues booting Rawhide kernel-5.6.0-0.rc0.git1.2.fc32.x86_64?
On Thu, Feb 06, 2020 at 13:02:32 +, "Richard W.M. Jones" wrote: I tried out this kernel: - kernel-5.6.0-0.rc0.git1.2.fc32.x86_64 It gets to grub, lets you select the kernel, but apparently no further. It's kind of frustrating to debug because either it produces *no* messages at all even in verbose mode, or else it's screwing up the display somehow so that nothing can be seen. I moved back to kernel-5.5.0-0.rc6.git2.1.fc32.x86_64 which boots fine, so I don't think it's a UEFI or grub issue. See: https://bugzilla.redhat.com/show_bug.cgi?id=1796780 5.6.0-0.rc0.git2.1.fc32.x86_64 works. If last nights rawhide compose finishes successfully this morning, there should be a working kernel in the repo. The nodebug repo hasn't been updated since the work around was implemented, so right now you can't get a good one there either. You can get a good kernel from koji though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unretire question
I filed ticket https://pagure.io/releng/issue/9197 to request that glob2 be unretired. The ticket is closed as completed, but the f32 branch still appears as a dead package. Am I supposed to fix this, more time is needed for the process to really finish or did something get missed? P.S. glob2 actually has some new upstream work going on on github, though they haven't published a recent release yet. ___ 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: Git Forge Requirements: Please see the Community Blog
On Wed, Jan 22, 2020 at 10:28:52 -0500, Neal Gompa wrote: We don't need to. There are improvements that people would like, and that does take development effort. That's the piece that requires manpower to go faster. In my opinion, I think this is where Red Hat should be helping. Pagure has a chance to change what free projects use for software development. Github isn't free (though they do some nice things for free software). Gitlab is open core, which means they have a conflict of interest when accepting improvements from outsiders. They could also stop supporting the open core at any time, leaving users who want infrastructure running on free software in a poor place. ___ 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: No More i686 Kernels, No i686 Repositories
On Mon, Sep 16, 2019 at 13:15:08 -0700, Samuel Sieb wrote: On 9/16/19 1:08 PM, Alessio wrote: - Can a user running a 32 bit F30 upgrade to F31? No. From the change page: "686 users will not be able to upgrade, and will have to move to another supported arch. " You can crossgrade using dnf. I wrote about it a few weeks ago. The process worked pretty smoothly for me. ___ 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 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 19:01:59 -, vvs vvs wrote: No, I don't think so. I'm using some (non Fedora related) applications which use every bit of available memory. It's a bit stressed just as it is, but losing additional couple of megabytes for no useful reason will be too much a hit. And I can't change their code, because that codebase is big and complex (as usual) and I just don't have enough time to do everything myself. Have you actually tested this? That is very odd behavior. ___ 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 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 18:23:18 -, vvs vvs wrote: Anyway, I'm not expecting that something will change because of that discussion. It is just bad that the interests of users are of a lower priority then some purely bureaucratic reasons. It isn't happening because of bureaucratic reasons, but because not enough work is getting done to support i686, because people aren't volunteering to do it (and actually doing the work). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 18:06:02 -, vvs vvs wrote: Yes, thanks. Sadly, I see that I have no choice but to switch to another distribution even though I'm using 64-bit CPU. It's just that the memory can't be upgraded and buying new computer just to keep running Fedora is not viable. It's 12 years old, is in good condition and I'm completely satisfied with its performance for my needs. I wonder what owners of thin terminals will do if they used Fedora, especially if there are many of them. The cost of upgrading some old terminals for some school can be too high. It is probably very rare for someone to have just enough memory for a system to run reasonably using i686, but tank when using x86_64. If there is some key code that causes the problem, you might be able to rebuild that code to use 32 bit addresses and save enough memory to make things work reasonably. ___ 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 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 17:55:06 -, vvs vvs wrote: First of all thanks for the link. It just proves that the SIG's expectations were too high. If I understand it all correctly, the main reason to drop i686 repo was the mailing list inactivity? Is that right? So everyone interested in that architecture is now deprived from using it on Fedora because some formalities were not met? And if I have no time to participate in that list, I can't fix problems myself? Because without that repository I'm forced to use other distribution. There were announcements on other lists. This issue was brought to the development list a long time ago. New people didn't do enough. Just being on a mailing list doesn't make things get done. People needed to fix problems or at least facilitate getting them fixed, and not enough of that happened. So it isn't just a formallity causing the problem. You can still use f30 until about May. It looks like CentOS 7 can be used with i686, so you could probably use that a bit longer if you wanted to stick with a similar distro. Someone has to do the work and most of Fedora's work gets done by volunteers. If no one volunteers for something, then that thing is unlikely to get done. I was willing to do some work on i686 when I was forced to use it, but shortly I won't be using any i686 systems and will be spending what little time I use for Fedora on things that are more important and more practical for me. ___ 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 System-Wide Change proposal (late): No i686 Repositories
On Mon, Sep 09, 2019 at 14:52:07 -, vvs vvs wrote: May be there are more interested people that we know, but they are not reading that list. There will just be just every man for himself and Fedora has failed to recognize that. This requires time and effort too. Nobody will appear just by a miracle. I recognize that there is much less people interested in this architecture but it's much more than zero. I'm probably one of the few people still running Fedora on a machine that uses i686, that can't use x86_64. The machine is around 15 years old and is costly to get replacement parts for and I'm running out of spares. I was supposed to replace the machine last month, but needed another month to save up enough to buy the rest of the replacement. I've actually work with upstream to get kernel bugs fixed for this machine. Unfortunately I run rawhide and things got shut down a little sooner than I hoped, so I'm not getting updates right now and don't want to go back to f30 with the short horizon for retirement (though I did grab an f30 kernel). I don't think you are going to find many people who both run Fedora and have to use i686. There is a cost to keeping things running on i686 and it doesn't look like it is worth paying right now. And things are looking to get worse rather than better. You have options. You can switch to another distro that will support i686 for a while yet. Use f30 until it's EOL (or beyond if the machines are isolated). Or maintain your own distro. The tools for Fedora are open, so you could set up your own koji instance drawing from Fedora and applying your fixes where needed. Getting started will probably be hard, but once things are running you'll be OK until there is a key bug you can't get fixed. ___ 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: Best practice for local files in a package
On Fri, Aug 30, 2019 at 11:17:11 -0700, Kevin Fenzi wrote: Well, in the squashfs-tools case these are in the looaside cache, so you could (all be it ugly looking), use: https://src.fedoraproject.org/lookaside/pkgs/squashfs-tools/unsquashfs.1/sha512/6e1be535d370fb39b2a0e47c98052727bab94ae4f306bb3eb8f7dd07fb84bf985e82ba66bb2030e08261473cffc34d1c1973b27e77cb7127d588e24297f2f0a3/unsquashfs.1 You would have to change that if the file got uploaded again with changes of course. I'll give it a try. The files do need to change, so I won't be using that exact string. But if it isn't crazy to provide a lookaside cache reference then I'll give it a try when I do the update. I'll also see if I can find a place in the packaging documentation to note this solution for others. ___ 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
Best practice for local files in a package
I got a warning about not having urls for a couple of files in the squashfs-tools package from release monitoring. The bug which has the comment is: https://bugzilla.redhat.com/show_bug.cgi?id=1747102 These are based on some man pages used in Debian at one time, but do not track changes in the originals. I need to look at these again since 4.4 has a number of new options. And I'm wondering what I should do to not break test release monitoring builds for files in the package that are local and not derived from (on an ongoing basis) an upstream? ___ 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 System-Wide Change proposal: No More i686 Kernels
I cross graded a laptop from i686 to x86_64 yesterday using dnf and it went pretty well without a reinstall. It also ran fine using an x86_64 kernel with i686 user space during the transition. I noticed that at least with using --forcearch=x86_64 that installing two packages that had names differing only in arch was a problem, even when there shouldn't have been file conflicts. So that to get an x86_64 kernel installed, I needed to install a different version than any of the installed i686 kernels. Initially I installed an x86_64 kernel and then booted into that. I assumed that x86_64 user space wouldn't work with an i686 kernel. (Though I didn't test that to be sure.) I didn't want an upgrade failing part way through, since it is a pain to clean up after that. Then I got of list of i686 packages (skipping noarch packages). After playing around with how to get dnf to do the update in one go (since it seemed likely to break things to have i686 libraries removed early) I found that using yum shell and swap worked. So you build a file with a swap line for each i686 to x86_64 conversion and then run yum shell with --forcearch=x86_64 specify that file and all the x86_64 packages get installed before the i686 packages get removed. I ran the process using screen to protect against desktop crashes and script to keep a record of what was done to check over afterwards. But it ran to completion without problems. wine is a special case. It couldn't be reinstalled in the mass cut over because it has dependencies on both x86_64 and i686 libs. So I had to reinstall afterwards. I'm not sure how dnf decides what the arch is. I still needed to use --forcearch when running an x86_64 kernel and an i686 user space. I rebooted after the userspace update and was able to reinstall wine properly without having to use --forcearch any more. So far things seem to be working normally, though in theory there might be some data that needs to get updated for an application. This went a lot smoother than I was expecting. I have had worse experiences updating after mass rebuilds than this one. Most of the articles on switching arches without full reinstalls are very old and describe more complicated processes. So I wanted to get something out there for other people that might have systems they want to switch over. ___ 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: always update the bootloader during major upgrades
On Wed, Jun 26, 2019 at 14:19:26 -0600, Chris Murphy wrote: Short version: Fedora should take responsibility for the bootloader being up to date, by updating it during major version upgrades. This is already the case on UEFI with conventional installations. I'd like to make sure it always happens on major version upgrades for BIOS installations. What's the problem? This would step on any custom bootloader configuration a user has for multiboot. There is no reasonable mechanism on BIOS systems to determine if the bootloader is a Fedora bootloader, and somehow only update a Fedora bootloader and not touch any other bootloader. How do you envision this working for rawhide? I had a problem where grub1 configs were no longer updated with kernel updates, where I finally needed to upgrade to grub2. ___ 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 System-Wide Change proposal: No More i686 Kernels
On Mon, Jun 24, 2019 at 23:17:30 -0500, Justin Forbes wrote: It is not a violent cheat. It was proposed this way 2 years ago. At the time a SIG was created to maintain i686 so that it could continue as a secondary arch. They are inactive. See the post in the SIG there. When a call for a status was made (as the only traffic on their list so far this year), it got a single reply from someone saying that they would no longer have 32bit hardware as of August. I'm the one who responded. I still have one machine that runs i686, but not x86_64. I'm hoping it keeps working until August, when I can afford to buy the rest of my power 9 based Blackbird to replace it. I have one other machine that I use on occasion that boots with an i686 kernel, because I used that when I first got it to use the same arch for all of my machines at that time. And I have been deferring doing a cross arch upgrade, but will in August. In theory I have another laptop with a bad keyboard, that can't use x86_64, but that I think would run current Fedora i686 kernels. But I haven't powered it on in years. I have done bisects for i686 issues in the past. I haven't had to in a while (at least a year for an i686 specific issue). People will actually get until spring if this passes, if they don't use rawhide. The hardware I have that is stuck on i686 is around 15 years old. I don't know other people who run hardware that old. I'm sure there are some, but probably not many. I would also expect new shiny software (i.e. Fedora) and ancient hardware is an odd combination. ___ 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: rawhide status - 2019-06-19
On Wed, Jun 19, 2019 at 10:44:41 -0700, Kevin Fenzi wrote: The last rawhide compose that completed was 2019-06-09 (10 days ago now). A lot of the incomplete composes are actually usable for updates and I have been getting systems updated and things have worked reasonably for the most part. If we had enough resources, it would be nice if the part of the compose needed for installs was treated differently from the part that people could use to get updates. (For example kernel-5.2.0-0.rc5.git1.1.fc31 fixes a remote DOS bug and people won't get it by default until there is a successful compose. Though it also seems to have problems on some hardware.) The naive way to do this is to have two seperate repos with hard linked rpms. Hopefully as time goes on, there will be fewer multi-day compose failures. ___ 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: Tagging commit hashes of Koji builds in dist-git
On Fri, Jun 07, 2019 at 08:37:57 -, Petr Pisar wrote: On 2019-06-06, Stephen Gallagher wrote: Might be worth asking if there's a reason to need this offline. If the exact commit ID is stored in Koji and is authoritative, also tagging it into git might be convenient for offline purposes. The fact that it's not immutable is probably not an issue as long as the authoritative site *is*. (e.g. The same script that gets the hash from Koji could also detect if someone manually changed it in git, which would probably qualify as suspicious behavior.) If tags in dist-git could disagree with Koji, people could not rely on them and would use Koji instead rendering tags in dist-tag useless. Would having signed tags help? ___ 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: Stale packages in Fedora 30
On Mon, Jun 03, 2019 at 12:47:53 +0200, Hans de Goede wrote: I once maintained this, it seems that Bruno, who took it over, no longer has time to maintain this. Yeah, but leave me as a co-maintainer as things might get better. I did some CI work for squashfs-tools a couple of weeks ago, so I'm starting to get a little done again. But getting zstd support in squashfs-tools (which involves a few other changes as a prerequisite) is what I want to get done next. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Mon, Jan 07, 2019 at 22:00:25 -0500, Matthew Miller wrote: Since there is no personal information attached, I don't see how on the face of it this is a privacy violation. I want to take this concern seriously, but I need more to go on than "this is inherent". Can you elaborate? From the users point if view, they can't tell if IP addresses are tracked along with UUIDs. Some IP addresses can be tied to specific users, and now with UUIDs, the same machine can be seen to use different IP addresses so that a person can now be seen to be using multiple IP addreses that couldn't be as easily correlated before. Some of these IP addresses may have been hard to associate with the person previously. Users can defend against this by being selective when they do updates relatively easily as long as updates are the only thing using this UUID. If you care about that level of not revealing usage, Fedora is probably not the best distribution in the first place. A number of packages do not make a priority of limiting networking requests. For example it is common for web browsers in Fedora to refer to a network version of a Fedora web page as their default start page rather than using a local copy of this page that might be a bit out of date. So I don't know if IP address correlation is likely to be of big concern to many Fedora users. I would prefer that Fedora make different privacy / convenience trade offs than it does, but I'm pretty sure I'm in a small minority and I'm able to do work arounds on my end for this for cases where I want to spend the effort. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Tue, Jan 08, 2019 at 00:44:26 -0500, John Harris wrote: On Tuesday, January 8, 2019 12:32:45 AM EST Bruno Wolff III wrote: The cost for pretending to be lots of machines is also reduced a lot in this scheme over having to connect from lots of different IP addresses. Though at some point spoofing too many would probably be considered a denial of service attack and might get the perpatrator in legal trouble, which might discourage people from doing that. If such an attack wasn't noticed because of the request volume from a small amount of IP addresses, it might be possible to have a significant affect on the aggregate stats. So it might be worth having some filters watching out for this kind of attack. I definitely don't think it's best to start considering legal action against Fedora users in a thread about invading on user privacy. This will only scare folks. I think it is reasonable to discuss mitigations to attacks on the proposed system for counting unique users before implementation starts as that might affect the design. The new system greatly reduces the cost for pretending to be unique systems and someone mad at Fedora or just for laughs, might try to spoof a very large number of systems. Legal risk is one thing that might encourage people not to do this (possibly to the point where no one tries to do an attack spoofing say multiple unique machines per second). Another mitigation is proactively looking for lots of unique machines on a small number of IP addresses and flagging this for evaluation by a human. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Mon, Jan 07, 2019 at 21:43:46 -0500, Matthew Miller wrote: On Mon, Jan 07, 2019 at 02:27:39PM -0600, Bruno Wolff III wrote: Is this going to happen on install or upgrade before there is a chance to turn it off? Maybe? Keep in mind that you are _already_ contacting the mirror systems when installing or upgrading. Sending a random number once (or a few times, even) does not seem particularly invasive. I keep local mirrors of the particular versions and arches I use, so I generally don't connect to Fedora repos on a per machine basis. But I have only a few machines. I imagine there are some organizations where this might also be the case. Probably not enough to care about from a stats perspective and they probably aren't doing it for privacy reasons. But it isn't guaranteed that installs and upgrades will need to connect to Fedora infrastructure to access repos. Are the UUIDs going to be sanity checked so that NSFW UUIDs don't show up in reports? You mean if someone sends a fake UUID rather than a genuine one? I don't expect we'll actually present the UUIDs directly in reports. It does seem reasonable to check that UUIDs actually match the expected format, which should cut out most of that. Yes I was thinking of fake ones. They might be ones intended to be disruptive visually or someone may change their UUID every hour so that each dnf contact is likely to have a different UUID. I don't know that this would change the aggregate stats enough to care about. The cost for pretending to be lots of machines is also reduced a lot in this scheme over having to connect from lots of different IP addresses. Though at some point spoofing too many would probably be considered a denial of service attack and might get the perpatrator in legal trouble, which might discourage people from doing that. If such an attack wasn't noticed because of the request volume from a small amount of IP addresses, it might be possible to have a significant affect on the aggregate stats. So it might be worth having some filters watching out for this kind of attack. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Mon, Jan 07, 2019 at 17:44:59 -0500, John Harris wrote: We don't need to be thinking of more things to track about the user, but ways to prevent tracking and still get the counts the Council wants. There are two mutually opposed sides here. The users need to consider how they might be attacked by Fedora infrastructure or by people with access to the information collected by Fedora infrastructure. And Fedora needs to be concerned about people supplying bogus data to their logging related to getting data on system counts. So it is useful to consider what might be done with data available to Fedora infrastructure even if that isn't the plan. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Mon, Jan 07, 2019 at 22:54:46 +0100, Tom Gundersen wrote: You could move the rotation to the client by hashing the UUID with a timestamp of sufficiently coarse granularity (a week?) before submitting it. Then you make sure that all UUIDs submitted by a given machine during a given time window are the same, but UUIDs submitted in different windows are not related, and you don't have to trust the server to respect your privacy. There are ways to link the new UUIDs to the old ones in many cases. This could be by looking at IP addresses in common, times of the requests, varients, repo(s) and possibly other characteristics of the requests. While a GUUID is in use it could be used to link IP, and time information with more certainty than you would otherwise. So this allows better tracking than if you just had to go by IP, time and other information in the requests. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Mon, Jan 07, 2019 at 17:04:11 -0500, John Harris wrote: On Monday, January 7, 2019 5:00:48 PM EST Stephen Gallagher wrote: I think the only useful data we could get from unknown variants would be "the number of times we see an unknown variant". So I think throwing it away and just incrementing a counter of "the number of times people have tried to poison the data" is probably reasonable. I have to say that I actually disagree with this. It is possible that Fedora Remixes could send the variant as being the name of their Remix. While my Remix wouldn't do this (it is privacy oriented, and ensures only free software), I can see the case for others. Presumably groups that wanted these counts could let Fedora know the varient name to expect for counting. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Mon, Jan 07, 2019 at 16:41:46 -0500, John Harris wrote: On Monday, January 7, 2019 4:31:29 PM EST Bruno Wolff III wrote: If the strings aren't checked when they are received, they could be anything. The system varient also has the same issue. You shouldn't trust the clients supplying this information. If we are just using this UUID to count machines, it doesn't matter what the UUID is. Just that it's different between machines. Yes, if they are not so long as to break the software and no public report has the actual strings so the project doesn't get embarrassed and no one who has to look at the strings is easily offended, then it isn't a problem. The system varient is probably a bit different of a case. Unexpected varients could end up in public reports depending on things are designed. It might be good to throw out any data which has unexpected varients in it. ___ 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: F30: System-Wide Change proposal: DNF UUID
On Mon, Jan 07, 2019 at 16:00:46 -0500, John Harris wrote: On Monday, January 7, 2019 3:27:39 PM EST Bruno Wolff III wrote: Are the UUIDs going to be sanity checked so that NSFW UUIDs don't show up in reports? I don't see how a UUID could possibly be NSFW, or why UUIDs would ever be included in reports regardless. The point is supposedly counting, not tracking. If the strings aren't checked when they are received, they could be anything. The system varient also has the same issue. You shouldn't trust the clients supplying this information. ___ 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: F30: System-Wide Change proposal: DNF UUID
Is this data only going to be sent to the metalink or do the mirrors actually used, get the data? Is the data going to be sent along with requests to non-Fedora repos (e.g. rpmfusion)? This will make it much easier to spoof being lots of systems. Is there some plan to mitigate this risk? Is this going to turn on automatically for rawhide users? Is this going to happen on install or upgrade before there is a chance to turn it off? Are the UUIDs going to be sanity checked so that NSFW UUIDs don't show up in reports? ___ 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: Wasn't gpg supposed to be renamed to gpg1?
On Wed, Dec 19, 2018 at 11:28:16 +0100, Igor Gnatenko wrote: Seems that I missed writing announcement, but there is a package called `gnupg1` which provides `gpg1` binary. So you should be fine with that I hope. And sorry for this trouble. Thanks for the help. I'm not sure why I didn't find it with dnf search. It might be a good idea to mention it on the change page, on the off chance that someone else using it thinks to look at the change page. It might also help get it noted in the release notes. In my case it would have helped if gnupg1 had obsoleted gnupg, but I don't know if that was true for most people who had gnupg installed. I also already had gnupg2 installed already so I didn't need its installation triggered as part of the update. Other people might have needed that. ___ 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
Wasn't gpg supposed to be renamed to gpg1?
gnupg2 is now obsoleting gnupg and the previous gpg command is not available. The change page said gpg would be renamed gpg1, but this was not done. Unfortunately gpg2 will not read my existing secret keys. (They are pretty old and probably should be replaced.) For now using rpm --nodeps allowed me to replaced the gnupg2 version of gpg with the gnupg version so I could get at some encrypted data, but it would be nice if the plan from the change page had been used instead of what was done. If the plan has changed, then updating the change page to match what was done would be nice. Though in the latter case there should be a warning about breaking things for some people. ___ 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-rawhide-kernel-nodebug is not getting updates
On Wed, Dec 12, 2018 at 12:37:24 -0600, Bruno Wolff III wrote: On Thu, Dec 06, 2018 at 14:29:15 +, "Richard W.M. Jones" wrote: Anyway it seems like Rawhide isn't getting new nodebug kernels. - Latest nodebug kernel: kernel-4.20.0-0.rc1.git4.2.fc30.x86_64.rpm (https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/) - Latest Rawhide kernel: kernel-4.20.0-0.rc5.git2.1.fc30 (https://koji.fedoraproject.org/koji/packageinfo?packageID=8) Something weird is going on. The git0.1 kernels make it in, but the other gitX.2 kernels don't. It keeps reverting to 4.20.0-0.rc1.git4.2. It reverted again today. Is this issue being tracked somewhere? If not, where is the correct place to report it? ___ 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
