Re: Add new co-maintainer
Done. Now you can add yshestakov as comaintainer. чт, 9 июл. 2020 г. в 09:47, Andrey Maslennikov : > > Yes, I trust him completely on this matter. > > @Vascom thank you for your help! Should I open a ticket for 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: Add new co-maintainer
Yes, I trust him completely on this matter. @Vascom thank you for your help! Should I open a ticket for it? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Add new co-maintainer
Are you sure that he will be a good maintainer? If you want to follow this https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer I can be a sponsor. чт, 9 июл. 2020 г. в 09:01, Andrey Maslennikov : > > Hello! > > I'm trying to add a co-maintainer to my project > (https://src.fedoraproject.org/rpms/ucx). User I want to add just recently > joined to Fedora environment (the name is yshestakov) and need a sponsor to > become a packager. I've tried to add him to the group, but he didn't get any > notifications about it. > > How can he become a co-maintainer of my project? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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: TPM2 for disk encryption, clevis
Kevin Fenzi writes: > What does 'support for clevis' there look like? you mean just binding a > encrypted drive to look for clevis servers on boot? Yes, currently we only support the "tang" pin. > I think tpm2 might be good, but lots of machines don't have tpm2. > So I would think it would need to be optional? Of course. ___ 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: TPM2 for disk encryption, clevis
Richard Hughes writes: > On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote: >> As I understand it, there is a lot of evolving OS specific subtlety >> involved, so I am asking specifically how this would look on current >> Fedora and what to expect in the near future. > > Just a heads-up; the PCR0 changes when you upgrade the system > firmware. Yeah, that is the fragility that Matthew is talking about here, right? https://mjg59.dreamwidth.org/48897.html How far along are we with implementing the "measure keys and policy into PCR7" scheme? Is it maybe done? Is that actually the plan for Fedora, or somehting else? ___ 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
Add new co-maintainer
Hello! I'm trying to add a co-maintainer to my project (https://src.fedoraproject.org/rpms/ucx). User I want to add just recently joined to Fedora environment (the name is yshestakov) and need a sponsor to become a packager. I've tried to add him to the group, but he didn't get any notifications about it. How can he become a co-maintainer of my project? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Thursday's FPC Meeting (2020-07-09 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2020-07-09 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2020-07-09 09:00 PDT US/Pacific 2020-07-09 12:00 EDT --> US/Eastern <-- 2020-07-09 16:00 UTC UTC 2020-07-09 17:00 BST Europe/London 2020-07-09 18:00 CEST Europe/Berlin 2020-07-09 18:00 CEST Europe/Paris 2020-07-09 21:30 IST Asia/Calcutta New Day: Friday - 2020-07-10 00:00 HKT Asia/Hong_Kong 2020-07-10 00:00 +08 Asia/Singapore 2020-07-10 01:00 JST Asia/Tokyo 2020-07-10 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Issues = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #977 Get new members? .fpc 977 https://pagure.io/packaging-committee/issue/977 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-938 Add Package Review Process page. https://pagure.io/packaging-committee/pull-request/938 #topic #pr-947 Deprecate Old Style Dependency Generators. https://pagure.io/packaging-committee/pull-request/947 #topic #pr-954 Prohibit use of `rpm` command from specfile. https://pagure.io/packaging-committee/pull-request/954 = New Pull Requests = #topic #pr-942 Recommend storing changelog entries in separate file. https://pagure.io/packaging-committee/pull-request/942 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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
mingw GCC help needed: -fstack-protector and -lssp, undefined reference to `__strcpy_chk'
Hi
I'm working on updating the mingw toolchain [1], and am hitting the
situation [2] where I build with -fstack-protector in the ldflags, can
confirm that -lssp and -lssp_nonshared are automatically added to the
ldflags (seen via gcc -v [3] and strace), but I still get i.e. with this
minimal testcase:
#include
int main () {
return closedir (NULL);
}
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector
/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/bin/ld:
/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingwex.a(lib32_libmingwex_a-dirent.o):(.text+0x22f):
undefined reference to `__strcpy_chk'
collect2: error: ld returned 1 exit status
OTOH, if I write
$ i686-w64-mingw32-gcc -o test.exe test.c -fstack-protector
/usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll
it links correctly.
The only other thing which came to mind to verify is that the import
library references the correct dll, and this appears to be the case:
$ i686-w64-mingw32-dlltool -I
/usr/i686-w64-mingw32/sys-root/mingw/lib/libssp.dll.a
libssp-0.dll
I'd appreciate any pointers as I'm pretty much in the dark here.
Thanks
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-7.0.0/builds/
[2] Specifically when building mingw-gdb, which adds
-D_FORTIFY_SOURCES=2 internally, hence adding -fstack-protector to the
ldflags
[3] I.e. I gtt COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe'
'-fstack-protector' '-mtune=generic' '-march=pentiumpro'
/usr/libexec/gcc/i686-w64-mingw32/10.1.1/collect2 -plugin
/usr/libexec/gcc/i686-w64-mingw32/10.1.1/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/i686-w64-mingw32/10.1.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/cckKHr8u.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt
--sysroot=/usr/i686-w64-mingw32/sys-root -m i386pe -Bdynamic -o test.exe
/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o
/usr/lib/gcc/i686-w64-mingw32/10.1.1/crtbegin.o
-L/usr/lib/gcc/i686-w64-mingw32/10.1.1
-L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib/../lib
-L/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib
-L/usr/lib/gcc/i686-w64-mingw32/10.1.1/../../../../i686-w64-mingw32/lib
-L/usr/i686-w64-mingw32/sys-root/mingw/lib /tmp/ccpeowDx.o
/usr/i686-w64-mingw32/sys-root/mingw/bin/libssp-0.dll -lssp_nonshared
-lssp -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread
-ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh
-lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-w64-mingw32/10.1.1/crtend.o
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Wed, 2020-07-08 at 17:23 -0400, James Cassell wrote: > On Tue, Jul 7, 2020, at 12:30 PM, Adam Williamson wrote: > > On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote: > > > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen > > > wrote: > > > > > > > > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote: > > > > > > > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek > > > > > wrote: > > > > > > Making btrfs opt-in for F33 and (assuming the result go well) > > > > > > opt-out for F34 > > > > > > could be good option. I know technically it is already opt-in, but > > > > > > it's not > > > > > > very visible or popular. We could make the btrfs option more > > > > > > prominent and > > > > > > ask people to pick it if they are ready to handle potential fallout. > > > > > > > > > > I'm leaning towards recommending this as well. I feel like we don't > > > > > have > > > > > good data to make a decision on -- the work that Red Hat did > > > > > previously when > > > > > making a decision was 1) years ago and 2) server-focused, and the > > > > > Facebook > > > > > production usage is encouraging but also not the same use case. I'm > > > > > particularly concerned about metadata corruption fragility as noted > > > > > in the > > > > > Usenix paper. (It'd be nice if we could do something about that!) > > > > > > > > So if one has a spare partition to play with btrfs, is there an easy > > > > way to install a second copy of Fedora without having the /boot/efi/ > > > > entries overwrite the existing Fedora installation? Or fix it to have > > > > 2 separate entries after the fact? > > > > > > > > > It's possible but has challenges. Separate ESP's you'll need to either > > > (a) use the firmware's built-in boot manager to choose what will > > > probably appear to be identically named Fedora's > > > > No, you have to rename the first one before doing the second install. > > anaconda explicitly deletes any existing efibootmgr entry named > > "Fedora" before creating a new one. > > Any idea if this process is documented? I think it's `efibootmgr -b -L DefinitelyNotFedora`, where is the number of the entry called 'Fedora', which you could find by just running `efibootmgr` to get a list of entries. -b selects the entry to operate on and -L changes the 'label', which I think is what we're dealing with here. If you do that before doing the second install, you *should* be able to choose between them by using whatever mechanism your firmware offers to select an EFI boot manager entry at boot time. The one called DefinitelyNotFedora would be the first install, the one called Fedora would be the second install. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Tue, Jul 7, 2020, at 12:30 PM, Adam Williamson wrote: > On Mon, 2020-07-06 at 20:06 -0600, Chris Murphy wrote: > > On Mon, Jul 6, 2020 at 4:48 PM Gerald Henriksen wrote: > > > > > > On Wed, 1 Jul 2020 14:24:37 -0400, you wrote: > > > > > > > On Wed, Jul 01, 2020 at 06:54:02AM +, Zbigniew J?drzejewski-Szmek > > > > wrote: > > > > > Making btrfs opt-in for F33 and (assuming the result go well) opt-out > > > > > for F34 > > > > > could be good option. I know technically it is already opt-in, but > > > > > it's not > > > > > very visible or popular. We could make the btrfs option more > > > > > prominent and > > > > > ask people to pick it if they are ready to handle potential fallout. > > > > > > > > I'm leaning towards recommending this as well. I feel like we don't have > > > > good data to make a decision on -- the work that Red Hat did previously > > > > when > > > > making a decision was 1) years ago and 2) server-focused, and the > > > > Facebook > > > > production usage is encouraging but also not the same use case. I'm > > > > particularly concerned about metadata corruption fragility as noted in > > > > the > > > > Usenix paper. (It'd be nice if we could do something about that!) > > > > > > So if one has a spare partition to play with btrfs, is there an easy > > > way to install a second copy of Fedora without having the /boot/efi/ > > > entries overwrite the existing Fedora installation? Or fix it to have > > > 2 separate entries after the fact? > > > > > > It's possible but has challenges. Separate ESP's you'll need to either > > (a) use the firmware's built-in boot manager to choose what will > > probably appear to be identically named Fedora's > > No, you have to rename the first one before doing the second install. > anaconda explicitly deletes any existing efibootmgr entry named > "Fedora" before creating a new one. Any idea if this process is documented? I typically install on a laptop, with the "encrypt my data" option. I can confirm that the only way to successfully have 2 side-by-side Fedora installs with UEFI, using only Anaconda to set it up, is to have 2 separate physical disks, and choose which physical disk to boot by hitting F12 at machine power on. Any attempts to share /boot result in at least one of the installs being broken. Any attempts to share /boot/efi breaks at least fedora-by-fedora installs. Adding a separate /boot/efi partition for the second Fedora install makes the resulting system usable on the new Fedora install, but there is no obvious way to boot into the older Fedora install. If you unlock the disks within Anaconda for the existing Fedora install, grub gets boot entries for that install, but they are non-functional. (No password is prompted for unlocking the disk, indefinite hang.) What /does/ seem to work is having RHEL and Fedora side-by-side on the same disk, as long as each has its own /boot and /boot/efi partitions. Generally, I'd like the fedora-by-fedora parallel installs to work better because that's how I'm best able to participate in the Test Matrix. V/r, James Cassell ___ 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: Btrfs by default, the compression option
On Wednesday, July 8, 2020 10:20:30 AM MST Matthew Miller wrote: > On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote: > > > I expect beefy CPU systems, including gaming systems, to have the same > > or better read/write performance using mount option compress=zstd:1. > > Where I've seen equal or better read performance, there can be a write > > performance drop if the IO storage has been upgraded. Sample size 1, > > and the workload was kernel compiling. > > > Yeah I guess for /usr the most relevant write metric is "does it slow down > DNF upgrades or install operations enough to be noticeable / annoying / > problematic"? More importantly, does it hurt the performance of installed packages? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote: > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr > wrote: > > needlessly disables a lot of kernel functionality > > > It disables functionality which can destroy platform security. It disables functionality that users need, such as inserting their kernel modules on their own system, or hibernating to disk. Let's be honest about what this does. This is not something that's beneficial here, it's only harming our users. > > You cannot load kernel modules you've built > > > If you can build and insert your own kernel module you can do almost > anything to the hardware, including disabling various firmware > protection technologies. > > tl;dr: if you care about platform security at all, enable secure boot. If you've got root, you can STILL do almost anything to the hardware, including disabling various "firmware protection technologies". This is needlessly kneecapping users. -- John M. Harris, Jr. ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Wednesday, July 8, 2020 12:53:05 PM MST Przemek Klosowski via devel wrote: > On 7/8/20 12:15 PM, John M. Harris Jr wrote: > > Really, this is starting to sound like it's more of an issue with web > > browsers, and less of a problem with our current configurations, without > > EarlyOOM needlessly killing things. > > [...] > > Currently, pages that haven't been used in a while are the ones that would > > get swapped out first, which I'm sure we can all agree is the most sane > > option. Your GIMP example is accurate, but that'll take a fraction of a > > second. > Argumentative, Your Honor! It's not just an issue with web > browsers---you say that yourself few lines further down, it happens with > every program that uses big data---GIMP with lots of images, FreeCAD > with a complex geometry, rmaxima with a combinatiorally exploding > symbolic expression, even your editor where you read in the entire > /var/log/httpd/access_log against your better judgement. Literally all > those examples happened to me fairly recently---the system went > unresponsive, essentially requiring hard reset, whereas the preferred > outcome would have been to abort those runaway tasks. That other software's data would get swapped out doesn't mean "it's not just an issue with web browsers". It's not an issue with anything else. It's okay to swap out a few pages, and it doesn't hurt GIMP, FreeCAD, etc. If it does with browsers, that's a bug. > >> One way to think about it is that disk is tens of thousands times slower > >> than RAM. If you need to use it, your system is commensurably slower. > >> That's why zram is such a good idea. Swap was always a tradeoff: you > >> saved $'s not spent on RAM, and paid with your time sitting idle waiting > >> for the computer. > > > > Well, no. It's not "tens of thousands times slower than RAM". If you need > > to use it, you're swapping in a few pages at a time, not the entire > > contents of swap. Swap isn't a replacement for RAM. It's an optimization > > that doesn't waste RAM needlessly. > > I think we both understand what the other person is trying to say, to > the point where no further explanations are needed. Having said that, > I'd prefer if you would qualify and augment instead of denying my > statements. I stand by both of them: > > * disk access is literally O(1) slower than RAM access This is just false, and you can prove that on your own system using only `dd`. In fact, if your system is newer than my Lenovo ThinkPad X200 Tablet, you'll probably have even faster reads/writes from/to disk. > * swap is a cheap substitute for RAM, with the right swap/RAM mix > determined by cost-benefit considerations It can be used as such, but really shouldn't be. It's more of an optimization such that you don't waste RAM than anything else. > You're right that there's a sweet spot where swap just provides a buffer > for occasional peak demand---but this entire discussion results from > complaints about system behavior under heavy swap use, when swap is > being an inadequate replacement for the needed RAM. That's not what this discussion results from. This discussion results from somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing our applications at random, and ruining our desktop experience. -- John M. Harris, Jr. ___ 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: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 12:54 PM Adam Williamson wrote: > > On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote: > > Hi, > > > > The change proposal has a 'compression option' and we kinda need to > > get organized. > > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression > > It feels to me like this might be a great area to slow down a bit and > not try to do everything at once. > > Why don't we just make the simplest change for F33 - going to btrfs by > default - and see how that goes, and consider the 'options' for F34 or > later, rather than changing too much stuff at once? Yes, it's completely reasonable to not do it. It might seem like a big change on its own, but Btrfs has had native compression for 10+ years, and at least three years for most all of the workloads at Facebook. So it's quite safe. It does, however, touch parts in Anaconda. So yeah, we definitely do not have to do it. But if we are, I guess my point is, we need to get serious and act quick like a bunny. This isn't gonna be some late addition. -- Chris Murphy ___ 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: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 1:45 PM Matthew Miller wrote: > > On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote: > > If it's the center, I think that favors the mount option approach and > > do it with the lowest level of compression, i.e. zstd:1. But this > > suggests more benchmarking still, to make certain it's well understood > > what the range of write performance hit could be in those scenarios. > > Whereas the curated approach can just bypass most of that question - > > the payload and workload for flatpak and usr and containers is fairly > > fixed across all Fedora users rather than mixed content and workloads > > found in ~/ > > I just did some quick tests out of curiousity. I tarred up /usr on my > system, resulting in a 9.8GB file. Ran this in my home dir on a > run-of-the-mill Western Digital SSD. Btrfs uses a cheap entropy estimator to decide if it should even try to compress blocks. So it won't always do it. Hence results like this: $ sudo compsize /usr Processed 204133 files, 108496 regular extents (114715 refs), 101700 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 57% 3.2G 5.7G 6.2G none 100% 1.8G 1.8G 1.9G zstd36% 1.3G 3.8G 4.3G -- Chris Murphy ___ 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On 7/8/20 12:15 PM, John M. Harris Jr wrote: I'd rather crash and restart where I left off than have the computer drag me along trying to save my application. Sorry, what? Why would your data not be on your system? What about "the modern way of computing" would move your data from your system to something else? I'd rather not see software crash, and risk data loss, or have my system "drag me along". I am talking about every process that has enough safeguards to be effectively idempotent, either because it doesn't use local data or saves it often enough to have a reliable, resumeable checkpoints. Here's a couple of examples: * browsing, because it both displays remote data and because it saves the state (tabs and whatnot) * make -j 30 * even emacs editing, because emacs saves the buffers when it's killed If the computer gets in trouble doing those things, I don't want it to do heroics trying to recoverit's OK to abort and retry. I think the 'modern cloud computing' is, for many reasons, having to be like that---resilient to failures and idempotent. Really, this is starting to sound like it's more of an issue with web browsers, and less of a problem with our current configurations, without EarlyOOM needlessly killing things. [...] Currently, pages that haven't been used in a while are the ones that would get swapped out first, which I'm sure we can all agree is the most sane option. Your GIMP example is accurate, but that'll take a fraction of a second. Argumentative, Your Honor! It's not just an issue with web browsers---you say that yourself few lines further down, it happens with every program that uses big data---GIMP with lots of images, FreeCAD with a complex geometry, rmaxima with a combinatiorally exploding symbolic expression, even your editor where you read in the entire /var/log/httpd/access_log against your better judgement. Literally all those examples happened to me fairly recently---the system went unresponsive, essentially requiring hard reset, whereas the preferred outcome would have been to abort those runaway tasks. One way to think about it is that disk is tens of thousands times slower than RAM. If you need to use it, your system is commensurably slower. That's why zram is such a good idea. Swap was always a tradeoff: you saved $'s not spent on RAM, and paid with your time sitting idle waiting for the computer. Well, no. It's not "tens of thousands times slower than RAM". If you need to use it, you're swapping in a few pages at a time, not the entire contents of swap. Swap isn't a replacement for RAM. It's an optimization that doesn't waste RAM needlessly. I think we both understand what the other person is trying to say, to the point where no further explanations are needed. Having said that, I'd prefer if you would qualify and augment instead of denying my statements. I stand by both of them: * disk access is literally O(1) slower than RAM access * swap is a cheap substitute for RAM, with the right swap/RAM mix determined by cost-benefit considerations You're right that there's a sweet spot where swap just provides a buffer for occasional peak demand---but this entire discussion results from complaints about system behavior under heavy swap use, when swap is being an inadequate replacement for the needed RAM. ___ 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: Btrfs by default, the compression option
On Wed, Jul 08, 2020 at 11:37:11AM -0600, Chris Murphy wrote: > If it's the center, I think that favors the mount option approach and > do it with the lowest level of compression, i.e. zstd:1. But this > suggests more benchmarking still, to make certain it's well understood > what the range of write performance hit could be in those scenarios. > Whereas the curated approach can just bypass most of that question - > the payload and workload for flatpak and usr and containers is fairly > fixed across all Fedora users rather than mixed content and workloads > found in ~/ I just did some quick tests out of curiousity. I tarred up /usr on my system, resulting in a 9.8GB file. Ran this in my home dir on a run-of-the-mill Western Digital SSD. This results in: compression file compression % better than level size ratio previous 1 4.1G41.36%- 2 3.8G38.97% 6.1% 3 3.6G36.81% 5.9% 4 3.6G36.36% 1.2% 5 3.5G35.63% 2.8% 6 3.5G35.33% 2.0% 9 3.4G34.19%- 19 2.8G29.72%- That's pretty good even at level 1. I don't think my setup is useful for timing benchmarks, and also that takes more care than I want to put into it this minute, but the interesting note is that levels 1-4 are all about the same in speed (within 10 seconds) and level 5 suddenly 3x slower. I assume that's not surprising to anyone who knows how zstd works. But also, unless you go to crazy high levels, the gains above level 3 really drop off. (19, by the way, is amazingly slow. Took almost an hour.) -- Matthew Miller Fedora Project Leader ___ 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: Btrfs by default, the compression option
It feels to me like this might be a great area to slow down a bit and not try to do everything at once. Why don't we just make the simplest change for F33 - going to btrfs by default - and see how that goes, and consider the 'options' for F34 or later, rather than changing too much stuff at once Considering how controversial the change has been already,?? I think it would make a lot of sense to make one change at a time. If someone were to have a bad experience with the new default, it would be unclear whether that's because of the filesystem itself or because of the options we chose to deploy the filesystem with. If we make those changes separately, and the compression change goes badly, the changes would still be clearly independent. Changing one thing at a time is responsible change management in any case, especially when we're talking about defaults. Thanks, Marty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On 7/8/20 10:47 AM, John M. Harris Jr wrote: On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote: On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: Well, if that is your concern the answer is secure boot. That will not only prevent tampering with /boot files, but also prevent tampering with the bootloader itself. No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway, needlessly disables a lot of kernel functionality, which makes it completely unusable. You cannot load kernel modules you've built, hibernate your system, etc. Additionally, Secure Boot does not prevent tampering with /boot files. You can still change grub.cfg as you like. Yet here I am, happily using it, across multiple systems... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
Once upon a time, Richard Hughes said: > tl;dr: if you care about platform security at all, enable secure boot. If you want to use interesting and useful kernel technologies (namely eBPF), disable secure boot. That's a real killer of secure boot IMHO. -- Chris Adams ___ 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: Btrfs by default, the compression option
On Wed, 2020-07-08 at 00:24 -0600, Chris Murphy wrote: > Hi, > > The change proposal has a 'compression option' and we kinda need to > get organized. > https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Compression It feels to me like this might be a great area to slow down a bit and not try to do everything at once. Why don't we just make the simplest change for F33 - going to btrfs by default - and see how that goes, and consider the 'options' for F34 or later, rather than changing too much stuff at once? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 11:20 AM Matthew Miller wrote: > > On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote: > > I expect beefy CPU systems, including gaming systems, to have the same > > or better read/write performance using mount option compress=zstd:1. > > Where I've seen equal or better read performance, there can be a write > > performance drop if the IO storage has been upgraded. Sample size 1, > > and the workload was kernel compiling. > > Yeah I guess for /usr the most relevant write metric is "does it slow down > DNF upgrades or install operations enough to be noticeable / annoying / > problematic"? I'm pretty fussy and impatient. I think I'd notice. But this is not a reliable metric. I think a sane test might be looking at the program.log for a netinstall on lvm+ext4 vs btrfs vs btrfs +compress. Delete the download portion of the test to eliminate network variation error, and only look at payload delivery time. I have done this just today with a Live installation, but this has the problem that we're significantly read bound due to a tightly wound up xz compressed image. That acts as a moderator for whoever is really faster. All these results tell is is that we don't have a problem with live install performance being meaningfully different. https://paste.centos.org/view/7ce7b52f > > SD Card and eMMC it's a win for sure. Also an argument could be made > > do use Btrfs+compression on USB sticks. This class of flash will just > > return garbage if they encounter uncorrectable errors - rather than a > > discrete read error. In this case, Btrfs refuses to hand over the > > corrupt data, in normal operation. A good question is, whether the > > desktop should warn that the file is corrupt, and then permit a > > degraded read somehow to still get the file off the media. It might > > imply necessary desktop integration. > > A related question: Are we planning on using btrfs on live media? No. It will still be ext4 nested in a squashfs image, and rsync to copy. There is/was an idea to move to plain squashfs image, and unsquashfs to copy - but I'm not certain of its status. https://fedoraproject.org/wiki/Category:Changes/OptimizeSquashFS https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L6ZQCOYXZOIIOZM7SUFQDGEUEQU2QY7N/ There is a trade off using Btrfs as the image for media. (a) compression won't be as good as plain squashfs, images will get bigger. Maybe as much as 20% - but I've done no optimizing to see if that can be improved. (b) Always on checksumming of the payload we care about (excludes the bootloader, kernel, initramfs for the live environment boot). We can get rid of the long slow one time media checker option. With no meaningful performance hit to the user. And catch even transient corruption due to flakey USB media, etc. (c) We can use rsync for installs to non-btrfs file systems, they still get the benefit of (b); and an optimization for installs to Btrfs is using a seed/sprout replication feature that avoids the decompression/recompression hit of the (b) option because it just copies compressed block groups intact, it's not a file copy. Also these things can be chained (dependently stacked in order; not like independent overlays). https://btrfs.wiki.kernel.org/index.php/Seed-device But yea, as Neal says. Not this cycle. -- Chris Murphy ___ 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: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 1:20 PM Matthew Miller wrote: > > On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote: > > I expect beefy CPU systems, including gaming systems, to have the same > > or better read/write performance using mount option compress=zstd:1. > > Where I've seen equal or better read performance, there can be a write > > performance drop if the IO storage has been upgraded. Sample size 1, > > and the workload was kernel compiling. > > Yeah I guess for /usr the most relevant write metric is "does it slow down > DNF upgrades or install operations enough to be noticeable / annoying / > problematic"? > > > SD Card and eMMC it's a win for sure. Also an argument could be made > > do use Btrfs+compression on USB sticks. This class of flash will just > > return garbage if they encounter uncorrectable errors - rather than a > > discrete read error. In this case, Btrfs refuses to hand over the > > corrupt data, in normal operation. A good question is, whether the > > desktop should warn that the file is corrupt, and then permit a > > degraded read somehow to still get the file off the media. It might > > imply necessary desktop integration. > > A related question: Are we planning on using btrfs on live media? > Not for this change, no. Part of the reason is that I didn't want to bite off more than I can chew, and part of it is that I want to explore some of the Btrfs-specific enhancements with seed images and the seed/sprout flow before I go down that road. There's some seriously cool opportunities there, but I want to actually try it before I propose it. :) We are, however, changing all the disk image deliverables to Btrfs (like the ARM ones), since that's how people wind up using it anyway. -- 真実はいつも一つ！/ 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: [External] Re: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 10:54 AM Mark Pearson wrote: > > I personally haven't had any experience with btrfs but if there are any > guidelines on testing that we can do and what data should be collected to > help out let me know and I'll see if we can hit up some of our platforms and > get some numbers. > As much as benchmarks make me loopy... they are only as valid, as they actually represent the workload, and many don't. But. The Phoronix test suite might be a starting point in finding unusually bad things to look into. (Conversely, unusually good results I consider equally suspicious but, like, haha ... am I gonna care as much? No.) -- Chris Murphy ___ 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: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 9:50 AM Matthew Miller wrote: > > On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote: > > 2. Benchmarking: this is hard. A simple tool for doing comparisons > > among algorithms on a specific bit of hardware is lzbench. > > https://github.com/inikep/lzbench > > How to compile on F32. > > https://github.com/inikep/lzbench/issues/69 > > But is that adequate? How do we confirm/deny on a wide variety of > > hardware that this meets the goal? And how is this test going to > > account for parallelization, and read ahead? Do we need a lot of data > > or is it adequate to get a sample "around the edges" (e.g. slow cpu > > fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow > > drive). What algorithm? > > More data is always better. I like qualifying the situations in that way. I > think we should make our decision based on the "center" rather than the > edges, though. If it's the center, I think that favors the mount option approach and do it with the lowest level of compression, i.e. zstd:1. But this suggests more benchmarking still, to make certain it's well understood what the range of write performance hit could be in those scenarios. Whereas the curated approach can just bypass most of that question - the payload and workload for flatpak and usr and containers is fairly fixed across all Fedora users rather than mixed content and workloads found in ~/ > For I hope obvious reasons, I'd love to see this tested on a Lenovo X1 > Carbon Gen 8 with the default SSD options. > > And, for benchmarks, I'm thinking more application benchmarks than a > benchmark of the compression itself. How much does compressed /usr affect > boot times for GNOME and KDE? What about startup time for LibreOffice, > Firefox, etc? Any impact on run-time usage? > > > [...] > > D. Which directories? Some may be outside of the installer's scope. > > As I noted in the bugzilla entry, the /var/log on this system compresses to > 3.6% of its original size. Yep. I'm not opposed to it by any means. I'm not sure what things other than VMs and databases would be there - and we still have to figure out who "owns" those locations to decide how we get them to set nodatacow. There is bit of a rabbit hole for /var/log/journals. systemd-journald detects btrfs and automatically does nodatacow on its journals. That means no compression. On a HDD, it makes sense. But on SSD the files are relatively small and while fragmentation can be bad the tracking isn't that bad on an SSD, I'm pretty sure compression makes up for it but I haven't benchmarked it. Anyway I 'touch /etc/tmpfiles.d/journal-nocow.conf' to prevent the setting of nodatacow on journals. -- Chris Murphy ___ 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: Btrfs by default, the compression option
On Wed, Jul 08, 2020 at 11:08:53AM -0600, Chris Murphy wrote: > I expect beefy CPU systems, including gaming systems, to have the same > or better read/write performance using mount option compress=zstd:1. > Where I've seen equal or better read performance, there can be a write > performance drop if the IO storage has been upgraded. Sample size 1, > and the workload was kernel compiling. Yeah I guess for /usr the most relevant write metric is "does it slow down DNF upgrades or install operations enough to be noticeable / annoying / problematic"? > SD Card and eMMC it's a win for sure. Also an argument could be made > do use Btrfs+compression on USB sticks. This class of flash will just > return garbage if they encounter uncorrectable errors - rather than a > discrete read error. In this case, Btrfs refuses to hand over the > corrupt data, in normal operation. A good question is, whether the > desktop should warn that the file is corrupt, and then permit a > degraded read somehow to still get the file off the media. It might > imply necessary desktop integration. A related question: Are we planning on using btrfs on live media? -- Matthew Miller Fedora Project Leader ___ 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: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 5:13 AM Kamil Paral wrote: > > On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet > wrote: >> >> Please test, but if a file is deemed not compressible (based on, not >> sure what? the first few blocks?) then it will be stored in the >> non-compressed version. >> You can check with compsize after the fact if the file had been >> compressed or not. >> >> This should be true unless the compress-force mount option is used, even >> the chattr is only a hint > > > OK, this is an interesting piece of information I wasn't aware of. In this > case, if the btrfs heuristics work OK in the majority of cases, the > performance hit might not be there, as I feared. Some thorough investigation > would be needed, though. There is a cheap estimator of how well blocks will compress and Btrfs will do an early bail, and not compress if there's no good gain. It's common to see mixed compression on files. I expect beefy CPU systems, including gaming systems, to have the same or better read/write performance using mount option compress=zstd:1. Where I've seen equal or better read performance, there can be a write performance drop if the IO storage has been upgraded. Sample size 1, and the workload was kernel compiling. The mount option method is file system wide, and permits level to be specified (except lzo). Whereas using the XATTR is subvolume/directory/file granularity, and works by inheritance when set on a directory, it doesn't yet support levels. Upstream development tells me it's straightforward to include the level in the XATTR - but that is an RFE so we can't plan for it just yet. The default level for zstd is 3. The read time performance is about the same, but the write time performance takes a bigger hit. This isn't a big deal if we're "curating" specific directories that are likely to have their write performance limited by, for example internet bandwidth, or perception wise that the offline update takes however many tens of seconds longer. I also tentatively agree that many users' drives are not likely to see their drive lifetime writes exceeded without compression. But if they can save ~50% of the space without a read time performance hit (or even a gain) that's a win. For folks compiling, that needs more testing. It might work out in favor of some cases and not others - and if they do a lot of writes the write amplification reduction is more meaningful. And also some low end very high density chip SSDs can have low write endurance these days. SD Card and eMMC it's a win for sure. Also an argument could be made do use Btrfs+compression on USB sticks. This class of flash will just return garbage if they encounter uncorrectable errors - rather than a discrete read error. In this case, Btrfs refuses to hand over the corrupt data, in normal operation. A good question is, whether the desktop should warn that the file is corrupt, and then permit a degraded read somehow to still get the file off the media. It might imply necessary desktop integration. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr wrote: > needlessly disables a lot of kernel functionality It disables functionality which can destroy platform security. > You cannot load kernel modules you've built If you can build and insert your own kernel module you can do almost anything to the hardware, including disabling various firmware protection technologies. tl;dr: if you care about platform security at all, enable secure boot. Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
RE: [External] Re: Btrfs by default, the compression option
> -Original Message- > From: Matthew Miller > Sent: Wednesday, July 8, 2020 11:51 AM > > On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote: > > 2. Benchmarking: this is hard. A simple tool for doing comparisons > > among algorithms on a specific bit of hardware is lzbench. > > https://github.com/inikep/lzbench > > How to compile on F32. > > https://github.com/inikep/lzbench/issues/69 > > But is that adequate? How do we confirm/deny on a wide variety of > > hardware that this meets the goal? And how is this test going to > > account for parallelization, and read ahead? Do we need a lot of data > > or is it adequate to get a sample "around the edges" (e.g. slow cpu > > fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow > > drive). What algorithm? > > More data is always better. I like qualifying the situations in that way. I > think we should make our decision based on the "center" rather than the > edges, though. > > For I hope obvious reasons, I'd love to see this tested on a Lenovo X1 > Carbon Gen 8 with the default SSD options. > I personally haven't had any experience with btrfs but if there are any guidelines on testing that we can do and what data should be collected to help out let me know and I'll see if we can hit up some of our platforms and get some numbers. Mark ___ 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: nodebug kernel repo file missing
On Wed, Jul 8, 2020 at 5:24 AM Zbigniew Jędrzejewski-Szmek wrote: > > https://fedoraproject.org/wiki/RawhideKernelNodebug > links to > http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo > which gives 404 now. The kernels seems to be there though. But without > the repo file it's not easy to enable. > I just put a new one up, unfortunately my home directory was deleted as part of the datacenter move, and I did not have a proper back up. of everything, so the sync scripts got rid of it. Thanks for pointing it out. ___ 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: Can we do away with release and changelog bumping?
Le 2020-07-08 17:19, Pavel Raiskup a écrit : Small experiment (few-liner) for copr with "%bid, build system tag": https://pagure.io/copr/copr/pull-request/1436 Well, that ties the system to corp, not koji, and like the other proposal, that makes releases that do not import from one system to another (which definitely matters to me, because my packager workflow has rpmbuild, mock, copr and koji stages). I honestly do not see how you can bump safely, without providing the bumping code the "bump from that point" information. When you bump, you graft new release growth over an existing release tree. Stacking something blindly without looking upon where you stack it will work in a lot of cases, but will fail horribly in others. I like KISS but this KISS is too SS for my tastes. If linear history worked for a project the size of Fedora we’d be all still using CVS. The bumping code itself is not hard to write Serializing 'bump from here' in a format that can be reliably read later is also not hard (as long as you do not insist on expanding Release and trying to decompose it back at the next build). The hard part is moving 'bump from here' info between builds. 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://docs.fedoraproject.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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
On Tuesday, July 7, 2020 8:54:40 AM MST Przemek Klosowski via devel wrote: > On 7/6/20 6:49 PM, John M. Harris Jr wrote: > > Unless you're actively using all of those tabs (I don't know how you would > > be, but it's certainly possible), swap sounds like the perfect solution. > > Unless Firefox keeps JS running in there, and it's updating the DOM, > > these would likely be able to get swapped out. > > > > Firefox will actually unload tabs that you haven't done anything with in a > > while under specific circumstances, but I don't know what those are. You > > may notice, for example, that the page "reloads" without network traffic, > > when going to a tab you haven't had open in a while. I've seen this on my > > system recently. > > Take a look at the Task Manager. You will see tabs running even though > you're not touching that: the pages have elements (ads, animations, etc) > that run even though the tabs are not visible. True, the browser tries > to pacify them (turns off sound/video, and whatnot) but they still > run---and if the JS engine has memory leaks their memory footprint > increases. You can see the culprits---sort them by "Energy Impact" or > "Memory" by clicking on the column headers. I don't really use web browsers on "intensive" pages, so I've never noticed that sort of issue, but I alluded to that above, JS running or updating the DOM. Most of the pages I use, with the exception of those included in Fedora's repos (doh), don't require JavaScript in order to function, for example, LWN. Really, this is starting to sound like it's more of an issue with web browsers, and less of a problem with our current configurations, without EarlyOOM needlessly killing things. > >> More swap doesn't necessarily solve this problem: remember that 1GB/min > >> is a ballpark HD speed so if you have 10GB swap that your system is > >> actually trying to use, you will just sit there for 10 minutes. > > > > I don't really understand how that'd be the case. For that to happen, > > you'd > > have to load all of those into memory, have them swap out, then try to > > swap > > them all back in at the same time. > > That's my point---you don't have control over it. Swap algorithm decides > which pages are evicted from RAM or brought back---if the browser starts > allocating memory, my FreeCAD might get pushed out, and if I click on > GIMP window after not using it for an hour it tries to bring it back in. You do have control over it, with the swappiness value, for example. Currently, pages that haven't been used in a while are the ones that would get swapped out first, which I'm sure we can all agree is the most sane option. Your GIMP example is accurate, but that'll take a fraction of a second. > One way to think about it is that disk is tens of thousands times slower > than RAM. If you need to use it, your system is commensurably slower. > That's why zram is such a good idea. Swap was always a tradeoff: you > saved $'s not spent on RAM, and paid with your time sitting idle waiting > for the computer. Well, no. It's not "tens of thousands times slower than RAM". If you need to use it, you're swapping in a few pages at a time, not the entire contents of swap. Swap isn't a replacement for RAM. It's an optimization that doesn't waste RAM needlessly. > With the modern way of computing, where your data is mostly NOT on your > system---so you don't lose it if your application shuts down---I am > beginning to think that application crashes aren't such a big deal as > they used to be. I'd rather crash and restart where I left off than have > the computer drag me along trying to save my application. Sorry, what? Why would your data not be on your system? What about "the modern way of computing" would move your data from your system to something else? I'd rather not see software crash, and risk data loss, or have my system "drag me along". > Having said that, of course lots of applications ARE local and will lose > data if crashed, so maybe the cgroup-based approach is the definitive > solution: hard-limit the memory for cloud apps, to protect the local > apps from resource exhaustion. How would you differentiate between "cloud apps" and "local apps"? Are you defining "cloud apps" as things that run in web browsers, or use a web browser engine, or just anything running from a remote system? If the web browser approach, I'd support that handling. -- John M. Harris, Jr. ___ 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: 20200708.n.0 changes
OLD: Fedora-Rawhide-20200707.n.0 NEW: Fedora-Rawhide-20200708.n.0 = SUMMARY = Added images:1 Dropped images: 5 Added packages: 14 Dropped packages:1 Upgraded packages: 173 Downgraded packages: 0 Size of added packages: 44.65 MiB Size of dropped packages:567.81 KiB Size of upgraded packages: 5.03 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 71.89 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20200708.n.0.iso = DROPPED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200707.n.0.ppc64le.tar.xz Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200707.n.0.ppc64le.tar.xz Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200707.n.0.ppc64le.vmdk Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200707.n.0.ppc64le.raw.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200707.n.0.ppc64le.qcow2 = ADDED PACKAGES = Package: badwolf-1.0.0-2.fc33 Summary: Web Browser which aims at security and privacy over usability RPMs:badwolf Size:375.61 KiB Package: cvise-1.4.0-1.fc33 Summary: Super-parallel Python port of the C-Reduce RPMs:cvise Size:17.08 MiB Package: jgmenu-4.2.1-3.fc33 Summary: Simple X11 application menu RPMs:jgmenu jgmenu-gtktheme jgmenu-lx jgmenu-pmenu jgmenu-xfce4 Size:998.39 KiB Package: perl-Color-ANSI-Util-0.164-1.fc33 Summary: Routines for dealing with ANSI colors RPMs:perl-Color-ANSI-Util Size:25.17 KiB Package: perl-Color-RGB-Util-0.601-1.fc33 Summary: Utilities related to RGB colors RPMs:perl-Color-RGB-Util Size:27.21 KiB Package: perl-ColorThemeBase-Static-0.008-1.fc33 Summary: Base class for color theme modules with static list of items RPMs:perl-ColorThemeBase-Static Size:31.92 KiB Package: perl-Graphics-ColorNamesLite-WWW-1.14.000-1.fc33 Summary: WWW color names and equivalent RGB values RPMs:perl-Graphics-ColorNamesLite-WWW Size:18.83 KiB Package: perl-Module-Load-Util-0.003-1.fc33 Summary: Some utility routines related to module loading RPMs:perl-Module-Load-Util Size:21.37 KiB Package: perl-Regexp-Pattern-Perl-0.002-1.fc33 Summary: Regexp patterns related to Perl RPMs:perl-Regexp-Pattern-Perl Size:20.43 KiB Package: perl-Test-RandomResult-0.001-1.fc33 Summary: Test that results of a running code look random RPMs:perl-Test-RandomResult Size:18.92 KiB Package: python-flask-compress-1.5.0-2.fc33 Summary: Compress responses in your Flask app with gzip or brotli RPMs:python3-flask-compress Size:15.47 KiB Package: python-jose-3.1.0-1.fc33 Summary: JOSE implementation in Python RPMs:python3-jose python3-jose-cryptography python3-jose-pycrypto python3-jose-pycryptodome Size:76.12 KiB Package: qxmledit-0.9.15-3.fc33 Summary: Simple XML Editor and XSD Viewer RPMs:libqxmledit libqxmledit-devel qxmledit qxmledit-doc Size:25.93 MiB Package: rust-libcryptsetup-rs-0.4.2-1.fc33 Summary: High level Rust bindings for libcryptsetup RPMs:rust-libcryptsetup-rs+default-devel rust-libcryptsetup-rs-devel Size:50.07 KiB = DROPPED PACKAGES = Package: lv2-artyfx-plugins-1.3-0.14.20150506gitff73e5a.fc32 Summary: A collection of LV2 RT plugins RPMs:lv2-artyfx-plugins Size:567.81 KiB = UPGRADED PACKAGES = Package: OpenImageIO-2.1.17.0-1.fc33 Old package: OpenImageIO-2.1.16.0-3.fc33 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 19.84 MiB Size change: -532 B Changelog: * Thu Jul 02 2020 Richard Shaw - 2.1.17.0-1 - Update to 2.1.17.0. Package: aom-2.0.0-1.fc33 Old package: aom-1.0.0-9.20190810git9666276.fc32 Summary: Royalty-free next-generation video format RPMs: aom libaom libaom-devel Size: 10.54 MiB Size change: 445.13 KiB Changelog: * Wed Jul 01 2020 Robert-Andr?? Mauchin - 2.0.0-1 - Update to 2.0.0 (#1852847) Package: awscli-1.18.94-1.fc33 Old package: awscli-1.18.93-1.fc33 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.80 MiB Size change: -14 B Changelog: * Tue Jul 07 2020 Gwyn Ciesla - 1.18.94-1 - 1.18.94 Package: bemenu-0.5.0-1.fc33 Old package: bemenu-0.4.1-2.fc33 Summary: Dynamic menu library and client program inspired by dmenu RPMs: bemenu bemenu-devel Size: 592.11 KiB Size change: 1.51 KiB Changelog: * Tue Jul 07 2020 Jan Stan??k - 0.5.0-1 - Upgrade to version 0.5.0 Package: binutils-2.34.0-8.fc33 Old package: binutils-2.34.0-7.fc33 Summary: A GNU collection
Re: Btrfs by default, the compression option
On Wed, Jul 08, 2020 at 12:24:27AM -0600, Chris Murphy wrote: > 2. Benchmarking: this is hard. A simple tool for doing comparisons > among algorithms on a specific bit of hardware is lzbench. > https://github.com/inikep/lzbench > How to compile on F32. > https://github.com/inikep/lzbench/issues/69 > But is that adequate? How do we confirm/deny on a wide variety of > hardware that this meets the goal? And how is this test going to > account for parallelization, and read ahead? Do we need a lot of data > or is it adequate to get a sample "around the edges" (e.g. slow cpu > fast drive; fast cpu slow drive; fast cpu fast drive; slow cpu slow > drive). What algorithm? More data is always better. I like qualifying the situations in that way. I think we should make our decision based on the "center" rather than the edges, though. For I hope obvious reasons, I'd love to see this tested on a Lenovo X1 Carbon Gen 8 with the default SSD options. And, for benchmarks, I'm thinking more application benchmarks than a benchmark of the compression itself. How much does compressed /usr affect boot times for GNOME and KDE? What about startup time for LibreOffice, Firefox, etc? Any impact on run-time usage? [...] > D. Which directories? Some may be outside of the installer's scope. As I noted in the bugzilla entry, the /var/log on this system compresses to 3.6% of its original size. (Methodology: I tarred up the dir and then ran zstd -1 on the tar file. If I use -19, it's unsurprisingly slow and saves another whole one percent of the original.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of legacy BIOS support in Fedora.
On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote: > On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot > > > and > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > files you can find there are public anyway, you can download them from > > > the fedora servers. Encrypting /boot would make the boot process more > > > fragile for no benefit. > > > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered > > with, > > > Well, if that is your concern the answer is secure boot. That will not > only prevent tampering with /boot files, but also prevent tampering with > the bootloader itself. No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway, needlessly disables a lot of kernel functionality, which makes it completely unusable. You cannot load kernel modules you've built, hibernate your system, etc. Additionally, Secure Boot does not prevent tampering with /boot files. You can still change grub.cfg as you like. > > or config files haven't been read by somebody other than the end > > user. > > > Hmm, typically that is pretty standard stuff and very simliar on all > fedora installs. Only the root filesystem uuid differs, and possibly > local tweaks like configuring a serial console. I can't see how reading > that is of much concern. There's no reason to allow these files to be read to begin with, if the system is going to be encrypted. -- John M. Harris, Jr. ___ 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: Btrfs by default, the compression option
On Wednesday, July 8, 2020 1:10:12 AM MST Kamil Paral wrote: > On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote: > > D. Which directories? Some may be outside of the installer's scope. > > > > /usr > > /var/lib/flatpak > > ~/.local/share/flatpak > > I have a concern regarding games. Currently, we have a few a bit more > demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In > the glorious future (tm) we might get more. Games are very sensitive to > available CPU cycles and context switching and usually come with their data > files already compressed. Including the btrfs compression by default on > flatpak dirs could lead to lowered performance whenever the game tries to > load some assets (older titles do that during the loading screen, newer > titles stream new assets constantly during gameplay and any slowdown > manifests as game stuttering). Flatpack stuff aside, we have games like 0AD, Xonotic, Albion and others in the repos as well, where compression should not be used. Also, just wondering, how are you planning to enable compression on an unknown user's home directory? As a modification to the homedir helper? -- John M. Harris, Jr. ___ 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: Using "rawhide" for the dist-git branch for Fedora Rawhide
On Wed, Jul 08, 2020 at 03:48:23PM +0200, Till Maas wrote: > Just had another idea, how about instead of branch down from the rawhide > branch to new branched to make Rawhide always use the fxy version that > it develops. So instead of creating branched f33 later we would rename > master to f33 now and then once we need to branch we branch of Rawhide > as f34? There could still be a symbolic ref called rawhide for the > latest rawhide for convenience. What do you think? I do like this, because it reflects the actual process. However, it does ask something of our git forge web front end: what would it show by default? -- Matthew Miller Fedora Project Leader ___ 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: Can we do away with release and changelog bumping?
On Wednesday, July 8, 2020 4:16:34 PM CEST Pavel Raiskup wrote:
> On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> > problem few months ago.
> > It is a koji plugin as well as CLI tool that makes bumping the release
> > field and generating changelog problem of Koji,
> > instead of package-maintainer. Currently it sits deployed in staging koji,
> > so you can give it a test-drive :-)
> >
> > We hope we can return to it later this year, to have it deployed in prod
> > koji.
>
> +1 to what Florian proposes over rpmautospec, though. I think bumping the
> release flag is the bare minimal technical change that is needed (except that
> bodhi should pre-fill the description by diffs from %changelogs).
Small experiment (few-liner) for copr with "%bid, build system tag":
https://pagure.io/copr/copr/pull-request/1436
Pavel
> I before stated my opinion that I don't like the generated %changelog
> idea. Fedora git changelog and `rpm --changelog` are two different
> things. Mixing them up will bring more costs than savings (fixing
> mistakes in git commit messages retrospectively). Or in other extreme the
> ugly `rpm --changelog` output (people don't care they mistakenly provided
> broken git commit message).
>
> I think that it would be just enough to allow people to stop producing
> `rpm --changelog`s if they think that it so awful amount of work (both
> better than more expensive %changelog variant, or ugly variant). Let's
> allow packagers to specify something like:
>
> %changelog
> * there's no package metadata in changelog
>
> Or in the worst case, automatize:
>
> * there's no package metadata in changelog
> - check %_pkgdocdir/fedora-git-changelog file
>
> I'm not saying that we can not see every proposed approach in action as
> opt-in. But, IMVHO, we are wasting to much efforts time here that could
> be spent on our content served to our users instead (== I mean the overall
> %changelog quality).
>
> Pavel
>
> > [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
> >
> > On Mon, Jul 6, 2020 at 8:22 AM Florian Weimer wrote:
> >
> > > * Björn Persson:
> > >
> > > > The macro could be defined like this for example:
> > > >
> > > > %buildtag .%(date +%%s)
> > >
> > > Using time for synchronization is always a bit iffy.
> > >
> > > > It would be used in each spec like this:
> > > >
> > > > Release: 1%{?dist}%{?buildtag}
> > >
> > > We could put the Koji task ID directly into the %dist tag. We know that
> > > this works in principle. If we are worried that the number gets too
> > > large, we could subtract the current task ID at the time the fcNN part
> > > of the %dist tag changes.
> > >
> > > The %dist tag is not recorded in the changelog by most packages, so the
> > > changelog does not need changing.
> > >
> > > 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://docs.fedoraproject.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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal
On Tue, Jul 07, 2020 at 15:16:22 -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PostgreSQL_13 == Summary == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 12 to version 13 in the non-modular (main) builds. While I like to have the latest postgresql available for my use, it seems pretty aggressive to try to get postgresql 13 into F33. Using the beta versions is a pain because the catalog will often change right up to release and you need to dump and reload or run a conversion on your data with each update. So this won't be practical to put in rawhide until it is released. While the release might be done soon, postgresql releases often end up happening in October. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TPM2 for disk encryption, clevis
On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote: > As I understand it, there is a lot of evolving OS specific subtlety > involved, so I am asking specifically how this would look on current > Fedora and what to expect in the near future. Just a heads-up; the PCR0 changes when you upgrade the system firmware. Dell already requested that fwupd somehow "informs" clevis about the new PCR0, but until vendors start supplying this in the firmware metadata it's not super useful to know "it's going to be different". Richard. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using "rawhide" for the dist-git branch for Fedora Rawhide
On 08.07.2020 16:29, Pierre-Yves Chibon wrote: > One wonder which I have is: should we keep a "master" branch, just as a > symlink > to the "rawhide" one for backward compatibility purposes? Yes. Master branch is hardcoded in lots of places (infra, maintainer's scripts, etc.) and such rename will break lots of greatly working things. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using "rawhide" for the dist-git branch for Fedora Rawhide
On Wednesday, 08 July 2020 at 16:29, Pierre-Yves Chibon wrote: > On Wed, Jul 08, 2020 at 10:09:35AM -0400, Kaleb Keithley wrote: > >Whatever name is picked: devel, main, rawhide, next, etc., how about > >setting the default branch. > >E.g. `git symbolic-ref HEAD refs/heads/rawhide` > >This way when someone clones the repo they don't need to know or remember > >which name Fedora is using as the mainline development branch. > > That is easy to do, already supported by our forge and I am definitely +1 on > this. > > One wonder which I have is: should we keep a "master" branch, just as a > symlink > to the "rawhide" one for backward compatibility purposes? I'd say yes. I believe muscle memory will make most people do git checkout master for a long time, even after git upstream decides on a new default branch name. It'd be nice if this was handled similar to foo->rpms/foo namespace transition. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: TPM2 for disk encryption, clevis
On Wed, Jul 08, 2020 at 11:58:58AM +0300, Marius Vollmer wrote:
> Hi,
>
> we have some rudimentary support for Clevis in the Cockpit Web Console,
> and now the question is, should we add support for "tpm2" to that?
What does 'support for clevis' there look like? you mean just binding a
encrypted drive to look for clevis servers on boot?
>
> As I understand it, there is a lot of evolving OS specific subtlety
> involved, so I am asking specifically how this would look on current
> Fedora and what to expect in the near future.
>
> Here is the discussion that prompted my question:
>
> https://github.com/cockpit-project/cockpit/issues/14313[1]
>
> In most concrete terms: Which PCRs should we use on which version of
> Fedora? ("None" is a totally nice answer.)
>
> I don't think we can let the user enter the PCR numbers, that requires
> way to much intimate knowledge of the current state of support for
> secure boot of their OS. I.e., the best way I have to answer that for
> myself is to ask here.
>
> The user needs to be shielded from that knowledge, I'd say, and ideally
> clevis would already shield me from it, but I am happy to do it in
> Cockpit.
I think tpm2 might be good, but lots of machines don't have tpm2.
So I would think it would need to be optional?
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: Packagers with no corresponding valid bugzilla accounts
On Wed, Jul 08, 2020 at 09:25:32AM +0200, Pierre-Yves Chibon wrote: > On Tue, Jul 07, 2020 at 10:38:01AM -0700, Michel Alexandre Salim wrote: > > Should we make the script more robust and ignore invalid watcher > > emails? Seems worrying if someone who's not even a packager can block > > packager changes from being reflected in Bugzilla. > > As you can see in this JSON there is no difference between maintainers and > watchers, so the script syncing to bugzilla does not have this information. > I think that asking FESCo for a policy on how to deal with this + an automated > way to detect this situation (which we didn't really have so far) may be > sufficient. However, if this situation happens too frequently, and leads to > too > much manual work to clean things up, we may need to see about somehow adding > this information to the JSON file and teaching the script the difference. > It would increase the load on bugzilla though :( In the ideal world, we would just add checks so that people couldn't get into this state. But thats going to require a lot of coordination/those checks might be very difficult right now. I wonder though, if we could get the new account system to help us here: I think there was a plan to have it allow for a 'bugzilla email'. Could it perhaps also verify the bugzilla email and have some 'bugzilla ok' property? Then, pagure could check it before allowing someone to watch/own/be point of contact on a package and tell them to go set it before allowing? 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
[Test-Announce] Fedora 33 Rawhide 20200708.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 33 Rawhide 20200708.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200708.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@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: Using "rawhide" for the dist-git branch for Fedora Rawhide
On Wed, Jul 08, 2020 at 10:09:35AM -0400, Kaleb Keithley wrote: >Whatever name is picked: devel, main, rawhide, next, etc., how about >setting the default branch. >E.g. `git symbolic-ref HEAD refs/heads/rawhide` >This way when someone clones the repo they don't need to know or remember >which name Fedora is using as the mainline development branch. That is easy to do, already supported by our forge and I am definitely +1 on this. One wonder which I have is: should we keep a "master" branch, just as a symlink to the "rawhide" one for backward compatibility purposes? >On Wed, Jul 8, 2020 at 9:57 AM Miro Hrončok <[1]mhron...@redhat.com> >wrote: > > On 08. 07. 20 15:48, Till Maas wrote: > > On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote: > >> Hi, > >> > >> in [2]https://pagure.io/fesco/issue/2410 I proposed to name the > dist-git > >> branch for Fedora Rawhide "rawhide" to clarify the purpose of that > >> branch. There was also some feedback that Rawhide might not be the > best > >> name and it could be renamed. In that case, the branch could be named > as > >> this. This is just the first step to check if there is enough support > >> for this to move forward. The next step would be to start a change > >> process. > > > > Just had another idea, how about instead of branch down from the > rawhide > > branch to new branched to make Rawhide always use the fxy version that > > it develops. So instead of creating branched f33 later we would rename > > master to f33 now and then once we need to branch we branch of Rawhide > > as f34? There could still be a symbolic ref called rawhide for the > > latest rawhide for convenience. What do you think? > > I like that idea. However IMHO packagers tend to forget about branching > if they > are not following Fedora development closely. > > When they do that now, they still do changes in rawhide and they might > not > update their package in branched -- however in long term, this does not > matter > because their change is in all future versions. > > When they do that after this, their change will be in branched but not > in > rawhide and in the long term, it will be lost. Having a "rawhide" symlink to whatever is the current FXX rawhide *may* solve this, if and only if they work on that rawhie branch, if they do not, the risk you are pointing is real and would trigger potentially more upgrade path break. Pierre ___ 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
Summary/Minutes from today's FESCo Meeting (2020-07-08)
Meeting started by mhroncok at 14:01:30 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-07-08/fesco.2020-07-08-14.01.log.html . Meeting summary --- * init process#topic init process#topic init process (mhroncok, 14:01:41) * init process (mhroncok, 14:01:43) * #2420 F33 System-Wide Change: Use %make_build and %make_install macros (mhroncok, 14:05:09) * LINK: https://pagure.io/fesco/issue/2420 (mhroncok, 14:05:25) * LINK: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CPRVJJ56XSF4S6DSYIPVXHEXUXGR4PUX/ (mhroncok, 14:09:34) * AGREED: Neal's proposal in https://pagure.io/fesco/issue/2420#comment-662515 and ask change owner to reopen discussion if they think more should happen than that. APPROVED (+6, 2, -0) (mhroncok, 14:16:00) * Next week's chair (mhroncok, 14:16:36) * ACTION: zbyszek will chair next meeting (mhroncok, 14:17:57) * Open Floor (mhroncok, 14:18:09) Meeting ended at 14:24:44 UTC. Action Items * zbyszek will chair next meeting Action Items, by person --- * zbyszek * zbyszek will chair next meeting * **UNASSIGNED** * (none) People Present (lines said) --- * mhroncok (48) * dcantrell (21) * zodbot (15) * zbyszek (15) * nirik (9) * decathorpe (9) * bcotton (8) * King_InuYasha (3) * ignatenkobrain (2) * cverna (2) * Conan_Kudo (0) * Eighth_Doctor (0) * sgallagh (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0) -- 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: Can we do away with release and changelog bumping?
On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the release
> field and generating changelog problem of Koji,
> instead of package-maintainer. Currently it sits deployed in staging koji,
> so you can give it a test-drive :-)
>
> We hope we can return to it later this year, to have it deployed in prod
> koji.
+1 to what Florian proposes over rpmautospec, though. I think bumping the
release flag is the bare minimal technical change that is needed (except that
bodhi should pre-fill the description by diffs from %changelogs).
I before stated my opinion that I don't like the generated %changelog
idea. Fedora git changelog and `rpm --changelog` are two different
things. Mixing them up will bring more costs than savings (fixing
mistakes in git commit messages retrospectively). Or in other extreme the
ugly `rpm --changelog` output (people don't care they mistakenly provided
broken git commit message).
I think that it would be just enough to allow people to stop producing
`rpm --changelog`s if they think that it so awful amount of work (both
better than more expensive %changelog variant, or ugly variant). Let's
allow packagers to specify something like:
%changelog
* there's no package metadata in changelog
Or in the worst case, automatize:
* there's no package metadata in changelog
- check %_pkgdocdir/fedora-git-changelog file
I'm not saying that we can not see every proposed approach in action as
opt-in. But, IMVHO, we are wasting to much efforts time here that could
be spent on our content served to our users instead (== I mean the overall
%changelog quality).
Pavel
> [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
>
> On Mon, Jul 6, 2020 at 8:22 AM Florian Weimer wrote:
>
> > * Björn Persson:
> >
> > > The macro could be defined like this for example:
> > >
> > > %buildtag .%(date +%%s)
> >
> > Using time for synchronization is always a bit iffy.
> >
> > > It would be used in each spec like this:
> > >
> > > Release: 1%{?dist}%{?buildtag}
> >
> > We could put the Koji task ID directly into the %dist tag. We know that
> > this works in principle. If we are worried that the number gets too
> > large, we could subtract the current task ID at the time the fcNN part
> > of the %dist tag changes.
> >
> > The %dist tag is not recorded in the changelog by most packages, so the
> > changelog does not need changing.
> >
> > 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://docs.fedoraproject.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: Using "rawhide" for the dist-git branch for Fedora Rawhide
Whatever name is picked: devel, main, rawhide, next, etc., how about setting the default branch. E.g. `git symbolic-ref HEAD refs/heads/rawhide` This way when someone clones the repo they don't need to know or remember which name Fedora is using as the mainline development branch. On Wed, Jul 8, 2020 at 9:57 AM Miro Hrončok wrote: > On 08. 07. 20 15:48, Till Maas wrote: > > On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote: > >> Hi, > >> > >> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git > >> branch for Fedora Rawhide "rawhide" to clarify the purpose of that > >> branch. There was also some feedback that Rawhide might not be the best > >> name and it could be renamed. In that case, the branch could be named as > >> this. This is just the first step to check if there is enough support > >> for this to move forward. The next step would be to start a change > >> process. > > > > Just had another idea, how about instead of branch down from the rawhide > > branch to new branched to make Rawhide always use the fxy version that > > it develops. So instead of creating branched f33 later we would rename > > master to f33 now and then once we need to branch we branch of Rawhide > > as f34? There could still be a symbolic ref called rawhide for the > > latest rawhide for convenience. What do you think? > > I like that idea. However IMHO packagers tend to forget about branching if > they > are not following Fedora development closely. > > When they do that now, they still do changes in rawhide and they might not > update their package in branched -- however in long term, this does not > matter > because their change is in all future versions. > > When they do that after this, their change will be in branched but not in > rawhide and in the long term, it will be lost. > > -- > 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 > ___ 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: Using "rawhide" for the dist-git branch for Fedora Rawhide
On 08. 07. 20 15:48, Till Maas wrote: On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote: Hi, in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git branch for Fedora Rawhide "rawhide" to clarify the purpose of that branch. There was also some feedback that Rawhide might not be the best name and it could be renamed. In that case, the branch could be named as this. This is just the first step to check if there is enough support for this to move forward. The next step would be to start a change process. Just had another idea, how about instead of branch down from the rawhide branch to new branched to make Rawhide always use the fxy version that it develops. So instead of creating branched f33 later we would rename master to f33 now and then once we need to branch we branch of Rawhide as f34? There could still be a symbolic ref called rawhide for the latest rawhide for convenience. What do you think? I like that idea. However IMHO packagers tend to forget about branching if they are not following Fedora development closely. When they do that now, they still do changes in rawhide and they might not update their package in branched -- however in long term, this does not matter because their change is in all future versions. When they do that after this, their change will be in branched but not in rawhide and in the long term, it will be lost. -- 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: CPE Team Engagement Feedback
On Wed, Jul 8, 2020 at 2:44 PM Vipul Siddharth wrote: > > oops, sent too soon (more like didn't read correctly)! please ignore last > email > > On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote: > > > > Le 08/07/2020 à 11:09, Aoife Moloney a écrit : > > > > > Our CPE Review Team > > > include: > > > * Fedora - mmiller, mnordin, bcotton > > > * CentOS - rbowen, bex > > > * RHEL - bex, dperpeet, aslobodova > > > > > > Where is EPEL ? > > > > Hi Remi, This list represents the CPE Teams stakeholders and as EPEL is a part of the Fedora project, its representation is covered by Matthew, Marie & Ben. Hope that clarifies! Aoife > > > > > > Remi > > ___ > > 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 > > > > -- > Vipul Siddharth > He/His/Him > Fedora | CentOS CI Infrastructure Team > Red Hat > w: vipul.dev > ___ > 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 -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: Using "rawhide" for the dist-git branch for Fedora Rawhide
On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote: > Hi, > > in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git > branch for Fedora Rawhide "rawhide" to clarify the purpose of that > branch. There was also some feedback that Rawhide might not be the best > name and it could be renamed. In that case, the branch could be named as > this. This is just the first step to check if there is enough support > for this to move forward. The next step would be to start a change > process. Just had another idea, how about instead of branch down from the rawhide branch to new branched to make Rawhide always use the fxy version that it develops. So instead of creating branched f33 later we would rename master to f33 now and then once we need to branch we branch of Rawhide as f34? There could still be a symbolic ref called rawhide for the latest rawhide for convenience. What do you think? 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: CPE Team Engagement Feedback
oops, sent too soon (more like didn't read correctly)! please ignore last email On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote: > > Le 08/07/2020 à 11:09, Aoife Moloney a écrit : > > > Our CPE Review Team > > include: > > * Fedora - mmiller, mnordin, bcotton > > * CentOS - rbowen, bex > > * RHEL - bex, dperpeet, aslobodova > > > Where is EPEL ? > > > > > Remi > ___ > 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 -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team Red Hat w: vipul.dev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Team Engagement Feedback
On Wed, Jul 8, 2020 at 7:09 PM Remi Collet wrote: > > Le 08/07/2020 à 11:09, Aoife Moloney a écrit : > > > Our CPE Review Team > > include: > > * Fedora - mmiller, mnordin, bcotton > > * CentOS - rbowen, bex > > * RHEL - bex, dperpeet, aslobodova > > > Where is EPEL ? Extra Packages for Enterprise Linux https://fedoraproject.org/wiki/EPEL > > > > > Remi > ___ > 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 -- Vipul Siddharth He/His/Him Fedora | CentOS CI Infrastructure Team Red Hat w: vipul.dev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Team Engagement Feedback
Le 08/07/2020 à 11:09, Aoife Moloney a écrit : > Our CPE Review Team > include: > * Fedora - mmiller, mnordin, bcotton > * CentOS - rbowen, bex > * RHEL - bex, dperpeet, aslobodova Where is EPEL ? Remi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-08 at 14:13 +0200, Vitaly Zaitsev via devel wrote: > On 07.07.2020 19:57, Orion Poplawski wrote: > > What's the plan for EPEL8/7 compatibility? > > +1. The new Cmake macros behaviour must be backported to EPEL7/8. Feel free to submit patches to cmake3 and epel-rpm-macros. > Currently all fixed by proven packages SPEC files cannot be built on > EPEL branches. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8Fx9EACgkQEV1auJxc Hh7JzxAAtK8VXZz+jEdw1KICPRBOnsRvEcPBzpXbT7SLJd+84HRzxTFnWWJKqn3I 8hOKDl+lm00DKnplcIVPQXJ2g9CkV3a17bDWFGq9oW47eyH97lGRNUZifTKWcv7n OJNBB3OsU1jbhkKs0WtCX8NVmux2w9C/pCrSfcxCXxiWT7vz70NALqPX526sCDyb 6Unid5W/dZ35xl7tWmLm4WEwefpDOoCUF+khc9x8JPY6laczHmPk1RIdZ6g9a2FI Nwe6GNry1CWP22+wqxJlNQI0AEoev/olerIRD9hZ/TYiH+fRGqcOSefKDLE5TE3Y y9SF+5pEsELZgZm0hnI8b9QjIiNjf7m7RELn+Pdm/nS5eqJyIKuUUr/Zz+M4oDYW aZ2xToIyak769PmF6wr7x3oMAiT/OkvZRzwdpB6lC7cDslMAonsDisFIK8D7kE8x du/fHb/tIbbYuVVm4CnhxxY304U8NmBxCRsXZIYJNKdinG0nSAZUdy0Z5UqRk5VQ Tt2NMjSRBa2jV+AurM3thRCrJaVf6oPTKb6+pUsM6fBCF/HAoDN52AstxXNB97sS j/yOF4rPFg9N6i+ojDF7893n2ThkZXFERiqVTg2CWozLzK1g8AwfA66J38B5FQBJ QhL9vp8IO/aSrUa6pcfTbFTTozMncz7XZUDl4uStLFgUvkSzLxQ= =TyCb -END 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
CPE Team Engagement Feedback
Hi Everyone, As we kick off our team's work for Quarter 3 of this year, we would like to take this opportunity to ask for your feedback on our engagement over the last few months. The CPE has been working on trying to improve our communication with our communities and increase visibility on how we decide on what to work on. We have taken many steps to improve our communication such as IRC Office hours, regular initiative updates on our taiga board, weekly mail and blog posts on what we achieved in each quarter and what we are planning to work on next. We have also had a few discussions before with some Fedora Council and CentOS Board members on how best to engage with the CPE Team when you wish to brief in an initiative or need to file a bug/issue/enhancement, and as time goes by we are refining our processes. We would like to share with you our current approaches that we are using for you to provide feedback on how you feel these are working. It is important for our team to feel like their time is protected so that they are able to enjoy a healthy work-life balance, so we have categorized work requests that the team responds to into two categories which we believe benefits both the CPE team and the communities we serve: - Project Teams - These teams are created based on an initiative that has been: - Received by our product owner in advance - The work involved has been scoped, reviewed and accepted to the backlog by the CPE Review Team - Prioritized and actioned for work during our teams quarterly planning sessions by CPE Team Stakeholders and Review Team - Sustaining Team - This team responds to 'lights on work' and requests that come in on an ad hoc & regular basis such as: - BAU infra/releng requests - RFEs - Bug fixes ## How we propose to deal with Project Team Initiatives? * We have published deadlines for initiatives to be briefed into our team by for each quarter here: https://docs.fedoraproject.org/en-US/cpe/time_tables/ * Project requests that are recieved are then discussed further with the requestor and relevant team lead(s) with our product owner * During our monthly quarterly planning sessions, the CPE Review Team reviews and prioritises which proposals to scope. * All scoped proposed initiatives are brought into our QP session for review and consideration to be worked on in the next quarter. * Our CPE Review Team review all and vote on the initiatives they would like to see actioned in the next quarter. Our CPE Review Team include: * Fedora - mmiller, mnordin, bcotton * CentOS - rbowen, bex * RHEL - bex, dperpeet, aslobodova * CPE - * CPE Product Owner - amoloney * CPE Management - lgriffin, antcarroll, smattejiet * CPE Team Leads - pingou, bstinson As a picture is worth a thousand words, so here is one :) >  > Image Credit goes to Smera Goel, the very talented graphic designer that is > currently interning as part of the Fedora Outreachy Project. ## How we propose to deal with Sustaining Team BAU requests, RFEs and bug fixes? In order to allow the people working on initiatives to focus on them, our Sustaining Team members will be responsible for dealing with all these requests. They can be filed in the normal ways by community members. BAU infra requests can be made on the fedora-infrastructure issue tracker: https://pagure.io/fedora-infrastructure/ BAU releng requests can be made on the releng issue tracker: https://pagure.io/releng/ ## Project Team vs Sustaining Team Work Classification ### Project Initiatives Initiatives are weeks to months long projects involving a team of people to work on and deliver. We have some deadlines that we try to work towards Examples of initiatives: - rawhide package gating - FAS replacement - ... ### BAU infra/releng requests Business As Usual (BAU) requests are simple requests that do not need anyone to code something, just run some code to solve the request. Examples of BAU requests: - A new mailing list - A new FAS/dist-git/copr group - A new IRC channel - A new project on ci.centos.org - A new tag in koji ### RFE Requests For Enhancements (RFE) are requests to improve a changes made to either an application or a workflow used in Fedora. ### Bug fixes Bug fixes are what they are, request to fix bugs. Examples of bug fixes: - Well you know: https://github.com/fedora-infra/bodhi/issues or pagure.io/pagure/issues are full of them ;-) This is our team's current way of working, and we are seeing the benefits from this but wanted to have your feedback too. We would like to publish this as a 'policy' of sorts for our team on docs.fpo and on the CentOS wiki and want to include you in this process. So what are your thoughts on these ideas? Are they suitable for you or do they need more adjustments? If they do, what are your suggestions? To view this email in hackmd, please
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On 07.07.2020 19:57, Orion Poplawski wrote: > What's the plan for EPEL8/7 compatibility? +1. The new Cmake macros behaviour must be backported to EPEL7/8. Currently all fixed by proven packages SPEC files cannot be built on EPEL branches. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On Wed, Jul 8, 2020 at 4:11 AM Igor Raits wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote: > > Richard Shaw 于 2020年7月8日周三 上午6:11写道： > > > > > Ok, so it appears this change was for F32+ only, so I can't merge > > > master > > > into f32 or earlier... > > > > > Maybe wait it to be backported into f31. The documents said this > > will be > > backported into older supported version. > > > > But now, merging master into older version is impossible, can cause > > FTBTS. > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-a66614733c > https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b99724ef6 > > Test them and leave karma please :) > So the F32 update already had negative karma so auto push is disabled. Additionally this doesn't help with infra or mock builds,though I suppose I could force the update into my mock buildroot. Although non-traditional, perhaps a buildroot override for testing would have worked to allow infra builds and could be removed if it caused a problem. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 11:22 AM Dominique Martinet wrote: > Please test, but if a file is deemed not compressible (based on, not > sure what? the first few blocks?) then it will be stored in the > non-compressed version. > You can check with compsize after the fact if the file had been > compressed or not. > > This should be true unless the compress-force mount option is used, even > the chattr is only a hint > OK, this is an interesting piece of information I wasn't aware of. In this case, if the btrfs heuristics work OK in the majority of cases, the performance hit might not be there, as I feared. Some thorough investigation would be needed, though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-java] Re: Questions on an update to javamail in ursine
Sure, but when updating the javamail package, you will be providing compatibility aliases for the old maven coordinates using %mvn_alias and compatibility symlinks for the old filename using %mvn_file in order to not break dependent packages, right? Right? ;-) Unless a package somehow is not using the felix-bundle-plugin or aqute-bnd, a simple rebuild should fix OSGi metadata (i.e. the next mass rebuild should take care of it). On Mon, 6 Jul 2020 at 19:59, Jie Kang wrote: > Hey Mat, > > On further investigation, the compatibility changes that require > attention are made in javamail 1.6.3 and later, see: > > https://eclipse-ee4j.github.io/mail/docs/COMPAT.txt > > The maven coordinates are changed, generally javax -> jakarta. This > also affects the osgi provides. > > > Regards, > Jie Kang > > On Thu, Jul 2, 2020 at 5:54 AM Mat Booth wrote: > > > > > > > > On Wed, 1 Jul 2020 at 15:05, Fabio Valentini > wrote: > >> > >> On Mon, Jun 29, 2020 at 4:06 PM Jie Kang wrote: > >> > > >> > Hi all, > >> > > >> > javamail ursine is using version 1.5.2 while there are some module > >> > streams at 1.6.x > >> > > >> > The upstream project also moved to the eclipse foundation and these > >> > 1.6.x releases have different exports for OSGi, making an update to > >> > them potentially breaking for users. > >> > > >> > I'd like to update ursine to 1.6.x, but I understand packages > >> > depending on them should be notified or some such. However I realized > >> > I don't know what commands to run to get a list of such and then where > >> > to send it. Could anyone advise? > >> > > >> > Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail > >> > so maybe a new package 'mail' can be introduced to use it? Any > >> > thoughts there? > >> > >> I use this command to check for dependent packages: > >> > >> $ dnf --repo rawhide --repo rawhide-source --releasever rawhide > >> repoquery --whatrequires javamail > >> > >> Which is enough, since there are no other subpackages except -javadoc. > >> The command yielded (on July 1): > >> > >> ant-0:1.10.8-1.fc33.src > >> ant-javamail-0:1.10.8-1.fc33.noarch > >> bouncycastle-0:1.65-2.fc33.src > >> httpunit-0:1.7-29.fc32.src > >> log4j-0:2.13.1-1.fc33.src > >> log4j12-0:1.2.17-26.fc32.src > >> openas2-0:2.10.0-2.fc33.src > >> openas2-lib-0:2.10.0-2.fc33.noarch > >> > >> So the list of affected packages seems to be: > >> > >> - ant (Stewardship / Java SIG will deal with this) > >> - bouncycastle (?) > > > > > > Bouncycastle is me (it is a dep of jgit). From reading the javamail > "compat" document: https://javaee.github.io/javamail/docs/COMPAT.txt it > looks like I probably will need to take no action at all. > > > > ___ > > 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 > ___ > java-devel mailing list -- java-de...@lists.fedoraproject.org > To unsubscribe send an email to java-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/java-de...@lists.fedoraproject.org > -- Mat Booth http://fedoraproject.org/get-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: PostgreSQL 13 - Fedora 33 Self-Contained Change proposal
On 07. 07. 20 21:16, Ben Cotton wrote: == Scope == * Proposal owners: **Prepare PostgreSQL 13 as a module for Rawhide and at least one stable Fedora release (done) **Prepare PostgreSQL 12 as a module for Rawhide, so there would be a failover in case of problems **Build PostgreSQL 13 to Rawhide **Check software that requires or depends on `postgresql-server` or `libpq` packages for incompatibilities **Gather user input on the changes between PostgreSQL 12 and PostgreSQL 13 When we updated from PostgreSQL 11 to PostgreSQL 12 in Fedora 32, there was no targeted rebuild of the dependent packages and a dozen of packages failed to install. We were firefighting this between beta and final in: https://bugzilla.redhat.com/show_bug.cgi?id=1811800 I would very much like to see a targeted rebuild of dependent packages in a side tag in the scope (who does it? when?) and a contingency mechanism that reverts to PostgreSQL 12 if many packages cannot build. == Contingency Plan == Modules will provide the functional version of PostgreSQL 12, available to all users. If the 13 dependent packages don't install, a module with PostgreSQL 12 is **not** a contingency plan. -- 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
nodebug kernel repo file missing
https://fedoraproject.org/wiki/RawhideKernelNodebug links to http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo which gives 404 now. The kernels seems to be there though. But without the repo file it's not easy to enable. Zbyszek ___ 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: Btrfs by default, the compression option
Kamil Paral wrote on Wed, Jul 08, 2020: > On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote: > > > D. Which directories? Some may be outside of the installer's scope. > > > > /usr > > /var/lib/flatpak > > ~/.local/share/flatpak > > I have a concern regarding games. Currently, we have a few a bit more > demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In > the glorious future (tm) we might get more. Games are very sensitive to > available CPU cycles and context switching and usually come with their data > files already compressed. Including the btrfs compression by default on > flatpak dirs could lead to lowered performance whenever the game tries to > load some assets (older titles do that during the loading screen, newer > titles stream new assets constantly during gameplay and any slowdown > manifests as game stuttering). Please test, but if a file is deemed not compressible (based on, not sure what? the first few blocks?) then it will be stored in the non-compressed version. You can check with compsize after the fact if the file had been compressed or not. This should be true unless the compress-force mount option is used, even the chattr is only a hint > I'm personally more concerned about reduced performance in e.g. my web > browser than disk wear out. I don't see much harm in compressing /usr, > because it's a read-only location that gets loaded once when the app starts > (it might delay the app startup a bit, though, and decrease the perceived > snappiness of the desktop). But I'm concerned about compressing locations > which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5 > years and I'm just at 10% of expected TBW (total bytes written). If the SSD > lasts 50 or 100 years is not really important for me, but the desktop and > app responsiveness is (and game performance, of course:)). I think write > amplification is a problem specific to devices with SD cards, and for > anyone else, it might be better to leave it unset and let people enable it > (it's simple) if they want it for their use case. This obviously needs testing on a wide variety of hardware but I haven't noticed any difference in the feeling on an intel laptop (kabylake i5 throttled at 2GHz) ; that being said firefox isn't the most responsive app in my book... -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2020-07-08 at 09:12 +0800, Qiyu Yan wrote: > Richard Shaw 于 2020年7月8日周三 上午6:11写道： > > > Ok, so it appears this change was for F32+ only, so I can't merge > > master > > into f32 or earlier... > > > Maybe wait it to be backported into f31. The documents said this > will be > backported into older supported version. > > But now, merging master into older version is impossible, can cause > FTBTS. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a66614733c https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b99724ef6 Test them and leave karma please :) > > > > > This whole change is still broken AF. > > > > Thanks, > > Richard > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > ___ > 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 - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8FjcEACgkQEV1auJxc Hh6+yxAAoJAojZ3en5ip2Lov+rciwDYKQaNW7231oYN2FsuG5EakUtu9CPjCAjRW 9n7W7Z2QmkrV/aPg3V304n4UFfNiKp01HHVF9vco8ljryrJObWSgwhzsv/8VO1k7 O+3rSieII8TcUyupAP5VfEqgJb0GFqdPeJpDNh3kovMbDAH6kdEH4ZGmwg/+xoPn 7gNBNl5r7FBik9i8nLhxm3sgglw0zjzAT1ac9PFrx8fx7eXo8clbuAD0i6bi8qJM 7i0NSTppf0KaeDRv88VZUwQMeZmjL2FrUvFIiWDlPvynjqZ6aGa4rNnJrEOLYbRy mpZTYa4qIWQ4+rgwwQbFfHoc168ZDenoWLR5YE+Qr/SzlyFN09WPmwffnFELHCX+ DJgv2vUHbwpAW7WTDrwjPLb2vmfK3wtI5StPGTh4Ntp8uy7j/B2hZipvub1TLeDb i26ouzKmHDOohizWrA/CQwlpxx7qFRPl5NuQveCp4oV7A8Xram/2h/J9UEA3skxr +3m5RJBtjUVWfdMGUkxqL88H/WN4Z6EkCQXhnZA9IAU043kORu3uImMArmv3ZkPT rhiSq443HNIpvUOd0nwtxx3O47YSv9uvQWY35PL27VqSznzuPnK1MiOxShF3w/iR MpYadfe/lruo6xwppPUhLRqilumQZDUUZuZptWwVwV5ykBkRxfw= =IeUt -END 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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 11:57 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> > From cmake.1:
> >
> >
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> >
> >
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> > %cmake +
> > %(make|ninja)_(build|install)
> >
> > There are multiple paths to complete the migration:
> >
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> >
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> >
> > %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Existing packages can (and most likely will) become FTBFS, but
> > proposal owners will fix as many Fedora packages as possible.
> > However
> > fixing third-party packages is not possible and out of scope.
> > Third-party packagers will need to adapt based on the
> > recommendations
> > noted in this Change.
>
> What's the plan for EPEL8/7 compatibility?
Ask people that work on EPEL :) The change talks only about Fedora
backports that have been done already and are sitting in the testing
now.
>
>
> ___
> 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
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, 2020-07-07 at 12:07 -0600, Orion Poplawski wrote:
> On 6/15/20 1:47 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org,
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> >
> > == Detailed Description ==
> > Historically, software builds had a singular build configuration
> > and
> > required running the build within the project root. Nowadays, there
> > are many build modes and options that can be configured in
> > projects,
> > different build settings (e.g. compiler flags) / types (release,
> > debug) that can be applied and different tools that can be used to
> > actually execute builds (compilers like gcc/clang, build job
> > schedulers like make/ninja, and so on). Thus, CMake upstream
> > strongly
> > discourages users of doing in-source builds and recommends doing
> > out-of-source builds.
> >
> > From cmake.1:
> >
> >
> > To maintain a pristine source tree, perform an out-of-source build
> > by
> > using a separate dedicated build tree. An in-source build in which
> > the
> > build tree is placed in the same directory as the source tree is
> > also
> > supported, but discouraged.
> >
> >
> > The other part of the change is introduction of additional macros
> > is
> > creation of set of macro that can build, install and run tests in a
> > backend-agnostic, vpath-aware (out-of-source, in-source) way.
> >
> > === Migration ===
> >
> > %cmake +
> > %(make|ninja)_(build|install)
> >
> > There are multiple paths to complete the migration:
> >
> > * Add -C "%{_vpath_builddir}" to the
> > %(make|ninja)_*
> > * Replace %(make|ninja)_build and
> > %(make|ninja)_install with %cmake_build
> > and
> > %cmake_install respectively
> > * Redefine vpath builddir %global _vpath_builddir . to
> > continue performing in-source builds (and optionally converting to
> > the
> > %cmake_*)
> >
> > Depending on the package, one of these options may be used to adapt
> > to
> > this change.
> >
> > %cmake -B builddir +
> > %(make|ninja)_(build|install) -C builddir
> >
> > No changes are needed.
> >
> > == Benefit to Fedora ==
> > * Follow CMake upstream recommendations when building packages
> > * Brings Fedora package builds more in-line with how upstream
> > projects
> > expect them to be built
> > * Improve compatibility with other RPM distributions that already
> > do this
> > * Support backend-agnostic way of building CMake projects
> >
> > == Scope ==
> > * Proposal owners: Implement necessary macros, try to build
> > packages
> > that BuildRequires: cmake in a side tag, analyze
> > failures
> > and fix the relevant ones (introduced by this change).
> > * Other developers: While proposal owners will try to fix all
> > affected
> > packages, there might be some cases where package is already FTBFS
> > so
> > the fix can't be performed. Other package maintainers will have to
> > fix
> > the issue themselves after they fix FTBFS.
> > * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> > * Policies and guidelines: CMake page will be adjusted to mention
> > newly created macros and the documentation about relevant VPATH
> > macros
> > needs to be restructured a bit (they are already documented on the
> > Meson page, they need to be moved to the separate page and
> > referenced
> > both from CMake and Meson page).
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Existing packages can (and most likely will) become FTBFS, but
> > proposal owners will fix as many Fedora packages as possible.
> > However
> > fixing third-party packages is not possible and out of scope.
> > Third-party packagers will need to adapt based on the
> > recommendations
> > noted in this Change.
>
> What's with %{nil}? If we're writing macros that require the use of
> %{nil} I think we have a problem.
>
> %cmake3 \
> %{?_with_cppunit: -DENABLE_CPPUNIT=ON} \
> %{nil}
It is not strictly needed, but I wanted to avoid moving lines around to
keep diff as small as possible.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe
TPM2 for disk encryption, clevis
Hi,
we have some rudimentary support for Clevis in the Cockpit Web Console,
and now the question is, should we add support for "tpm2" to that?
As I understand it, there is a lot of evolving OS specific subtlety
involved, so I am asking specifically how this would look on current
Fedora and what to expect in the near future.
Here is the discussion that prompted my question:
https://github.com/cockpit-project/cockpit/issues/14313[1]
In most concrete terms: Which PCRs should we use on which version of
Fedora? ("None" is a totally nice answer.)
I don't think we can let the user enter the PCR numbers, that requires
way to much intimate knowledge of the current state of support for
secure boot of their OS. I.e., the best way I have to answer that for
myself is to ask here.
The user needs to be shielded from that knowledge, I'd say, and ideally
clevis would already shield me from it, but I am happy to do it in
Cockpit.
Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Using "rawhide" for the dist-git branch for Fedora Rawhide
On Tue, Jul 07, 2020 at 10:13:36PM +, Gary Buhrmaster wrote: > I (strongly) support the renaming of the branch, but I really > really would prefer there to be a rough consensus on the > replacement name across the entire git community, so > that I don't need to remember to git-checkout devel in one > project, git-checkout trunk in another, git-checkout main in > a third, git-checkout release in a fourth, git-checkout default > in a fifth, etc.(*). In this case, I would prefer Fedora follow > the rough consensus presuming that one can be achieved > rather than pick yet another (different) name. There are several other branches than the branch for Rawhide that have a name that is unlikely to be found in many other projects like f32, el6, epel7, epel8-playground. Why is it more intuitive to use a name from other projects as the name for the branch for Rawhide? 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: Btrfs by default, the compression option
On Wed, Jul 8, 2020 at 8:26 AM Chris Murphy wrote: > D. Which directories? Some may be outside of the installer's scope. > > /usr > /var/lib/flatpak > ~/.local/share/flatpak > I have a concern regarding games. Currently, we have a few a bit more demanding titles on Flathub already, like 0AD, Xonotic or Albion Online. In the glorious future (tm) we might get more. Games are very sensitive to available CPU cycles and context switching and usually come with their data files already compressed. Including the btrfs compression by default on flatpak dirs could lead to lowered performance whenever the game tries to load some assets (older titles do that during the loading screen, newer titles stream new assets constantly during gameplay and any slowdown manifests as game stuttering). May it make sense to have different compression defaults per Edition/Spin? For example, Workstation is likely used on computers which have sufficient disk space, don't suffer from disk wear out that much (compared to SD cards), and users are likely to play games on them. On the other hand, ARM or IoT devices are the very opposite and compression can be very useful there. > /var/lib/containers/ > ~/.local/share/containers/ > ~/.var > If we enable it on ~/.var, it will affect all Steam games installed through the Steam flatpak. So any AAA games you play including those emulated through Proton will need to deal with extra compression. I find it unlikely that the user experience would be unchanged. It would be similar to Microsoft enabling disk compression on Program Files by default. I actually tried to figure out which locations are compressed by default on Windows 10, and I failed in searching, but I looked at my Win10 instance and I didn't find any folders that would have compression enabled. > ~/.cache > > (Plausible this list should be reversed. While compressing ~/.cache > may not save much space, it's likely hammered with more changes than > other locations, hence more benefit in terms of reducing write > amplification.) > I'm personally more concerned about reduced performance in e.g. my web browser than disk wear out. I don't see much harm in compressing /usr, because it's a read-only location that gets loaded once when the app starts (it might delay the app startup a bit, though, and decrease the perceived snappiness of the desktop). But I'm concerned about compressing locations which are hit often, like ~/.var or ~/.cache. I've had my 120GB SSD for 5 years and I'm just at 10% of expected TBW (total bytes written). If the SSD lasts 50 or 100 years is not really important for me, but the desktop and app responsiveness is (and game performance, of course:)). I think write amplification is a problem specific to devices with SD cards, and for anyone else, it might be better to leave it unset and let people enable it (it's simple) if they want it for their use case. ___ 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: Packagers with no corresponding valid bugzilla accounts
On Tue, Jul 07, 2020 at 10:38:01AM -0700, Michel Alexandre Salim wrote: > On Tue, 2020-07-07 at 10:30 +0200, Pierre-Yves Chibon wrote: > > On Tue, Jul 07, 2020 at 08:17:00AM +, Mattia Verga wrote: > > > Il 06/07/20 22:04, Pierre-Yves Chibon ha scritto: > > > > Good Morning Everyone, > > > > > > > > The list is slowly going down, we have now 38 accounts that are > > > > still > > > > problematic, they have all received several personal emails over > > > > the last few > > > > weeks and none but one reacted. > > > > I will likely start to ping FESCo about them starting next week. > > > > ... > > > > > > From a quick look to that list, there are some users that have no > > > package assigned... I wonder if the unresponsive maintainer > > > process > > > implies the user to be removed from the packager group when their > > > packages get orphaned and the user has no more any package > > > associated to > > > their account. > > > > The source of info is: > > https://src.fedoraproject.org/extras/pagure_bz.json > > which includes people that are packagers as well as people who are > > watching the > > packages (ie who asked to be included in the CC list on bugzilla). > > > > Should we make the script more robust and ignore invalid watcher > emails? Seems worrying if someone who's not even a packager can block > packager changes from being reflected in Bugzilla. As you can see in this JSON there is no difference between maintainers and watchers, so the script syncing to bugzilla does not have this information. I think that asking FESCo for a policy on how to deal with this + an automated way to detect this situation (which we didn't really have so far) may be sufficient. However, if this situation happens too frequently, and leads to too much manual work to clean things up, we may need to see about somehow adding this information to the JSON file and teaching the script the difference. It would increase the load on bugzilla though :( Pierre pgp2uDfJPHgDl.pgp 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
