Fedora-Cloud-33-20201228.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) ID: 747636 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/747636 ID: 747643 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/747643 Passed openQA tests: 6/7 (x86_64), 6/7 (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
Re: Self Introduction -- Derek Pressnall
Hi Derek,
ds...@needcaffeine.net writes:
> Hello fellow developers.
> I've joined this list quite a while ago, mostly to keep a pulse on the Fedora
> development community, but also to look to become a package contributor. But
> before getting to that, a few words about myself.
>
> I've been "into computers" since mid-80's, started off with a 4.77 Mhz 8088
> (IBM PCjr). I learned Unix in the early 90's on an IBM AIX system, where I
> picked up C programming and sysadmin experience. Which eventually took me
> into the world of Linux (I think it was kernel version 0.12, came on a boot
> disk and root disk pair I grabbed off a BBS, long before there was easy
> general public Internet access).
> Anyway I've been focused on Red Hat based distros for the past 15 years, and
> at my current employer I oversee about 700 systems installed at customer
> locations (where I was the resource responsible for packaging our
> applications and creating system build images).
>
> Any way, what I'd like to give back to the community is a really nice backup
> system called Snebu (Simple Network Encrypting Backup Utility). I initially
> developed this more than 8 years ago since there wasn't anything else that
> fit my needs -- I used it to back up my personal systems, and also in some
> lab environments. I've read plenty of rants that have been posted about how
> backups are either too difficult to set up, or don't support multiple
> clients, or require a repository encryption password to be placed in plain
> text on clients, and other issues people have. With that in mind, I believe
> that Snebu can be just what people want.
>
I have not really looked into the source code, so forgive me if that is
obvious, but why is the snebu executable setuid?
> Before going through and submitting the package for formal review, I'd
> appreciate some feedback on what I have packaged up so far. The current
> release is at
> https://github.com/derekp7/snebu/releases/download/v1.1.0/snebu-1.1.0-1.fc33.src.rpm,
> and the project web site is at https://www.snebu.com.
>
The spec file is mostly good, I'd suggest a few changes though:
- use macros instead of hardcoded paths, e.g. %_bindir instead of
/usr/bin/
- don't disable the debug package generation, Fedora packages must
include debuginfo versions
- replace make %{?_smp_mflags} with:
%set_build_flags
%make_build
- mark LICENSE.txt as %license and not as %doc
- there is no need to install the documentation under
/usr/share/doc/snebu manually, you can just add the following into
%files and rpmbuild will copy the files into the right place:
%doc readme.md
%doc snebu.adoc
- I'd recommend to replace the %pre check for the snebu user with a
systemd-sysusers config:
https://fedoraproject.org/wiki/Changes/SystemdSysusers
And one general issue not directly related to rpmbuild itself: does your
Makefile honor the CFLAGS & LDFLAGS environment variables? Because if it
does not, then all the compiler hardening flags that %set_build_flags
inject will be just ignored.
Cheers,
Dan
___
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: What is the most time consuming task for you as packager?
Miroslav Suchý writes: > I am looking for challenges for upcoming year - what I and my team should > enhance. I have some ideas, but I want to hear > yours. > > What you - as Fedora packager - find most time consuming on packaging? > Where you will welcome more simplicity or automation? Besides what was already said, I'd welcome the option to start builds & updates directly from pull requests on pagure. If someone sends me a pull request that only needs a fedpkg build && fedpkg update, then it would be terrific if I could trigger this from pagure's web UI directly and be done with it. Cheers, Dan 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: What is the most time consuming task for you as packager?
Michael Cronenworth writes: > On 12/15/20 4:29 PM, Miroslav Suchý wrote: >> What you - as Fedora packager - find most time consuming on packaging? >> Where you will welcome more simplicity or automation? > > Pushing updates requires too many steps, IMHO. > > 1. > 2. fedpkg mockbuild > 3. > 4. fedpkg commit -p > 5. fedpkg build > 6. fedpkg update ... 100% agree with this and add one to two fedpkg switch-branch commands to that with a bunch of git merge and git cherry-pick. > Can we make the Bodhi update notes part of the git repo? Ex. ChangeLog.md > If not, could a file be referenced instead of a "--notes" argument? Ex. > --notes-file > ChangeLog.md > Stretch goal: Bodhi update defaults (inc. notes?) as part of git, > too. Ex. update.yml Afaik there was the good idea to use annotated git tags for that. Thus this whole thing would be condensed to: git commit -m $commit_msg git tag -a -m $update_msg fedpkg push (-> build is run and a bodhi update is triggered) Cheers, Dan 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
[389-devel] 389 DS nightly 2020-12-28 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/12/28/report-389-ds-base-1.4.4.9-1.fc33.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: heads up: nss 3.59 breaks firefox add-ons
Ok, I am the n00b here but I have experienced some nss related problems since upgrading to Fedora 33. I found that the systemd-resolved service interferes with or corrupts previously normal nss functions, most related. to the resolver. For example, when some hosts used systemd-resolved and others used nss, dig and nslookup don't resolve properly. Sometmes ping does work. Sometimes extrernal lookups work and internals don't and sometimes the other way round. But the exact symptom can depend on which type of host you are working with. I stopped and disabled systemd-resolved and all of those problems disappeared. Firefox now works fine for me as do all my network services. http://www.linux-databook.info/?page_id=5951 Thanks -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Sat, 19 Dec 2020, Kevin Fenzi wrote: Date: Sat, 19 Dec 2020 12:32:28 -0800 From: Kevin Fenzi Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora Subject: Re: heads up: nss 3.59 breaks firefox add-ons On Sat, Dec 19, 2020 at 05:33:57PM +0100, Marius Schwarz wrote: Am 18.12.20 um 15:33 schrieb James Szinger: I see nss.x86_64 3.59.0-3.fc33 in today’s updates. Is this fixed or are there going to be a lot of unhappy Firefox users? The bug is still open. Can someone pls lush this into rawhide? There is only -2 WITH the SHA-1 blockade. firefox-84.0-6 in rawhide (the latest package available) has enabled it's bundled nss that doesn't do that check. ;( https://koji.fedoraproject.org/koji/buildinfo?buildID=1659741 So, upgrading to that should work around the problem. Of course it causes other problems, like firefox exposing all the nss provides. The best workaround for now would be firefox adding some code to exempt itself from the sha1 check for now and resume building against the system nss and the system nss re-enabling the sha1 check. The real solution is of course mozilla updaing add-ons to not use sha1. ;) 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: Stale proven packagers
On Sun, Dec 27, 2020 at 06:43:23PM -0700, Ken Dreyer wrote: > On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune > wrote: > > > > > The weakest point in the current system is really the FAS password. If > > > you have a packager's FAS password you can change the ssh key > > > associated with the account to another that you control, and the FAS > > > password is also all you need to run a build and submit it to Bodhi. > > > > Or you add an SSH key without removing the maintainer's keys on the > > off chance that it would go unnoticed... > > From what I can tell, the current implementation of FAS does not allow > more than one SSH key per user account. You can add more than one. Just put them in a file and upload all of them for 'ssh key' one key per line. There's a limit based on applications getting the ssh keys, but you can upload multiple keys fine. 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: Stale proven packagers
On Sun, Dec 27, 2020 at 01:11:20PM +, Dridi Boukelmoune wrote: > On Sat, Dec 26, 2020 at 6:14 PM Kevin Fenzi wrote: > > > > On Thu, Dec 24, 2020 at 07:32:04AM +, Dridi Boukelmoune wrote: > > > > The weakest point in the current system is really the FAS password. If > > > > you have a packager's FAS password you can change the ssh key > > > > associated with the account to another that you control, and the FAS > > > > password is also all you need to run a build and submit it to Bodhi. > > > > Well, really the weakest point is email. If you have control over a fas > > accounts email address you can reset the password, etc. > > > > > Or you add an SSH key without removing the maintainer's keys on the > > > off chance that it would go unnoticed... > > > > fas sends email on every such change. > > There are situations where notifications could go unnoticed. At this > point if an attacker managed to compromise an email address and add an > SSH key to a fas account, the attacker might also delete the > notification email promptly. Sure, or reset the password...or change the email address, or pretty much anything. This is why I said "the weakest point is email". We assume someone who controls an email is the same as the person who controls the account associated with that email. 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-bc6881c4f5 pngcheck-2.4.0-5.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dddcb59a9c phpldapadmin-1.2.5-1.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83291355d7 openssl11-1.1.1g-2.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599 openjpeg2-2.3.1-10.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7c91badc19 guacamole-server-1.2.0-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing exfatprogs-1.0.4-1.el7 openhantek-3.1.5-1.el7 Details about builds: exfatprogs-1.0.4-1.el7 (FEDORA-EPEL-2020-7e23671a4b) Userspace utilities for exFAT filesystems Update Information: Userspace utilities for exFAT filesystems ChangeLog: References: [ 1 ] Bug #1824156 - Review Request: exfatprogs - Userspace utilities for exFAT filesystems https://bugzilla.redhat.com/show_bug.cgi?id=1824156 openhantek-3.1.5-1.el7 (FEDORA-EPEL-2020-324dd02f6b) Hantek and compatible USB digital signal oscilloscope Update Information: Update to 3.1.5. ChangeLog: * Sun Dec 27 2020 Vasiliy Glazov - 3.1.5-1 - Update to 3.1.5 ___ 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 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c82583d07e pngcheck-2.4.0-5.el8 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fe42686452 mbedtls-2.16.9-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing doctest-2.4.4-1.el8 exfatprogs-1.0.4-1.el8 openhantek-3.1.5-1.el8 pdns-recursor-4.3.6-1.el8 python-img2pdf-0.4.0-3.el8 Details about builds: doctest-2.4.4-1.el8 (FEDORA-EPEL-2020-ec36912a45) Feature-rich header-only C++ testing framework Update Information: New upstream 2.4.4. 2.4.1 -> 2.4.3 ChangeLog: * Sat Dec 26 2020 Nick Black - 2.4.4-1 - New upstream release * Wed Dec 16 2020 Nick Black - 2.4.3-1 - New upstream release exfatprogs-1.0.4-1.el8 (FEDORA-EPEL-2020-b83de3a61f) Userspace utilities for exFAT filesystems Update Information: Userspace utilities for exFAT filesystems ChangeLog: References: [ 1 ] Bug #1824156 - Review Request: exfatprogs - Userspace utilities for exFAT filesystems https://bugzilla.redhat.com/show_bug.cgi?id=1824156 openhantek-3.1.5-1.el8 (FEDORA-EPEL-2020-09904a637a) Hantek and compatible USB digital signal oscilloscope Update Information: Update to 3.1.5. ChangeLog: * Sun Dec 27 2020 Vasiliy Glazov - 3.1.5-1 - Update to 3.1.5 pdns-recursor-4.3.6-1.el8 (FEDORA-EPEL-2020-88cf91be6f) Modern, advanced and high performance recursing/non authoritative name server Update Information: - Upstream released new version - See https://doc.powerdns.com/recursor/changelog/4.3.html#change-4.3.6 for more details ChangeLog: * Sun Dec 27 2020 Ruben Kerkhof - 4.3.6-1 - Upstream released new version - See https://doc.powerdns.com/recursor/changelog/4.3.html#change-4.3.6 for more details python-img2pdf-0.4.0-3.el8 (FEDORA-EPEL-2020-1666a75a04) Lossless images to PDF conversion library and command Update Information: Support EPEL8 - fix macro expansion ChangeLog: References: [ 1 ] Bug #1907226 - Please build python-img2pdf for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1907226 ___ 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: Stale proven packagers
On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune wrote: > > > The weakest point in the current system is really the FAS password. If > > you have a packager's FAS password you can change the ssh key > > associated with the account to another that you control, and the FAS > > password is also all you need to run a build and submit it to Bodhi. > > Or you add an SSH key without removing the maintainer's keys on the > off chance that it would go unnoticed... From what I can tell, the current implementation of FAS does not allow more than one SSH key per user account. - Ken ___ 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 1911158] New: perl-Mojolicious-8.68 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1911158 Bug ID: 1911158 Summary: perl-Mojolicious-8.68 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mojolicious Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com, yan...@declera.com Target Milestone: --- Classification: Fedora Latest upstream release: 8.68 Current version/release in rawhide: 8.67-1.fc34 URL: https://metacpan.org/release/Mojolicious 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/5966/ -- 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 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 27/12/2020 20:07, Luya Tshimbalanga wrote: On 2020-12-21 3:31 a.m., Tom Hughes via devel wrote: On 20/11/2020 16:26, Ben Cotton wrote: < - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. I was unable to get this to work. Works with Galaxy Buds+ as highlighted below: I was trying it with Bose QC35 headphones. The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager. Which version of pipewire was used on your system? Pipewire 0.3.18 enabled a bluetooth headphone i.e. Galaxy Buds+ with issue related to resuming for the reopened lid of a laptop. Workaround is with the command for terminal "systemctl --user restart pipewire.service pipewire-pulse.service". See attached pipewire.conf with include bleuz5 enabled by default. It was 0.3.18 and as I say it was showing up as a device but with no node that I could route audio to. That configuration you attached still seems to be missing the extra "-e bluez5" on the pipewire-media-session line? or is the comment there wrong when it says that is required? The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you switch to a different desktop to something because once I started a second session things got horribly confused and I wound up with one desktop where audio worked and one where it didn't work at all. No issue on my desktop running Rawhide. Maybe some issues are user error like using old version of pipewire. Update your system and make sure pipewire version is 0.3.18 whose pipewire-pulseaudio properly handle dependencies. Should you see Steam from RPM Fusion being removed, grab the latest version from their Koji page which fixes the problem. I don't use steam so it's nothing to do with that. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Popularity contest for Fedora
On Sun, Dec 27, 2020 at 07:44:57PM +0100, clime wrote: > I think we can simply parse server-side access logs to count package > downloads, no? We can for our primary server, but most people get updates from mirrors which we don't run directly. The central mirrorlist (from which I get the dnf count data) just redirects people to those mirrors. Even if we could get package download counts from the mirrors, they're heavily skewed by: * public mirrors pulling the whole thing * people pulling the whole thing for a private mirror * ci and build systems (like, running mock) * mysterious bots downloading stuff for whatever reason * proxies and caching and probably more. Popcon and smolt are better because it's actual individual system data. On the other than, they're worse as mentioned because opt-in doesn't give a realistic picture. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Popularity contest for Fedora
I think we can simply parse server-side access logs to count package downloads, no? That ignores the effect of caching proxies, which are prevalent in academic and corporate environments. ___ 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-20201227.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 9/180 (x86_64), 4/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201226.n.0): ID: 747276 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/747276 ID: 747382 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/747382 ID: 747409 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/747409 Old failures (same test failed in Fedora-Rawhide-20201226.n.0): ID: 747277 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/747277 ID: 747284 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/747284 ID: 747294 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/747294 ID: 747303 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/747303 ID: 747305 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/747305 ID: 747317 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/747317 ID: 747457 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/747457 ID: 747484 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/747484 ID: 747511 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/747511 ID: 747520 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/747520 Soft failed openQA tests: 20/180 (x86_64), 15/122 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20201226.n.0): ID: 747262 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/747262 ID: 747282 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/747282 Old soft failures (same test soft failed in Fedora-Rawhide-20201226.n.0): ID: 747223 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/747223 ID: 747224 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/747224 ID: 747231 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/747231 ID: 747235 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/747235 ID: 747239 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/747239 ID: 747240 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/747240 ID: 747253 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/747253 ID: 747325 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/747325 ID: 747334 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/747334 ID: 747335 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/747335 ID: 747343 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/747343 ID: 747354 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/747354 ID: 747360 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/747360 ID: 747374 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/747374 ID: 747378 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/747378 ID: 747401 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/747401 ID: 747402 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/747402 ID: 747417 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/747417 ID: 747426 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/747426 ID: 747454 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/747454 ID: 747468 Test: x86_64 universal
Re: What is the most time consuming task for you as packager?
On 2020-12-21 4:02 a.m., Miroslav Suchý wrote: Dne 19. 12. 20 v 21:24 Luya Tshimbalanga napsal(a): Just an idea of a form application that generates the spec file for newcomers as an example. Something like https://xsuchy.github.io/rpm-spec-wizard/ ? I do not propagate it too much as the first page needs a lot of love - it seems empty, but there is button in upper left corner, which does the magic. Cool!! That is a much needed tool for new packagers!! The first page could start with a title "RPM SPEC generator", a brief description of its purpose and then the button at the bottom. -- 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 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 2020-12-15 10:52 a.m., Tom Seewald wrote: Gary Buhrmaster wrote on Mon, Dec 14, 2020: With updates-testing enabled here, it's much better than last month (no more gdm being removed), but there still are a few pulseaudio direct dependencies: Steam from rpmfusion still conflicts with pipewire-pulseaudio as well. Until that conflict is resolved it is going to prevent a lot of people from being able to test pipewire since it will mean removing their ability to use steam and all of the games tied to it. Resolved on steam 1.0.0.68-6 https://koji.rpmfusion.org/koji/packageinfo?packageID=413 -- 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 34 Change: Route all Audio to PipeWire (System-Wide Change)
On 2020-12-21 3:31 a.m., Tom Hughes via devel wrote: On 20/11/2020 16:26, Ben Cotton wrote: == Summary == This change proposal is to route all audio from PulseAudio and JACK to the PipeWire Audio daemon by default. So I tried this in F33 with the packages from updates-testing and I'm afraid to say it didn't end well... Audio functionality should be like it was before with the Pulseaudio daemon. Some things to verify: - patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x) As pactl was removed by the switch I couldn't test this. pactl command is still present after replacing pulseaudio by pipewire-pulseaudio. pactl info Server String: /run/user/1000/pulse/native Library Protocol Version: 34 Server Protocol Version: 34 Is Local: yes Client Index: 78 Tile Size: 65472 Server Name: PulseAudio (on PipeWire 0.3.18) Server Version: 14.0.0 Default Sample Specification: float32le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: alsa_output.pci-:03:00.6.analog-stereo Default Source: alsa_input.pci-:03:00.6.analog-stereo Cookie: 5667:4fbd - gnome-control-center: check the audio tab, check the volume sliders and do the audio channel test. Change the card profile, plug/unplug headphones and observe correct switch. This worked initially, but see later. - pavucontrol: check volumes in the input devices tabs and check the microphone volumes Didn't test this. Worked fine. - firefox: check out a website with audio/video such as youtube and verify that audio works as usual. Check out a website with a video chat test page (bluejeans.com/111). Didn't test this. Works. - rhythmbox: check if playback works as expected This worked initially, but see later. Works here. - bluetooth devices, connect as usual and verify working behaviour with PipeWire. Check volume changes etc. I was unable to get this to work. Works with Galaxy Buds+ as highlighted below: pactl info Server String: /run/user/1000/pulse/native Library Protocol Version: 34 Server Protocol Version: 34 Is Local: yes Client Index: 97 Tile Size: 65472 Server Name: PulseAudio (on PipeWire 0.3.18) Server Version: 14.0.0 Default Sample Specification: float32le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: api.bluez5.a2dp.sink.Galaxy Buds+ (11C1) Default Source: alsa_input.pci-:03:00.6.analog-stereo Cookie: 4766:6514 The first problem is that bluetooth is not actually enabled by default so you have to edit /etc/pipewire/pipewire.conf and tell it to add "-e bluez5" when starting the session manager. Which version of pipewire was used on your system? Pipewire 0.3.18 enabled a bluetooth headphone i.e. Galaxy Buds+ with issue related to resuming for the reopened lid of a laptop. Workaround is with the command for terminal "systemctl --user restart pipewire.service pipewire-pulse.service". See attached pipewire.conf with include bleuz5 enabled by default. After that my headphones who show up as a device in pw-cli but not as a target I could send sound to. An example with Galaxy Buds+: id 84, type PipeWire:Interface:Node/3 factory.id = "7" client.id = "31" device.id = "83" node.description = "Galaxy Buds+ (11C1)" node.name = "api.bluez5.a2dp.sink.Galaxy Buds+ (11C1)" media.class = "Audio/Sink" id 85, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):playback_0" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FL" port.name = "playback_FL" port.direction = "in" port.physical = "true" port.terminal = "true" port.alias = "Galaxy Buds+ (11C1):playback_FL" id 86, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):monitor_0" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FL" port.name = "monitor_FL" port.direction = "out" port.alias = "Galaxy Buds+ (11C1):monitor_FL" id 87, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):playback_1" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FR" port.name = "playback_FR" port.direction = "in" port.physical = "true" port.terminal = "true" port.alias = "Galaxy Buds+ (11C1):playback_FR" id 88, type PipeWire:Interface:Port/3 object.path = "Galaxy Buds+ (11C1):monitor_1" format.dsp = "32 bit float mono audio" node.id = "84" audio.channel = "FR" port.name = "monitor_FR" port.direction = "out" port.alias = "Galaxy Buds+ (11C1):monitor_FR" The final straw though was that fast user switching seems to completely break it. I assume that the daemon doesn't release the audio device when you
Fedora rawhide compose report: 20201227.n.0 changes
OLD: Fedora-Rawhide-20201226.n.0 NEW: Fedora-Rawhide-20201227.n.0 = SUMMARY = Added images:71 Dropped images: 0 Added packages: 3 Dropped packages:0 Upgraded packages: 81 Downgraded packages: 0 Size of added packages: 468.38 KiB Size of dropped packages:0 B Size of upgraded packages: 1.17 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 90.27 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20201227.n.0.iso Image: KDE live x86_64 Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20201227.n.0.iso Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20201227.n.0.armhfp.raw.xz Image: KDE raw-xz aarch64 Path: Spins/aarch64/images/Fedora-KDE-Rawhide-20201227.n.0.aarch64.raw.xz Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20201227.n.0.iso Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20201227.n.0.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20201227.n.0.iso Image: Container_Base docker armhfp Path: Container/armhfp/images/Fedora-Container-Base-Rawhide-20201227.n.0.armhfp.tar.xz Image: Server dvd armhfp Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-Rawhide-20201227.n.0.iso Image: Server boot x86_64 Path: Server/x86_64/iso/Fedora-Server-netinst-x86_64-Rawhide-20201227.n.0.iso Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201227.n.0.x86_64.vagrant-libvirt.box Image: Everything boot aarch64 Path: Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20201227.n.0.iso Image: Everything boot x86_64 Path: Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20201227.n.0.iso Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20201227.n.0-sda.raw.xz Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-Rawhide-20201227.n.0.aarch64.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20201227.n.0.s390x.qcow2 Image: Minimal raw-xz armhfp Path: Spins/armhfp/images/Fedora-Minimal-Rawhide-20201227.n.0.armhfp.raw.xz Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20201227.n.0.iso Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20201227.n.0.aarch64.raw.xz Image: Cloud_Base qcow2 aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20201227.n.0.aarch64.qcow2 Image: Cloud_Base qcow2 x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20201227.n.0.x86_64.qcow2 Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20201227.n.0.aarch64.raw.xz Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20201227.n.0.s390x.raw.xz Image: Server dvd ppc64le Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20201227.n.0.iso Image: Xfce_Appliance raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20201227.n.0-sda.raw.xz Image: Cloud_Base raw-xz aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20201227.n.0.aarch64.raw.xz Image: Cloud_Base raw-xz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20201227.n.0.x86_64.raw.xz Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201227.n.0.x86_64.vagrant-virtualbox.box Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20201227.n.0.iso Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20201227.n.0.x86_64.tar.gz Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20201227.n.0.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20201227.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20201227.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20201227.n.0.iso Image: Server boot armhfp Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-Rawhide-20201227.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20201227.n.0.iso Image: Server boot aarch64 Path: Server/aarch64/iso/Fedora-Server-netinst-aarch64-Rawhide-20201227.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20201227.n.0.iso Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20201227.n.0.iso Image: Server_Appliance raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-armhfp-Rawhide-20201227.n.0-sda.raw.xz Image: Everything boot armhfp Path: Everything/armhfp/iso/Fedora-Everything-netinst-armhfp-Rawhide-20201227.n.0.iso Image
Re: Popularity contest for Fedora
On 27.12.2020 19:44, clime wrote: I think we can simply parse server-side access logs to count package downloads, no? On every third-party mirror? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Popularity contest for Fedora
On Sun, 27 Dec 2020 at 17:41, Gary Buhrmaster wrote: > > On Sun, Dec 27, 2020 at 3:12 PM Matthew Miller > wrote: > > > It's been talked about before but no one has done it. > > There was also smolt, which collected some > system information (and could be extended > to collect more) However, not only did the > upstream die, follow-on proposals never > took off, and also opened the entire > can-of-worms regarding an opt-in data > collection mechanism (and it was agreed > by most it had to be opt-in) not being able to > provide useful data to actually make good > decisions on. It is also true that many wish > we did have sufficiently good data in order > to make good decisions. Rock, meet hard > place. I think we can simply parse server-side access logs to count package downloads, no? It won't be probably very precise but could be enough to give us a basic idea... clime > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libmemcached replacement
On Tue, 22 Dec 2020 at 10:55, Remi Collet wrote: > > Hi, > > libmemcached exists in Fedora for years and is used by lot of projects > to handle communication with a memcached server. > > Sadly this project is dead: > https://launchpad.net/libmemcached/ > > Last version released in 2014 > and nearly no git activity since this > > > A fork now exists > https://github.com/m6w6/libmemcached/ > > Version 1.1.0beta1 is released and is design to > be a drop in replacement, with API and ABI compatibility > > > I've start working on a package update > and this will probably become the new upstream > for the fedora libmemcached package > > > Comment / idea ? For me, the biggest issue always is that I don't know if I should pick php-memcache or php-memcached plugin...is there any recommendation regarding this? Thank you! clime > > > Remi > > > P.S. of course, I'm mostly interested by the the PHP extension > which uses it https://pecl.php.net/package/memcached > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Popularity contest for Fedora
On Sun, Dec 27, 2020 at 3:12 PM Matthew Miller wrote: > It's been talked about before but no one has done it. There was also smolt, which collected some system information (and could be extended to collect more) However, not only did the upstream die, follow-on proposals never took off, and also opened the entire can-of-worms regarding an opt-in data collection mechanism (and it was agreed by most it had to be opt-in) not being able to provide useful data to actually make good decisions on. It is also true that many wish we did have sufficiently good data in order to make good decisions. Rock, meet hard place. ___ 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 Screnshots
.El dom, 27 dic 2020 a las 12:11, Matthew Miller () escribió: > On Sat, Dec 26, 2020 at 09:48:56PM -0300, Sergio Belkin wrote: > > I was taking a look at /etc/appstream.conf and I see there is a > screenshot > > website for Debian and Ubuntu: > > ``` > > [debian] > > ScreenshotUrl=http://screenshots.debian.net > > > > [opensuse] > > ScreenshotUrl=http://software.opensuse.org/package > > ``` > > The openSUSE one does not appear to actually be screenshots, but a package > search. We had something like that before and AIUI a new one is in the > works. Great, the openSUSE is a package search, but it seems that most GUI packages have screenshots. I was surprised that this files has links to another distros, but I've found that appstream.conf has the same content in its sources. I guess because appstream is distro-agnostic. AFAIK, appstream gets screenshots from each of the upstream projects. > But it wasn't screenshot focused. We don't have that, but it's > traditional for Fedora Marketing to make a wiki page for each release, > like: > > https://fedoraproject.org/wiki/F33_screenshots_library > Nice! > > > -- > Matthew Miller > > Fedora Project Leader > ___ > -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libmemcached replacement
On Wed, Dec 23, 2020 at 4:47 PM Remi Collet wrote: > > Le 22/12/2020 à 10:55, Remi Collet a écrit : > > I've start working on a package update > > and this will probably become the new upstream > > for the fedora libmemcached package > > A scratch build is available > https://koji.fedoraproject.org/koji/taskinfo?taskID=58118722 > > From my local tests, everything seems OK and compatible with 1.0.18 If the fork is essentially a "quasi-official" continuation of a dead project, and it's API / ABI compatible, then I'd say using the new one instead of the dead one is a good idea. :+1: Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Popularity contest for Fedora
On Sat, Dec 26, 2020 at 05:33:39PM -0600, Ron Olson wrote: > Has anything like this been considered for Fedora? It would actually > be kind of nice to see installation statistics of my packages, if > only to determine if I’m the only one using them. :) It's been talked about before but no one has done it. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Screnshots
On Sat, Dec 26, 2020 at 09:48:56PM -0300, Sergio Belkin wrote: > I was taking a look at /etc/appstream.conf and I see there is a screenshot > website for Debian and Ubuntu: > ``` > [debian] > ScreenshotUrl=http://screenshots.debian.net > > [opensuse] > ScreenshotUrl=http://software.opensuse.org/package > ``` The openSUSE one does not appear to actually be screenshots, but a package search. We had something like that before and AIUI a new one is in the works. But it wasn't screenshot focused. We don't have that, but it's traditional for Fedora Marketing to make a wiki page for each release, like: https://fedoraproject.org/wiki/F33_screenshots_library -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
On Sat, Dec 26, 2020 at 6:14 PM Kevin Fenzi wrote: > > On Thu, Dec 24, 2020 at 07:32:04AM +, Dridi Boukelmoune wrote: > > > The weakest point in the current system is really the FAS password. If > > > you have a packager's FAS password you can change the ssh key > > > associated with the account to another that you control, and the FAS > > > password is also all you need to run a build and submit it to Bodhi. > > Well, really the weakest point is email. If you have control over a fas > accounts email address you can reset the password, etc. > > > Or you add an SSH key without removing the maintainer's keys on the > > off chance that it would go unnoticed... > > fas sends email on every such change. There are situations where notifications could go unnoticed. At this point if an attacker managed to compromise an email address and add an SSH key to a fas account, the attacker might also delete the notification email promptly. Dridi ___ 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: Popularity contest for Fedora
On 27.12.2020 00:33, Ron Olson wrote: Has anything like this been considered for Fedora? It would actually be kind of nice to see installation statistics of my packages, if only to determine if I’m the only one using them. :) Telemetry and user tracking are evil. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1910040] perl-CatalystX-SimpleLogin-0.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1910040 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-CatalystX-SimpleLogin- ||0.21-1.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-12-27 11:06:44 --- Comment #1 from Emmanuel Seyman --- Build for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1662316 -- 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 1910956] perl-Net-POP3S-0.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1910956 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Net-POP3S-0.12-1.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-12-27 11:06:26 --- Comment #1 from Emmanuel Seyman --- Build for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1662319 -- 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 1911027] perl-Term-ReadLine-Gnu-1.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1911027 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Term-ReadLine-Gnu-1.37 ||-1.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-12-27 11:05:28 --- Comment #1 from Emmanuel Seyman --- Build for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1662339 -- 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: Stale proven packagers
On Sat, Dec 26, 2020 at 10:54 PM Björn Persson wrote: > > Gary Buhrmaster wrote: > > Arguably those with elevated access (provenpackagers(*)) > > should be required to use a hardware token such > > as a FIDO2 authenticators with biometrics and/or > > PIN required > > I'm in favor of complementing the FAS passphrase with a second factor. > > I'm against any attempt to require biometrics. These are my reasons: He did say and/or and there's been no official proposal for biometrics, and I very much doubt there will be, I don't see the point in it. > · Biometric identifiers aren't cleanly separated from identity. They > are more akin to your username than to your passphrase. A random key or > a passphrase can be revoked and replaced if it gets out. Fingers and > faces are very difficult to replace. And yes they can get out. Once > your fingerprint has been scanned and turned into data, those data can > be copied like any other secret. You also leave your fingerprints on > everything you touch. > > · Such a requirement is unenforceable. A client can never prove to a > server that it has a certain piece of hardware. It can only prove that > it knows a certain secret – or two secrets since we're talking about > two-factor authentication. Whether the secrets are stored on a hard > disk, in a Yubikey, in somebody's brain or in somebody's retina, is > unknown to the server. Before authentication it must be assumed that > the client may be an attacker who is lying about everything they can > lie about. Some protocol might allow the client to claim that it used a > fingerprint reader, but as far as the server knows the attacker might > just be using a stored scan of the real user's fingerprint. > > · Biometrics is low-grade security for use where convenience takes > precedence. If somebody can't remember a good PIN, then it's better for > them to unlock their phone with their fingerprint than to choose "" > for their PIN. Strong crypto keys and hardware tokens are better where > security requirements are higher, like in two-factor authentication. > Requiring biometrics is effectively the same as prohibiting stronger > authentication methods, which is a stupid thing to do. > > Björn Persson > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Stale proven packagers
Il giorno sab, 26/12/2020 alle 23.53 +0100, Björn Persson ha scritto: > Gary Buhrmaster wrote: > > Arguably those with elevated access (provenpackagers(*)) > > should be required to use a hardware token such > > as a FIDO2 authenticators with biometrics and/or > > PIN required > > I'm in favor of complementing the FAS passphrase with a second > factor. > > I'm against any attempt to require biometrics. These are my reasons: I totally agree with you, for the reasons you explained below. > · Biometric identifiers aren't cleanly separated from identity. They > are more akin to your username than to your passphrase. A random key > or > a passphrase can be revoked and replaced if it gets out. Fingers and > faces are very difficult to replace. And yes they can get out. Once > your fingerprint has been scanned and turned into data, those data > can > be copied like any other secret. You also leave your fingerprints on > everything you touch. > > · Such a requirement is unenforceable. A client can never prove to a > server that it has a certain piece of hardware. It can only prove > that > it knows a certain secret – or two secrets since we're talking about > two-factor authentication. Whether the secrets are stored on a hard > disk, in a Yubikey, in somebody's brain or in somebody's retina, is > unknown to the server. Before authentication it must be assumed that > the client may be an attacker who is lying about everything they can > lie about. Some protocol might allow the client to claim that it used > a > fingerprint reader, but as far as the server knows the attacker might > just be using a stored scan of the real user's fingerprint. > > · Biometrics is low-grade security for use where convenience takes > precedence. If somebody can't remember a good PIN, then it's better > for > them to unlock their phone with their fingerprint than to choose > "" > for their PIN. Strong crypto keys and hardware tokens are better > where > security requirements are higher, like in two-factor authentication. > Requiring biometrics is effectively the same as prohibiting stronger > authentication methods, which is a stupid thing to do. Guido Aulisi 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
Fedora-Cloud-32-20201227.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) ID: 747214 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/747214 ID: 747221 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/747221 Passed openQA tests: 6/7 (x86_64), 6/7 (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
