Re: Conflicting build-ids in chromium and chromium-freeworld
On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: Hi. There is an ongoing problem with conflicting build-ids in chromium and chromium-freeworld [1][2]: Error: Transaction test error: file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 There is no clear idea why it happens, but my assumption is that due to the fact of building with the same source code (with similar patches), some generated shared libraries are the same which generates conflict(s). The quick look at the algorithm for build-id generation [3] doesn't answer my question what exactly is taken into account for their generation and more precisely is there is way to add some "fuzz" (having different buildroots doesn't help) to distinguish those libraries. To wrap up: 1. Is there a better way to deal with the aforementioned build-id conflicts than disable their generation on one side (with "%global _build_id_links none")? Instead of disabling entirely, you could tell rpm to put it all into -debuginfo packages (ie the original debuginfo layout). Which would still conflict, but fewer people are affected: %global _build_id_links alldebug 2. Maybe my assumption about the same generated shared libraries is wrong and there is something else what can be done to fix the root problem? That's exactly the cause, build-id's are engineered to reproducably identify identical built objects, regardless of their location. Which causes conflicts when the house rules of not shipping multiple idental copies is broken (one might call this a feature). Short of unbundling the shared libraries, I guess a reasonable workaround would be patching them to include some identifier string based on the containing package name, which would cause them to have different build_ids. - Panu - [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037 [2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743 [3] - https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803 [4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758 Marcin P.S. There are cases where it would be best to have those two packages installed simultaneously [4]. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0214580ca4 mbedtls-2.16.8-1.el8 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c5ced83bcc seamonkey-2.53.4-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-11f765300e singularity-3.6.3-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-17fdec3133 zeromq-4.3.3-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9720b9f379 matio-1.5.18-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b65eda12a7 chromium-85.0.4183.102-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing nohang-0.1-33.20200919gitfaf49b0.el8 Details about builds: nohang-0.1-33.20200919gitfaf49b0.el8 (FEDORA-EPEL-2020-eb68c876fc) Sophisticated low memory handler for Linux Update Information: Update to latest version ChangeLog: * Sun Sep 20 2020 Artem Polishchuk - 0.1-33.20200919gitfaf49b0 - Update to latest git snapshot ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 768 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 507 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 15 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83bdeb2965 ansible-2.9.13-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f9a03b mbedtls-2.7.17-1.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-25e525a9ca seamonkey-2.53.4-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-918ad695f6 proftpd-1.3.5e-10.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d968abb383 golang-1.15.2-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0f3f88c479 nginx-1.16.1-2.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-92064b5b2b singularity-3.6.3-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6b04ee5c07 libuv-1.39.0-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e621d9ff68 matio-1.5.18-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dec199d5a2 chromium-85.0.4183.102-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing nohang-0.1-33.20200919gitfaf49b0.el7 Details about builds: nohang-0.1-33.20200919gitfaf49b0.el7 (FEDORA-EPEL-2020-ccae81aa14) Sophisticated low memory handler for Linux Update Information: Update to latest version ChangeLog: * Sun Sep 20 2020 Artem Polishchuk - 0.1-33.20200919gitfaf49b0 - Update to latest git snapshot ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[389-devel] Review Reminder: entryuuid fixup correction
https://github.com/389ds/389-ds-base/pull/4328 Reminder to review this please :) — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Conflicting build-ids in chromium and chromium-freeworld
Hi. There is an ongoing problem with conflicting build-ids in chromium and chromium-freeworld [1][2]: > Error: Transaction test error: > file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 > file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea from > install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 conflicts with file > from package chromium-85.0.4183.102-1.fc32.x86_64 There is no clear idea why it happens, but my assumption is that due to the fact of building with the same source code (with similar patches), some generated shared libraries are the same which generates conflict(s). The quick look at the algorithm for build-id generation [3] doesn't answer my question what exactly is taken into account for their generation and more precisely is there is way to add some "fuzz" (having different buildroots doesn't help) to distinguish those libraries. To wrap up: 1. Is there a better way to deal with the aforementioned build-id conflicts than disable their generation on one side (with "%global _build_id_links none")? 2. Maybe my assumption about the same generated shared libraries is wrong and there is something else what can be done to fix the root problem? [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1869037 [2] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5743 [3] - https://github.com/rpm-software-management/rpm/blob/505fe16f863f83637c9577417a7ae959df674a61/build/files.c#L1803 [4] - https://bugzilla.rpmfusion.org/show_bug.cgi?id=5758 Marcin P.S. There are cases where it would be best to have those two packages installed simultaneously [4]. -- https://blog.solidsoft.pl/ - Working code is not enough ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-09-20 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/09/20/report-389-ds-base-1.4.4.4-20200916gitf9638bb.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: btrfs and ERC defaults
On 20/09/2020 21:16, Chris Murphy wrote: > On Sun, Sep 20, 2020 at 11:07 AM Daniel Pocock wrote: >> >> >> >> Does Btrfs have any mechanism to help manage ERC settings in the drives >> or is there any desire for Fedora to help users do this? > > File systems have nothing do with SCT ERC or the SCSI command timer. > There's no mechanism at all. > >> I've typically used rc.local to check the settings on drives used in md >> or btrfs arrays, e.g. > > Or udev rule. > > Part of the blame goes to drive vendors for producing drives that can > take upwards of *minutes* of thinking to decide whether or not your > data can be returned. But then particularly pernicious is the kernel's > default 30 second command timer where it just assumes a non-response > requires a link reset, thereby obliterating all state information for > the drive in question. > > Over on linux-raid@ list, these mismatch comes up all the time. It > prevents normal raid repair function from working, whether mdadm, LVM, > or Btrfs (and presumably ZFS on Linux but I'm not certain) and > eventually will result in loss of the array, for the typical mortal > user. > > For desktop users, the mismatch is perhaps a non-factor because which > is better? Early loss of a sector resulting in I/O error? Or an > increasingly slow system as the sole warning sign of bad sectors > accumulating until it results in the loss of multiple sectors? It's > just not great either way. > > Meanwhile some of these behaviors have changed as SSD's have become > more common. You're more likely to get transient bit flips as the > early warning sign, and then either all zeros or garbage instead of > your data. If you're lucky, the drive itself goes read-only (different > than the file system reporting the fs has gone read only) leaving your > data readable. My original mail was probably a bit ambiguous about the desktop users I suspect that the type of desktop user who really wants Btrfs and also wants to use it in RAID1 probably chooses to buy disks that support ERC, e.g. the disks promoted for NAS For other users, it is not clear if they will always use two disks and it is not clear if they will have disks that support ERC configuration. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 Weekly: 2020-09-20
Hi Everyone, Below is this week's CPE weekly for week ending 2020-09-20. I found that if you want to skip to the hackmd, you can use the view link https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view and then use the header bar on your left to skip to either the Fedora or CentOS updates, whichever interest you. I'll also be adjusting these updates in the coming weeks to make them a bit more direct to consume. Thanks for giving me this feedback in the CPE survey, I want to deliver value to you all, so it's great to KNOW what you find valuable first hand :) # CPE Weekly: 2020-08-14 ## General Project Updates As a reminder, below are the projects the CPE team are working on for the months of July, August & September: * Data Centre Move - Final Works * CentOS Stream Phase 3 * Noggin Phase 3 * Packager Workflow Healthcare * Fedora Messaging Schemas We have recently held our Q4 planning session and the CPE review team, Fedora, CentOS and RHEL BU have voted the following projects for action in Q4, which is the months of October November & December: *OSBS for aarch64 *Fedora-messaging schemas We are continuing to work on CentOS Stream and Noggin and took these projects as confirmed when looking at what other work our team could realistically complete in the Q4 period, given that there's both Thanksgiving and Christmas time off to consider, plus any time off our team wishes to take. The taiga cards of Noggin, CentOS Stream, OSBS for aarch64 and fedora-messaging schemas will be updated next week with what our team hopes to deliver in the next quarter on each of the projects. Our project board is here (it's just not updated properly - yet) https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null ### Misc GitLab Thank you so much to everyone for adding your questions to the doc for the GitLab AMA session on Thursday 10th September, and for your attendance on the day during the call. Here is the full AMA transcript https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html however it is a bit confusing to read so we got a few great suggestions to have dedicted topics like Message Bus and Branching, etc go out to the devel lists to discuss. I'm happy to start this next week, but I will collect the questions related to each topic and propose a cadence to send them out first to discuss, so people dont miss mails and know the week ending 2nd October will be (for example) the topic of Group Permissions - What do you think? GitLab have also agreed to answer the questions, we have asked them to do so within 2 weeks of the AMA so as soon as this is complete I will let you know so you can read through them on the hackmd link. The link is here where we asked you to contribute your questions and I will be posting answers once we have them underneath https://hackmd.io/RW8HahOeR7OJPON1dwuo3w I really appreciate your involvement with this as we begin to dig deeper into how this might play out next year and what way it should for everyone's benefit. ## Project Updates *The below updates are pulled directly from our CPE team call we have every week.* ## Fedora ### General * 6 of 8 Beta-blockers have fixes for F33 beta * New release of fedscm_admin * FMW mac and windows binaries are signed ### Staging Environment * About 70% done installing vm’s (27 left out of 88) * Still need to bring up aarch64/armv7/ppc64le builders * Databases need syncing ### AAA Replacement * The team are working on testing Ipsilon in Staging and adding OpenID Connect Capability * they are also testing fas2ipa migration script in tiny-stage and improve it * Add Noggin to tiny-stage environment and test * The teams kanban board where they track their work can be found here https://github.com/orgs/fedora-infra/projects/6 ### Fedora Messaging Schemas * This project is on hold until Noggin completes. * It will be resumed around December timeframe and is part of our Q4 workload to complete * There is a list of applications that require messaging schemas can be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit * There is a readme which contains documentation on messaging schemas, a cookie-cutter template to create the schema and a definition of Done for writing a schemas https://github.com/fedora-infra/fedora-messaging-schemas-issues * The board they are working from can be viewed here https://github.com/orgs/fedora-infra/projects/7 ### Packager Workflow Healthcare * The team have been working on more improvements and fixes to the monitor-gating * These improvements have led to * Finding a bug in our testing script * Improved log messages * We actually caught a problem! :) * The data the team have been reviewing have been from April - July and have already discovered that so far it looks like Pagure, koji and bodhi work well * We see some intermittent problems, but nothing too big, mostly only spikes in runtime * Fedora CI still
Re: Fedora 33 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa
On Sunday, September 20, 2020 8:52:21 PM CEST Kevin Fenzi wrote: > On Sun, Sep 20, 2020 at 07:11:29PM +0200, Pavel Raiskup wrote: > > After upgrade of one of my servers to F33, I noticed that I can not ssh to > > one of my other servers running Debian 9 system (relatively freshly EOLed, > > I need to do something about it). On F33 I always need to: > > > > $ ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa user@debian-9-host > > > > The changes in Fedora packages led me to: > > > > > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/b298a9e1 > > > > Which led me to: > > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > > > I'm curious about the effects of the change. It claims that RSA 2048 >= > > should > > stay accepted by DEFAULT, and from what I can tell the host server key > > seems to > > be RSA 2048 (at least that's what is generated by default on Debian 9): > > > > $ ssh-keygen -l -f ssh_host_rsa_key.pub > > 2048 SHA256:<...> root@debian-9-host (RSA) > > > > Can anyone translate to me if this is really expected or a bug? Effect is > > that > > Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not sure > > about > > the supported Debian 10, and the key quality there). > > I thought this was actually due to openssh dropping support for > 'ssh-rsa': > > https://www.openssh.com/txt/release-8.3 > > (ie, the sha-1 ssh-rsa) Well, I did: $ cd /etc/ssh $ rm ssh_host* $ ssh-keygen -N "" -t rsa-sha2-512 -b 4096 -f /etc/ssh/ssh_host_rsa_key $ dpkg-reconfigure openssh-server ... generates the remaining ECDSA and ED25519 ... New host signature detected, but I still get on F33 when trying to ssh: $ ssh -vv ... debug1: Offering public key: /home/praiskup/.ssh/id_rsa RSA SHA256:... debug1: send_pubkey_test: no mutual signature algorithm ... And still -oPubkeyAcceptedKeyTypes=+ssh-rsa helps... Does that meant that the ssh-keygen on Debian 9 is broken? How am I able to tell this is server or client problem? Pavel > kevin > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 and ERC defaults
On Sun, Sep 20, 2020 at 11:07 AM Daniel Pocock wrote: > > > > Does Btrfs have any mechanism to help manage ERC settings in the drives > or is there any desire for Fedora to help users do this? File systems have nothing do with SCT ERC or the SCSI command timer. There's no mechanism at all. > I've typically used rc.local to check the settings on drives used in md > or btrfs arrays, e.g. Or udev rule. Part of the blame goes to drive vendors for producing drives that can take upwards of *minutes* of thinking to decide whether or not your data can be returned. But then particularly pernicious is the kernel's default 30 second command timer where it just assumes a non-response requires a link reset, thereby obliterating all state information for the drive in question. Over on linux-raid@ list, these mismatch comes up all the time. It prevents normal raid repair function from working, whether mdadm, LVM, or Btrfs (and presumably ZFS on Linux but I'm not certain) and eventually will result in loss of the array, for the typical mortal user. For desktop users, the mismatch is perhaps a non-factor because which is better? Early loss of a sector resulting in I/O error? Or an increasingly slow system as the sole warning sign of bad sectors accumulating until it results in the loss of multiple sectors? It's just not great either way. Meanwhile some of these behaviors have changed as SSD's have become more common. You're more likely to get transient bit flips as the early warning sign, and then either all zeros or garbage instead of your data. If you're lucky, the drive itself goes read-only (different than the file system reporting the fs has gone read only) leaving your data readable. -- 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: Fedora EOL wrt new dist-git branches (and my confusion)
On 20. 09. 20 20:45, Kevin Fenzi wrote: But also because it doesn't really make sense to me. I can imagine a case when a bug in Fedora N can be fixed by adding a new package (for example when we accidentally introduce a new dependency) and I don't understand why Wouldn't that be caught in testing? I usually find out about broken dependencies only after such untested update gets autopushed to stable (w/out karma) and Koschei sends me a notification that one of my packages fails to resolve build dependencies becasue it ransitively depends on the broken one. -- 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: btrfs / booting alternative OS versions from subvolumes
On Sat, Sep 19, 2020 at 5:39 AM Neal Gompa wrote: > > On Sat, Sep 19, 2020 at 5:48 AM Daniel Pocock wrote: > > > > > > I noticed another thread about subvolumes already exists, I'm starting > > this one for the very specific topic of installing multiple root > > filesystems as subvolumes > > > > Examples: Fedora 33 in one subvolume, Fedora rawhide in another > > subvolume, Fedora 33 32-bit in another subvolume, maybe RHEL in a > > subvolume too > > > > Can this be supported by the installer? > > > > Can it be supported by grub? > > > > If somebody installs their OS to the top level of their btrfs today, can > > they pivot that into a subvolume later? > > > > All these OS installs would shared some things like /home > > If all the operating systems support working with the same grub and > support Btrfs with the features enabled in the filesystem, yes. > > The only known issue I'm aware of is that Fedora 33 GRUB cannot boot > Fedora 32 or RHEL 8 because the bootloader spec implementation changed > and it no longer supports variables inside of file snippets. Fedora 33 BLS snippets themselves don't use the kernelopts macro. But F33 GRUB does still load the variable if it's present in the grubenv. On a clean install of Fedora 33, the grubenv is replaced with one that doesn't have kernelopts. But you can restore it. I don't know if this can be done reliably with grubby, without somehow affecting the Fedora 33 installation. But if you merely: grub2-editenv - set kernelopts="root=UUID=32291cea-4dee-4e0d-bdf3-813314e2ab10 ro rootflags=subvol=root32 rhgb quiet" Then this variable will be used by Fedora 32 BLS snippets, and not Fedora 33 snippets. What I'm only 90% certain of (or 100% wrong just by accident) is the behavior of kernel updates. In my sample size of one, Fedora 32 kernel updates continue to create the F32 style BLS snippet with macro. Fedora 33 kernel updates create the F33 style BLS without macro. And thus coexist so long as you don't ever do 'grub2-mkconfig' within Fedora 33,thereby obliterating the shared grubenv, wiping out the kernelopts line. -- 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: Fedora 33 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa
On Sun, Sep 20, 2020 at 07:11:29PM +0200, Pavel Raiskup wrote: > After upgrade of one of my servers to F33, I noticed that I can not ssh to > one of my other servers running Debian 9 system (relatively freshly EOLed, > I need to do something about it). On F33 I always need to: > > $ ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa user@debian-9-host > > The changes in Fedora packages led me to: > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/b298a9e1 > > Which led me to: > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > I'm curious about the effects of the change. It claims that RSA 2048 >= > should > stay accepted by DEFAULT, and from what I can tell the host server key seems > to > be RSA 2048 (at least that's what is generated by default on Debian 9): > > $ ssh-keygen -l -f ssh_host_rsa_key.pub > 2048 SHA256:<...> root@debian-9-host (RSA) > > Can anyone translate to me if this is really expected or a bug? Effect is > that > Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not sure about > the supported Debian 10, and the key quality there). I thought this was actually due to openssh dropping support for 'ssh-rsa': https://www.openssh.com/txt/release-8.3 (ie, the sha-1 ssh-rsa) 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: Fedora EOL wrt new dist-git branches (and my confusion)
On Sat, Sep 19, 2020 at 03:11:39PM -0500, Richard Shaw wrote: > On Fri, Sep 18, 2020 at 5:03 PM Ben Cotton wrote: > > > On Fri, Sep 18, 2020, 17:03 Miro Hrončok wrote: > > > >> > >> So, my question is: Should we fix the document to describe the long > >> standing > >> practice more understandably, or should we change the practice to allow > >> new > >> dist-git branches until the actual EOL? > >> > > > > I'm in favor of allowing new branches until the actual EOL, with the > > expectation that it will be a pretty rare occurrence. We shouldn't preclude > > ourselves from providing support to a supported release. > > > > Tangent nit-pick... Once an update has been created for a branch, why not > at least allow it to go to stable? Seeing my packages stuck in testing for > eternity bothers my OCD until I push enough updates I don't see it anymore. We could push all the testing updates stable at the end... but... that means there would be a flood of changes of things that didn't meed testing requirements, and additionally we could never fix any problems that happen because of that. Perhaps it would be better to unpush all the pending ones at eol? 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: Fedora EOL wrt new dist-git branches (and my confusion)
On Fri, Sep 18, 2020 at 11:02:26PM +0200, Miro Hrončok wrote:
> Hello,
>
> As many of you know, Fedora has an EOL policy that roughly tl;drs to:
>
> "Fedora N goes to End of Life 4 weeks after Fedora N+2 Final Release (GA)."
>
> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
>
> The document also says:
>
> > Branches for new packages in the SCM are not allowed for distribution X
> > after
> > the Fedora X+2 release and new builds are no longer allowed.
>
> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#End_of_Life_.28EOL.29
>
> I've recently discovered that for 10+ years, this was interpreted as:
>
> 1. at release of Fedora N+2, new dist-git branches for N are no longer
> allowed
> 2. 4 weeks later, Fedora N is EOL
>
> https://pagure.io/releng/issue/9759#comment-687136
>
> When I was told this, I found it very surprising. Mostly because we usually
> only ever announce the actual EOL deadline and I've never seen an
> announcement that says: "From now on, no new packages for Fedora N are
> possible."
We used to say this in every single announcement about upcoming EOL
releases. I guess it dropped from the template somehow?
For example:
https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/thread/QCFQCN7JCRCNPD46UK5IAAJJHPRLYVK4/
"Fedora 21 will reach end of life on 2015-12-01, and no further updates
will be pushed out after that time. Additionally, with the recent
release of Fedora 23, no new packages will be added to the Fedora 21
collection."
I think we always did this until perhaps the last few?
Mohan: can you check the template you use for these? Or was Ben sending
them now?
> But also because it doesn't really make sense to me. I can imagine a case
> when a bug in Fedora N can be fixed by adding a new package (for example
> when we accidentally introduce a new dependency) and I don't understand why
Wouldn't that be caught in testing? but anyhow...
> this should not be possible between Fedora N+2 release and Fedora N EOL.
> Understandably many packagers might decide to WONTFIX at that point ("It's
> going EOL in couple weeks anyway"), but if they choose to fix, we should
> allow them to do so.
>
> Similarly, before Fedora N is EOL, it is considered supported, and a need
> to introduce a new package to a supported Fedora version IMHO is valid,
> regardless of the approaching EOL.
The idea is that when a release has only 1 month left, we should really
avoid making changes to it. After it's EOL we can't fix anything we
break right before that, so we should be very conservative in changes.
The "one month" after the current release is a buffer time to allow
people who want to only upgrade every other release time to upgrade.
It shouldn't be used to push changes other than security or major
bugfixes. All IMHO of course.
>
> So, my question is: Should we fix the document to describe the long standing
> practice more understandably, or should we change the practice to allow new
> dist-git branches until the actual EOL?
I think we should fix the document. :)
Additionally, we should fix/add it to the updates policy document... I
don't think it's there and it's really hard to find.
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: Need assistance for luxcorerender to use c++14
The build was successfully as tested: https://koji.fedoraproject.org/koji/taskinfo?taskID=51905588 Patch submitted to upstream: https://github.com/LuxCoreRender/LuxCore/issues/449 -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Wed, Sep 16, 2020 at 11:28:10AM -0700, Troy Dawson wrote: > On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote: > > > > On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: > > ...snip... > > > > > > When a maintainer is done with their package in playground, they must > > > untag all builds of it out of epel-playground. We do not want > > > epel-playground cluttered with old test packages. Done means either > > > the package has been moved to regular EPEL, and / or the maintainer no > > > longer wants to play and test in epel-playground. Untagging all > > > builds of a package is currently done via a release engineering > > > ticket. > > > > This puts more work on releng, but I am not sure how often it will come > > up. We could also create a 'epel-sig' permission and grant everyone in > > that group permissions to untag from playground? > > > > Otherwise, looks good to me. > > > > kevin > > If the maintainer could do it themselves, I'm ok with that. But > currently, I don't think they can. They cannot. We would need to create a new koji permission and add people to it, or just have releng do it. > If we can get something better than rel-eng, I'm all for it. But as > far as I know, that's what we currently have to do. > We can update it when we get something better in place. Well, I think it might be worthwhile to add a permission and a small group of people who can do it, then they could process the releng tickets too. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: proposal: EPEL 8 Next
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote: > At the EPEL Steering Committee last week, we had an extensive discussion of > this proposal, specifically focused on how to handle the dist macro. I > believe these are the possible choices. > > * keep dist the same as epel8 (.el8) > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for > dist. It would make sense to continue using the same dist for EPEL Next. > However, this would put a little more work on packagers. They would not be > able to build the same commit for both EPEL and EPEL Next because the NVR > will conflict in Koji. In simple rebuild situations, this is not a problem > because at a minimum the release will be higher. But if a packager wanted > to update the package in both EPEL and EPEL Next, they will need to first > update and build it in EPEL, then bump the release and build it in EPEL > Next. This isn't ideal, but isn't terrible either, and can be partially > mitigated by good documentation around EPEL Next workflows. > > * modify dist to always be higher than epel8 (.el8.next or similar) > > In EPEL Next we could define dist to a string that RPM evaluates higher than > .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be > in sync and the same commit could be built for both targets. The higher > dist would ensure the upgrade path works. I think this makes the most sense and will help packages workflows the best. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: btrfs / booting alternative OS versions from subvolumes
On Sat, Sep 19, 2020 at 3:48 AM Daniel Pocock wrote: > > > I noticed another thread about subvolumes already exists, I'm starting > this one for the very specific topic of installing multiple root > filesystems as subvolumes > > Examples: Fedora 33 in one subvolume, Fedora rawhide in another > subvolume, Fedora 33 32-bit in another subvolume, maybe RHEL in a > subvolume too > > Can this be supported by the installer? > > Can it be supported by grub? > > If somebody installs their OS to the top level of their btrfs today, can > they pivot that into a subvolume later? > > All these OS installs would shared some things like /home It's generally possible when narrowing the parameters. There's a new QA test case for preserving /home use case. The intent of the use case is not dual boot but rather merely to ensure the user's home subvolume is reused when clean installing. This is possible with LVM+ext4 layout because /home is a separate file system; merely reformatting the root and reusing its space for a new /. Whereas with Btrfs, in fact the old root is also preserved (not destroyed), it's effectively left alone and abandoned (its fate is not addressed in the test case). https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserve_home There is a variation on this test case that's still in draft form. It could be a starting point for further describing exactly what conditions we could support Fedora multiboot. Right now Fedora release criteria only specify dual boot in relation to Windows and macOS, not any other Linux distribution including Fedora. While much of the possibility for supporting dual boot Fedora goes to the BootLoaderSpec effort, the Btrfs by default effort makes it's more space efficient to support. https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs Neither of these take into account any sort of snapshot/rollback regime. That's a bit more complicated. But on the plus side, there is a rather straightforward way to have combinations: Server + Workstation, Workstation + KDE, Workstation + Silverblue. For the adventurous and ultra efficiency seekers, such installations would be highly prone to being deduped. Of course from the DE's perspective, these are still completely separate installations, with separate system updates, separate RPM databases, and so on. -- 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: Need assistance for luxcorerender to use c++14
On 2020-09-20 4:49 a.m., Richard Shaw wrote: On Sat, Sep 19, 2020 at 8:27 PM Luya Tshimbalanga mailto:l...@fedoraproject.org>> wrote: Thanks for quick response. The suggestion seems to work. Unfortunately, the build failed on openvdb (either using the bundled and 7.1.0 version) while working fine on Fedora 32. https://koji.fedoraproject.org/koji/taskinfo?taskID=51860207 The error is more informative than you think, but only because I've run into this with another package. In boost 1.73 they made a change to the scope of the placeholders[1] to not conflict with std namespace. "Changed all uses of the boost.bind placeholders to use the |boost::placeholders|namespace." Something like this may work, but it's untested. I don't see where any boost headers are being included, but they must be somewhere to use boost::bind. If it doesn't I would try adding "#include " in bakesputhread.cpp. Index: LuxCore-luxcorerender_v2.4/src/slg/engines/bakecpu/bakecputhread.cpp === --- LuxCore-luxcorerender_v2.4.orig/src/slg/engines/bakecpu/bakecputhread.cpp +++ LuxCore-luxcorerender_v2.4/src/slg/engines/bakecpu/bakecputhread.cpp @@ -340,7 +340,7 @@ void BakeCPURenderThread::RenderLightSam const PathTracer = engine->pathTracer; const PathTracer::ConnectToEyeCallBackType connectToEyeCallBack = boost::bind( - ::RenderConnectToEyeCallBack, this, mapInfo, _1, _2, _3, _4); + ::RenderConnectToEyeCallBack, this, mapInfo, boost::placeholders::_1, boost::placeholders::_2, boost::placeholders::_3, boost::placeholders::_4); pathTracer.RenderLightSample(state.device, state.scene, state.film, state.lightSampler, state.lightSampleResults, connectToEyeCallBack); Thanks, Richard [1] https://www.boost.org/users/history/version_1_73_0.html This patch is the right solution as luxcorerender finally successfully mock built. Thank you for the help. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa
On 9/20/20 10:11 AM, Pavel Raiskup wrote: I'm curious about the effects of the change. It claims that RSA 2048 >= should stay accepted by DEFAULT, and from what I can tell the host server key seems to be RSA 2048 (at least that's what is generated by default on Debian 9): $ ssh-keygen -l -f ssh_host_rsa_key.pub 2048 SHA256:<...> root@debian-9-host (RSA) Sure, but the PubkeyAcceptedKeyTypes doesn't influence acceptable server host keys (and if it did, the client should simply use another one of the server's keys). PubkeyAcceptedKeyTypes influences what key types the client will try to use for authentication. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1880859] New: perl-CPAN-Perl-Releases-5.20200920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1880859 Bug ID: 1880859 Summary: perl-CPAN-Perl-Releases-5.20200920 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPAN-Perl-Releases Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20200920 Current version/release in rawhide: 5.20200820-1.fc34 URL: http://search.cpan.org/dist/CPAN-Perl-Releases/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5881/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa
On Sun, 20 Sep 2020 at 13:12, Pavel Raiskup wrote: > After upgrade of one of my servers to F33, I noticed that I can not ssh to > one of my other servers running Debian 9 system (relatively freshly EOLed, > I need to do something about it). On F33 I always need to: > > $ ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa user@debian-9-host > > The changes in Fedora packages led me to: > > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/b298a9e1 > > Which led me to: > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > I'm curious about the effects of the change. It claims that RSA 2048 >= > should > stay accepted by DEFAULT, and from what I can tell the host server key > seems to > be RSA 2048 (at least that's what is generated by default on Debian 9): > > $ ssh-keygen -l -f ssh_host_rsa_key.pub > 2048 SHA256:<...> root@debian-9-host (RSA) > > Can anyone translate to me if this is really expected or a bug? Effect is > that > Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not sure > about > the supported Debian 10, and the key quality there). > > My guess looking at the changes is that it is not key length which is caulsing problems but with the SHA used in the key to verify it. from the Cygwin manpage I am looking at: The available RSA signature variants are “ssh-rsa” (SHA1 signatures, not recommended), “rsa-sha2-256”, and “rsa-sha2-512” (the default). I am guessing this key was generated with the older ssh-rsa and so the new boxes won't work unless you force it. I would regenerate the key with a newer sig :). > Pavel > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1880857] New: perl-Module-CoreList-5.20200920 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1880857 Bug ID: 1880857 Summary: perl-Module-CoreList-5.20200920 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Module-CoreList Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jose.p.oliveira@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 5.20200920 Current version/release in rawhide: 5.20200820-1.fc34 URL: http://search.cpan.org/dist/Module-CoreList/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3080/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 33 - ssh clients - drop of PubkeyAcceptedKeyTypes=ssh-rsa
After upgrade of one of my servers to F33, I noticed that I can not ssh to one of my other servers running Debian 9 system (relatively freshly EOLed, I need to do something about it). On F33 I always need to: $ ssh -oPubkeyAcceptedKeyTypes=+ssh-rsa user@debian-9-host The changes in Fedora packages led me to: https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/b298a9e1 Which led me to: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 I'm curious about the effects of the change. It claims that RSA 2048 >= should stay accepted by DEFAULT, and from what I can tell the host server key seems to be RSA 2048 (at least that's what is generated by default on Debian 9): $ ssh-keygen -l -f ssh_host_rsa_key.pub 2048 SHA256:<...> root@debian-9-host (RSA) Can anyone translate to me if this is really expected or a bug? Effect is that Fedora 33 clients can not ssh to Debian 9 hosts by default (I'm not sure about the supported Debian 10, and the key quality there). Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
btrfs and ERC defaults
Does Btrfs have any mechanism to help manage ERC settings in the drives or is there any desire for Fedora to help users do this? I've typically used rc.local to check the settings on drives used in md or btrfs arrays, e.g. DISKS="/dev/sda /dev/sdb" echo -n "smartctl: Trying to enable SCTERC / TLER and disable write cache on main disks..." for d in $DISKS; do smartctl -l scterc,70,70 $disk >/dev/null hdparm -W 0 $disk done echo "." ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1880852] perl-HTTP-CookieJar-0.010 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1880852 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-HTTP-CookieJar-0.010-1.fc32.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=51900377 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1880852] New: perl-HTTP-CookieJar-0.010 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1880852 Bug ID: 1880852 Summary: perl-HTTP-CookieJar-0.010 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-CookieJar Keywords: FutureFeature, Triaged Assignee: yan...@declera.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, yan...@declera.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.010 Current version/release in rawhide: 0.008-16.fc33 URL: http://search.cpan.org/dist/HTTP-CookieJar/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7525/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1880852] perl-HTTP-CookieJar-0.010 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1880852 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1715469 --> https://bugzilla.redhat.com/attachment.cgi?id=1715469=edit [patch] Update to 0.010 (#1880852) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1880850] New: perl-libwww-perl-6.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1880850 Bug ID: 1880850 Summary: perl-libwww-perl-6.48 is available Product: Fedora Version: rawhide Status: NEW Component: perl-libwww-perl Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, john.j5l...@gmail.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 6.48 Current version/release in rawhide: 6.47-1.fc34 URL: http://search.cpan.org/dist/libwww-perl/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3024/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora-IoT-33-20200920.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64) New failures (same test not failed in Fedora-IoT-33-20200919.0): ID: 672309 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/672309 ID: 672312 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/672312 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20200919.0): ID: 672298 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/672298 Passed openQA tests: 13/16 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.51 to 0.07 Previous test data: https://openqa.fedoraproject.org/tests/671639#downloads Current test data: https://openqa.fedoraproject.org/tests/672301#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-33-20200920.n.0 compose check report
No missing expected images. Failed openQA tests: 1/181 (x86_64) Old failures (same test failed in Fedora-33-20200919.n.0): ID: 672194 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/672194 Soft failed openQA tests: 9/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-33-20200919.n.0): ID: 672119 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/672119 ID: 672138 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/672138 ID: 672165 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/672165 ID: 672178 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/672178 ID: 672198 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/672198 ID: 672201 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/672201 ID: 672215 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/672215 ID: 672228 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/672228 ID: 672249 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/672249 Passed openQA tests: 171/181 (x86_64) Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 16 MiB to 27 MiB System load changed from 0.92 to 0.73 Previous test data: https://openqa.fedoraproject.org/tests/671500#downloads Current test data: https://openqa.fedoraproject.org/tests/672162#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 30 MiB to 25 MiB System load changed from 0.72 to 0.88 Previous test data: https://openqa.fedoraproject.org/tests/671502#downloads Current test data: https://openqa.fedoraproject.org/tests/672164#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used swap changed from 10 MiB to 13 MiB System load changed from 1.27 to 1.46 Previous test data: https://openqa.fedoraproject.org/tests/671519#downloads Current test data: https://openqa.fedoraproject.org/tests/672181#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 1.15 to 0.88 Previous test data: https://openqa.fedoraproject.org/tests/671520#downloads Current test data: https://openqa.fedoraproject.org/tests/672182#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 16 MiB to 21 MiB Previous test data: https://openqa.fedoraproject.org/tests/671536#downloads Current test data: https://openqa.fedoraproject.org/tests/672198#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: System load changed from 0.34 to 0.53 Previous test data: https://openqa.fedoraproject.org/tests/671539#downloads Current test data: https://openqa.fedoraproject.org/tests/672201#downloads Installed system changes in test x86_64 universal install_package_set_kde: Used swap changed from 3 MiB to 6 MiB System load changed from 1.36 to 1.75 Previous test data: https://openqa.fedoraproject.org/tests/671580#downloads Current test data: https://openqa.fedoraproject.org/tests/672242#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Orphaning vdr-skinsoppalusikka and the status of my packages (looking for co-maintainers for Finnish spell checking)
On 20. 09. 20 15:07, Ville-Pekka Vainio wrote: I have now orphaned vdr-skinsoppalusikka, because I don't have a working VDR installation anymore. If someone has the ability, my user (vpv) can be dropped from the packages vdr, vdr-epgsearch, vdr-femon and vdr-osdteletext. Done. -- 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
Orphaning vdr-skinsoppalusikka and the status of my packages (looking for co-maintainers for Finnish spell checking)
Hi all, As some of you may have noticed, I have been away from Fedora packaging for quite a while. I've been hoping to find the time for packaging work, but it hasn't happened. In hindsight, I should have let the project know earlier. I have now orphaned vdr-skinsoppalusikka, because I don't have a working VDR installation anymore. If someone has the ability, my user (vpv) can be dropped from the packages vdr, vdr-epgsearch, vdr-femon and vdr-osdteletext. My main interest in Fedora packaging used to be Finnish spell checking. The spell checking stack, consisting of libreoffice-voikko, libvoikko, voikko-fi and foma (as a dependency) went through quite major changes in 2017-2019. The vocabulary package voikko-fi requires foma to build. I managed to get the foma package reviewed and into Fedora in 2018. It was automatically orphaned and then retired due to FTBFS (https://src.fedoraproject.org/rpms/foma). The code has now been fixed in Github (https://github.com/mhulden/foma) and it should build, but I haven't tried it yet. If I get it to build, I might ask for it to be added back. It seems like I'll be able to work on packaging for a few days a year, so don't expect any miracles. Once foma is built, voikko-fi can be built. Even though it shares some history with the previous vocabulary package malaga-suomi-voikko, it probably needs a new review. Then libvoikko could be updated to use the new vocabulary. If anyone is interested in working on these, I would be happy to get co-maintainers. I'm willing to stay as a co-maintainer of gpodder and python-mygpoclient. I code Python at $DAYJOB so I might be able to help. Best regards, Ville-Pekka Vainio (vpv) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 33 compose report: 20200920.n.0 changes
OLD: Fedora-33-20200919.n.0 NEW: Fedora-33-20200920.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: SoaS raw-xz armhfp Path: Spins/armhfp/images/Fedora-SoaS-armhfp-33-20200920.n.0-sda.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-IoT-34-20200920.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64) Old failures (same test failed in Fedora-IoT-34-20200919.0): ID: 672059 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/672059 ID: 672062 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/672062 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20200919.0): ID: 672048 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/672048 Passed openQA tests: 13/16 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.10 to 0.27 Previous test data: https://openqa.fedoraproject.org/tests/671440#downloads Current test data: https://openqa.fedoraproject.org/tests/672049#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Need assistance for luxcorerender to use c++14
On Sat, Sep 19, 2020 at 8:27 PM Luya Tshimbalanga wrote: > Thanks for quick response. The suggestion seems to work. Unfortunately, > the build failed on openvdb (either using the bundled and 7.1.0 version) > while working fine on Fedora 32. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=51860207 > The error is more informative than you think, but only because I've run into this with another package. In boost 1.73 they made a change to the scope of the placeholders[1] to not conflict with std namespace. "Changed all uses of the boost.bind placeholders to use the boost:: placeholders namespace." Something like this may work, but it's untested. I don't see where any boost headers are being included, but they must be somewhere to use boost::bind. If it doesn't I would try adding "#include " in bakesputhread.cpp. Index: LuxCore-luxcorerender_v2.4/src/slg/engines/bakecpu/bakecputhread.cpp === --- LuxCore-luxcorerender_v2.4.orig/src/slg/engines/bakecpu/bakecputhread.cpp +++ LuxCore-luxcorerender_v2.4/src/slg/engines/bakecpu/bakecputhread.cpp @@ -340,7 +340,7 @@ void BakeCPURenderThread::RenderLightSam const PathTracer = engine->pathTracer; const PathTracer::ConnectToEyeCallBackType connectToEyeCallBack = boost::bind( - ::RenderConnectToEyeCallBack, this, mapInfo, _1, _2, _3, _4); + ::RenderConnectToEyeCallBack, this, mapInfo, boost::placeholders::_1, boost::placeholders::_2, boost::placeholders::_3, boost::placeholders::_4); pathTracer.RenderLightSample(state.device, state.scene, state.film, state.lightSampler, state.lightSampleResults, connectToEyeCallBack); Thanks, Richard [1] https://www.boost.org/users/history/version_1_73_0.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-20200920.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 10/181 (x86_64) New failures (same test not failed in Fedora-Rawhide-20200919.n.0): ID: 671797 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/671797 ID: 671809 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/671809 ID: 671850 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/671850 Old failures (same test failed in Fedora-Rawhide-20200919.n.0): ID: 671873 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/671873 ID: 671909 Test: x86_64 universal install_blivet_resize_lvm URL: https://openqa.fedoraproject.org/tests/671909 ID: 671934 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/671934 ID: 671968 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/671968 ID: 671970 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/671970 ID: 671971 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/671971 ID: 671972 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/671972 Soft failed openQA tests: 7/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20200919.n.0): ID: 671790 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/671790 ID: 671836 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/671836 ID: 671869 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/671869 ID: 671872 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/671872 ID: 671886 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/671886 ID: 671899 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/671899 ID: 671920 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/671920 Passed openQA tests: 149/181 (x86_64) New passes (same test not passed in Fedora-Rawhide-20200919.n.0): ID: 671849 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/671849 Skipped gating openQA tests: 4/181 (x86_64) Old skipped gating tests (same test skipped in Fedora-Rawhide-20200919.n.0): ID: 671975 Test: x86_64 KDE-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/671975 ID: 671976 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/671976 ID: 671985 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/671985 ID: 671987 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/671987 Skipped non-gating openQA tests: 11 of 181 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.40 to 0.16 Previous test data: https://openqa.fedoraproject.org/tests/671233#downloads Current test data: https://openqa.fedoraproject.org/tests/671788#downloads Installed system changes in test x86_64 Server-boot-iso install_default@uefi: System load changed from 0.37 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/671234#downloads Current test data: https://openqa.fedoraproject.org/tests/671789#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 0.22 to 0.09 Previous test data: https://openqa.fedoraproject.org/tests/671243#downloads Current test data: https://openqa.fedoraproject.org/tests/671798#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 0.28 to 0.17 Previous test data: https://openqa.fedoraproject.org/tests/671245#downloads Current test data: https://openqa.fedoraproject.org/tests/671800#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 1.08 to 1.30 Previous test data: https://openqa.fedoraproject.org/tests/671278#downloads Current test data: https://openqa.fedoraproject.org/tests/671833#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: Used swap changed from 18 MiB to 23 MiB
Fedora-Cloud-31-20200920.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: 20200920.n.0 changes
OLD: Fedora-Rawhide-20200919.n.0 NEW: Fedora-Rawhide-20200920.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 1 Dropped packages:2 Upgraded packages: 124 Downgraded packages: 0 Size of added packages: 130.53 KiB Size of dropped packages:74.10 MiB Size of upgraded packages: 2.81 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 124.72 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20200919.n.0.iso = ADDED PACKAGES = Package: hexchat-autoaway-2.0-3.fc34 Summary: HexChat plugin that automatically mark you away RPMs:hexchat-autoaway Size:130.53 KiB = DROPPED PACKAGES = Package: mozjs52-52.9.0-8.fc33 Summary: SpiderMonkey JavaScript library RPMs:mozjs52 mozjs52-devel Size:73.70 MiB Package: rubygem-wikicloth-0.8.0-14.fc33 Summary: Mediawiki parser RPMs:rubygem-wikicloth rubygem-wikicloth-doc Size:403.84 KiB = UPGRADED PACKAGES = Package: ansible-lint-1:4.3.5-1.fc34 Old package: ansible-lint-1:4.3.4-1.fc34 Summary: Best practices checker for Ansible RPMs: python3-ansible-lint Size: 118.19 KiB Size change: 2.04 KiB Changelog: * Sat Sep 19 2020 Parag Nemade - 1:4.3.5-1 - Update to 4.3.5 version (#1880470) Package: bcm283x-firmware-20200917-1.7b99da7.fc34 Old package: bcm283x-firmware-20200903-1.baec4d2.fc34 Summary: Firmware for the Broadcom bcm283x/bcm2711 used in the Raspberry Pi RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware bcm283x-overlays Size: 13.66 MiB Size change: 14.47 KiB Changelog: * Thu Sep 17 2020 Peter Robinson 20200917-1.7b99da7 - Latest firmware update Package: bluedevil-5.19.90-1.fc34 Old package: bluedevil-5.19.5-1.fc34 Summary: Bluetooth stack for KDE RPMs: bluedevil Size: 2.00 MiB Size change: -400.10 KiB Changelog: * Fri Sep 18 2020 Jan Grulich - 5.19.90-1 - 5.19.90 Package: breeze-gtk-5.19.90-1.fc34 Old package: breeze-gtk-5.19.5-1.fc34 Summary: Breeze widget theme for Gtk2 and Gtk3 RPMs: breeze-gtk Size: 1.48 MiB Size change: 5.43 KiB Changelog: * Fri Sep 18 2020 Jan Grulich - 5.19.90-1 - 5.19.90 Package: cinnamon-4.6.7-2.fc34 Old package: cinnamon-4.6.7-1.fc33 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-devel-doc Size: 8.56 MiB Size change: -36.63 KiB Changelog: * Sat Sep 19 2020 Leigh Scott - 4.6.7-2 - Switch to gjs f34+ Package: clamav-0.103.0-1.fc34 Old package: clamav-0.102.4-2.fc33 Summary: End-user tools for the Clam Antivirus scanner RPMs: clamav clamav-data clamav-devel clamav-filesystem clamav-lib clamav-milter clamav-update clamd Size: 227.99 MiB Size change: 20.42 MiB Changelog: * Thu Sep 17 2020 Orion Poplawski - 0.103.0-1 - Update to 0.103.0 Package: deepin-wallpapers-1.7.6-11.fc34 Old package: deepin-wallpapers-1.7.6-10.fc33 Summary: Deepin Wallpapers provides wallpapers of DDE RPMs: deepin-wallpapers Size: 59.56 MiB Size change: -4.75 MiB Changelog: * Sat Sep 19 2020 Robin Lee - 1.7.6-11 - Rebuild for f33-backgrounds Package: dummy-test-package-crested-0-1599 Old package: dummy-test-package-crested-0-1586 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 105.52 KiB Size change: 744 B Changelog: * Sat Sep 19 2020 packagerbot - 0-1587 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1588 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1589 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1590 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1591 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1592 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1593 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1594 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1595 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1596 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1597 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1598 - rebuilt * Sun Sep 20 2020 packagerbot - 0-1599 - rebuilt Package: dummy-test-package-gloster-0-1465.fc34 Old package: dummy-test-package-gloster-0-1453.fc34 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 96.18 KiB Size change: 773 B Changelog: * Sat Sep 19 2020 packagerbot - 0-1454 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1455 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1456 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1457 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1458 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1459 - rebuilt * Sat Sep 19 2020 packagerbot - 0-1460 - rebuilt * Sat Sep 19 2020
Re: changing page size: what must be recompiled?
> If anybody wants to try their kernel with a different page size, for > example, using ppc64el with the 4k page size instead of 64k > > - are there any packages in a standard installation that should be > recompiled? No, there's no recompile needed, in the early aarch64 days there was but we fixed that issue in binutils long ago and there's been a recompile (probably dozens) since then and we've tested both 4K and 64K kernels in Fedora without issue. > - before recompiling anything, should we recompile any build tools, such > as gcc, on the machine with 4k page size? None required, although I think ADA or Fortran (don't remember which) may have minor issues without a recompile. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-Cloud-32-20200920.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20200918.0): ID: 671734 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/671734 Passed openQA tests: 6/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
changing page size: what must be recompiled?
If anybody wants to try their kernel with a different page size, for example, using ppc64el with the 4k page size instead of 64k - are there any packages in a standard installation that should be recompiled? - before recompiling anything, should we recompile any build tools, such as gcc, on the machine with 4k page size? Personally, I haven't seen any adverse impact of changing page size so far ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Need assistance for luxcorerender to use c++14
On Sun, 20 Sep 2020 at 03:27, Luya Tshimbalanga
wrote:
> On 2020-09-19 1:32 p.m., Andy Mender wrote:
>
> On Sat, 19 Sep 2020 at 22:27, Richard Shaw wrote:
>
>> On Sat, Sep 19, 2020 at 3:16 PM Luya Tshimbalanga
>> wrote:
>>
>>> Hello team,
>>>
>>> openvdb is updated to 7.1.0 in Rawhide and luxcorerender needs to switch
>>> to -std=c++14 similar to that upstream ticket:
>>> https://github.com/AcademySoftwareFoundation/openvdb/issues/795.
>>>
>>> Is there anyone knowing how to do it on the spec file?
>>>
>>> https://src.fedoraproject.org/rpms/luxcorerender/
>>>
>>> It seems "sed -i 's|${CMAKE_CXX_FLAGS} -std=c++11|${CMAKE_CXX_FLAGS}
>>> -std=c++14|' CMakeLists.txt" is not enough because "-std=c++11" still
>>> comes back.
>>>
>>
>> Looks like it's specified here:
>>
>> cmake/PlatformSpecific.cmake
>>
>> I would just patch it instead.
>>
>>
> I would also suggest patching the main CMakeLists file, for instance the
> following way:
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
> If that's not too invasive, of course.
>
> Thanks for quick response. The suggestion seems to work. Unfortunately,
> the build failed on openvdb (either using the bundled and 7.1.0 version)
> while working fine on Fedora 32.
>
The build.log logfile isn't informative at all :(. I would try checking all
of the flags the %cmake macro adds to the regular cmake call and try to
build the thing outside of mock, locally.
Also, maybe set the compiler to clang to get better output:
CXX=clang++
CC=clang
Clang, at least in my experience, tends to be a lot more pedantic and
verbose. However, it may behave differently and fail the build in other
ways.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
