Fedora-Rawhide-20210526.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed, 8 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 13/194 (x86_64), 12/133 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210525.n.0): ID: 896080 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/896080 ID: 896092 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/896092 ID: 896194 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/896194 ID: 896216 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/896216 ID: 896301 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/896301 ID: 896302 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/896302 ID: 896306 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/896306 ID: 896308 Test: aarch64 universal install_repository_http_graphical@uefi URL: https://openqa.fedoraproject.org/tests/896308 ID: 896333 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/896333 ID: 896338 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/896338 ID: 896356 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/896356 ID: 896357 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/896357 ID: 896358 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/896358 ID: 896375 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/896375 Old failures (same test failed in Fedora-Rawhide-20210525.n.0): ID: 896028 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/896028 ID: 896031 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/896031 ID: 896037 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/896037 ID: 896062 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/896062 ID: 896170 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/896170 ID: 896172 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/896172 ID: 896178 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/896178 ID: 896183 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi URL: https://openqa.fedoraproject.org/tests/896183 ID: 896244 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/896244 ID: 896263 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/896263 ID: 896317 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/896317 Soft failed openQA tests: 4/194 (x86_64), 5/133 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210525.n.0): ID: 896127 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/896127 ID: 896129 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/896129 ID: 896185 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/896185 ID: 896214 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/896214 ID: 896230 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/896230 ID: 896260 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/896260 ID: 896291 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/896291 ID: 896326 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/896326 ID: 896336 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/896336 Passed openQA tests: 144/194 (x86_64), 102/133 (aarch64) New passes (same test not passed in Fedora-Rawh
Re: [Test-Announce] Fedora 35 Rawhide 20210526.n.0 nightly compose nominated for testing
On Thu, 2021-05-27 at 01:07 +, rawh...@fedoraproject.org wrote: > Announcing the creation of a new nightly release validation test event > for Fedora 35 Rawhide 20210526.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 > > Notable package version changes: > anaconda - 20210520.n.1: anaconda-35.15-1.fc35.src, 20210526.n.0: > anaconda-35.16-1.fc35.src > lorax - 20210520.n.1: lorax-35.2-1.fc35.src, 20210526.n.0: > lorax-35.3-1.fc35.src Note - there seems to be a bug between libxcrypt and pam which prevents live images booting to a desktop. It's affecting this Rawhide compose and also libxcrypt updates for F33 and F34. I'm investigating currently. Other media seem OK, so it's likely only affecting the liveuser account that's created on boot of live images for some reason. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora 35 Rawhide 20210526.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 35 Rawhide 20210526.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 Notable package version changes: anaconda - 20210520.n.1: anaconda-35.15-1.fc35.src, 20210526.n.0: anaconda-35.16-1.fc35.src lorax - 20210520.n.1: lorax-35.2-1.fc35.src, 20210526.n.0: lorax-35.3-1.fc35.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/35 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_35_Rawhide_20210526.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210526.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210526.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210526.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210526.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210526.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210526.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, 2021-05-26 at 16:59 -0600, Chris Murphy wrote: > On Wed, May 26, 2021 at 5:30 AM Peter Boy wrote: > > > Am 26.05.2021 um 08:51 schrieb Chris Murphy < > > > li...@colorremedies.com>: > > > What controversial discussion is being referenced? Currently before > > > us > > > is a proposal to switch to Btrfs for Cloud edition. > > > > I’m quite sure you know that discussion. Part to it was Red Hat’s > > decision to drop BTRFS in RHEL 8 (to my dismay, by the way, because I > > used it for some file systems on our servers). And because there is > > that decision and that discussion, I expect it will take a longer > > time to switch e.g. server to BTRFS as system wide default. So my > > casual 10-year forecast is not an overreaction as Neal put it (at > > most some pessimism). > > I understand you think it will take longer. What I don't understand is > why you think this, but I guess we can just skip over that. > > But let's keep the Red Hat aspect of the storyline in context though. > And not extrapolate beyond the available facts. > https://news.ycombinator.com/item?id=14907771 > > Whereupon Server SIG/WG perform an evaluation of Btrfs for their use > cases, and decide Btrfs should be the default in a compelling manner, > FESCo will approve it. And this plausibly could still happen for > Fedora 35, if folks really want it to happen. But I think it's neither > urgent nor requires a long delay. Server SIG can do anything they > want. Red Hat is doing the same. > > > > I think we have a misunderstanding here. My argument refers to > > expected hurdles of a possible changeover process, not to technical > > features. > > My opinion is to not worry about the process in advance of arriving at > the hurdle. You jump over the hurdle at the proper time. The vast > majority of the process is about technical features liabilities. > > For example, I expect Server folks probably prefer LVM LV's for > backing virtual machines, rather than raw or qcow2 no matter the file > system. Even if this can be approximated by fallocate (raw and qcow2 > support it, as as well as ext4, xfs, btrfs) to preallocate the backing > file, it's likely a lot of Server folks will just prefer using LVM for > this case. That's fine. > > A good question is to what degree can Server edition, via Anaconda > kickstart, divvy up a drive in boolean fashion? I know there's some > thresholds like, if the drive is below a certain size, don't create > /home, and so on. Could Server default installations default to a ~20G > Btrfs system volume; and either leave the rest unallocated (not > partitioned)? Or make all remaining space an LVM PV, added to a single > VG? And then just not create any LVs? I think I'd like to see each: > unallocated, PV only, PV + VG, in Cockpit's UI and get some feedback > from those folks because it'd be ideal if the overview of the > initially installed system can clearly show the layout, whatever it > is. > > Not often but sometimes folks ask "where has all the space gone?" > following a Server installation. They're not expecting or maybe not > discovering, that quite a lot is held in reserve in the VG. > > > > Again, it’s not about technical properties. We have (or probably > > had?) an agreement to align (or try to align) Server Edition and > > Cloud. That was 2 or 3 months ago. Regarding to that agreement, it is > > a step into the wrong direction. > > Is there a Server or Cloud meeting with minutes that this discussion > happened in? Or email thread you can point to? > As I recall it was very preliminary, and the suggestion is that the working groups can be merged at some point in the future. - mattdm brought it up back in December https://meetbot.fedoraproject.org/teams/serversig/serversig.2020-12-16-18.00.log.html (timestamp: 18:52:23) - there's discussion about talking to Cloud WG on April 7 https://meetbot.fedoraproject.org/teams/fedora-server/fedora-server.2021-04-07-17.01.log.html (timestamp: 17:44:55) I don't think there was ever a discussion of making the two products technically aligned (nor do I really see a need, even if the working groups end up being merged). There has not been an official proposal; to my recollection it has not been brought up at a Cloud WG meeting. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
the assumption that all of those several million
people will want to print from anything with a CPU ("whatever computing
devices one uses") or that that is even the common case.
There's been no assumption that "all" want any-one-thing.
As for common, print-from-any-device-you-use is common here, with ~ 1K
'in-house' users, and easily-dozens-per-day of 'guests'.
That's FAR more common than your 'objection' to it.
As has been said repeatedly here -- paraphrasing, "different strokes for different
folks".
If the developers think its important to support their user-base, what are you
objecting to?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Stephen John Smoogen wrote:
> On Mon, 24 May 2021 at 22:30, Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Solomon Peachy wrote:
>>
>> > On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote:
>> >> I do not see how that is the common use case. Why would I want to
>> >> print from my telephone? I do not even normally print from my
>> >> notebook!
>> >
>> > I don't think it's controversial to say that one needs to print from
>> > whatever computing devices one uses.
>>
>> If I am sitting next to my printer, I have a desktop computer in front of
>> me
>> from which I can issue the print job, so why would I want to do it from a
>> notebook or smartphone?
>>
> Kevin. No one is saying YOU want to print from your phone. However this
> software is not written just for you. Solomon and others do not write the
> software just for you but for the several million people who have to use
> printers in all different kinds of environments.
What I am objecting to is the assumption that all of those several million
people will want to print from anything with a CPU ("whatever computing
devices one uses") or that that is even the common case.
Of course, if all you have is a smartphone, then you will want to print from
it. But that is not going to be the central use case for Fedora (even though
it may be a niche use case for those running Fedora on the PinePhone ;-) ).
> For a good proportion of those people out there.. printing from the phone
> is an expected feature be it instagram memes or that pdf your department
> head sent out which is too small to read on the phone.
Sent out per e-mail? Then you fire up your desktop e-mail client (on your
desktop or notebook) and print from there.
> So it is going to be something Solomon and others will focus on or they
> might as well scrap printing.
That is quite a strong wording.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Tue, May 25, 2021 at 12:04 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/FedoraCloudBtrfsByDefault > > == Summary == > > For cloud installs of Fedora, we want to provide advanced file system > features to users in a transparent fashion. Thus, we are changing the > file system for the Cloud Edition to Btrfs so we can leverage its > features and capabilities to improve the quality of experience for > Cloud users. > > == Owners == > > * Name: [[User:Davdunc|David Duncan]], [[User:Chrismurphy|Chris > Murphy]], [[User:Josef|Josef Bacik]], [[User:Salimma|Michel Alexandre > Salim]], [[User:Dcavalca|Davide Cavalca]], [[User:Ngompa|Neal Gompa]], > [[User:Dustymabe|Dusty Mabe]], [[User:Malmond|Matthew Almond]] > * Email: davd...@amazon.com, chrismur...@fedoraproject.org, > jo...@toxicpanda.com, mic...@michel-slm.name, dcava...@fb.com, > ngomp...@gmail.com, du...@dustymabe.com, malm...@fb.com > * Products: Fedora Cloud Edition > * Responsible WGs: Fedora Cloud WG > > > == Detailed Description == > > Fedora Cloud Edition will switch to using Btrfs for its images. The > configuration for the Cloud Edition will match the setup used on the > desktop variants, as this has been very well-tested with production > deployments across multiple Fedora Linux releases now. > > This includes the same subvolume layout that is used on the desktop > variants [[Changes/BtrfsByDefault|as introduced in Fedora Linux 33]], > as well as transparent Zstd compression > [[Changes/BtrfsTransparentCompression|as introduced in Fedora Linux > 34]]. > > == Feedback == > > == Benefit to Fedora == > > The benefits are similar to > [[Changes/BtrfsByDefault#Benefit_to_Fedora|the ones for Fedora desktop > variants]]; however, there are specific benefits for Fedora Cloud: > > * Adds support to Fedora Cloud for [[Changes/RPMCoW|the Change to > introduce support for Copy-on-Write enhancements to improve > performance to package management]] > * Adds the ability to logically separate contents of the volume > without dividing up the available space > ** Transparent compression: significantly reduces write amplification > and improves effective I/O throughput > ** Reflinks and snapshots improve efficiency for use cases like > containers (CRI-O, containerd, and Podman support both) > * Storage devices can be flaky, resulting in data corruption; Btrfs > can help mitigate this > ** Everything is checksummed and verified on every read > ** Corrupt data results in EIO (input/output error), instead of > resulting in application confusion, and isn’t replicated into backups > and archives > * Improves system responsiveness under pressure > ** Btrfs has been tested in production to have proper IO isolation > capability via cgroups2 > ** Completes the resource control picture: memory, cpu, IO isolation > * File system resize > ** Online shrink and grow are cornerstones of the Btrfs design > * Complex storage setups are… complicated > ** Simple and comprehensive command interface. One master command > ** Simpler to boot, all code is in the kernel, no initramfs complexities > ** Simple and efficient file system replication, including incremental > backups, with btrfs send and btrfs receive > > == Scope == > > * Proposal owners: > ** Submit PRs for Cloud Edition kickstarts to produce disk images using Btrfs. > * Release engineering: [https://pagure.io/releng/issue/10129 #10129] > * Policies and guidelines: N/A > * Trademark approval: N/A > > == Upgrade/compatibility impact == > > Change will not affect upgrades. > > == How To Test == > > Once the change lands in Rawhide, spin up the images in AWS, GCP, and > KVM/OpenStack to test to see systems boot and run. > > == User Experience == > > * Mostly transparent. > * Space savings and extend hardware life, via compression. > * Utilities for used and free space are expected to behave the same. > No special commands are required. > * More detailed information can be revealed by btrfs > specific commands. > * cp command will create reflink copies > [https://src.fedoraproject.org/rpms/coreutils/c/5d08d14b/ by default.] > > == Dependencies == > > None. > > == Contingency Plan == > > * Contingency mechanism: Owner will revert changes back to the > previous ext4 configuration > * Contingency deadline: Beta freeze > * Blocks release? Yes > * Blocks product? Cloud > > == Documentation == > > Strictly speaking, no extra documentation is required reading for users. > > == Release Notes == > > The default file system on the cloud is now Btrfs, following the > desktop change in Fedora Linux 33. Fedora Server, IoT, and CoreOS are > still specifically excluded. > > Just for the formality, from a kernel standpoint, btrfs is treated like it always has been. The decision as to which default filesystem any edition or spin chooses is entirely up to the SIG or spin maintainer of that edition/spin. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe sen
Re: f34 - llvm12 update
On 5/26/21 3:47 PM, Tom Stellard wrote: On 5/14/21 5:20 AM, Serge Guelton wrote: Hi folks, we're preparing an update of the LLVM package from 12.0.0rc1 to 12.0.0. In addition the package the llvm team maintain, the following packages needs a rebuild: annobin-0:9.65 bindgen-0:0.57.0 clazy-0:1.9 doxygen-1:1.9.1 gnome-builder-0:3.40.0 mesa-dri-drivers-0:21.0.2 mesa-libOSMesa-0:21.0.2 mesa-vulkan-drivers-0:21.0.2 postgresql-llvmjit-0:13.2 qt-creator-0:4.14.1 qt6-doctools-0:6.0.3 qt6-linguist-0:6.0.3 There have been some more packages that rebuilt against 12.0.0rc1 since this email, so the full list of packages that will be rebuilt against llvm 12.0.0 is now: annobin bcc bpftrace castxml clazy cvise doxygen ghdl gnome-builder mesa openshadinglanguage postgresql qt-creator qt6-qttools rust rust-bindgen scorep spirv-llvm-translator My mistake, I ran the query on rawhide instead of f34. Here is the real list: annobin clazy doxygen gnome-builder mesa pocl postgresql qt-creator qt6-qttools rust-bindgen spirv-llvm-translator -Tom Once the llvm packaes are all rebuit, we will push these rebuilds in the side-tag f34-build-side-41029. Feel free to contact sguel...@redhat.com and tstel...@redhat.com if you have any question/remark. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
On Wed, May 26, 2021 at 5:30 AM Peter Boy wrote: > > Am 26.05.2021 um 08:51 schrieb Chris Murphy : > > What controversial discussion is being referenced? Currently before us > > is a proposal to switch to Btrfs for Cloud edition. > > I’m quite sure you know that discussion. Part to it was Red Hat’s decision to > drop BTRFS in RHEL 8 (to my dismay, by the way, because I used it for some > file systems on our servers). And because there is that decision and that > discussion, I expect it will take a longer time to switch e.g. server to > BTRFS as system wide default. So my casual 10-year forecast is not an > overreaction as Neal put it (at most some pessimism). I understand you think it will take longer. What I don't understand is why you think this, but I guess we can just skip over that. But let's keep the Red Hat aspect of the storyline in context though. And not extrapolate beyond the available facts. https://news.ycombinator.com/item?id=14907771 Whereupon Server SIG/WG perform an evaluation of Btrfs for their use cases, and decide Btrfs should be the default in a compelling manner, FESCo will approve it. And this plausibly could still happen for Fedora 35, if folks really want it to happen. But I think it's neither urgent nor requires a long delay. Server SIG can do anything they want. Red Hat is doing the same. > I think we have a misunderstanding here. My argument refers to expected > hurdles of a possible changeover process, not to technical features. My opinion is to not worry about the process in advance of arriving at the hurdle. You jump over the hurdle at the proper time. The vast majority of the process is about technical features liabilities. For example, I expect Server folks probably prefer LVM LV's for backing virtual machines, rather than raw or qcow2 no matter the file system. Even if this can be approximated by fallocate (raw and qcow2 support it, as as well as ext4, xfs, btrfs) to preallocate the backing file, it's likely a lot of Server folks will just prefer using LVM for this case. That's fine. A good question is to what degree can Server edition, via Anaconda kickstart, divvy up a drive in boolean fashion? I know there's some thresholds like, if the drive is below a certain size, don't create /home, and so on. Could Server default installations default to a ~20G Btrfs system volume; and either leave the rest unallocated (not partitioned)? Or make all remaining space an LVM PV, added to a single VG? And then just not create any LVs? I think I'd like to see each: unallocated, PV only, PV + VG, in Cockpit's UI and get some feedback from those folks because it'd be ideal if the overview of the initially installed system can clearly show the layout, whatever it is. Not often but sometimes folks ask "where has all the space gone?" following a Server installation. They're not expecting or maybe not discovering, that quite a lot is held in reserve in the VG. > Again, it’s not about technical properties. We have (or probably had?) an > agreement to align (or try to align) Server Edition and Cloud. That was 2 or > 3 months ago. Regarding to that agreement, it is a step into the wrong > direction. Is there a Server or Cloud meeting with minutes that this discussion happened in? Or email thread you can point to? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: f34 - llvm12 update
On 5/14/21 5:20 AM, Serge Guelton wrote: Hi folks, we're preparing an update of the LLVM package from 12.0.0rc1 to 12.0.0. In addition the package the llvm team maintain, the following packages needs a rebuild: annobin-0:9.65 bindgen-0:0.57.0 clazy-0:1.9 doxygen-1:1.9.1 gnome-builder-0:3.40.0 mesa-dri-drivers-0:21.0.2 mesa-libOSMesa-0:21.0.2 mesa-vulkan-drivers-0:21.0.2 postgresql-llvmjit-0:13.2 qt-creator-0:4.14.1 qt6-doctools-0:6.0.3 qt6-linguist-0:6.0.3 There have been some more packages that rebuilt against 12.0.0rc1 since this email, so the full list of packages that will be rebuilt against llvm 12.0.0 is now: annobin bcc bpftrace castxml clazy cvise doxygen ghdl gnome-builder mesa openshadinglanguage postgresql qt-creator qt6-qttools rust rust-bindgen scorep spirv-llvm-translator -Tom Once the llvm packaes are all rebuit, we will push these rebuilds in the side-tag f34-build-side-41029. Feel free to contact sguel...@redhat.com and tstel...@redhat.com if you have any question/remark. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [LEGAL] License field not match the content of eigen3-devel?
On Wed, May 26, 2021 at 3:23 PM Jiri Kucera wrote: > > CC'ing Richard Fontana > > - Original Message - > > From: "Jiri Kucera" > > To: "Development discussions related to Fedora" > > > > Sent: Wednesday, May 26, 2021 4:15:21 PM > > Subject: [LEGAL] License field not match the content of eigen3-devel? > > > > Hello, > > > > I do some investigation of eigen3-devel package and found out that there are > > some files distributed under the Minpack license: > > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMcovar.h > > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMonestep.h > > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMpar.h > > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMqrsolv.h > > - > > /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LevenbergMarquardt.h > > > > There is no "minpack" identifier in the License field inside the > > eigen3.spec. > > However, Minpack license claims itself to be BSD-like. > > > > 1. Should minpack be added to the License field or it is covered by the BSD > > license identifier? First, I think Minpack is an acceptable license for Fedora (it's similar to the old Apache Software License 1.1 but is somewhat more permissive). As far as I can tell it is not on the current list of Fedora "good" licenses (https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses). So I believe the process is to post something to le...@lists.fedoraproject.org. Since these files are in the binary RPM I believe the spec file should reflect that by adding "Minpack" and the file "COPYING.MINPACK" should get installed as well. Also cc'ing Jilayne Lovejoy who may be interested in this more from an SPDX perspective - as far as I can tell Minpack is not represented in the current SPDX list (as currently formulated Apache-1.1 would not be a match). The perennial topic of whether SPDX-style license identifiers should be used in Fedora RPM spec files has recently resurfaced :-) > > 2. Are we really need to ship files in the eigen3-devel packages that are > > marked as unsupported? If the answer to that is "no", then I don't think my answers to the first question would be applicable. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 4:47 PM, Solomon Peachy wrote: But disabling mDNS altogether might cause undesired regerssions elsewhere. Sure. Particularly if you don't set up your /etc/nsswitch.conf correctly. Hence the 'YMMV'. In general, we assume zero-trust and avoid enabling auto-anything. We add trust and loosen constraints, cautiously, when said 'regressions elsewhere' absolutely demand it. Avoids the 'fun' of accidentally exposing a printer queue in the CEOs office ;-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Wed, May 26, 2021 at 04:41:27PM -0400, PGNet Dev wrote: > On 5/26/21 4:28 PM, Björn Persson wrote: > > > You have always had (and always will) have that choice; the ability to > > > disable automatic printer discovery has been present since discovery was > > > added with CUPS 1.2 (released back in 2006!) > > > > I'll have to see if I can find that option. Thanks for the hint. > > fyi, also useful, > > man cups-browsed > > here, I > > systemctl disable cups-browsed > systemctl disable avahi-daemon > > setup printers @ dhcp/dns explicitly, and avoid autodiscovery 'surprises' > altogether. cups-browsed isn't enabled by default, FWIW. But disabling mDNS altogether might cause undesired regerssions elsewhere. If all you want to do is prevent CUPS from auto-discovering remote printers, edit /etc/cups/cupsd.conf and set 'Browsing Off' - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 4:28 PM, Björn Persson wrote: You have always had (and always will) have that choice; the ability to disable automatic printer discovery has been present since discovery was added with CUPS 1.2 (released back in 2006!) I'll have to see if I can find that option. Thanks for the hint. fyi, also useful, man cups-browsed here, I systemctl disable cups-browsed systemctl disable avahi-daemon setup printers @ dhcp/dns explicitly, and avoid autodiscovery 'surprises' altogether. ymmv. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On Wed, May 26, 2021 at 08:15:46PM +0200, Björn Persson wrote: > > And I always try to avoid using protocols that assume that the local > > link is secure. That's one of the reasons why my printer is connected by > > USB, and I would like to continue to have that choice. > > You have always had (and always will) have that choice; the ability to > disable automatic printer discovery has been present since discovery was > added with CUPS 1.2 (released back in 2006!) I'll have to see if I can find that option. Thanks for the hint. Björn Persson pgpLUW8ag8A8D.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [LEGAL] License field not match the content of eigen3-devel?
CC'ing Richard Fontana - Original Message - > From: "Jiri Kucera" > To: "Development discussions related to Fedora" > > Sent: Wednesday, May 26, 2021 4:15:21 PM > Subject: [LEGAL] License field not match the content of eigen3-devel? > > Hello, > > I do some investigation of eigen3-devel package and found out that there are > some files distributed under the Minpack license: > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMcovar.h > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMonestep.h > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMpar.h > - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMqrsolv.h > - > /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LevenbergMarquardt.h > > There is no "minpack" identifier in the License field inside the eigen3.spec. > However, Minpack license claims itself to be BSD-like. > > 1. Should minpack be added to the License field or it is covered by the BSD > license identifier? > 2. Are we really need to ship files in the eigen3-devel packages that are > marked as unsupported? > > Regards, > Jiri > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Wed, May 26, 2021 at 08:15:46PM +0200, Björn Persson wrote: > And I always try to avoid using protocols that assume that the local > link is secure. That's one of the reasons why my printer is connected by > USB, and I would like to continue to have that choice. You have always had (and always will) have that choice; the ability to disable automatic printer discovery has been present since discovery was added with CUPS 1.2 (released back in 2006!) But there is no way to tell from a stock OS print dialog if a given printer identifier is local, remote, "secure", "hostile" or whatever. There never has been, and I don't think there ever can be. You want secure printing? Put the document you want to print onto a USB stick, and plug it into an airgapped printer that is in a controlled-access room. Even that's not necessarily sufficient, but anything _less_ than that is clearly insecure and inherently untrustable. - Solomon -- Solomon Peachypizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Stephen John Smoogen wrote: > The truth is that most people know about it, and have decided that they can > go 'meh' and keep living. I am well aware that most people don't think for a second about computer security. I see examples every day. They tend to begin caring after they find out that they personally have been owned. So your argument is that programs should be written insecurely to make the few who care as insecure as the majority? I shouldn't even have the option to care about security? Otherwise I don't see how what you wrote is an argument in this debate. > Instead IPP, LPD and other > print protocols have always been written with the assumption that the local > network is some level of secure. And I always try to avoid using protocols that assume that the local link is secure. That's one of the reasons why my printer is connected by USB, and I would like to continue to have that choice. Björn Persson pgp2GJIq_HFQB.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > Those that do appear show up as "queuename at host" or > "mfg_model_hostname" I can trust that they always contain either the string " at " or two underscores? Or is that just what well-behaved printers do, while an attacker can name their fake printer however they want? > (for native IPP printers, there's usually a partial > MAC address in there by default too) Security has no use for "usually". > Queues you create > manually/permanently can be called whatever you want and point wherever > you want. So if I see a print queue whose name contains neither the word "at" nor any underscores, is that a guarantee that it's a manually configured queue? In that case I may be able to keep my configured queue and know that I'm sending to my USB printer (or, I guess, redo the configuration when I'm forced to wrap a web server around the USB printer). But the existence of two different naming schemes makes me suspect that there is no such guarantee. I thought for a while that I could configure an unguessable queue name to let me distinguish between my own print queue and the attacker's, but that won't work. A DNS rebinding attack would let the attacker read the queue name from CUPS' web interface, so I can't rely on the queue name being secret. > CUPS's auto-discovery mechanisms have _always_ assumed the > local network can be trusted. You mean CUPS _already_ allows an attacker on the local link to impersonate my USB printer, even before it starts wrapping web servers around USB printers? That's disappointing, but at this point I'm quite ready to believe it. > Sure, someone could be spoofing a specific printer name/identifier just > so they can capture a document *you* want to print, but if there's that > level of persistant hostile presence on your local network, you're > already completly screwed. I would be if I would use insecure protocols on that network – but I stopped using Telnet, SMB and FTP at home decades ago. Björn Persson pgpeiVdE4m7Yl.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: fail2ban: need selinux help!
On Tue, May 25, 2021 at 2:01 PM Richard Shaw wrote: > Due to a change in SELinux for Fedora 34 (I can't find the link right > now), the policy for fail2ban needs to be updated[1] but the changes are a > little bit beyond my understanding of SELinux. > > Any help or pointers from an expert? > Hi Robert, There were a set of changes [1] adding new SELinux permissions in F34. Fail2ban uses its own selinux policy which overrides the one distributed in the selinux-policy package, so it needs to be addressed in the component. I am helping with that [2]. I will take a look at those new bzs and suggest additional changes, probably close some of them as dups. [1] https://fedoraproject.org/wiki/SELinux/Changes/Make_selinux_policy_uptodate_with_current_kernel [2] https://bugzilla.redhat.com/show_bug.cgi?id=1943696 > Thanks, > Richard > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1953321 > https://bugzilla.redhat.com/show_bug.cgi?id=1953322 > https://bugzilla.redhat.com/show_bug.cgi?id=1953323 > https://bugzilla.redhat.com/show_bug.cgi?id=1953324 > https://bugzilla.redhat.com/show_bug.cgi?id=1953325 > https://bugzilla.redhat.com/show_bug.cgi?id=1943696 > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Zdenek Pytela Security SELinux team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[LEGAL] License field not match the content of eigen3-devel?
Hello, I do some investigation of eigen3-devel package and found out that there are some files distributed under the Minpack license: - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMcovar.h - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMonestep.h - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMpar.h - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LMqrsolv.h - /usr/include/eigen3/unsupported/Eigen/src/LevenbergMarquardt/LevenbergMarquardt.h There is no "minpack" identifier in the License field inside the eigen3.spec. However, Minpack license claims itself to be BSD-like. 1. Should minpack be added to the License field or it is covered by the BSD license identifier? 2. Are we really need to ship files in the eigen3-devel packages that are marked as unsupported? Regards, Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Automation/gating for handling soname bumps? (was Re: Unannounced soname bump: libgta)
On Wed, May 26, 2021 at 05:44:28AM -0400, Jiri Kucera wrote: > - Original Message - > > From: "Richard Shaw" > > To: "Development discussions related to Fedora" > > > > Sent: Thursday, May 20, 2021 2:06:34 PM > > Subject: Unannounced soname bump: libgta > > > > Looks like a long standing FTBFS was finally fixed, after previous version > > update attempts failed and the soname bump (0->1) went unnoticed. > > My apologies for breaking the rawhide. Do we have some gating/automation that > keeps new builds gated and additionally rebuilds dependent packages whenever > the soname change is detected? Yes, we do: OpenQA gating for critpath packages. For other packages, we have advisory tests (iiuc current state correctly). We also have guidelines to detect so bumps at build time: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_library_files 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 7:05 AM, Zdenek Dohnal wrote: Hi Robert, On 5/24/21 2:39 PM, Robert Marcano via devel wrote: On 5/24/21 3:29 AM, Zdenek Dohnal wrote: Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. This application will advertise the device on localhost via MDNS protocol and will communicate with CUPS via IPP, both public well-known protocols. The only place where the data can turn into proprietary is filtering, but it's the same with printer drivers. -- Greetings, Is there any plan to support these IPP printer applications over Unix domain sockets? pappl supports listening on domain sockets (IIUC the docs https://www.msweet.org/pappl/pappl.html), so if a printer application decides on it will use domain sockets, it is possible. Thanks for the information. Last time I saw some reluctance from CUPS maintainers (before the fork) to add domain sockets support for IPP, that was the reason I asked. If pappl can do it now I presume CUPS will be able to use these printers. I manage a virtual printer that uses CUPS filters and backends to capture documents to an application database. We have been using CUPS authentication features to control who can use the printer, and not to have to reimplement authentication on the filter and backends. With network bound IPP applications, anyone on the same multiuser machine would be able to bypass CUPS and send documents directly unless I duplicate CUPS authentication functionality. Unix sockets would help with that, ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
PyPy license correction (wrt bundled libraries)
pypy and pypy3 license metadata have been corrected from: MIT and Python and UCD to: MIT and Python and UCD and BSD and (ASL 2.0 or BSD) # PyPy is MIT # Python standard library is Python # pypy/module/unicodedata is UCD # Bundled pycparser is is BSD # Bundled pycparser.ply is BSD # Bundled bits from cryptography are ASL 2.0 or BSD The mising bundled() provides have been added. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Make btrfs the default file system for Fedora Cloud (System-Wide Change proposal)
> Am 26.05.2021 um 08:51 schrieb Chris Murphy : > > On Tue, May 25, 2021 at 5:52 PM Peter Boy wrote: >> >> >>> Am 25.05.2021 um 23:20 schrieb Neal Gompa : >>> Cloud images never had such separation. It was always one big ext4 >>> partition. With Btrfs, we can introduce subvolumes so user data can be >>> trivially managed separately without losing the benefits of a single >>> pool of storage. >> >> That’s the difference: As a server sysadmin I would rather consider >> potential risks of a single pool of storage. :-) > > OK, let's consider 2-3 potential risks. > > Hard drive mechanical failure (spindle, motor, actuator, rw head), no > matter what file system and partitioning you use, you are out of luck. > ... > > What are the potential risks you are concerned about in the cloud and > server use cases? Please be specific. That sounds very promising. But I wanted to emphasize something else: The criteria and the point of view are different. For logical reasons, an argument from one context has no assertiveness in the other context. The same detail is evaluated differently in a different context. >> What I get from the controversial discussion about BTRFS is that there is >> doubt about how really clean that "cleanly isolate" is, at least compared to >> LVM. But if important data is (supposed to be) on additional external >> storage, that's perfect. > > What controversial discussion is being referenced? Currently before us > is a proposal to switch to Btrfs for Cloud edition. I’m quite sure you know that discussion. Part to it was Red Hat’s decision to drop BTRFS in RHEL 8 (to my dismay, by the way, because I used it for some file systems on our servers). And because there is that decision and that discussion, I expect it will take a longer time to switch e.g. server to BTRFS as system wide default. So my casual 10-year forecast is not an overreaction as Neal put it (at most some pessimism). I think we have a misunderstanding here. My argument refers to expected hurdles of a possible changeover process, not to technical features. >> Regarding that idea, the switch to BTRFS tends to be a step in the wrong >> direction. > > Cloud and Server editions have had different file system and > partitioning strategies since day 1. Today is the first I've heard > that there should be, could be, would be, some kind of realignment > where Cloud uses LVM or Server uses ext4, or some other combination. > But you are now asserting that this alignment should happen? And are > you asserting that this is a central question needing an answer as a > prerequisite for evaluating this Fedora 35 change proposal? Again, it’s not about technical properties. We have (or probably had?) an agreement to align (or try to align) Server Edition and Cloud. That was 2 or 3 months ago. Regarding to that agreement, it is a step into the wrong direction. But maybe in the meantime we had another trend coming up. Neal came up with some arguments about a general difference between both so an alignment is seen as not possible or not useful. I’m not a stakeholder for any decision about that. And I have no intention of missionizing for any of the options. I’m just the bookkeeper and try to ensure that nothing is forgotten and everything follows a solid and consistent logic. And because I am not a native English speaker, some wording may be misleading, much to my chagrin. So we may drop it from the table. I’ve put it on the agenda of todays Server IRC meeting. Best Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Robert, On 5/24/21 2:39 PM, Robert Marcano via devel wrote: > On 5/24/21 3:29 AM, Zdenek Dohnal wrote: >> >> Devices which currently depend on a deprecated functionality - >> printer drivers and raw queues - will need a printer application once >> the deprecated functionality is removed from CUPS. This application >> will advertise the device on localhost via MDNS protocol and will >> communicate with CUPS via IPP, both public well-known protocols. The >> only place where the data can turn into proprietary is filtering, but >> it's the same with printer drivers. >> >> -- > > Greetings, Is there any plan to support these IPP printer applications > over Unix domain sockets? pappl supports listening on domain sockets (IIUC the docs https://www.msweet.org/pappl/pappl.html), so if a printer application decides on it will use domain sockets, it is possible. > > I manage a virtual printer that uses CUPS filters and backends to > capture documents to an application database. We have been using CUPS > authentication features to control who can use the printer, and not to > have to reimplement authentication on the filter and backends. With > network bound IPP applications, anyone on the same multiuser machine > would be able to bypass CUPS and send documents directly unless I > duplicate CUPS authentication functionality. Unix sockets would help > with that, > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Przemek, thank you for trying the driverless and the investigation! Would you mind checking if the similar bug isn't already reported on Avahi in Fedora and reporting it if not? Maybe Avahi maintainers can point out what is the best for debugging Avahi. I recommend setting debug logging on avahi-daemon service file, maybe its logs will show something more. On 5/25/21 8:20 PM, przemek klosowski via devel wrote: > > There are so many moving pieces here that it's hard to get a handle on > this. I had trouble seeing local network printers so I tried following > the advice Zdenek published [1], but I ran into a nest of issues: > printing depending on avahi, which fails quietly and is hard to debug. > > Specifically, I did *avahi-browse -avrt* which just returns with > avahi_service_browser_new() failed: Invalid service type > > This seems to be related to a bug where some devices are sending > non-compliant data to avahi: > https://github.com/lathiat/avahi/issues/212 but we're already far away > from the print subsystem.. I tried running avahi-browser under gdb but > between the missing and not-autoloading debuginfo packages, and the > callback-style structure, I wasn't able to catch it receiving the data > that causes the problem. > > I guess my point here is that we have a complex, interdependent > system, and when it fails, it is fairly opaque. At this point I am not > sure what to do: is the root cause here the avahi bug? I am willing to > spend the effort getting to the bottom of it but I can't figure out > where to start. > IIUC the upstream issue, the core of the problem is that something in your local network sends a broken PTR record which avahi cannot cope with and it breaks avahi-browse in whole LAN... > > > >> On 5/24/21 1:42 PM, Stephen John Smoogen wrote: >>> I have had very bad luck in setting up new network printers over the >>> last 4 years. I can get all of them to print from Windows and Mac, >>> but every one of them from HP, Brother, and some other brands could >>> not print anything from Linux. They were all 'Linux ready' but were >>> doing it via either Google Print or a set of proprietary software >>> blobs to be put on the computer. [They even came with ipp filters >>> but they called the blobs]. I have a Brother MFC-27100W in my office >>> which I print to via my wife's Mac because of this. >>> >> >> I have written some basic info about how to find out whether your >> printer supports driverless [1] and how to setup it [2]. If you have >> at least F33 and have the device in your LAN, you can use temp queues >> for sure, otherwise you need to create a permanent queue via lpadmin: >> >> $ lpadmin -p -v -m >> everywhere -E >> >> >> If you still experience the issue, do feel free to file a bug for >> cups in bugzilla and I can look into it further. >> >> >> [1] >> https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F >> >> [2] >> https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer >> >> > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Automation/gating for handling soname bumps? (was Re: Unannounced soname bump: libgta)
- Original Message - > From: "Richard Shaw" > To: "Development discussions related to Fedora" > > Sent: Thursday, May 20, 2021 2:06:34 PM > Subject: Unannounced soname bump: libgta > > Looks like a long standing FTBFS was finally fixed, after previous version > update attempts failed and the soname bump (0->1) went unnoticed. My apologies for breaking the rawhide. Do we have some gating/automation that keeps new builds gated and additionally rebuilds dependent packages whenever the soname change is detected? Regards and have a nice day, Jiri > https://src.fedoraproject.org/rpms/libgta/commits/rawhide > > Looks like only two packages need rebuilding: > gdal > OpenSceneGraph > > I'll go ahead and kick off builds. > > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Let's retire original glib and gtk+
On Tue, May 25, 2021 at 11:01 PM Michael Catanzaro wrote: > > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple > wrote: > > I have no idea how significant this might be, but perhaps this should > > be discussed more publicly. > > Use containers? Ship your own glib as a static lib? I'm impressed you > have software that still needs it tbh. I think copr is the perfect place for these sort of things for those that care 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The future of legacy BIOS support in Fedora.
> On Saturday, July 4, 2020 6:44:55 AM MST Solomon Peachy wrote: > > There are still new systems built today that only support BIOS, and vendors > providing systems factory-configured for BIOS boot on hardware that does > support UEFI. There is no 2TB upper limit on drive sizes as a result of > booting from BIOS. > > > > I don't know where you got this, but that's completely false. You can use GPT > partition tables on systems with BIOS boot. Whoever told you otherwise is > misinformed at best. > > > Why do you "despise" BIOS boot? > > > I highly doubt that, but time will tell. > > > That's absolutely false, as demonstrated elsewhere in this thread. Pretending > otherwise is delusional, and delusions are no basis for technical decisions. As Mr Poettering noted earlier and quite correctly, JMH junior ought to grow up. Harris junior is not to be taken seriously. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Let's retire original glib and gtk+
On Tue, 25 May 2021 17:00:31 -0500 Michael Catanzaro wrote: > On Sat, May 22 2021 at 09:23:23 AM +1000, Bob Hepple > wrote: > > I have no idea how significant this might be, but perhaps this > > should be discussed more publicly. > > Use containers? Ship your own glib as a static lib? I'm impressed you > have software that still needs it tbh. > > Anyway, there have been no other objections, and there's been no > comment from the package owner, so I wonder if any provenpackagers > would be willing to do the glib package retirement? I'm the package owner and I'm prepared to retire glib/gtk+ once there are no further dependencies on them in Fedora. Paul, ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210526.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210525.0): ID: 894666 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/894666 ID: 894673 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/894673 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Linux 32 End Of Life
On Wednesday, 26 May 2021 at 00:23, Mohan Boddu wrote: > On Tue, May 25, 2021 at 5:12 PM Dominik 'Rathann' Mierzejewski > wrote: > > > > On Tuesday, 25 May 2021 at 23:06, Mohan Boddu wrote: > > > Hello all, > > > > > > As of the 25th of May 2021, Fedora Linux 32 has reached its end of > > > life for updates and support. No further updates, including security > > > updates, will be available for Fedora 32. All the updates that are > > > currently in testing won't get pushed to stable. > > > > What about updates that were in "submitted to stable" state? Don't they > > deserve the final push? I'm talking about this one in particular: > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-5f3479aaf3 > > It waited to be pushed to stable for 17 hours only to be made obsolete > > at the last step. It doesn't seem fair to me. > > I understand the problem here, but we push updates once a day and > today's push is already finished. The problem with running another > push just before starting the EOL process is that update pushes take > some time and we cannot start the EOL process until they are finished > and the push might fail which delays the EOL process even further. EOL > process takes some time and we cannot delay it to the next day and > also even when going through the EOL process, updates can go to stable > and we cannot simply keep pushing them. > > Sorry for the trouble this has caused, but I am not sure if there is > an easy way to fix this issue. Announcing that "updates must be submitted to stable before May 24th 12:00 UTC[1] to be included in the last stable push" would suffice for me. Sending such a reminder a week before the deadline and a second one 24h before the deadline would be really great. [1] I haven't checked what the actual cut-off time is. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
