Broken el7 ppc64 koji
Hi. Whats wrong with ppc64 in koji? https://koji.fedoraproject.org/koji/taskinfo?taskID=31454970 https://kojipkgs.fedoraproject.org//work/tasks/4970/31454970/root.log DEBUG util.py:439: Error: Package: wxGTK3-3.0.2-15.el7.ppc64 (build) DEBUG util.py:439: Requires: libmspack.so.0()(64bit) Other arches build normally. ___ 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: Orphaning pykka
pykka is now back in rawhide. ___ 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: Why is bugzilla spamming me?
Did you report a bug? Well, the new bugzilla is obviously still in Beta. I experience another bug with an odd timeout issue to autofill the dropdown boxes, after another reload it magically works. ___ 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
Why is bugzilla spamming me?
I'm currently getting up to 9 emails per new issue, each attachment generates a separate email! This needs fixing now/yesterday, if it continues I will pipe all bugzilla mail to spam. ___ 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: Orphaning pykka
On Wed, 2018-12-12 at 06:10 +, Raphael Groner wrote: > > I've just orphaned pykka ( > > https://admin.fedoraproject.org/pkgdb/package > > /rpms/pykka/) as I'm no longer using it. > > Hi Jonathan, > what do you use instead? > Regards, Raphael MPD with local music. Jonathan ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Thu, Dec 13, 2018 at 2:30 PM, stan wrote: Latency statistics: min max avg std_dev conf99% 1.51 2.583 1.925330.576087 11.5249 Looks like this is what we want for Workstation, where latency is more important than throughput? ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Thu, 13 Dec 2018 19:59:14 +0100 Paolo Valente wrote: > > Il giorno 13 dic 2018, alle ore 18:34, stan > > ha scritto: > > > > On Thu, 13 Dec 2018 17:46:30 +0100 > > Paolo Valente wrote: > > > >>> Il giorno 13 dic 2018, alle ore 17:41, stan > >>> ha scritto: > >>> > > > >> You don't have bfq for a comparison, but you can still get an idea > >> of how good your system is, by comparing these start-up times with > >> how long the same application takes to start when there is no > >> I/O. Just do > >> > >> sudo ./comm_startup_lat.sh 0 0 seq 3 > >> "replay-startup-io gnometerm" > >> > > cfq with the above command (without I/O): *BIG* difference. > > > > Great! (for bfq :) ) > > > Latency statistics: > > min max avg std_dev conf99% > >1.34 1.704 1.533670.183118 3.66336 > > Aggregated throughput: > > min max avg std_dev conf99% > > 08.03 5.23143 2.60745 15.4099 > > Read throughput: > > min max avg std_dev conf99% > > 08.03 5.22571 2.60522 15.3967 > > Write throughput: > > min max avg std_dev conf99% > > 00.02 0.00571429 0.00786796 0.0464991 > > > >> and get ready to be surprised (next surprise when/if you'll try > >> with bfq ...) > > > > I had a response saying that bfq isn't available for single queue > > devices, but there might be a workaround. So it might or might not > > happen, depending on whether I can get it working. > > > > Actually, there's still a little confusion on this point. First, > blk-mq *is not* only for multi-queue devices. blk-mq is for any kind > of block device. If you have a fast, single-queue SSD, then > blk-mq is likely to make it go faster. If you have a multi-queue > drive, which implicitly means that your drive is very fast (according > to the current standards for 'fast'), then it is 100% sure that > blk-mq is the only way to utilize a high portion of the max speed of > your multi-queue monster. > > To use blk-mq, i.e., to have blk-mq handle your storage, you need > (only) to tell the I/O stack that you want blk-mq to manage the I/O > for the driver of your storage. In this respect, SCSI is for sure the > most used generic storage driver. So, according to the instructions > already provided by others, you can have blk-mq handle your storage > device by, e.g., adding "scsi_mod.use_blk_mq=y" as kernel boot option. > Such a choice of yours is not constrained, in any respect, by the > nature of your drive, be it an SD Card, eMMC, HDD, SSD or whatever > you want. As for multi-queue devices, they are handled by the > NVMe driver, and for that one only blk-mq is available. > > Once you have switched to blk-mq for your drive, you will have the set > of I/O schedulers that live in blk-mq. bfq is among these schedulers. > Actually, there is also an out-of-tree bfq available also for the good > old legacy block, but this is another story. > > Finally, from 4.21 there will be no legacy block any longer. Only > blk-mq will be available, so only blk-mq I/O schedulers will be > available. And finally, once I added scsi_mod.use_blk_mq=y to the kernel command line, I was able to set bfq for my I/O scheduler (for me, under blk-mq there is only none or bfq). Here are the results of your utility using bfq. The latency nearly matches no I/O load. Thanks for writing a utility that is so easy to use, and allows the evaluation of different schedulers. bfq Latency statistics: min max avg std_dev conf99% 1.51 2.583 1.925330.576087 11.5249 Aggregated throughput: min max avg std_dev conf99% 30.12 142.3 73.5314 45.6032 269.512 Read throughput: min max avg std_dev conf99% 26.45 136.92 69.5629 44.7932 264.725 Write throughput: min max avg std_dev conf99% 2.445.38 3.968570.948603 5.60619 > >>> cfq > >>> > >>> Latency statistics: > >>>min max avg std_dev conf99% > >>> 22.142 27.157 24.1967 2.6273 52.5604 > >>> Aggregated throughput: > >>>min max avg std_dev conf99% > >>> 67.29 139.74 105.491 19.245 39.7628 > >>> Read throughput: > >>>min max avg std_dev conf99% > >>> 51.73 135.67 102.402 21.3985 44.2123 > >>> Write throughput: > >>>min max avg std_dev conf99% > >>> 0.01 46.29 3.08857 8.37179 17.2972 > >>> > >>> noop > >>> > >>> Latency statistics: > >>>min max avg std_dev conf99% > >>> 40.861 42.021 41.36370.595266 11.9086 > >
Re: How to avoid re-generating Pagure API keys all the time?
On 12/13/18 11:50 AM, Ken Dreyer wrote: > I would love to help bring back the birds-eye view dashboard that > pkgdb provided for things like "how many packages does X person > maintain", https://src.fedoraproject.org/user/ktdreyer You maintain 62 packages (or are co-maintainer, etc) > or "who is on the watch list for X component in Bugzilla". https://src.fedoraproject.org/api/0/rpms/ansible/watchers shows the users who are watching the 'ansible' package. > Maybe we could build that into the fedora-packages application ? I > know the Infra team doesn't need more new apps to run :) It could also be there and query pagure. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: How to avoid re-generating Pagure API keys all the time?
On Thu, Dec 13, 2018 at 4:14 AM Nicolas Mailhot wrote: > Not treating it as a community objective is how we got in a situation, > where upstreams (including @rh upstreams) want nothing to do with rpms > and Fedora, and invent their own packaging tech to bypass Linux > distributions completely. They're not doing it for lofty theoretical > reasons. Those are added later as PC justifications. The root cause of > why they behave like this, is that they feel, the packager experience > Fedora (or Debian, or Ubuntu) sucks loads. It used not to suck, when it > matched perfectly c/c++ autotools needs, and then it slowly degraded as > things were not updated to match new needs and packagers were asked to > fill in the gaps. The dynamic that you've described about upstreams matches my experience. If we do have some kind of "packager experience" SIG, I would like to be a part of it. I would love to help bring back the birds-eye view dashboard that pkgdb provided for things like "how many packages does X person maintain", or "who is on the watch list for X component in Bugzilla". Maybe we could build that into the fedora-packages application ? I know the Infra team doesn't need more new apps to run :) - Ken ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
> Il giorno 13 dic 2018, alle ore 18:34, stan ha > scritto: > > On Thu, 13 Dec 2018 17:46:30 +0100 > Paolo Valente wrote: > >>> Il giorno 13 dic 2018, alle ore 17:41, stan >>> ha scritto: >>> > >> You don't have bfq for a comparison, but you can still get an idea of >> how good your system is, by comparing these start-up times with how >> long the same application takes to start when there is no I/O. Just >> do >> >> sudo ./comm_startup_lat.sh 0 0 seq 3 >> "replay-startup-io gnometerm" >> > cfq with the above command (without I/O): *BIG* difference. > Great! (for bfq :) ) > Latency statistics: > min max avg std_dev conf99% >1.34 1.704 1.533670.183118 3.66336 > Aggregated throughput: > min max avg std_dev conf99% > 08.03 5.23143 2.60745 15.4099 > Read throughput: > min max avg std_dev conf99% > 08.03 5.22571 2.60522 15.3967 > Write throughput: > min max avg std_dev conf99% > 00.02 0.00571429 0.00786796 0.0464991 > >> and get ready to be surprised (next surprise when/if you'll try with >> bfq ...) > > I had a response saying that bfq isn't available for single queue > devices, but there might be a workaround. So it might or might not > happen, depending on whether I can get it working. > Actually, there's still a little confusion on this point. First, blk-mq *is not* only for multi-queue devices. blk-mq is for any kind of block device. If you have a fast, single-queue SSD, then blk-mq is likely to make it go faster. If you have a multi-queue drive, which implicitly means that your drive is very fast (according to the current standards for 'fast'), then it is 100% sure that blk-mq is the only way to utilize a high portion of the max speed of your multi-queue monster. To use blk-mq, i.e., to have blk-mq handle your storage, you need (only) to tell the I/O stack that you want blk-mq to manage the I/O for the driver of your storage. In this respect, SCSI is for sure the most used generic storage driver. So, according to the instructions already provided by others, you can have blk-mq handle your storage device by, e.g., adding "scsi_mod.use_blk_mq=y" as kernel boot option. Such a choice of yours is not constrained, in any respect, by the nature of your drive, be it an SD Card, eMMC, HDD, SSD or whatever you want. As for multi-queue devices, they are handled by the NVMe driver, and for that one only blk-mq is available. Once you have switched to blk-mq for your drive, you will have the set of I/O schedulers that live in blk-mq. bfq is among these schedulers. Actually, there is also an out-of-tree bfq available also for the good old legacy block, but this is another story. Finally, from 4.21 there will be no legacy block any longer. Only blk-mq will be available, so only blk-mq I/O schedulers will be available. Thanks for trying my tests, Paolo >>> cfq >>> >>> Latency statistics: >>>min max avg std_dev conf99% >>> 22.142 27.157 24.1967 2.6273 52.5604 >>> Aggregated throughput: >>>min max avg std_dev conf99% >>> 67.29 139.74 105.491 19.245 39.7628 >>> Read throughput: >>>min max avg std_dev conf99% >>> 51.73 135.67 102.402 21.3985 44.2123 >>> Write throughput: >>>min max avg std_dev conf99% >>> 0.01 46.29 3.08857 8.37179 17.2972 >>> >>> noop >>> >>> Latency statistics: >>>min max avg std_dev conf99% >>> 40.861 42.021 41.36370.595266 11.9086 >>> Aggregated throughput: >>>min max avg std_dev conf99% >>> 45.66 72.89 55.9847 5.99054 9.87365 >>> Read throughput: >>>min max avg std_dev conf99% >>> 41.69 70.85 51.9495 6.02467 9.9299 >>> Write throughput: >>>min max avg std_dev conf99% >>> 0 7.9 4.03527 1.62392 2.67656 > ___ > 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 ___ 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_g
Re: Backwards incompatible changes planned for Bodhi 4.0.0
On Thu, Dec 13, 2018 at 09:36:09AM -0500, Randy Barlow wrote: > On Thu, 2018-12-13 at 01:40 +, Peter Robinson wrote: > > Is there an executive summary as to what's backwards incompatible and > > what the impact on the average user is? A quick look at the kanban > > doesn't give me any understanding :) > > Each of the issues on the kanban board is a proposal to make a > backwards incompatible change. I have not written any summary other > than to gather those together in a kanban. Many of them are removing > code that I don't believe is used (but that will have an effect on the > REST API, or will require admin intervention to upgrade). > > Bodhi has many types of users, from release engineers, to admins, to > packagers, to integrators, to testers. > > Here are some of the proposals I'd draw the most attention to: > > * Drop the update title (a list of NVRs that is very buggy) as the > Update's primary key, and instead use the update alias (the string > that looks like FEDORA-2018-abcde) as the only identifier[0]. +1. For big updates the title is completely useless (e.g. kde updates with 100+ packages). > * Drop Python 2 support in the client[1] (we will need some > dependencies to move to Python 3 to bring this to Rawhide.) +1, by the time bodhi 4 is out, a large part of the python2 stack will be gone. > * Switch to OpenID Connect[2], which will require backwards > incompatible changes in the authentication API and possibly in the > Python bindings to the REST API[2]. Sounds good. > * Drop anonymous comments[3] - you can't ask follow up questions > because anonymous users don't get e-mails. It's not a very useful > feature. +1. In my experience those happen much more often because people forget to log in than because they actually want to post anonymously. > * Change how the edit APIs work so that a diff is sent rather than the > entire set of fields[4]. > * Remove critpath karma[5]. +1. I know it has some uses, adamw recently pointed some out, but I don't think the balance is strongly on the side of not needing that field. Zbyszek ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Thu, 13 Dec 2018 17:46:30 +0100 Paolo Valente wrote: > > Il giorno 13 dic 2018, alle ore 17:41, stan > > ha scritto: > > > You don't have bfq for a comparison, but you can still get an idea of > how good your system is, by comparing these start-up times with how > long the same application takes to start when there is no I/O. Just > do > > sudo ./comm_startup_lat.sh 0 0 seq 3 > "replay-startup-io gnometerm" > cfq with the above command (without I/O): *BIG* difference. Latency statistics: min max avg std_dev conf99% 1.34 1.704 1.533670.183118 3.66336 Aggregated throughput: min max avg std_dev conf99% 08.03 5.23143 2.60745 15.4099 Read throughput: min max avg std_dev conf99% 08.03 5.22571 2.60522 15.3967 Write throughput: min max avg std_dev conf99% 00.02 0.00571429 0.00786796 0.0464991 > and get ready to be surprised (next surprise when/if you'll try with > bfq ...) I had a response saying that bfq isn't available for single queue devices, but there might be a workaround. So it might or might not happen, depending on whether I can get it working. > > cfq > > > > Latency statistics: > > min max avg std_dev conf99% > > 22.142 27.157 24.1967 2.6273 52.5604 > > Aggregated throughput: > > min max avg std_dev conf99% > > 67.29 139.74 105.491 19.245 39.7628 > > Read throughput: > > min max avg std_dev conf99% > > 51.73 135.67 102.402 21.3985 44.2123 > > Write throughput: > > min max avg std_dev conf99% > >0.01 46.29 3.08857 8.37179 17.2972 > > > > noop > > > > Latency statistics: > > min max avg std_dev conf99% > > 40.861 42.021 41.36370.595266 11.9086 > > Aggregated throughput: > > min max avg std_dev conf99% > > 45.66 72.89 55.9847 5.99054 9.87365 > > Read throughput: > > min max avg std_dev conf99% > > 41.69 70.85 51.9495 6.02467 9.9299 > > Write throughput: > > min max avg std_dev conf99% > > 0 7.9 4.03527 1.62392 2.67656 ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Thu, 13 Dec 2018 17:24:21 +0100 Tomasz Torcz wrote: > On Wed, Dec 12, 2018 at 04:30:20PM -0700, stan wrote: > > Enabled deadline and cfq again, but still no bfq available. > > $ cat /sys/block/sda/queue/scheduler > > noop deadline [cfq] > > Those are single-queue scheduler. Multiqueue uses different > schedulers: bfq, kyber, mq-deadline. MQ schedulers won't appear on > single-queue devices even if you modprobe such schedulers. > You probably need “scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y” kernel > commandline options, although I think those are default in recent > kernels. Thanks. I got the impression from the documentation I read that BFQ operated for both mq and single queue. In fact, IIRC it actually degraded mq performance slightly, but enhanced single queue performance. I guess I was wrong. I'll try the above to see if it enables me to use bfq on single queue devices. ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
> Il giorno 13 dic 2018, alle ore 17:53, stan ha > scritto: > > On Thu, 13 Dec 2018 13:42:24 +0100 > Paolo Valente wrote: > >> To test the behavior of your system, why don't you check, e.g., how >> long it takes to start an application while there is some background >> I/O? >> >> A super quick way to do this is >> >> git clone https://github.com/Algodev-github/S >> cd S/comm_startup_lat >> sudo ./comm_startup_lat.sh 5 5 seq 3 >> "replay-startup-io gnometerm" >> >> The last command line >> - starts the reading of 5 files plus the writing of 5 other files >> - replays, for three times, the I/O that gnome terminal does while; >> starting up (if you want I can tell you how to change the last >> command line so as to execute the original application, but you would >> get the same results); >> - for each attempt, measures how long this start-up I/O takes to >> complete. > > Just a note: I would feel a lot more comfortable with this utility if > it didn't have to run as root. Paranoia. Could you add the > functionality that if it is run as a normal user, it tests the I/O > scheduling scheme currently enabled. That is, it checks if it is > running as root. If it isn't, it just uses whatever I/O scheduler is > currently set, ignoring any parameter on the command line. Running as > root, it behaves exactly as it does now. > > The user would be responsible for issuing the > > echo > > /sys/block//queue/scheduler > > as root if they wanted to run as a normal user. I do agree with your point, and I already tried to make this run as non root. The actual problem is not the scheduler switch, but the need to drop caches before every start-up attempt. Without that, only the first attempt might be reliable, in case data are not already in the cache even at the first iteration. To drop caches, it seems necessary to be root. Any suggestion to work around this issue would super welcome! Thanks, Paolo > ___ > kernel mailing list -- ker...@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/ker...@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://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: How to use %license: with a license file ?
On Thu, Dec 13, 2018, 17:52 J. Scheurich https://bugzilla.redhat.com/show_bug.cgi?id=1653481 > > COPYING.txt must be installed with %license not %doc. > > But %License: only accepts things like GPLv3+ or am i wrong ? > You're talking about two different things: - The "License:" tag, which contains a textual description of the package's license, and - the "%license" annotation for files listed in "%files". So, just replace "%doc COPYING.txt" with "%license COPYING.txt". Fabio > so long > MUFTI > ___ > 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 > ___ 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: How to use %license: with a license file ?
On Thu, 2018-12-13 at 17:51 +0100, J. Scheurich wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1653481 > > COPYING.txt must be installed with %license not %doc. > > But %License: only accepts things like GPLv3+ or am i wrong ? > > so long > MUFTI Hi, you are confusing "License" tag with "%license" directive of %files section. See Licensing Guidelines [1] for more info. Regards, Nikola [1] https://fedoraproject.org/wiki/Packaging:LicensingGuidelines ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Thu, 13 Dec 2018 13:42:24 +0100 Paolo Valente wrote: > To test the behavior of your system, why don't you check, e.g., how > long it takes to start an application while there is some background > I/O? > > A super quick way to do this is > > git clone https://github.com/Algodev-github/S > cd S/comm_startup_lat > sudo ./comm_startup_lat.sh 5 5 seq 3 > "replay-startup-io gnometerm" > > The last command line > - starts the reading of 5 files plus the writing of 5 other files > - replays, for three times, the I/O that gnome terminal does while; > starting up (if you want I can tell you how to change the last > command line so as to execute the original application, but you would > get the same results); > - for each attempt, measures how long this start-up I/O takes to > complete. Just a note: I would feel a lot more comfortable with this utility if it didn't have to run as root. Paranoia. Could you add the functionality that if it is run as a normal user, it tests the I/O scheduling scheme currently enabled. That is, it checks if it is running as root. If it isn't, it just uses whatever I/O scheduler is currently set, ignoring any parameter on the command line. Running as root, it behaves exactly as it does now. The user would be responsible for issuing the echo > /sys/block//queue/scheduler as root if they wanted to run as a normal user. ___ 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
How to use %license: with a license file ?
https://bugzilla.redhat.com/show_bug.cgi?id=1653481 COPYING.txt must be installed with %license not %doc. But %License: only accepts things like GPLv3+ or am i wrong ? so long MUFTI ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
> Il giorno 13 dic 2018, alle ore 17:41, stan ha > scritto: > > On Thu, 13 Dec 2018 13:42:24 +0100 > Paolo Valente wrote: > >> To test the behavior of your system, why don't you check, e.g., how >> long it takes to start an application while there is some background >> I/O? >> >> A super quick way to do this is >> >> git clone https://github.com/Algodev-github/S >> cd S/comm_startup_lat >> sudo ./comm_startup_lat.sh 5 5 seq 3 >> "replay-startup-io gnometerm" >> >> The last command line >> - starts the reading of 5 files plus the writing of 5 other files >> - replays, for three times, the I/O that gnome terminal does while; >> starting up (if you want I can tell you how to change the last >> command line so as to execute the original application, but you would >> get the same results); >> - for each attempt, measures how long this start-up I/O takes to >> complete. > > Results for cfq and noop, haven't enabled bfq yet. I interpret these > as showing that cfq was a large improvement for all categories except > write throughput, where it actually degraded performance. > Great! You don't have bfq for a comparison, but you can still get an idea of how good your system is, by comparing these start-up times with how long the same application takes to start when there is no I/O. Just do sudo ./comm_startup_lat.sh 0 0 seq 3 "replay-startup-io gnometerm" and get ready to be surprised (next surprise when/if you'll try with bfq ...) Thanks, Paolo > cfq > > Latency statistics: > min max avg std_dev conf99% > 22.142 27.157 24.1967 2.6273 52.5604 > Aggregated throughput: > min max avg std_dev conf99% > 67.29 139.74 105.491 19.245 39.7628 > Read throughput: > min max avg std_dev conf99% > 51.73 135.67 102.402 21.3985 44.2123 > Write throughput: > min max avg std_dev conf99% >0.01 46.29 3.08857 8.37179 17.2972 > > noop > > Latency statistics: > min max avg std_dev conf99% > 40.861 42.021 41.36370.595266 11.9086 > Aggregated throughput: > min max avg std_dev conf99% > 45.66 72.89 55.9847 5.99054 9.87365 > Read throughput: > min max avg std_dev conf99% > 41.69 70.85 51.9495 6.02467 9.9299 > Write throughput: > min max avg std_dev conf99% > 0 7.9 4.03527 1.62392 2.67656 > ___ > 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 ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Thu, 13 Dec 2018 13:42:24 +0100 Paolo Valente wrote: > To test the behavior of your system, why don't you check, e.g., how > long it takes to start an application while there is some background > I/O? > > A super quick way to do this is > > git clone https://github.com/Algodev-github/S > cd S/comm_startup_lat > sudo ./comm_startup_lat.sh 5 5 seq 3 > "replay-startup-io gnometerm" > > The last command line > - starts the reading of 5 files plus the writing of 5 other files > - replays, for three times, the I/O that gnome terminal does while; > starting up (if you want I can tell you how to change the last > command line so as to execute the original application, but you would > get the same results); > - for each attempt, measures how long this start-up I/O takes to > complete. Results for cfq and noop, haven't enabled bfq yet. I interpret these as showing that cfq was a large improvement for all categories except write throughput, where it actually degraded performance. cfq Latency statistics: min max avg std_dev conf99% 22.142 27.157 24.1967 2.6273 52.5604 Aggregated throughput: min max avg std_dev conf99% 67.29 139.74 105.491 19.245 39.7628 Read throughput: min max avg std_dev conf99% 51.73 135.67 102.402 21.3985 44.2123 Write throughput: min max avg std_dev conf99% 0.01 46.29 3.08857 8.37179 17.2972 noop Latency statistics: min max avg std_dev conf99% 40.861 42.021 41.36370.595266 11.9086 Aggregated throughput: min max avg std_dev conf99% 45.66 72.89 55.9847 5.99054 9.87365 Read throughput: min max avg std_dev conf99% 41.69 70.85 51.9495 6.02467 9.9299 Write throughput: min max avg std_dev conf99% 0 7.9 4.03527 1.62392 2.67656 ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
> Il giorno 13 dic 2018, alle ore 17:17, stan ha > scritto: > > On Thu, 13 Dec 2018 13:42:24 +0100 > Paolo Valente wrote: > >> To test the behavior of your system, why don't you check, e.g., how >> long it takes to start an application while there is some background >> I/O? >> >> A super quick way to do this is >> >> git clone https://github.com/Algodev-github/S >> cd S/comm_startup_lat >> sudo ./comm_startup_lat.sh 5 5 seq 3 >> "replay-startup-io gnometerm" >> >> The last command line >> - starts the reading of 5 files plus the writing of 5 other files >> - replays, for three times, the I/O that gnome terminal does while; >> starting up (if you want I can tell you how to change the last >> command line so as to execute the original application, but you would >> get the same results); >> - for each attempt, measures how long this start-up I/O takes to >> complete. > > Thanks for this. I suspect I wasn't really stressing my system when I > was evaluating it, and it was subjective. I'm running a kernel with cfq > right now, but I will boot the noop kernel when I get a chance and test > it. I suppose I could just switch to noop io scheduling instead. > Should be interesting. Consider that noop means legacy block too. From 4.21, the equivalent of noop will be none, in blk-mq. At any rate, you can do these tests with cfq too. Results may surprise you ... And, if results will feel like just numbers to you, I'll tell you how to change the command line for starting real applications. Thanks, Paolo > ___ > kernel mailing list -- ker...@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/ker...@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://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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Wed, Dec 12, 2018 at 04:30:20PM -0700, stan wrote: > On Wed, 12 Dec 2018 14:41:37 -0700 > stan wrote: > > > On Wed, 12 Dec 2018 16:07:49 -0500 > > Jeff Moyer wrote: > > > > Thanks for your insight. Doesn't look good for my use of BFQ. > > > > > Note that you can change the current I/O scheduler for any block > > > device by echo-ing into /sys/block//queue/scheduler. Cat-ing > > > that file will give you the list of available schedulers. > > > > That's part of the problem. BFQ doesn't appear in the list of > > available schedulers. When I cat that location for my disks, I see > > [noop]. Since CFQ does appear there if it is compiled into the > > kernel, I'll have to look into what is done for CFQ and see how hard > > it would be to patch the kernel to repeat that behavior for BFQ. > > Enabled deadline and cfq again, but still no bfq available. > $ cat /sys/block/sda/queue/scheduler > noop deadline [cfq] Those are single-queue scheduler. Multiqueue uses different schedulers: bfq, kyber, mq-deadline. MQ schedulers won't appear on single-queue devices even if you modprobe such schedulers. You probably need “scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y” kernel commandline options, although I think those are default in recent kernels. -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ 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: How to avoid re-generating Pagure API keys all the time?
On Thu, 13 Dec 2018 at 06:15, Nicolas Mailhot wrote: > > Le 2018-12-12 18:49, Kevin Fenzi a écrit : > > On 12/12/18 4:10 AM, Ben Rosser wrote: > > then > > finding out what it would take to solve each and helping create and > > land > > fixes for them, be that a pagure bugfix or a workflow change or > > whatever. > > … but only if there is an effort at the Fedora level to act on this > list. That's means infra time, and that means Fedora leadership time to > make sure infra has this time and actually uses it to fix the issues > packagers reported. > Having played this game also several times.. as soon as people aren't still able to do what they were doing already we get variations of the following: "What do you mean we only have 4/5ths of the builders so you can work out how to make the new system work at scale.. I don't care, move it back" "What do you mean that I have to do these new steps because it will drop the amount of time rawhide or a release is broken. I don't give a crap about rawhide or the releases. I want my package built now because I have other things to do!" "When I said I wanted less breakage I didn't meant my packages, I meant those people using that which are always breaking things for my builds. Those are the extremes which people remember, but all the little ones about "why do builds take so long?" "does infra actually do anything?" "ugh another packaging change, why are they making it so hard." adds up also. Eventually people working things (or the leadership) gets tired of 400 packagers grousing and says "that's enough.. just keep doing what you were doing.. we will try this again later." So we like many middle aged communities, end up in a state where we have found a local minima of grumpiness. People dislike where we are, but every change seems to make things worse enough that people just want what they had more. We think that the reason no one wants to live around us anymore is because 'the other people' cause so much noise, without realizing that is our own constant low-level complaining about everything which people are tired of. This is going to take more than infrastructure to fix. This is going to take more than our managers telling us to fix them. It is going to take everyone to not just list the problems, but go over them, triage them and come up with what level of pain they are willing to live with while it is getting worked on. > Been there, done that, not interested in filling new issues no one wants > to work on or look at. Already doing too much of that lately. > > Regards, > > -- > Nicolas Mailhot > ___ > 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 -- Stephen J Smoogen. ___ 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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
On Thu, 13 Dec 2018 13:42:24 +0100 Paolo Valente wrote: > To test the behavior of your system, why don't you check, e.g., how > long it takes to start an application while there is some background > I/O? > > A super quick way to do this is > > git clone https://github.com/Algodev-github/S > cd S/comm_startup_lat > sudo ./comm_startup_lat.sh 5 5 seq 3 > "replay-startup-io gnometerm" > > The last command line > - starts the reading of 5 files plus the writing of 5 other files > - replays, for three times, the I/O that gnome terminal does while; > starting up (if you want I can tell you how to change the last > command line so as to execute the original application, but you would > get the same results); > - for each attempt, measures how long this start-up I/O takes to > complete. Thanks for this. I suspect I wasn't really stressing my system when I was evaluating it, and it was subjective. I'm running a kernel with cfq right now, but I will boot the noop kernel when I get a chance and test it. I suppose I could just switch to noop io scheduling instead. Should be interesting. ___ 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: How to avoid re-generating Pagure API keys all the time?
On 12/13/18 3:14 AM, Nicolas Mailhot wrote: > Le 2018-12-12 18:49, Kevin Fenzi a écrit : ..snip... > >> IMHO, it mostly needs people spending time and driving it. First, >> gathering a list of issues that are non ideal for maintainers, > > That's quite easy to do and you'll find no end of volunteers to document > their packaging roadblocks. And they're not limited to the pagure behavior… Thats not what I am asking for. A flood of untriaged issues is going to hinder rather than help. >> then >> finding out what it would take to solve each and helping create and land >> fixes for them, be that a pagure bugfix or a workflow change or whatever. > > … but only if there is an effort at the Fedora level to act on this > list. That's means infra time, and that means Fedora leadership time to > make sure infra has this time and actually uses it to fix the issues > packagers reported. > > Been there, done that, not interested in filling new issues no one wants > to work on or look at. Already doing too much of that lately. What I was asking for was a prioritized list of triaged issues. This would help greatly in fixing things that would have the most impact. If we can't fix everything, lets at least fix the most painful things first. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: How to avoid re-generating Pagure API keys all the time?
On 12/13/18 2:34 AM, Ben Rosser wrote: ...snip... > Sure, I agree that this is what needs to be done. But I don't think it > is going to happen on its own without some sort of organization to > make it happen, and to try and organize/focus the work. I don't know > if that organization requires an Objective to make happen, but I think > it would be nice to enshrine this as one of our medium-term goals. If an objective is what the folks organizing and doing this want, thats fine with me. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: fedpkg build disconnects?
* Richard Shaw:
> I've never had this problem before but for the last week or so I frequently
> get the following
> at some point before the build completes:
>
> Could not execute build: ('Connection aborted.',
> RemoteDisconnected('Remote end closed connection without response'))
The Python 3 implementation of the Koji libraries is buggy. I think
it's this bug:
Thanks,
Florian
___
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: fedpkg build disconnects?
On Thu, 13 Dec 2018, Richard Shaw wrote:
I've never had this problem before but for the last week or so I frequently
get the following at some point before the build completes:
Could not execute build: ('Connection aborted.', RemoteDisconnected('Remote
end closed connection without response'))
I know it doesn't affect the build but sometimes I do like to wait and make
sure all arches complete before working on other dependencies.
I don't have any answers for you, but I've noticed the same problem
recently as well.
Scott___
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: Backwards incompatible changes planned for Bodhi 4.0.0
On Thu, 2018-12-13 at 01:40 +, Peter Robinson wrote: > Is there an executive summary as to what's backwards incompatible and > what the impact on the average user is? A quick look at the kanban > doesn't give me any understanding :) Each of the issues on the kanban board is a proposal to make a backwards incompatible change. I have not written any summary other than to gather those together in a kanban. Many of them are removing code that I don't believe is used (but that will have an effect on the REST API, or will require admin intervention to upgrade). Bodhi has many types of users, from release engineers, to admins, to packagers, to integrators, to testers. Here are some of the proposals I'd draw the most attention to: * Drop the update title (a list of NVRs that is very buggy) as the Update's primary key, and instead use the update alias (the string that looks like FEDORA-2018-abcde) as the only identifier[0]. * Drop Python 2 support in the client[1] (we will need some dependencies to move to Python 3 to bring this to Rawhide.) * Switch to OpenID Connect[2], which will require backwards incompatible changes in the authentication API and possibly in the Python bindings to the REST API[2]. * Drop anonymous comments[3] - you can't ask follow up questions because anonymous users don't get e-mails. It's not a very useful feature. * Change how the edit APIs work so that a diff is sent rather than the entire set of fields[4]. * Remove critpath karma[5]. [0] https://github.com/fedora-infra/bodhi/issues/1542 [1] https://github.com/fedora-infra/bodhi/issues/2759 [2] https://github.com/fedora-infra/bodhi/issues/1180 [3] https://github.com/fedora-infra/bodhi/issues/2700 [4] https://github.com/fedora-infra/bodhi/issues/2208 [5] https://github.com/fedora-infra/bodhi/issues/2194 signature.asc Description: This is a digitally signed message part ___ 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
fedpkg build disconnects?
I've never had this problem before but for the last week or so I frequently
get the following at some point before the build completes:
Could not execute build: ('Connection aborted.', RemoteDisconnected('Remote
end closed connection without response'))
I know it doesn't affect the build but sometimes I do like to wait and make
sure all arches complete before working on other dependencies.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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-bookmarks: Four PRs needing review
On Thu, Dec 13, 2018 at 8:53 AM Justin W. Flory wrote: > > Hi all, could a maintainer review these four PRs on the fedora-bookmarks > package? > > https://src.fedoraproject.org/rpms/fedora-bookmarks/pull-requests > > It would be cool to see these merged. I'm not sure what the process is > for requesting review on PRs in dist-git. > The three that you opened look fine to me. I'm not sure if we need to involve Legal before adding non-Fedora content to the default bookmarks, though. Adding them to the CC to find out. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fedora-bookmarks: Four PRs needing review
Hi all, could a maintainer review these four PRs on the fedora-bookmarks package? https://src.fedoraproject.org/rpms/fedora-bookmarks/pull-requests It would be cool to see these merged. I'm not sure what the process is for requesting review on PRs in dist-git. -- Cheers, Justin W. Flory jflo...@gmail.com signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or BFQ?
> Il giorno 12 dic 2018, alle ore 22:41, stan ha > scritto: > > On Wed, 12 Dec 2018 16:07:49 -0500 > Jeff Moyer wrote: > > Thanks for your insight. Doesn't look good for my use of BFQ. > >> Note that you can change the current I/O scheduler for any block >> device by echo-ing into /sys/block//queue/scheduler. Cat-ing >> that file will give you the list of available schedulers. > > That's part of the problem. BFQ doesn't appear in the list of > available schedulers. When I cat that location for my disks, I see > [noop]. Since CFQ does appear there if it is compiled into the kernel, > I'll have to look into what is done for CFQ and see how hard it would > be to patch the kernel to repeat that behavior for BFQ. > > My use case in not mq, so after reading one of the links in this > thread about performance, I saw that BFQ gave ~20 to 30 % boost in > disk io performance, and enhanced low latency performance (desktop > responsiveness) for single queue. That's what I want to capture by using > BFQ. I wonder if that is my problem. From what Chris said, an mq > scheduler is required in order to use BFQ, whether it is for mq or > single queue use. I'll try that. I normally use deadline and CFQ for > scheduling. Back to the compiler. > > I'm surprised this is so difficult. It's been in the kernel since the > 2.x series, and usually the configuration options are excellent for > allowing variation in how the kernel is configured. > > On the plus side, I notice only slight degradation in behavior using > noop scheduling. :-) Maybe I should just skip scheduling. :-D To test the behavior of your system, why don't you check, e.g., how long it takes to start an application while there is some background I/O? A super quick way to do this is git clone https://github.com/Algodev-github/S cd S/comm_startup_lat sudo ./comm_startup_lat.sh 5 5 seq 3 "replay-startup-io gnometerm" The last command line - starts the reading of 5 files plus the writing of 5 other files - replays, for three times, the I/O that gnome terminal does while; starting up (if you want I can tell you how to change the last command line so as to execute the original application, but you would get the same results); - for each attempt, measures how long this start-up I/O takes to complete. Paolo > ___ > kernel mailing list -- ker...@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/ker...@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://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: How to avoid re-generating Pagure API keys all the time?
Le 2018-12-12 18:49, Kevin Fenzi a écrit : On 12/12/18 4:10 AM, Ben Rosser wrote: On Tue, Dec 11, 2018 at 4:07 PM Till Maas wrote: Hi Ben, On Tue, Dec 11, 2018 at 11:42:51AM +0100, Ben Rosser wrote: I don't know. I feel like we could do a lot to improve the experience of packaging by investing time into fixing these sorts of minor annoyances. (But here I am complaining on the devel list and not actually doing anything to help, so I guess I'm part of the problem too). you are right. I am thinking this, too. Would you maybe be interested in making this a Community Objective[0] such as "Packaging Contribution Experience"? Kind regards Till [0] https://docs.fedoraproject.org/en-US/project/objectives/ Hi Till, Sure, I think it would be great to have packager quality of life as a community objective! Should I start by writing something up and sending an email to council-discuss? I'm not sure this really deserves the level of community objective... but perhaps I am wrong. Not treating it as a community objective is how we got in a situation, where upstreams (including @rh upstreams) want nothing to do with rpms and Fedora, and invent their own packaging tech to bypass Linux distributions completely. They're not doing it for lofty theoretical reasons. Those are added later as PC justifications. The root cause of why they behave like this, is that they feel, the packager experience Fedora (or Debian, or Ubuntu) sucks loads. It used not to suck, when it matched perfectly c/c++ autotools needs, and then it slowly degraded as things were not updated to match new needs and packagers were asked to fill in the gaps. IMHO, it mostly needs people spending time and driving it. First, gathering a list of issues that are non ideal for maintainers, That's quite easy to do and you'll find no end of volunteers to document their packaging roadblocks. And they're not limited to the pagure behavior… then finding out what it would take to solve each and helping create and land fixes for them, be that a pagure bugfix or a workflow change or whatever. … but only if there is an effort at the Fedora level to act on this list. That's means infra time, and that means Fedora leadership time to make sure infra has this time and actually uses it to fix the issues packagers reported. Been there, done that, not interested in filling new issues no one wants to work on or look at. Already doing too much of that lately. Regards, -- Nicolas Mailhot ___ 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: How to avoid re-generating Pagure API keys all the time?
On Wed, Dec 12, 2018 at 6:50 PM Kevin Fenzi wrote: > I'm not sure this really deserves the level of community objective... > but perhaps I am wrong. So, here's why a community objective sounds like a good idea to me (though other people should feel free to comment if they have different ideas): Firstly, I would hope that "making sure the experience of packaging software in Fedora is a good one" is one of our goals, as a distribution. (An "objective" with a lower case "o"). Two of our current objectives are "Modularity" and "Rethink the Fedora lifecycle". I think it is very important that, as we move in the direction of these sorts of big, sweeping changes, we also make sure that the experience of packaging remains positive. I don't know what is necessary to make sure that this happens. But I worry that it won't happen on its own. I am worried because I feel like the experience packaging *already* has gotten a bit worse since we retired pkgdb2, and we haven't done anything to fix that yet. So I would see the scope or mission statement of such a Community Objective as follows: 1. To identify parts of the packager workflow that are difficult or tedious, and to work with the maintainers of the relevant software components to resolve these issues. 2. In the short term, to identify things that pkgdb2 used to do that are now harder, or more difficult, for packagers to do today (and to try and improve things). 3. In the long term, to ensure that the core packager experience remains high as we continue to roll out Modularity and other future changes to come. Maybe what I've just written is the mission statement for a SIG or a Working Group. But perhaps an Objective could lead to the creation of such a group? > IMHO, it mostly needs people spending time and driving it. First, > gathering a list of issues that are non ideal for maintainers, then > finding out what it would take to solve each and helping create and land > fixes for them, be that a pagure bugfix or a workflow change or whatever. > > I'd love to help out, but just haven't had the time. If a group of folks > could help by triaging and labeling things that might make it easier to > know what needs work and where. Sure, I agree that this is what needs to be done. But I don't think it is going to happen on its own without some sort of organization to make it happen, and to try and organize/focus the work. I don't know if that organization requires an Objective to make happen, but I think it would be nice to enshrine this as one of our medium-term goals. Cheers, Ben Rosser ___ 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
