Re: RPM Fusion Bugzilla Bug 5307
On 9/22/19 9:09 PM, Neal Gompa wrote: On Sun, Sep 22, 2019 at 7:25 PM Ty Young wrote: On 9/22/19 5:51 PM, Samuel Sieb wrote: On 9/22/19 3:10 PM, Ty Young wrote: I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again. I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora. No, I meant the package manager GUI front-end won't work: https://imgur.com/a/Dajf28T I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else. If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora It's fine, I completely understand. I just happened to pick the Cinnamon spin since I knew it and MATE used LightDM and I don't use Fedora so I don't know if I can be of any help. Also, Spanish(?) confirm prompt when rest of GUI is English: https://imgur.com/a/7ashccO ...and proof X.Org on Cinnamon is running as root: https://imgur.com/a/UcLjjKT Yet on Gnome Fedora it isn't: https://imgur.com/a/DlXwcdK So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here. Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME. How would you propose we fix this bug, as you call it? Well, what exactly was the old behavior before? I know for a fact X. Org was running as root during the beta. Is X. Org as root during beta periods only the norm? Neither of the two other major distro families, Arch Linux and Ubuntu with Gnome, have X. Org as root disabled, at least not when running the Nvidia binary. Are there any malicious software that even exists that exploit X. Org being ran as root? If no one else sees that as an issue then why does Fedora? And is disabling root X. Org worth breaking people's software that would otherwise work? Clearly few DM(s) other than Gnome supports it despite earlier claims, so it isn't even standard behavior. Fedora supports multiple spins including DM(s) that don't support it, so you're just fragmenting your own ecosystem if it is enabled on Gnome Fedora only. That's not a great idea. So, IMO, the correct behavior here would be to disable until at least other DM(s) support it and other distros enabled it by default so that Fedora is at least following standards. Once it *actually* gets adopted *maybe* Nvidia will allow overclocking on non root X. Org but that could just be wishful thinking. At minimum there should always be an option to disable security features, especially if it results in performance loss(e.g. Specter) or, in this case, application compatibility problems easily... and editing a config file isn't that easy, obvious, or in some cases even safe. Maybe provide an optional rootless login session option in Gnome's login screen? FWIW, even if the application uses Flatpak, rootless X. Org still breaks the application. Would it be possible to grant individual applications privileged root access on a case by case basis? Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd. Maybe different versions of the software positioned it differently? Ah, no. The menu I'm talking looks like the application icon itself. I've only seen it manifest itself in Arch Linux when you install another DE. No other Gnome applications in Fedora that I could see has it, and it does stick out... maybe it's a CSD compatibility thing for Cinnomon and/or Mate? ___ 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
[389-devel] 389 DS nightly 2019-09-23 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/09/23/report-389-ds-base-1.4.2.1-20190922git16cf97e.fc30.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: RPM Fusion Bugzilla Bug 5307
On Sun, Sep 22, 2019 at 7:25 PM Ty Young wrote: > > > On 9/22/19 5:51 PM, Samuel Sieb wrote: > > On 9/22/19 3:10 PM, Ty Young wrote: > >> I couldn't actually install the drivers because the update GUI in the > >> cinnamon spin is broken and/or the repo/update servers are down. Again. > > > > I don't know why you're having so much trouble with updates. But just > > in case you're referring to rpmfusion as you have in other emails, I > > hope you're aware that Redhat has nothing to do with them. They are > > an independent third-party repo not managed by Fedora. They host > > packages that can't, for various reasons, be distributed by Fedora. > > > No, I meant the package manager GUI front-end won't work: > > > https://imgur.com/a/Dajf28T > > I'm sorry that dnfdragora isn't quite working properly on your system. As one of the developers of dnfdragora and dnfdaemon, I'm aware of some of those quirks, and myself and the other developer have been trying to work on fixing these problems. It's difficult though, as both of us are working on it in our spare time. We're committed to improving it, but I have to find time for it, among everything else. If you'd like to help, we'd appreciate it. The project is here: https://github.com/manatools/dnfdragora > > Also, Spanish(?) confirm prompt when rest of GUI is English: > > > https://imgur.com/a/7ashccO > > > ...and proof X.Org on Cinnamon is running as root: > > > https://imgur.com/a/UcLjjKT > > > Yet on Gnome Fedora it isn't: > > > https://imgur.com/a/DlXwcdK > > > So is Fedora going to admit it's a bug in Gnome Fedora or are we going > to keep being salty that Nvidia doesn't support or have an Open Source > driver by pointing the finger at them? Actually fixing the bug would be > the more productive option here. > Well, the rootless X thing is from gnome-session down, so that's a GNOME thing. I'm aware that not all DEs do this, the work was primarily done in GNOME. How would you propose we fix this bug, as you call it? > > Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to > the left of the cancel button but Arch doesn't? Bit odd. > Maybe different versions of the software positioned it differently? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RPM Fusion Bugzilla Bug 5307
On 9/22/19 5:51 PM, Samuel Sieb wrote: On 9/22/19 3:10 PM, Ty Young wrote: I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again. I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by Fedora. No, I meant the package manager GUI front-end won't work: https://imgur.com/a/Dajf28T Also, GUI in general is buggy: https://imgur.com/a/W4bIzyO https://imgur.com/a/ELpjoAQ Also, Spanish(?) confirm prompt when rest of GUI is English: https://imgur.com/a/7ashccO ...and proof X.Org on Cinnamon is running as root: https://imgur.com/a/UcLjjKT Yet on Gnome Fedora it isn't: https://imgur.com/a/DlXwcdK So is Fedora going to admit it's a bug in Gnome Fedora or are we going to keep being salty that Nvidia doesn't support or have an Open Source driver by pointing the finger at them? Actually fixing the bug would be the more productive option here. Also while I'm at it, why does Gnome Screenshot in Fedora have a menu to the left of the cancel button but Arch doesn't? Bit odd. ___ 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/22/19 3:10 PM, Ty Young wrote: I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again. I don't know why you're having so much trouble with updates. But just in case you're referring to rpmfusion as you have in other emails, I hope you're aware that Redhat has nothing to do with them. They are an independent third-party repo not managed by Fedora. They host packages that can't, for various reasons, be distributed by 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: RPM Fusion Bugzilla Bug 5307
On 9/22/19 3:08 AM, Leigh Scott wrote: On Sat, Sep 21, 2019 at 8:33 PM Ty Young Do you mean 'Support non-root X'? if so some DM's still don't support it. https://github.com/canonical/lightdm/issues/18 This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly. As far as I know we don't force non-rootless X. For the giggles I tried the Cinnamon spin. Unless something changes after installing the Nvidia drivers, X. Org is running as root unlike Gnome Fedora. I couldn't actually install the drivers because the update GUI in the cinnamon spin is broken and/or the repo/update servers are down. Again. Also, who is maintaining the cinnamon spin? Do they by chance speak Spanish as their primary language? ___ 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 ___ 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: Add a rule to have a compose when Fedora branched
On Sat, Sep 21, 2019 at 11:04:29PM +0200, Pavel Raiskup wrote: > On Friday, September 20, 2019 6:08:46 PM CEST Kevin Fenzi wrote: > > On 9/20/19 4:39 AM, jkone...@redhat.com wrote: > > > What COPR was doing (I think they changed it after F31) then before a > > > new chroot in COPR appeared they copied the latest Rawhide chroot to > > > have something working in the new chroot. So, if we build the new > > > Rawhide the same day as F31 branch compose is ready then they don't > > > have a time to react and sync "the old Rawhide" version. > > > > I thought that was not manually copied, but just that way because we had > > no f31 compose, so f31 and rawhide were the same thing (due to > > mirrormanager). > > What we were doing before was that we (a) copied Rawhide to > branched, and (b) enabled the branched chroot -- but both actions mostly > atomically at the same time (the (b) was always done immediately right > after (a)). > > This time (F31), for (b) to happen we needed to wait till there's F31 > compose available (so we waited even with (a)). So we copied the Rawhide > builds too late, many of them already had fc32 dist tag. Ah, ok. > So for the next time, we'll try to do (a) first, immediately after > the branching moment. And we'll wait for the branched compose with (b). ok. Hopefully that will be much shorter this next time, and you won't have to worry about rawhide moving on if we pause those composes for branched to complete. > > Naturally users will miss some builds in branched (those which happen > between (a) and (b)), but problems caused by this should be slightly > easier to resolve than what happened during F31->F32. Yep. kevin -- > > Pavel > > > ___ > 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 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fwd: Fedora Notifications Digest (2 updates)
On Sat, Sep 21, 2019 at 02:51:48PM -0400, Christopher wrote: > Why do sometimes notifications have empty message lines like the following? This is some mismatch between the bodhi messages and the way FMN expects them to be formatted. ;( https://github.com/fedora-infra/fmn/issues/298 if you want to watch or look further to investigate. kevin -- > -- Forwarded message - > From: > Date: Fri, Sep 20, 2019 at 10:10 PM > Subject: Fedora Notifications Digest (2 updates) > To: > > > Digest Summary: > 1. > 2. > > --- > > (2019-09-21 01:08:21 UTC) > - https://bodhi.fedoraproject.org/updates/FEDORA-2019-3a8dcac2ad > > > > --- > > (2019-09-21 02:00:32 UTC) > - https://bodhi.fedoraproject.org/updates/FEDORA-2019-cc981a88ce > ___ > 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 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Renewing the Modularity objective
On Wed, Sep 18, 2019 at 03:30:58PM -0400, Ben Cotton wrote: > Now that Modularity is available for all Fedora variants, it's time to > address issues discovered and improve the experience for packagers and > users. The Modularity team identified a number of projects that will > improve the usefulness of Modularity and the experience of creating > modules for packagers. Thoe team is proposing a renewed objective to > the Fedora Council. > > You can read the proposal at: > https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff Is it really good to replace the old objective with the new one? Shouldn't we archive off that one and call this one something else so you can see what was done when? Did you want comments here or on the PR? Or both? (I see a number of folks have commented on the PR... which is awesome!) I really like the goals/ideas here. We definitely need to improve modules. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: YACBSIPT, rawhide ceph build stuck in bodhi, again
On Fri, Sep 20, 2019 at 12:12:58PM -0400, Kaleb Keithley wrote: > Okay. Other builds I've done for f32 (gluster, nfs-ganesha, earlier ceph > builds even) all went straight to stable in bodhi, but this one didn't, > despite waiting several hours. Well, all of those likely were autosubmitted by gating? It looks like you submitted the ceph one manually before the gating could catch it. ;( https://bodhi.fedoraproject.org/updates/FEDORA-2019-6ebb10dcbc "This update was automatically created" https://bodhi.fedoraproject.org/updates/FEDORA-2019-995f3ae953 "This update has been submitted for testing by kkeithle." I know the folks working on gating were trying to make it so this happened before anyone could submit a manual update. It would be nice if it just blocked that entirely. > Then there's the ceph build for f31[1] that's still stuck in pending > testing after two days. I got that one unstuck. > And the ceph build for f30[2] that's been in testing for 15 days that isn't > allowing me push it to stable. > > ??? I think it's due to it being a critical path update... > Thanks for your help though, greatly appreciated. Thanks for bringing this stuff up, we need to improve things. ;( kevin -- > > Regards, > > [1]https://bodhi.fedoraproject.org/updates/FEDORA-2019-62e251afd9 > [2]https://bodhi.fedoraproject.org/updates/FEDORA-2019-f47093cc3d > > -- > > Kaleb signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Automation ignores FTBFS guidelines
On 9/22/19 4:08 PM, Miro Hrončok wrote: On 22. 09. 19 16:01, Till Hofmann wrote: So the guidelines allow package retirement without any announcement on devel. That's certainly unexpected, at least to me. I also don't think this is a good idea, because maintainers of packages that depend on the retired package are still clueless until it's too late. Or do they get a separate notification? I still find it somewhat inconsistent that basically every rule in the FTBFS guidelines is about notifying people, but (7) allows retirement without any prequisites other than being FTBFS for 2 releases -- no announcement, no orphaning. Yes, I agree. That's why I've started: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/ Ah yes, I now remember reading this. I'll add to if I have anything to add. Apologies for blaming this on the scripts! Kind regards, Till ___ 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: Automation ignores FTBFS guidelines
On 22. 09. 19 16:01, Till Hofmann wrote: So the guidelines allow package retirement without any announcement on devel. That's certainly unexpected, at least to me. I also don't think this is a good idea, because maintainers of packages that depend on the retired package are still clueless until it's too late. Or do they get a separate notification? I still find it somewhat inconsistent that basically every rule in the FTBFS guidelines is about notifying people, but (7) allows retirement without any prequisites other than being FTBFS for 2 releases -- no announcement, no orphaning. Yes, I agree. That's why I've started: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20190922.n.1 changes
OLD: Fedora-Rawhide-20190921.n.0 NEW: Fedora-Rawhide-20190922.n.1 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 8 Dropped packages:15 Upgraded packages: 191 Downgraded packages: 2 Size of added packages: 336.72 MiB Size of dropped packages:1.43 MiB Size of upgraded packages: 2.52 GiB Size of downgraded packages: 475.11 MiB Size change of upgraded packages: 6.82 MiB Size change of downgraded packages: -3.14 MiB = ADDED IMAGES = Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20190922.n.1.aarch64.tar.xz = DROPPED IMAGES = Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-armhfp-Rawhide-20190921.n.0-sda.raw.xz Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20190921.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: glassfish-el-3.0.1-0.12.b08.module_f32+6520+2b0184c9 Summary: J2EE Expression Language Implementation RPMs:glassfish-el glassfish-el-api glassfish-el-javadoc Size:485.35 KiB Package: libusbauth-configparser-1.0.1-1.fc32 Summary: Library for USB Firewall including flex/bison parser RPMs:libusbauth-configparser libusbauth-configparser-devel Size:308.30 KiB Package: nest-2.16.0-11.module_f32+6573+6bea5655 Summary: The neural simulation tool RPMs:nest nest-common nest-doc nest-headers nest-mpich nest-mpich-common nest-mpich-headers nest-openmpi nest-openmpi-common nest-openmpi-headers python3-nest python3-nest-mpich python3-nest-openmpi Size:88.81 MiB Package: openmpi-4.0.2-0.3.rc1.module_f32+6600+2b986227 Summary: Open Message Passing Interface RPMs:openmpi openmpi-devel openmpi-java openmpi-java-devel python2-openmpi python3-openmpi Size:18.99 MiB Package: postgresql-10.10-1.module_f32+6606+44a52e7b Summary: PostgreSQL client programs RPMs:postgresql postgresql-contrib postgresql-docs postgresql-plperl postgresql-plpython postgresql-plpython3 postgresql-pltcl postgresql-server postgresql-server-devel postgresql-static postgresql-test postgresql-test-rpm-macros postgresql-upgrade postgresql-upgrade-devel Size:225.82 MiB Package: rust-lsd-0.16.0-1.module_f32+6545+f3d888a1 Summary: Ls command with a lot of pretty colors and some other stuff RPMs:lsd Size:2.04 MiB Package: usbauth-1.0.1-1.fc32 Summary: USB firewall against BadUSB attacks RPMs:usbauth Size:144.12 KiB Package: usbauth-notifier-1.0-1.fc32 Summary: Notifier for USB Firewall to use with desktop environments RPMs:usbauth-notifier Size:145.46 KiB = DROPPED PACKAGES = Package: python-django-jsonfield-2.0.2-9.fc32 Summary: A reusable Django field that allows you to store validated JSON in your model RPMs:python3-django-jsonfield Size:29.06 KiB Package: python-django-rest-framework-composed-permissions-0.1-10.fc32 Summary: Composed permissions for django-rest-framework RPMs:python3-django-rest-framework-composed-permissions Size:20.71 KiB Package: python-nine-0.3.4-20.fc32 Summary: Python 2 / 3 compatibility, like six, but favouring Python 3 RPMs:python3-nine Size:20.78 KiB Package: python-offtrac-0.1.0-20.fc32 Summary: Trac xmlrpc library RPMs:python3-offtrac Size:18.89 KiB Package: python-tw2-jqplugins-ui-2.3.0-8.fc32 Summary: jQuery UI for ToscaWidgets2 RPMs:python3-tw2-jqplugins-ui Size:483.74 KiB Package: python-zipp-0.5.1-3.fc32 Summary: Backport of pathlib-compatible object wrapper for zip files RPMs:python3-zipp Size:13.57 KiB Package: python-zope-contenttype-4.1.0-14.fc31 Summary: Content-Type Handling Utility RPMs:python3-zope-contenttype Size:26.53 KiB Package: python-zope-datetime-4.1.0-13.fc32 Summary: Zope datetime utilities RPMs:python3-zope-datetime Size:57.09 KiB Package: python-zope-dottedname-4.1.0-16.fc32 Summary: Resolver for Python dotted names RPMs:python3-zope-dottedname Size:17.17 KiB Package: python-zope-filerepresentation-4.1.0-15.fc32 Summary: File-system Representation Interfaces RPMs:python3-zope-filerepresentation Size:18.90 KiB Package: python-zope-i18n-4.1.0-14.fc32 Summary: Zope Internationalization Support RPMs:python-zope-i18n-common python3-zope-i18n Size:382.60 KiB Package: python-zope-processlifetime-2.1.0-11.fc32 Summary: Zope process lifetime events RPMs:python3-zope-processlifetime Size:15.33 KiB Package: python-zope-proxy-4.2.0-10.fc32 Summary: Generic Transparent Proxies RPMs:python3-zope-proxy python3-zope-proxy-devel Size:295.50 KiB Package: python-zope-sequencesort-4.0.1-13.fc32 Summary: Sequence Sorting RPMs:python3-zope-sequencesort Size:24.83 KiB Package: shflags-1.0.3-15.fc31 Summary: Simple handling of command-line flags in Bourne based Unix scripts RPMs:shflags Size:35.64 KiB = UPGRADED PACKAGES = Package: ImageMagick-1:6.9.10.65-1.fc32 Old package: ImageMagick
Re: Automation ignores FTBFS guidelines
On 9/22/19 3:40 PM, Miro Hrončok wrote: On 22. 09. 19 14:37, Till Hofmann wrote: Hi all, So I've just been notified that tolua++ has been retired, which is a dependency of one of my packages (fawkes). BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1736911 I've closed this bug because it "was already retired", not because of that bug. The package was actually retired more than a month ago in here: https://bugzilla.redhat.com/show_bug.cgi?id=1676145#c12 Based on this rule: "7. A week before the mass branching, any packages which still have open FTBFS bugs from the previous release will be retired." I see, so the package was already FTBFS in F30. So the F31 FTBFS was actually a duplicate. It would have helped if it was marked as such, but I understand that's easier said than done. To put it differently, the guidelines were completely ignored. The package was retired 6 days after the initial FTBFS bug, without any announcement. No, they were not ignored at all. The comment "your package has not been built successfully in 31. Action is required from you" isn't helping either, as the package has long been retired at that time. Yes, that's why I closed the bugzilla. See https://pagure.io/releng/issue/8478 So can we please make sure that guidelines apply to everybody, also and especially to scripts? They do. You're right, as this was FTBFS in F30 already, it's all good. So the guidelines allow package retirement without any announcement on devel. That's certainly unexpected, at least to me. I also don't think this is a good idea, because maintainers of packages that depend on the retired package are still clueless until it's too late. Or do they get a separate notification? I still find it somewhat inconsistent that basically every rule in the FTBFS guidelines is about notifying people, but (7) allows retirement without any prequisites other than being FTBFS for 2 releases -- no announcement, no orphaning. Kind regards, Till ___ 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
Fedora-Rawhide-20190922.n.1 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 4 of 45 required tests failed, 11 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 8/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20190921.n.0): ID: 456408 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/456408 ID: 456410 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/456410 ID: 456486 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/456486 ID: 456550 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/456550 Old failures (same test failed in Fedora-Rawhide-20190921.n.0): ID: 456473 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/456473 ID: 456476 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/456476 ID: 456538 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/456538 ID: 456539 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/456539 ID: 456552 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/456552 Soft failed openQA tests: 3/152 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20190921.n.0): ID: 456450 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/456450 Old soft failures (same test soft failed in Fedora-Rawhide-20190921.n.0): ID: 456540 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/456540 ID: 456545 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/456545 Passed openQA tests: 119/152 (x86_64) New passes (same test not passed in Fedora-Rawhide-20190921.n.0): ID: 456442 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/456442 ID: 456443 Test: x86_64 Workstation-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/456443 ID: 456445 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/456445 ID: 456446 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/456446 ID: 456447 Test: x86_64 Workstation-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/456447 ID: 456448 Test: x86_64 Workstation-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/456448 ID: 456449 Test: x86_64 Workstation-live-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/456449 ID: 456451 Test: x86_64 Workstation-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/456451 ID: 456452 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/456452 ID: 456453 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/456453 ID: 456455 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/456455 ID: 456456 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/456456 ID: 456551 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/456551 Skipped gating openQA tests: 9/152 (x86_64) New skipped gating tests (same test not skipped in Fedora-Rawhide-20190921.n.0): ID: 456414 Test: x86_64 Server-dvd-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/456414 ID: 456415 Test: x86_64 Server-dvd-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/456415 ID: 456423 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/456423 ID: 456424 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/456424 ID: 456425 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/456425 ID: 456428 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/456428 ID: 456432 Test: x86_64 Server-dvd-iso
Re: Automation ignores FTBFS guidelines
On 22. 09. 19 15:40, Miro Hrončok wrote: "7. A week before the mass branching, any packages which still have open FTBFS bugs from the previous release will be retired." Whether this is a reasonable thing or not has been discussed in: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NKFYAWL4GWYR37C6XA63JMNBZYEM6BI3/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Automation ignores FTBFS guidelines
On 22. 09. 19 14:37, Till Hofmann wrote: Hi all, So I've just been notified that tolua++ has been retired, which is a dependency of one of my packages (fawkes). BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1736911 I've closed this bug because it "was already retired", not because of that bug. The package was actually retired more than a month ago in here: https://bugzilla.redhat.com/show_bug.cgi?id=1676145#c12 Based on this rule: "7. A week before the mass branching, any packages which still have open FTBFS bugs from the previous release will be retired." To put it differently, the guidelines were completely ignored. The package was retired 6 days after the initial FTBFS bug, without any announcement. No, they were not ignored at all. The comment "your package has not been built successfully in 31. Action is required from you" isn't helping either, as the package has long been retired at that time. Yes, that's why I closed the bugzilla. See https://pagure.io/releng/issue/8478 So can we please make sure that guidelines apply to everybody, also and especially to scripts? They do. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1754282] [RFE] EPEL-8 branch for perl-Compress-LZF
https://bugzilla.redhat.com/show_bug.cgi?id=1754282 Paul Howarth changed: What|Removed |Added Depends On||1753674, 1754281 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1753674 [Bug 1753674] build of liblzf for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1754281 [Bug 1754281] [RFE] EPEL-8 branch for perl-Coro-Multicore -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1754281] [RFE] EPEL-8 branch for perl-Coro-Multicore
https://bugzilla.redhat.com/show_bug.cgi?id=1754281 Paul Howarth changed: What|Removed |Added Blocks||1754282 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1754282 [Bug 1754282] [RFE] EPEL-8 branch for perl-Compress-LZF -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1754282] New: [RFE] EPEL-8 branch for perl-Compress-LZF
https://bugzilla.redhat.com/show_bug.cgi?id=1754282 Bug ID: 1754282 Summary: [RFE] EPEL-8 branch for perl-Compress-LZF Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Compress-LZF Assignee: dd...@cpan.org Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Hi, I need perl-Compress-LZF as a dependency of perl-Cpanel-JSON-XS. It seems to build OK for EPEL-8 once liblzf-devel and perlmulticore-static are available. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1754281] New: [RFE] EPEL-8 branch for perl-Coro-Multicore
https://bugzilla.redhat.com/show_bug.cgi?id=1754281 Bug ID: 1754281 Summary: [RFE] EPEL-8 branch for perl-Coro-Multicore Product: Fedora Version: rawhide Status: NEW Component: perl-Coro-Multicore Assignee: ppi...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora perlmulticore-static (from perl-Coro-Multicore) is a build dependency of perl-Compress-LZF, which I need for perl-Cpanel-JSON-XS. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Automation ignores FTBFS guidelines
On 9/22/19 3:01 PM, Hans de Goede wrote: But I do have something to say about the specific example used. tolua++ being retired is not a problem for fawkes, as fawkes depends on compat-tolua++, which is maintained by me and has NOT been retired. Thanks for pointing this out! I assumed compat-tolua++ was a subpackage of tolua++ (I hadn't actually looked at the spec file 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: Automation ignores FTBFS guidelines
Hi, On 22-09-2019 14:37, Till Hofmann wrote: Hi all, So I've just been notified that tolua++ has been retired, which is a dependency of one of my packages (fawkes). BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1736911 This would have been fine (as no action has been taken), if the automation had actually followed the FTBFS guidelines [1]. But it hasn't, in many ways: 1. "If an FTBFS or FTI bug remains in the NEW state for at least 1 week, any concerned party can set a NEEDINFO for the maintainer to respond and send an e-mail reminder with the Bugzilla link to -maintain...@fedoraproject.org, cc’ing the devel mailing list (so there is a public record) and commenting on the bug about doing so." I did not see such an email on devel. Also NEEDINFO was set on Sep 22, ~10 weeks after retirement. 2. "If the bug remains in NEW state for at least another 4 weeks after the second e-mail and comment (= at least 8 weeks in total), the package will be orphaned. Orphaning can be requested via a releng issue." There was no email at all, at least not to devel, or the maintainers of the dependencies of tolua++. 3. "The normal Orphaned package that needs new maintainers procedure will be followed for the packages orphaned in this way, leading to their retirement if nobody adopts them." This did not happen either. In particular, it was never announced that the package was orphaned. 4. In fact, as far as I can tell, the package was never orphaned, but directly retired. To put it differently, the guidelines were completely ignored. The package was retired 6 days after the initial FTBFS bug, without any announcement. This is in stark contrast to the 14 weeks mentioned in the guidelines. To add to this, the retirement isn't even mentioned in the bug report. It just silently happened. The comment "your package has not been built successfully in 31. Action is required from you" isn't helping either, as the package has long been retired at that time. I understand and support that FTBFS packages are retired, but this is not the way this should work. There was no way I could have heard about the issue in time. It effectively requires me to become co-maintainer on every package that I depend on. Clearly not something I want to do. So can we please make sure that guidelines apply to everybody, also and especially to scripts? I've no opinion on whether the process was followed correctly here (I did not look closely at that part of this email). But I do have something to say about the specific example used. tolua++ being retired is not a problem for fawkes, as fawkes depends on compat-tolua++, which is maintained by me and has NOT been retired. Regards, Hans ___ 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
Automation ignores FTBFS guidelines
Hi all, So I've just been notified that tolua++ has been retired, which is a dependency of one of my packages (fawkes). BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1736911 This would have been fine (as no action has been taken), if the automation had actually followed the FTBFS guidelines [1]. But it hasn't, in many ways: 1. "If an FTBFS or FTI bug remains in the NEW state for at least 1 week, any concerned party can set a NEEDINFO for the maintainer to respond and send an e-mail reminder with the Bugzilla link to -maintain...@fedoraproject.org, cc’ing the devel mailing list (so there is a public record) and commenting on the bug about doing so." I did not see such an email on devel. Also NEEDINFO was set on Sep 22, ~10 weeks after retirement. 2. "If the bug remains in NEW state for at least another 4 weeks after the second e-mail and comment (= at least 8 weeks in total), the package will be orphaned. Orphaning can be requested via a releng issue." There was no email at all, at least not to devel, or the maintainers of the dependencies of tolua++. 3. "The normal Orphaned package that needs new maintainers procedure will be followed for the packages orphaned in this way, leading to their retirement if nobody adopts them." This did not happen either. In particular, it was never announced that the package was orphaned. 4. In fact, as far as I can tell, the package was never orphaned, but directly retired. To put it differently, the guidelines were completely ignored. The package was retired 6 days after the initial FTBFS bug, without any announcement. This is in stark contrast to the 14 weeks mentioned in the guidelines. To add to this, the retirement isn't even mentioned in the bug report. It just silently happened. The comment "your package has not been built successfully in 31. Action is required from you" isn't helping either, as the package has long been retired at that time. I understand and support that FTBFS packages are retired, but this is not the way this should work. There was no way I could have heard about the issue in time. It effectively requires me to become co-maintainer on every package that I depend on. Clearly not something I want to do. So can we please make sure that guidelines apply to everybody, also and especially to scripts? Thanks, Till [1] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ ___ 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
Fedora-31-20190922.n.0 compose check report
No missing expected images. Failed openQA tests: 5/152 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20190921.n.0): ID: 456306 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/456306 ID: 456318 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/456318 ID: 456329 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/456329 Old failures (same test failed in Fedora-31-20190921.n.0): ID: 456283 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/456283 ID: 456319 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/456319 ID: 456322 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/456322 Soft failed openQA tests: 2/152 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-31-20190921.n.0): ID: 456296 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/456296 ID: 456398 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/456398 Passed openQA tests: 145/152 (x86_64) New passes (same test not passed in Fedora-31-20190921.n.0): ID: 456312 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/456312 ID: 456317 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/456317 ID: 456363 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/456363 Skipped non-gating openQA tests: 1 of 154 Installed system changes in test x86_64 Workstation-live-iso install_default_upload: 2 packages(s) added since previous compose: libwpe, wpebackend-fdo Previous test data: https://openqa.fedoraproject.org/tests/455959#downloads Current test data: https://openqa.fedoraproject.org/tests/456288#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: 2 packages(s) added since previous compose: libwpe, wpebackend-fdo 1 services(s) added since previous compose: dbus-:1.8-org.freedesktop.problems@0.service loaded active running dbus-:1.8-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service Previous test data: https://openqa.fedoraproject.org/tests/455961#downloads Current test data: https://openqa.fedoraproject.org/tests/456290#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 2 packages(s) added since previous compose: libwpe, wpebackend-fdo 1 services(s) added since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service 1 services(s) removed since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service System load changed from 1.54 to 1.07 Previous test data: https://openqa.fedoraproject.org/tests/455974#downloads Current test data: https://openqa.fedoraproject.org/tests/456303#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 2 packages(s) added since previous compose: libwpe, wpebackend-fdo 1 services(s) added since previous compose: pcscd.service System load changed from 1.82 to 0.64 Average CPU usage changed from 17.52857143 to 6.42857143 Previous test data: https://openqa.fedoraproject.org/tests/455976#downloads Current test data: https://openqa.fedoraproject.org/tests/456305#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 9 MiB to 4 MiB System load changed from 0.44 to 0.57 Previous test data: https://openqa.fedoraproject.org/tests/455992#downloads Current test data: https://openqa.fedoraproject.org/tests/456321#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Mount /run/user/1000 contents changed to 87.61290323% of previous size Used swap changed from 8 MiB to 4 MiB System load changed from 0.35 to 0.52 Average CPU usage changed from 5.98095238 to 29.22380952 Previous test data: https://openqa.fedoraproject.org/tests/455994#downloads Current test data: https://openqa.fedoraproject.org/tests/456323#downloads Installed system changes in test x86_64 universal install_package_set_kde: 2 packages(s) added since previous
Fedora 31 compose report: 20190922.n.0 changes
OLD: Fedora-31-20190921.n.0
NEW: Fedora-31-20190922.n.0
= SUMMARY =
Added images:0
Dropped images: 9
Added packages: 0
Dropped packages:0
Upgraded packages: 24
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded packages: 623.55 MiB
Size of downgraded packages: 0 B
Size change of upgraded packages: 6.10 MiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
= DROPPED IMAGES =
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-31-20190921.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-31-20190921.n.0.iso
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-31-20190921.n.0-sda.raw.xz
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-31-20190921.n.0.s390x.tar.xz
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190921.n.0.s390x.vmdk
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190921.n.0.s390x.raw.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-31-20190921.n.0.iso
Image: Container_Minimal_Base docker s390x
Path:
Container/s390x/images/Fedora-Container-Minimal-Base-31-20190921.n.0.s390x.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-31-20190921.n.0.s390x.qcow2
= ADDED PACKAGES =
= DROPPED PACKAGES =
= UPGRADED PACKAGES =
Package: ImageMagick-1:6.9.10.64-1.fc31
Old package: ImageMagick-1:6.9.10.28-4.fc31
Summary: An X application for displaying and manipulating images
RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel
ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs
ImageMagick-perl
Size: 39.89 MiB
Size change: -574.39 KiB
Changelog:
* Fri Sep 13 2019 Michael Cronenworth - 1:6.9.10.64-1
- Update to 6.9.10.64
- Set threading option
(https://src.fedoraproject.org/rpms/ImageMagick/pull-request/2)
- Enable more image formats (RHBZ#1485823)
Package: fedora-obsolete-packages-31-34
Old package: fedora-obsolete-packages-31-32
Summary: A package to obsolete retired packages
RPMs: fedora-obsolete-packages
Size: 77.67 KiB
Size change: 589 B
Changelog:
* Wed Sep 18 2019 Zbigniew J??drzejewski-Szmek - 31-33
- Obsolete fedora-release-notes, mono-debugger, python2-pillow-{tk,qt}
* Fri Sep 20 2019 Pete Walter - 31-34
- Bump python2-policycoreutils obsoletes version
Package: ghostscript-9.27-1.fc31
Old package: ghostscript-9.26-6.fc31
Summary: Interpreter for PostScript language & PDF
RPMs: ghostscript ghostscript-core ghostscript-doc ghostscript-gtk
ghostscript-tools-dvipdf ghostscript-tools-fonts ghostscript-tools-printing
ghostscript-x11 libgs libgs-devel
Size: 22.49 MiB
Size change: 56.04 KiB
Changelog:
* Fri Sep 06 2019 Martin Osvald - 9.27-1
- rebase to latest upstream version 9.27
- security fixes added for:
- CVE-2019-14811 (bug #1747908)
- CVE-2019-14812 (bug #1747907)
- CVE-2019-14813 (bug #1747906)
- CVE-2019-14817 (bug #1747909)
Package: gnome-shell-3.34.0-2.fc31
Old package: gnome-shell-3.34.0-1.fc31
Summary: Window management and application launching for GNOME
RPMs: gnome-shell
Size: 7.27 MiB
Size change: -135 B
Changelog:
* Fri Sep 20 2019 Florian M??llner - 3.34.0-2
- Fix disappearing icons in frequent view
Package: ksh-1:2020.0.0-0.4.fc31
Old package: ksh-1:2020.0.0-0.3.fc31
Summary: The Original ATT Korn Shell
RPMs: ksh
Size: 3.93 MiB
Size change: -127.08 KiB
Changelog:
* Tue Sep 03 2019 Siteshwar Vashisht - 1:2020.0.0-0.4
- Rebase to 2020.0.0-beta1
Package: librsvg2-2.46.0-2.fc31
Old package: librsvg2-2.46.0-1.fc31
Summary: An SVG library based on cairo
RPMs: librsvg2 librsvg2-devel librsvg2-tools
Size: 8.42 MiB
Size change: 876 B
Changelog:
* Fri Sep 20 2019 Kalev Lember - 2.46.0-2
- Backport a patch to fix svg rendering in gnome-initial-setup (#1753183)
Package: libvirt-5.6.0-3.fc31
Old package: libvirt-5.6.0-2.fc31
Summary: Library providing a simple virtualization API
RPMs: libvirt libvirt-admin libvirt-bash-completion libvirt-client
libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter
libvirt-daemon-driver-interface libvirt-daemon-driver-libxl
libvirt-daemon-driver-lxc libvirt-daemon-driver-network
libvirt-daemon-driver-nodedev libvirt-daemon-driver-nwfilter
libvirt-daemon-driver-qemu libvirt-daemon-driver-secret
libvirt-daemon-driver-storage libvirt-daemon-driver-storage-core
libvirt-daemon-driver-storage-disk libvirt-daemon-driver-storage-gluster
libvirt-daemon-driver-storage-iscsi libvirt-daemon-driver-storage-iscsi-direct
libvirt-daemon-driver-storage-logical libvirt-daemon-driver-storage-m
Looking for a maintainer for freemedforms
Hello, I am looking to give away freemedforms[1]. It isn't part of our packages for NeuroFedora, and those are what I'd like to focus my limited resources on now. It does not currently build in f31+ and may require dialogue with upstream to fix. https://src.fedoraproject.org/rpms/freemedforms https://bugzilla.redhat.com/show_bug.cgi?id=1735221 Please let me know if you would like to take it up, otherwise I will retire it from Fedora on Friday (27th September). It will get orphaned/retired as part of the FTBFS process otherwise anyway. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Problem with F30 module packages that are built in F32 buildroot (?)
Hi all, We have an odd issue with a module build of sway for F30: It looks like the module was actually built with a F32 buildroot. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1754167 Here's the build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1376355 The modulemd file contains: dependencies: - buildrequires: platform: [f30] requires: platform: [f30] But then, it built packages with f32 in the package version: artifacts: rpms: - mako-0:1.4-1.module_f32+6140+eb754d2b.src - mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64 - mako-debuginfo-0:1.4-1.module_f32+6140+eb754d2b.x86_64 - mako-debugsource-0:1.4-1.module_f32+6140+eb754d2b.x86_64 [and more packages] The package shows up in a F30 repoquery: $ dnf repoquery --releasever=30 mako Last metadata expiration check: 0:08:32 ago on Sun 22 Sep 2019 11:25:43 CEST. mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64 But it requires systemd-libs from F32: $ dnf repoquery --releasever=30 --requires \ mako-0:1.4-1.module_f32+6140+eb754d2b.x86_64 | grep SYSTEMD libsystemd.so.0(LIBSYSTEMD_221)(64bit) libsystemd.so.0(LIBSYSTEMD_222)(64bit) libsystemd.so.0(LIBSYSTEMD_243)(64bit) Can someone tell me what's going on here? Thanks! Till ___ 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: [NeuroFedora] Re: Please welcome @alciregi to the packager group
On Sat, Sep 21, 2019 14:56:36 -0400, Danny Lee wrote: > Congrats Alciregi! And thank you for helping! :) > > Im also interested, my time is limited for a couple of months, but after the > Jan 3, I will have much more time. Welcome @bt0dotninja and @dan1mal too---I've sponsored you now. We can see what packages you could potentially work on at this week's team meeting. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Add a rule to have a compose when Fedora branched
On 22. 09. 19 1:07, Neal Gompa wrote: ok. That does give developers 2 less weeks to finish up any changes (or get FE/blockers for them), but we could do that, sure. What does everyone else think? I'm not really in favor of any more time compressions in the schedule than we already have. It's already pretty hard for me to get what I need done on time in Fedora. Losing the Alpha made things much worse for me personally, as that extra window is just now gone. Losing two more weeks and then going immediately into freeze would make things considerably more difficult, as we lose the window to make last minute corrections before Beta. I don't quite understand where are the 2 weeks gone. 1. we branch. we freeze f31 until successful compose 2. compose runs, it fails, we fix it (things unblocking compose get exceptions) 3. repeat 2. 4. unfreeze This can be any arbitrary amount of time. I would expect it to be couple days, not 2 weeks. Where is 2 weeks coming from? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RPM Fusion Bugzilla Bug 5307
On 9/22/19 3:32 AM, Leigh Scott wrote: I'll just cut to the chase. Rawhide with Nvidia drivers because of debug kernel. There is a lack of software compared to other Linux distros like Ubuntu or Arch(no Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary software. etc. I guess debugging symbols are an alien concept to ArchLinux users as their distro sadly lacks them. There is a repo to provide nodebug kernels for rawhide https://fedoraproject.org/wiki/RawhideKernelNodebug I know but you can't use them with Silverblue. One time I tried and the repos were out of sync despite all meta update info being cleared and fresh. Another time I got farther IIRC but was still blocked by an "replacing forbidden base package error" and wasn't able to get past it. Even if I were to force it, would it cause conflicts and break in the future? ___ 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/22/19 3:08 AM, Leigh Scott wrote: On Sat, Sep 21, 2019 at 8:33 PM Ty Young Do you mean 'Support non-root X'? if so some DM's still don't support it. https://github.com/canonical/lightdm/issues/18 ...and it's Open Source. Ironic. Anyway, I did a google search and apparently running X. Org as user isn't exactly safe either. According to the Gentoo wik[1] a user could snoop on another user's input. It doesn't go into specifics on how these are a big deal, but if they are what's even the point of running non root? Just breaking into the entire system vs. a user? Not a security expert but if you have user permissions you can do anything a user could normally do including rebooting, shuttting down, uploading files to some private server, logging inputs, etc. The user account is the lowest hanging fruit there is from my understanding. [1] https://wiki.gentoo.org/wiki/Non_root_Xorg#Security_concerns This is Nvidia's fault. It was hidden from you because sometimes the packaging for the proprietary Nvidia driver has forced non-rootless Xorg. I guess that's no longer the case, oh well. Talk to the packager for the Nvidia driver, or better yet, talk to Nvidia to get them to support rootless Xorg properly. As far as I know we don't force non-rootless X. I haven't smoked any shrooms yet today(/joke), so it isn't my imagination By default X. Org runs as user but if you follow the Arch wiki you can force it to run as root. Again, this was never an issue during the mid beta but towards the end of the beta or shortly after release something changed. ___ 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 ___ 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: RPM Fusion Bugzilla Bug 5307
> I'll just cut to the chase. > Rawhide with Nvidia drivers because of debug kernel. There is a lack of > software compared to other Linux distros like Ubuntu or Arch(no > Vivaldi!?!?). Fedora developers tend to be hostile towards proprietary > software. etc. I guess debugging symbols are an alien concept to ArchLinux users as their distro sadly lacks them. There is a repo to provide nodebug kernels for rawhide https://fedoraproject.org/wiki/RawhideKernelNodebug ___ 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: RPM Fusion Bugzilla Bug 5307
On Sun, Sep 22, 2019, 10:09 Leigh Scott wrote: > > On Sat, Sep 21, 2019 at 8:33 PM Ty Young wrote: > > Fedora and other distributions have been working on rootless Xorg > > since 2013. We've had it in place since at least 2015. This change was > > made way back in Fedora 24. > > > > Do you mean 'Support non-root X'? if so some DM's still don't support it. > > https://github.com/canonical/lightdm/issues/18 > > > > > This is Nvidia's fault. It was hidden from you because sometimes the > > packaging for the proprietary Nvidia driver has forced non-rootless > > Xorg. I guess that's no longer the case, oh well. Talk to the packager > > for the Nvidia driver, or better yet, talk to Nvidia to get them to > > support rootless Xorg properly. > > As far as I know we don't force non-rootless X. > Right. Last I checked, the Xorg processes on my system (NVIDIA + proprietary drivers) ran as root on fedora 30 Workstation. Fabio ___ > 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 > ___ 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: RPM Fusion Bugzilla Bug 5307
> On Sat, Sep 21, 2019 at 8:33 PM Ty Young Fedora and other distributions have been working on rootless Xorg > since 2013. We've had it in place since at least 2015. This change was > made way back in Fedora 24. > Do you mean 'Support non-root X'? if so some DM's still don't support it. https://github.com/canonical/lightdm/issues/18 > > This is Nvidia's fault. It was hidden from you because sometimes the > packaging for the proprietary Nvidia driver has forced non-rootless > Xorg. I guess that's no longer the case, oh well. Talk to the packager > for the Nvidia driver, or better yet, talk to Nvidia to get them to > support rootless Xorg properly. As far as I know we don't force non-rootless X. ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/22/19 2:40 AM, John M. Harris Jr wrote: On Saturday, September 21, 2019 5:32:37 PM MST Ty Young wrote: I'll just cut to the chase. About 2-3 months ago I filed a bug report that overclocking on Nvidia hardware wasn't working on Fedora. I then later sent an email about this issue wherein Nvidia was immediately blamed for the bug despite this not being an issue on any other Linux distro. It's an issue on several other distros. Basically, anything modern. Please file a bug report with nvidia. Arch Linux and Pop!_OS 19.04 aren't modern? Overclocking on both works perfectly fine. I actually use Arch Linux normally, as said earlier. - - John M. Harris, Jr. Splentity ___ 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On Sunday, September 22, 2019 12:26:46 AM MST Ty Young wrote: > I'm of course also interested in ensuring compatibility with Fedora for > my application but given how hostile y'all are to Nvidia it doesn't seem > like it's ever going to happen. I guess it's not the end of the word > since noone really uses Fedora for gaming but still... if no one at > Fedora wants to support Nvidia then remove their driver from RPM Fusion > already and be done with it. Okay, you just lost the benefit of the doubt here. I'm going to respond to this, and this is my last message to this thread. I hope nvidia can provide you with the assistance you need. The Fedora project is not hostile to nvidia. On the contrary, we'd love to support nvidia GPUs. To that end, we provide up to date packages for the Nouveau driver. Nvidia only releases proprietary blobs, instead of a proper driver. We can't do anything with that. We can't make it compatible with Fedora, because it is proprietary. This has been a problem with nvidia for over a decade, to the point that there is now that famous clip of Torvalds giving nvidia the middle finger. There's just nothing we can do, unfortunately. If whatever application you're talking about is FLOSS, it'll likely not be a problem, as the end user could simply compile your software to run on their system, or install it through the package manager. At worst, they'd have to patch your software to work on an updated system like Fedora. Fedora does not maintain RPMFusion. We literally cannot support nvidia's proprietary drivers, as.. they're proprietary. Have a good one. - - John M. Harris, Jr. Splentity ___ 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: RPM Fusion Bugzilla Bug 5307
On Saturday, September 21, 2019 5:32:37 PM MST Ty Young wrote: > I'll just cut to the chase. > > > About 2-3 months ago I filed a bug report that overclocking on Nvidia > hardware wasn't working on Fedora. > I then later sent an email about this issue wherein Nvidia was immediately > blamed for the bug despite this not being an issue on any other Linux > distro. It's an issue on several other distros. Basically, anything modern. Please file a bug report with nvidia. - - John M. Harris, Jr. Splentity ___ 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: RPM Fusion Bugzilla Bug 5307
On Saturday, September 21, 2019 11:46:40 PM MST Ty Young wrote: > That's a load of bull dung if there ever was one. There are *MANY* bugs > in Intel/AMD's drivers and MESA that have yet to be fixed(which affect > everyone) despite being Open Source. You can't fix those bugs as is but > then turn around and imply that *IF* Nvidia released/contributed to an > Open Source driver these issues wouldn't happen? Really? There are bugs in every software. Currnetly, the Intel drivers are the most stable available on Linux. I don't know what in the world you're talking about. There will never come a day where there are zero bugs in any given complex software. > If this is your piss poor excuse for the binary driver, then what about > the Open Source one? That driver you can change and it's only seemingly > broken because of GRUB boot errors/warnings and a 5 second blank screen > with graphical glitch before showing the shutdown spinner. We can't do anything to help you with the binary driver. Go bug nvidia, they're the only ones that can help you with that. > Those GRUB boot errors/warnings? Yeah, those have existed since Fedora > 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to > hear the excuse for that. What errors or warnings are you talking about? - - John M. Harris, Jr. Splentity ___ 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
[Bug 1751411] perl-Mojolicious-8.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1751411 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mojolicious-8.24-1.fc3 ||2 Resolution|--- |RAWHIDE Last Closed||2019-09-22 07:29:42 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1377556 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: RPM Fusion Bugzilla Bug 5307
On 9/22/19 1:57 AM, Samuel Sieb wrote: On 9/21/19 11:46 PM, Ty Young wrote: That's a load of bull dung if there ever was one. There are *MANY* bugs in Intel/AMD's drivers and MESA that have yet to be fixed(which affect everyone) despite being Open Source. You can't fix those bugs as is but then turn around and imply that *IF* Nvidia released/contributed to an Open Source driver these issues wouldn't happen? Really? Of course there are bugs. But I'm talking about major features like rootless X and various kernel changes where the NVidia driver lags way behind and sometimes doesn't work at all. Lagging behind is as much as a bug as the dozens of bugs in AMD/Intel drivers and MESA. There are graphics cards that probably don't even work entirely still. I remember the R9 390 had issues and probably still does. In those cases you can't even get a bootable system. If this is your piss poor excuse for the binary driver, then what about the Open Source one? That driver you can change and it's only seemingly broken because of GRUB boot errors/warnings and a 5 second blank screen with graphical glitch before showing the shutdown spinner. If you're talking about Nouveau, then yes, it has many issues because it's an attempt at reverse-engineering. They have no documentation, so it's pretty amazing that it works as well as it does. Didn't Nvidia release documentation some time ago? Regardless, there is a lot things envolved with the shutdown process, isn't there? How do you even know it's the driver to begin with? Are we just assuming it is, like we assumed that overclocking was broke because something Nvidia did or does anyone have actual proof? I have a really old second generation Intel laptop that I can test to see if it's reproducible. Those GRUB boot errors/warnings? Yeah, those have existed since Fedora 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to hear the excuse for that. No idea what you're talking about here. I haven't had any issues with grub. There was a boot warning/error about GRUB not being on a FAT filesystem or something before. Now there is something else this install, I think... or maybe it's the same thing. It's hard to read in the short time it appears. Really, calm down. Maybe you should be using Windows instead where everything always works... That was one hell of a good joke. You should be a comedian. Like I said, I'm only interested in Fedora for Silverblue's immutable filesystem, at least from a user's perspective. The Fedora part is almost entirely a negative given all the problems listed earlier. No other active Linux distro has problems with keeping their update servers online, repo desyncing, and/or updating downloadable images on their website like Fedora does and it blows my mind that it's even an issue given it's sponsored by Red Hat. These are all issues that can be easily fixed i'm sure but still, it's very surprising. I'm of course also interested in ensuring compatibility with Fedora for my application but given how hostile y'all are to Nvidia it doesn't seem like it's ever going to happen. I guess it's not the end of the word since noone really uses Fedora for gaming but still... if no one at Fedora wants to support Nvidia then remove their driver from RPM Fusion already and be done with 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 ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/21/19 11:46 PM, Ty Young wrote: That's a load of bull dung if there ever was one. There are *MANY* bugs in Intel/AMD's drivers and MESA that have yet to be fixed(which affect everyone) despite being Open Source. You can't fix those bugs as is but then turn around and imply that *IF* Nvidia released/contributed to an Open Source driver these issues wouldn't happen? Really? Of course there are bugs. But I'm talking about major features like rootless X and various kernel changes where the NVidia driver lags way behind and sometimes doesn't work at all. If this is your piss poor excuse for the binary driver, then what about the Open Source one? That driver you can change and it's only seemingly broken because of GRUB boot errors/warnings and a 5 second blank screen with graphical glitch before showing the shutdown spinner. If you're talking about Nouveau, then yes, it has many issues because it's an attempt at reverse-engineering. They have no documentation, so it's pretty amazing that it works as well as it does. Those GRUB boot errors/warnings? Yeah, those have existed since Fedora 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to hear the excuse for that. No idea what you're talking about here. I haven't had any issues with grub. Really, calm down. Maybe you should be using Windows instead where everything always works... ___ 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: RPM Fusion Bugzilla Bug 5307
On 9/22/19 12:48 AM, Samuel Sieb wrote: On 9/21/19 6:31 PM, Ty Young wrote: Really? It's Nvidia's fault that noone can agree on anything and keep fragmenting the ecosystem in incredibly stupid ways? No, it's NVidia's fault because they refuse to open-source their driver. That means that they always have to play catch-up with every change being made because the ones making the changes can't help them. All the other major drivers work just fine with rootless X. That's a load of bull dung if there ever was one. There are *MANY* bugs in Intel/AMD's drivers and MESA that have yet to be fixed(which affect everyone) despite being Open Source. You can't fix those bugs as is but then turn around and imply that *IF* Nvidia released/contributed to an Open Source driver these issues wouldn't happen? Really? If this is your piss poor excuse for the binary driver, then what about the Open Source one? That driver you can change and it's only seemingly broken because of GRUB boot errors/warnings and a 5 second blank screen with graphical glitch before showing the shutdown spinner. Those GRUB boot errors/warnings? Yeah, those have existed since Fedora 30 released yet haven't been fixed. GRUB is Open Source, so I'd love to hear the excuse for that. ___ 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 ___ 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
