date:20230126



Dne 25. 01. 23 v 19:53 Adam Williamson napsal(a):

On Wed, 2023-01-25 at 10:30 -0800, Adam Williamson wrote:

The second issue is that systems that update to systemd-253~rc1-1.fc38
seem to get stuck on boot. With Plymouth enabled you just see the
splash screen. With it disabled (or by pressing esc) it seems to be
stuck at "Stopped initrd-switch-root.service - Switch Root.". I'm still
looking into this one, but it's happened to a lot of openQA tests and I
was able to confirm it first try in a local VM, by installing from the
20230123.n.0 compose then updating systemd and rebooting. Fresh
installs with the newer systemd seem to be OK, at least most openQA
tests for the new compose passed - it seems to be only updating an
existing install that has the problem, at least so far.

I've now filed this as
https://bugzilla.redhat.com/show_bug.cgi?id=2164594 .



Just FTR, this is very likely duplicate of:

https://bugzilla.redhat.com/show_bug.cgi?id=2164404


Vít



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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bootstrapping package with circular dependencies in koji

Dne 25. 01. 23 v 19:34 Kevin Fenzi napsal(a):

On Wed, Jan 25, 2023 at 03:45:35PM +0100, Jaroslav Skarvada wrote:

On Wed, Jan 25, 2023 at 12:13 PM Miro Hrončok wrote:

On 25. 01. 23 11:50, Vít Ondruch wrote:

Reading the thread, I was afraid this will be the end result. Nevertheless,
given this would be used just for side-tags, is there a chance to exclude side
tags from the policy? Who would handle such request?

I thought we had already done this, but it seems not.

I am not 100% koji has the needed policy for this, so I'd say file the
issue first as a koji issue and once we can allow/disallow this via
policy we can allow it for sidetags... but see below.

Although being able to modify one macro means also possibility to edit all
macros. Not sure this is desired. However one can achieve almost everything by
changing .spec file, so that should not be blocker IMHO.

Or add an option that will mark/unmark the sidetag for bootstrapping,
i.e. option that will add only this specific bootstrap macro to the
sidetag and nothing more.

Yeah, that would be better than allowing all tag options to be set.

I think the "commit the bootstrap conditional directly to bootstrap something"
approach is much more transparent than "fiddling with macros in Koji to save
myself one tiny commit" anyway.

It's one commit per package. If you rebuild more packages there may be
more things that need bootstrapping.

Also: commits to reverse the horrible with/without syntax are error
prone. If we can avoid doing them, we can probibly avoid some mistakes.

To answer the original question, it can be done like this:

1. commit all commits and push them all
2. fedpkg request-side-tag
3. koji chain-build --nowait f38-build-side-6
'git+https://src.fedoraproject.org/rpms/python3.12.git#fe95b37f25338c94bcfa2fb653e53b5262ec2812'
: ..instert mid deps here... :
'git+https://src.fedoraproject.org/rpms/python3.12.git#1bc45ffecb2b268fb56fbdc61ceb0ff429168d19'

If there already are the boostrap conditionals in the specs the logic
progress is to have some support in the infra. Just manually reverting
the condition in the spec is, let's say not the optimal solution. Just
my two cents.

I personally agree.

I think ideally koji would allow us to allow/deny changing taginfo to
side tags, and even better allow/deny changing just bootstrap=1.

I have opened this Koji ticket:

https://pagure.io/koji/issue/3669

Lets see what happens.

Vít

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, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired in February

2023-01-26 Thread Miro Hrončok


On 26. 01. 23 4:51, Yaakov Selkowitz wrote:

On Tue, 2023-01-24 at 15:55 +0100, Miro Hrončok wrote:

Based on the current fail to build from source policy, the following
packages
should be retired from Fedora 38 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 2 weeks, i.e. around 2023-02-08.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f38.

Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


Why isn't automatic orphaning at the beginning of this countdown part of this
policy, so that others have the chance to take and fix the package?  If
someone (other than the maintainer, who should already be well aware) were to
just now notice that one of these packages were about to be retired, there
isn't really enough time to go through the BZ route to get it orphaned first.


That is a good question.

The original idea is that FTBFS packages are orphaned when the maintainers 
don't respond to the FTBFS bugzillas. But many do set the bugzillas to ASSIGNED 
to avoid the orphaning or sometimes the FTBFS bugzillas are closed in mistake 
or not opened at all.


I suppose orphaning the packages first would make perfect sense, but the devil 
is in the details. I suppose packagers might feel bad if suddenly "their" 
packages are orphaned without any reminder or warning of some sort. So we would 
need to modify the policy from:


1. warn
2. warn
3. warn
4. warn
5. warn
6. retire

To something like:

1. warn
2. warn
3. warn
4. orphan
5. warn
6. warn
7. warn
8. retire

And make the process much longer. And we would need to figure out what to do if 
the package is taken (unorphaned) in between 4. and 8. without being fixed.



I am deliberately avoiding the option to modify the policy to:

1. warn
2. warn
3. warn
4. warn
5. warn
6. orphan
7. wait
8. wait
9. wait
10. wait
11. wait
12. retire via the orphan policy

Because folks will take the packages (and not fix them) between 6. and 12. -- 
it is often done by the previous maintainers (I don't really understand why) or 
by new maintainers who take the package without realizing they have been 
orphaned due to FTBFS.




free42   brouhaha
gtkhash  nonamedotc
kguitar  davidcornette
kjots    kde-sig, thunderbirdtr
kmplayer moceap, rdieter
libmobi  avsej
xml-security-c   bruno, kloczek


PRs have been posted for these.



Thanks. Since this is all done by a human you can just give me a definitive lit 
of package you want to maintain instead of letting them be retired and I can 
assign them to you and let you merge the PRs instead of retiring them. That 
offer stands for anybody.


However, note that I would very much prefer if you followed the nonresponsive 
maintainer policy -- that way other packages might become available to 
responsive maintainers.


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora 38 Rawhide 20230126.n.0 nightly compose nominated for testing

2023-01-26 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora 38 Rawhide 20230126.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 - 20230121.n.0: anaconda-38.17-1.fc38.src, 20230126.n.0: 
anaconda-38.18-1.fc38.src
python-blivet - 20230121.n.0: python-blivet-3.6.1-1.fc38.src, 20230126.n.0: 
python-blivet-3.6.1-2.fc38.src
parted - 20230121.n.0: parted-3.5-7.fc38.src, 20230126.n.0: 
parted-3.5-8.fc38.src
pykickstart - 20230121.n.0: pykickstart-3.43-1.fc38.src, 20230126.n.0: 
pykickstart-3.43-2.fc38.src
lorax - 20230121.n.0: lorax-38.4-2.fc38.src, 20230126.n.0: lorax-38.4-3.fc38.src
pungi - 20230121.n.0: pungi-4.3.7-1.fc38.src, 20230126.n.0: 
pungi-4.3.7-2.fc38.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/38

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_38_Rawhide_20230126.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230126.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230126.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230126.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230126.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230126.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20230126.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, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: (Fixed) Re: Most OCaml packages have broken deps now

2023-01-26 Thread Richard W.M. Jones

On Wed, Jan 25, 2023 at 02:36:56PM -0700, Jerry James wrote:
> On Wed, Jan 25, 2023 at 2:43 AM Richard W.M. Jones  wrote:
> > I think we're fixed now.  Here is the side tag & Bodhi update:
> 
> Thank you for taking care of that.
> 
> > - I have added support for rpmautospec
> 
> That's great.
> 
> > - There is now a cyclic dependency between ocaml-pp and ocaml-dune,
> >   which I have broken by hand, but we should try to avoid it in future
> >   if possible.
> 
> Well, that was an experiment, as you and I discussed starting here:
> https://bugzilla.redhat.com/show_bug.cgi?id=2101964#c1.  Apparently,
> the result is "that doesn't work".  Thanks for fixing.

Ah right, I'd forgotten about that.

Dune is a strange package because it's mainly just a program
(/usr/bin/dune).  But we sometimes use it by installing
ocaml-dune-configurator{,-devel}.  Because these packages install some
libraries ("Configurator") it gets the full OCaml dependency hashes:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=33297545

I'm not sure if in every case where we use ocaml-dune-configurator* we
really need that, or could just use /usr/bin/dune instead.  That would
avoid difficult dependency loops.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20230126.n.0 changes

2023-01-26 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20230125.n.0
NEW: Fedora-Rawhide-20230126.n.0

= SUMMARY =
Added images:5
Dropped images:  4
Added packages:  8
Dropped packages:1
Upgraded packages:   287
Downgraded packages: 1

Size of added packages:  9.18 MiB
Size of dropped packages:62.59 KiB
Size of upgraded packages:   8.62 GiB
Size of downgraded packages: 10.12 MiB

Size change of upgraded packages:   426.46 MiB
Size change of downgraded packages: 17.45 KiB

= ADDED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20230126.n.0.ppc64le.tar.xz
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-Rawhide-20230126.n.0.aarch64.raw.xz
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230126.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230126.n.0.iso
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20230126.n.0.ppc64le.tar.xz

= DROPPED IMAGES =
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20230125.n.0.x86_64.vagrant-libvirt.box
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20230125.n.0.aarch64.raw.xz
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20230125.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20230125.n.0.iso

= ADDED PACKAGES =
Package: libunistring1.0-1.0-1.fc38
Summary: Compatibility version of GNU Unicode string library
RPMs:libunistring1.0
Size:2.69 MiB

Package: rust-indicatif0.16-0.16.2-1.fc38
Summary: Progress bar and cli reporting library for Rust
RPMs:rust-indicatif0.16+default-devel 
rust-indicatif0.16+improved_unicode-devel rust-indicatif0.16+rayon-devel 
rust-indicatif0.16+unicode-segmentation-devel 
rust-indicatif0.16+unicode-width-devel rust-indicatif0.16+with_rayon-devel 
rust-indicatif0.16-devel
Size:89.73 KiB

Package: rust-portable-atomic-1.0.0-1.fc38
Summary: Portable atomic types including support for 128-bit atomics, atomic 
float, etc
RPMs:rust-portable-atomic+critical-section-devel 
rust-portable-atomic+default-devel rust-portable-atomic+fallback-devel 
rust-portable-atomic+float-devel rust-portable-atomic+serde-devel 
rust-portable-atomic+std-devel rust-portable-atomic-devel
Size:129.10 KiB

Package: rust-portpicker-0.1.1-1.fc38
Summary: Pick a free unused port
RPMs:rust-portpicker+default-devel rust-portpicker-devel
Size:17.27 KiB

Package: rust-sptr-0.3.2-1.fc38
Summary: Sptr: The Strict Provenance Polyfill
RPMs:rust-sptr+default-devel rust-sptr+opaque_fn-devel rust-sptr+uptr-devel 
rust-sptr-devel
Size:46.38 KiB

Package: rust-vt100-0.15.1-1.fc38
Summary: Library for parsing terminal data
RPMs:rust-vt100+default-devel rust-vt100-devel
Size:38.76 KiB

Package: rust-yrs-0.12.2-1.fc38
Summary: High performance implementation of the Yjs CRDT
RPMs:rust-yrs+default-devel rust-yrs-devel
Size:5.74 MiB

Package: vo-amrwbenc-0.1.3-18.fc38
Summary: VisualOn AMR-WB encoder library
RPMs:vo-amrwbenc vo-amrwbenc-devel
Size:458.05 KiB


= DROPPED PACKAGES =
Package: perl-Devel-GlobalDestruction-XS-0.03-24.fc38
Summary: Faster implementation of the Devel::GlobalDestruction API
RPMs:perl-Devel-GlobalDestruction-XS
Size:62.59 KiB


= UPGRADED PACKAGES =
Package:  R-qtl-1.58-1.fc38
Old package:  R-qtl-1.52-4.fc38
Summary:  Tools for analyzing QTL experiments
RPMs: R-qtl
Size: 21.68 MiB
Size change:  363 B
Changelog:
  * Wed Jan 25 2023 Mattias Ellert  - 1.58-1
  - Update to 1.58
  - Workaround broken openblas on aarch64 in RHEL 8 and 9


Package:  alt-ergo-2.3.3-5.fc38
Old package:  alt-ergo-2.3.3-4.fc38
Summary:  Automated theorem prover including linear arithmetic
RPMs: alt-ergo alt-ergo-gui ocaml-alt-ergo-lib ocaml-alt-ergo-lib-devel 
ocaml-alt-ergo-parsers ocaml-alt-ergo-parsers-devel
Size: 93.59 MiB
Size change:  7.78 KiB
Changelog:
  * Tue Jan 24 2023 Richard W.M. Jones  - 2.3.3-5
  - Rebuild OCaml packages for F38


Package:  ansible-collection-ansible-posix-1.5.1-1.fc38
Old package:  ansible-collection-ansible-posix-1.4.0-3.fc38
Summary:  Ansible Collection targeting POSIX and POSIX-ish platforms
RPMs: ansible-collection-ansible-posix
Size: 116.40 KiB
Size change:  -33.97 KiB
Changelog:
  * Tue Jan 24 2023 Maxwell G  - 1.5.1-1
  - Update to 1.5.1. Fixes rhbz#2162988.


Package:  ansible-collection-community-docker-3.4.0-1.fc38
Old package:  ansible-collection-community-docker-3.3.2-2.fc38
Summary:  Ansible modules and plugins for working with Docker
RPMs

Re: Some heads-ups for Rawhide users: python3-ptyprocess and systemd issues

2023-01-26 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Jan 26, 2023 at 09:29:22AM +0100, Vít Ondruch wrote:
>
> Dne 25. 01. 23 v 19:53 Adam Williamson napsal(a):
> > On Wed, 2023-01-25 at 10:30 -0800, Adam Williamson wrote:
> > > The second issue is that systems that update to systemd-253~rc1-1.fc38
> > > seem to get stuck on boot. With Plymouth enabled you just see the
> > > splash screen. With it disabled (or by pressing esc) it seems to be
> > > stuck at "Stopped initrd-switch-root.service - Switch Root.". I'm still
> > > looking into this one, but it's happened to a lot of openQA tests and I
> > > was able to confirm it first try in a local VM, by installing from the
> > > 20230123.n.0 compose then updating systemd and rebooting. Fresh
> > > installs with the newer systemd seem to be OK, at least most openQA
> > > tests for the new compose passed - it seems to be only updating an
> > > existing install that has the problem, at least so far.
> > I've now filed this as
> > https://bugzilla.redhat.com/show_bug.cgi?id=2164594 .

Quoting the commit in dist-git:
The socket exists and is enabled in the initrd. After switch-root, the 
system
goes into an infinite loop trying to stop the socket while incoming audit
messages trigger start jobs for the socket. This is a bug in the transaction
logic, that'll need to be fixed separately.

We need to preset the socket after the upgrade so that it remains enabled
by default. This should fix the boot issue, though it's not a complete fix,
because we actually want to allow people to disable the socket.

On initial install, the socket is covered by preset-all and gets enabled.

This explains why the issue was observed on upgraded systems, but not
on fresh installations.

The issue should now be resolved in rawhide because the socket will be
enabled again. But the issue with pid1 not handling this is a real
problem that we should solve regardless, see
https://github.com/systemd/systemd/issues/26216.

> Just FTR, this is very likely duplicate of:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2164404

I *think* that those are separate issues. I'm having trouble with
a combination of systemd-253~rc1 and the 6.2.0.rc4 kernel.
udev is unhappy.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Kevin Kofler via devel

Adam Williamson wrote:
> OTOH, it's not reasonable to dictate to the person maintaining a Fedora
> package whether they should think that's a reasonable use of their time
> or not. The current maintainers of Bottles decided they trust the
> upstream developers to distribute their software 'properly' and thus
> didn't want to dedicate their time to maintaining the package any more;
> that's entirely their decision to make.

Sure, but they should not be allowed to directly retire the package in such 
a case, only to orphan it.

> Of course, it should still be the case that someone who still sees
> value in distribution packaging of bottles can take the package over if
> they want to, as Pete Walter has already asked to do.

Which is why the package must be orphaned, not retired.

IMHO, retiring a Fedora package in favor of an upstream binary of whatever 
kind (Flatpak, Snap, AppImage, RPM, binary tarball, whatever) is a major 
disservice to Fedora users and defeats the whole point of having a 
distribution to begin with.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some heads-ups for Rawhide users: python3-ptyprocess and systemd issues

2023-01-26 Thread Florian Weimer

* Adam Williamson:

> 6 (__libc_message.cold+0x5) [0x7fbae3c2560f]
> Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 6: 
> /lib64/libc.so.6 (malloc_printerr+0x15) [0x7fbae3c96a05]
> Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 7: 
> /lib64/libc.so.6 (_int_free+0x9e5) [0x7fbae3c98de5]
> Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 8: 
> /lib64/libc.so.6 (__libc_free+0x7e) [0x7fbae3c9b42e]
> Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 9: 
> /usr/lib64/dri/zink_dri.so (__driDriverGetExtensions_zink+0x9e70) 
> [0x7fbad82b8180]
> Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 10: 
> /lib64/libgbm.so.1 (gbm_format_get_name+0xe81) [0x7fbae3229361]
> Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 11: 
> /lib64/libgbm.so.1 (gbm_format_get_name+0x1018) [0x7fbae32294f8]
> Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 12: 
> /lib64/libgbm.so.1 (gbm_format_get_name+0x121a) [0x7fbae32296fa]

I saw this during the latest glibc update, but given that the update
wasn't tested in isolation, I waived it through because the update
addresses the known sprintf issue.

I'm not aware of anything in glibc this might have caused this.  The
crashes related to -D_FORTIFY_SOURCE=3 look different (they try to crash
before causing heap corruption!), and it's not the sprintf assertion
failure in __printf_buffer_as_file_commit, either.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Fedocal] Reminder meeting : ELN SIG

2023-01-26 Thread sgallagh

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2023-01-27 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10133/

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Release monitoring for stable releases only

2023-01-26 Thread Jaroslav Skarvada

Hi,

it seems Anitya correctly distinguishes stable and pre-release
releases but where to set that I want Fedora bugs only for the stable
releases? IIRC Pagure had a switch for it, but I am unable to find it
on the https://src.fedoraproject.org/rpms/. There is only
"No-Monitoring", "Monitoring", and "Monitoring and scratch builds". It
seems there is no information about it in the docs [1]

thanks & regards

Jaroslav

[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Release monitoring for stable releases only

On Thu, Jan 26, 2023 at 7:02 AM Jaroslav Skarvada  wrote:
>
> Hi,
>
> it seems Anitya correctly distinguishes stable and pre-release
> releases but where to set that I want Fedora bugs only for the stable
> releases? IIRC Pagure had a switch for it, but I am unable to find it
> on the https://src.fedoraproject.org/rpms/. There is only
> "No-Monitoring", "Monitoring", and "Monitoring and scratch builds". It
> seems there is no information about it in the docs [1]
>

You configure it on release-monitoring.org for the upstream project,
not src.fedoraproject.org.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Release monitoring for stable releases only

2023-01-26 Thread Jaroslav Skarvada

On Thu, Jan 26, 2023 at 1:09 PM Neal Gompa  wrote:
>
> On Thu, Jan 26, 2023 at 7:02 AM Jaroslav Skarvada  wrote:
> >
> > Hi,
> >
> > it seems Anitya correctly distinguishes stable and pre-release
> > releases but where to set that I want Fedora bugs only for the stable
> > releases? IIRC Pagure had a switch for it, but I am unable to find it
> > on the https://src.fedoraproject.org/rpms/. There is only
> > "No-Monitoring", "Monitoring", and "Monitoring and scratch builds". It
> > seems there is no information about it in the docs [1]
> >
>
> You configure it on release-monitoring.org for the upstream project,
> not src.fedoraproject.org.

Where? The release-monitoring.org / Anitya correctly marks it as a
pre-release but the bug is still created. There is only a "Pre-release
filter" box, but I think it's a helper if the default regex doesn't
work, which in my case seems to work

Jaroslav
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:
> 
> Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):
> > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch 
> > wrote:
> > > I am not user of Bottles so I won't complain about this
> > > particular case,
> > > but the push towards (upstream) Flatpaks is unfortunate :/
> > Can you elaborate on why you feel that way?
> 
> 
> I don't trust upstream Flatpacks. I don't trust they follow any
> standard 
> except standard of their authors.

I maintain both packages in Fedora and flatpaks on Flathub, so I can
compare. The review to get an app to Flathub was as thorough as Fedora
package review. In some ways even stricter. It's not like "it builds,
it runs, you're good to go". They care about some standards, about
builds being verifiable etc.
The Flathub CI seems to be more extensive than what we have in Fedora. 

> And I don't like Flatpacks, because their main advantage (their 
> isolation) is also their biggest disadvantage. There can't be both 
> without making compromises. If I am not mistaken, the isolation is
> also 
> mostly myth, because it is disabled in most cases.

Why? Apps come with permissions they require (which you can override
btw). Just because some apps require access to your whole filesystem
doesn't mean the isolation is a myth. You know the permissions, you may
decide not to use such an app. None of the flatpaks maintained by me
require this kind of access and are well isolated.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Anitya [release-monitoring.org] 1.7.0

2023-01-26 Thread Michal Konecny


Hi everyone,

the new version of Anitya [0] (1.7.0) is deployed on production.

The major change in this version is the migration to Bootstrap 5 [1], 
this means that there is a new design of Anitya.

It also helped to unify the page design in Anitya.

The reason to move to Bootstrap 5 was the change of dependency 
management for CSS and javascript packages. Anitya is now using npm [2] 
for management of those packages and the old version of Bootstrap 
package was not available on npm

anymore.

I hope you will like the new design. :-)

The full changelog can be found in the release page on GitHub [3].

Michal
Mage from release-monitoring.org

[0] - https://release-monitoring.org
[1] - https://getbootstrap.com/
[2] - https://www.npmjs.com/
[3] - https://github.com/fedora-infra/anitya/releases/tag/1.7.0
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

On Thu, Jan 26, 2023 at 7:43 AM Jiri Eischmann  wrote:
>
> Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:
> >
> > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):
> > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch 
> > > wrote:
> > > > I am not user of Bottles so I won't complain about this
> > > > particular case,
> > > > but the push towards (upstream) Flatpaks is unfortunate :/
> > > Can you elaborate on why you feel that way?
> >
> >
> > I don't trust upstream Flatpacks. I don't trust they follow any
> > standard
> > except standard of their authors.
>
> I maintain both packages in Fedora and flatpaks on Flathub, so I can
> compare. The review to get an app to Flathub was as thorough as Fedora
> package review. In some ways even stricter. It's not like "it builds,
> it runs, you're good to go". They care about some standards, about
> builds being verifiable etc.
> The Flathub CI seems to be more extensive than what we have in Fedora.
>

All of that is optional in Flathub too. That makes it inherently
weaker. Firefox doesn't go through that, nor does OBS Studio.

> > And I don't like Flatpacks, because their main advantage (their
> > isolation) is also their biggest disadvantage. There can't be both
> > without making compromises. If I am not mistaken, the isolation is
> > also
> > mostly myth, because it is disabled in most cases.
>
> Why? Apps come with permissions they require (which you can override
> btw). Just because some apps require access to your whole filesystem
> doesn't mean the isolation is a myth. You know the permissions, you may
> decide not to use such an app. None of the flatpaks maintained by me
> require this kind of access and are well isolated.
>

How are people supposed to figure out you can change app permissions?
It's described precisely nowhere. For GNOME in particular, there's no
way to review and update app permissions (either to open them up or
close them further). KDE Plasma is getting this capability with KDE
Plasma 5.27.

And Flatseal (a third party app that someone has to figure out exists)
isn't a valid answer. Just like how customizing GNOME using Tweaks
isn't a valid answer. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Robert Marcano via devel

On 1/26/23 8:42 AM, Jiri Eischmann wrote:

Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:

Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):

On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch
wrote:

I am not user of Bottles so I won't complain about this
particular case,
but the push towards (upstream) Flatpaks is unfortunate :/

Can you elaborate on why you feel that way?

I don't trust upstream Flatpacks. I don't trust they follow any
standard
except standard of their authors.

I maintain both packages in Fedora and flatpaks on Flathub, so I can
compare. The review to get an app to Flathub was as thorough as Fedora
package review. In some ways even stricter. It's not like "it builds,
it runs, you're good to go". They care about some standards, about
builds being verifiable etc.

That doesn't seems to be enforced because many builds scripts just
download binaries built by other projects, for example;

https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89

Note: building the entire pandoc and TeX toolchain is very hard and I
understand this example packager decision, but It doesn't make more
trustful that version that one on Fedora.

The Flathub CI seems to be more extensive than what we have in Fedora.

And I don't like Flatpacks, because their main advantage (their
isolation) is also their biggest disadvantage. There can't be both
without making compromises. If I am not mistaken, the isolation is
also
mostly myth, because it is disabled in most cases.

Why? Apps come with permissions they require (which you can override
btw). Just because some apps require access to your whole filesystem
doesn't mean the isolation is a myth. You know the permissions, you may
decide not to use such an app. None of the flatpaks maintained by me
require this kind of access and are well isolated.

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, report it:
https://pagure.io/fedora-infrastructure/new_issue

___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

Neal Gompa píše v Čt 26. 01. 2023 v 07:51 -0500:
> On Thu, Jan 26, 2023 at 7:43 AM Jiri Eischmann 
> wrote:
> > 
> > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:
> > > 
> > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):
> > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch
> > > > 
> > > > wrote:
> > > > > I am not user of Bottles so I won't complain about this
> > > > > particular case,
> > > > > but the push towards (upstream) Flatpaks is unfortunate :/
> > > > Can you elaborate on why you feel that way?
> > > 
> > > 
> > > I don't trust upstream Flatpacks. I don't trust they follow any
> > > standard
> > > except standard of their authors.
> > 
> > I maintain both packages in Fedora and flatpaks on Flathub, so I
> > can
> > compare. The review to get an app to Flathub was as thorough as
> > Fedora
> > package review. In some ways even stricter. It's not like "it
> > builds,
> > it runs, you're good to go". They care about some standards, about
> > builds being verifiable etc.
> > The Flathub CI seems to be more extensive than what we have in
> > Fedora.
> > 
> 
> All of that is optional in Flathub too. That makes it inherently
> weaker. Firefox doesn't go through that, nor does OBS Studio.
> 
> > > And I don't like Flatpacks, because their main advantage (their
> > > isolation) is also their biggest disadvantage. There can't be
> > > both
> > > without making compromises. If I am not mistaken, the isolation
> > > is
> > > also
> > > mostly myth, because it is disabled in most cases.
> > 
> > Why? Apps come with permissions they require (which you can
> > override
> > btw). Just because some apps require access to your whole
> > filesystem
> > doesn't mean the isolation is a myth. You know the permissions, you
> > may
> > decide not to use such an app. None of the flatpaks maintained by
> > me
> > require this kind of access and are well isolated.
> > 
> 
> How are people supposed to figure out you can change app permissions?
> It's described precisely nowhere. For GNOME in particular, there's no
> way to review and update app permissions (either to open them up or
> close them further). KDE Plasma is getting this capability with KDE
> Plasma 5.27.

I mentioned overriding the permissions only as a side note. I don't
think it's something that necessarily has to be advertised to users,
simply because it can break apps.
However, any user can review the permission beforehand and decide
whether they're OK with them or not. That's well advertised in GNOME
Software and KDE Discover already.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400:
> On 1/26/23 8:42 AM, Jiri Eischmann wrote:
> > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:
> > > 
> > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):
> > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch
> > > > 
> > > > wrote:
> > > > > I am not user of Bottles so I won't complain about this
> > > > > particular case,
> > > > > but the push towards (upstream) Flatpaks is unfortunate :/
> > > > Can you elaborate on why you feel that way?
> > > 
> > > 
> > > I don't trust upstream Flatpacks. I don't trust they follow any
> > > standard
> > > except standard of their authors.
> > 
> > I maintain both packages in Fedora and flatpaks on Flathub, so I
> > can
> > compare. The review to get an app to Flathub was as thorough as
> > Fedora
> > package review. In some ways even stricter. It's not like "it
> > builds,
> > it runs, you're good to go". They care about some standards, about
> > builds being verifiable etc.
> 
> That doesn't seems to be enforced because many builds scripts just 
> download binaries built by other projects, for example;
> 
> https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89
> 
> Note: building the entire pandoc and TeX toolchain is very hard and I
> understand this example packager decision, but It doesn't make more 
> trustful that version that one on Fedora.
> > 
Flathub is definitely more flexible at that. I was involved in the deal
with Mozilla which was not willing to do special builds in Flathub
infra since from their point of view it was more secure to use builds
done in their infra and just upload them to Flathub. We still found
having official builds from Mozilla and Mozilla officially endorsing
Flathub more beneficial than having Firefox rebuilt by a 3rd party in
Flathub infra.

But Flathub is still a curated repo. If you want to deviate from
standards you have to justify it, if you're doing something fishy your
flatpak may be taken out. But ultimetaly you have to trust the author,
but that applies to Fedora, too, just to lesser extend.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Vitaly Zaitsev via devel


On 26/01/2023 13:42, Jiri Eischmann wrote:

I maintain both packages in Fedora and flatpaks on Flathub, so I can
compare. The review to get an app to Flathub was as thorough as Fedora
package review. In some ways even stricter. It's not like "it builds,
it runs, you're good to go". They care about some standards, about
builds being verifiable etc.
The Flathub CI seems to be more extensive than what we have in Fedora.


I can't agree. Some links:

- 
https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml#L67-L70
- 
https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L98-L102
- 
https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L149-L152


These popular apps are third-party DEB repacks.

--
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

On Thu, Jan 26, 2023 at 8:25 AM Jiri Eischmann  wrote:
>
> Neal Gompa píše v Čt 26. 01. 2023 v 07:51 -0500:
> > On Thu, Jan 26, 2023 at 7:43 AM Jiri Eischmann 
> > wrote:
> > >
> > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:
> > > >
> > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):
> > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch
> > > > > 
> > > > > wrote:
> > > > > > I am not user of Bottles so I won't complain about this
> > > > > > particular case,
> > > > > > but the push towards (upstream) Flatpaks is unfortunate :/
> > > > > Can you elaborate on why you feel that way?
> > > >
> > > >
> > > > I don't trust upstream Flatpacks. I don't trust they follow any
> > > > standard
> > > > except standard of their authors.
> > >
> > > I maintain both packages in Fedora and flatpaks on Flathub, so I
> > > can
> > > compare. The review to get an app to Flathub was as thorough as
> > > Fedora
> > > package review. In some ways even stricter. It's not like "it
> > > builds,
> > > it runs, you're good to go". They care about some standards, about
> > > builds being verifiable etc.
> > > The Flathub CI seems to be more extensive than what we have in
> > > Fedora.
> > >
> >
> > All of that is optional in Flathub too. That makes it inherently
> > weaker. Firefox doesn't go through that, nor does OBS Studio.
> >
> > > > And I don't like Flatpacks, because their main advantage (their
> > > > isolation) is also their biggest disadvantage. There can't be
> > > > both
> > > > without making compromises. If I am not mistaken, the isolation
> > > > is
> > > > also
> > > > mostly myth, because it is disabled in most cases.
> > >
> > > Why? Apps come with permissions they require (which you can
> > > override
> > > btw). Just because some apps require access to your whole
> > > filesystem
> > > doesn't mean the isolation is a myth. You know the permissions, you
> > > may
> > > decide not to use such an app. None of the flatpaks maintained by
> > > me
> > > require this kind of access and are well isolated.
> > >
> >
> > How are people supposed to figure out you can change app permissions?
> > It's described precisely nowhere. For GNOME in particular, there's no
> > way to review and update app permissions (either to open them up or
> > close them further). KDE Plasma is getting this capability with KDE
> > Plasma 5.27.
>
> I mentioned overriding the permissions only as a side note. I don't
> think it's something that necessarily has to be advertised to users,
> simply because it can break apps.
> However, any user can review the permission beforehand and decide
> whether they're OK with them or not. That's well advertised in GNOME
> Software and KDE Discover already.
>

But we know that people don't read those. We also know that ISVs
cannot generally be trusted with regards to the permissions they set
for their own apps. This is literally why Android and iOS changed
their model. If you want to encourage "upstream Flatpaks", you cannot
do this reasonably with a "trust-developer" mindset, because there is
no longer a check to keep them from doing stupid/malicious things.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a):

Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400:

On 1/26/23 8:42 AM, Jiri Eischmann wrote:

Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:

Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):

On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch

wrote:

I am not user of Bottles so I won't complain about this
particular case,
but the push towards (upstream) Flatpaks is unfortunate :/

Can you elaborate on why you feel that way?

I don't trust upstream Flatpacks. I don't trust they follow any
standard
except standard of their authors.

I maintain both packages in Fedora and flatpaks on Flathub, so I
can
compare. The review to get an app to Flathub was as thorough as
Fedora
package review. In some ways even stricter. It's not like "it
builds,
it runs, you're good to go". They care about some standards, about
builds being verifiable etc.

That doesn't seems to be enforced because many builds scripts just
download binaries built by other projects, for example;

https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89

Note: building the entire pandoc and TeX toolchain is very hard and I
understand this example packager decision, but It doesn't make more
trustful that version that one on Fedora.

Yes, this is good example. I cannot imagine anybody would do the reviews
for the 3rd party libraries. That is the main difference to Fedora,
because there are no 3rd party libraries there.

Flathub is definitely more flexible at that. I was involved in the deal
with Mozilla which was not willing to do special builds in Flathub
infra since from their point of view it was more secure to use builds
done in their infra and just upload them to Flathub. We still found
having official builds from Mozilla and Mozilla officially endorsing
Flathub more beneficial than having Firefox rebuilt by a 3rd party in
Flathub infra.

But Flathub is still a curated repo. If you want to deviate from
standards you have to justify it, if you're doing something fishy your
flatpak may be taken out. But ultimetaly you have to trust the author,
but that applies to Fedora, too, just to lesser extend.

I trust authors of the SW, but I don't trust in their trust to the
libraries they bundle in the Flatpak.

Vít

Re: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Michael Catanzaro

On Thu, Jan 26 2023 at 09:23:35 AM -0500, Neal Gompa 
 wrote:

But we know that people don't read those. We also know that ISVs
cannot generally be trusted with regards to the permissions they set
for their own apps. This is literally why Android and iOS changed
their model. If you want to encourage "upstream Flatpaks", you cannot
do this reasonably with a "trust-developer" mindset, because there is
no longer a check to keep them from doing stupid/malicious things.


I agree, but if we tighten the rules then these apps will just 
disappear. So I'm not sure what to do about it.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Michael Catanzaro



Maybe we can start by filtering out the most outrageous applications: 
anything that uses --filesystem=home, --filesystem=host, or unfiltered 
session bus access. That still leaves plenty of possible sandbox holes, 
but it's better than nothing.


We could do this just in GNOME Software and KDE Discover for starters, 
but it'd probably be confusing for the software centers to show fewer 
apps than Flathub has available. So maybe would be better for the 
software centers to just present the apps as insecure, and try to 
convince Flathub to have them removed.


___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

Vít Ondruch píše v Čt 26. 01. 2023 v 15:37 +0100:
> 
> Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a):
> > Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400:
> > > On 1/26/23 8:42 AM, Jiri Eischmann wrote:
> > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:
> > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):
> > > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch
> > > > > > 
> > > > > > wrote:
> > > > > > > I am not user of Bottles so I won't complain about this
> > > > > > > particular case,
> > > > > > > but the push towards (upstream) Flatpaks is unfortunate
> > > > > > > :/
> > > > > > Can you elaborate on why you feel that way?
> > > > > 
> > > > > I don't trust upstream Flatpacks. I don't trust they follow
> > > > > any
> > > > > standard
> > > > > except standard of their authors.
> > > > I maintain both packages in Fedora and flatpaks on Flathub, so
> > > > I
> > > > can
> > > > compare. The review to get an app to Flathub was as thorough as
> > > > Fedora
> > > > package review. In some ways even stricter. It's not like "it
> > > > builds,
> > > > it runs, you're good to go". They care about some standards,
> > > > about
> > > > builds being verifiable etc.
> > > That doesn't seems to be enforced because many builds scripts
> > > just
> > > download binaries built by other projects, for example;
> > > 
> > > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89
> > > 
> > > Note: building the entire pandoc and TeX toolchain is very hard
> > > and I
> > > understand this example packager decision, but It doesn't make
> > > more
> > > trustful that version that one on Fedora.
> 
> 
> Yes, this is good example. I cannot imagine anybody would do the
> reviews 
> for the 3rd party libraries. That is the main difference to Fedora, 
> because there are no 3rd party libraries there.

But let's not pretend it doesn't happen in Fedora at all. Yes, unlike
on Flathub guidelines rule it out, but in the reality I've seen quite a
few packages with (unacknowledged) bundled libraries in Fedora repos.
The package goes through the initial review, a new version introduces a
new dependency which is not available in the Fedora repo, you don't
want to go through the hassle of introducing and maintaining a new
package, you quietly bundle it.
No source is pristine. It's always a compromise. Flathub is more
flexible in what you can include in the flatpak, but Flatpak mitigates
it by isolation (although it may not be set strict enough for some
apps).

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Release monitoring for stable releases only

2023-01-26 Thread Michal Konecny


This feature is implemented in hotness, which is commenting in Bugzilla.
It's already implemented in dist-git and Pagure as well.
This is now waiting for new version of Pagure to be available in Fedora 
infra,

dist-git with the changes is already available. :-)

You can look at the upcoming monitoring options in the-new-hotness 
documentation [0].


Michal

[0] - https://the-new-hotness.readthedocs.io/en/stable/user-guide.html

On 26. 01. 23 13:38, Jaroslav Skarvada wrote:

On Thu, Jan 26, 2023 at 1:09 PM Neal Gompa  wrote:

On Thu, Jan 26, 2023 at 7:02 AM Jaroslav Skarvada  wrote:

Hi,

it seems Anitya correctly distinguishes stable and pre-release
releases but where to set that I want Fedora bugs only for the stable
releases? IIRC Pagure had a switch for it, but I am unable to find it
on the https://src.fedoraproject.org/rpms/. There is only
"No-Monitoring", "Monitoring", and "Monitoring and scratch builds". It
seems there is no information about it in the docs [1]


You configure it on release-monitoring.org for the upstream project,
not src.fedoraproject.org.

Where? The release-monitoring.org / Anitya correctly marks it as a
pre-release but the bug is still created. There is only a "Pre-release
filter" box, but I think it's a helper if the default regex doesn't
work, which in my case seems to work

Jaroslav
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Patrick Griffis via devel

> IMHO, retiring a Fedora package in favor of an upstream binary of whatever 
> kind (Flatpak, Snap, AppImage, RPM, binary tarball, whatever) is a major 
> disservice to Fedora users and defeats the whole point of having a 
> distribution to begin with.

How is an orphan package a good service to users? It will just become outdated 
and degrade over time. I think it is far more responsible, and respectful of 
users, to accept that some packages are better maintained elsewhere.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

Dne 26. 01. 23 v 16:07 Jiri Eischmann napsal(a):

Vít Ondruch píše v Čt 26. 01. 2023 v 15:37 +0100:

Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a):

Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400:

On 1/26/23 8:42 AM, Jiri Eischmann wrote:

Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:

Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):

On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch

wrote:

I am not user of Bottles so I won't complain about this
particular case,
but the push towards (upstream) Flatpaks is unfortunate
:/

Can you elaborate on why you feel that way?

BTW does the flathub version support all the platforms Fedora does?
Cannot tell from the Flathub pages :/

I don't trust upstream Flatpacks. I don't trust they follow
any
standard
except standard of their authors.

I maintain both packages in Fedora and flatpaks on Flathub, so
I
can
compare. The review to get an app to Flathub was as thorough as
Fedora
package review. In some ways even stricter. It's not like "it
builds,
it runs, you're good to go". They care about some standards,
about
builds being verifiable etc.

That doesn't seems to be enforced because many builds scripts
just
download binaries built by other projects, for example;

https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89

Note: building the entire pandoc and TeX toolchain is very hard
and I
understand this example packager decision, but It doesn't make
more
trustful that version that one on Fedora.

Yes, this is good example. I cannot imagine anybody would do the
reviews
for the 3rd party libraries. That is the main difference to Fedora,
because there are no 3rd party libraries there.

But let's not pretend it doesn't happen in Fedora at all.

Yes, of course you are right. But the mindset is what matters to me. We
try to do our best to avoid vendoring and 3rd party libraries. We do our
best to use single copy of library which is properly maintained.

Flatpacks on Flathub are antithesis to what Fedora does in this regard.

Yes, unlike
on Flathub guidelines rule it out, but in the reality I've seen quite a
few packages with (unacknowledged) bundled libraries in Fedora repos.
The package goes through the initial review, a new version introduces a
new dependency which is not available in the Fedora repo, you don't
want to go through the hassle of introducing and maintaining a new
package, you quietly bundle it.
No source is pristine. It's always a compromise. Flathub is more
flexible in what you can include in the flatpak

This is mostly just flexibility for upstream.

, but Flatpak mitigates
it by isolation (although it may not be set strict enough for some
apps).

Isolation is not silver bullet.

E.g. if Flatpak included vulnerable OpenSSL or OpenSSL which does not
obey the system crypto policies, this would be asking for troubles. What
Flathub does for identifying such SW? I don't think it can do much, but
I might be wrong.

Vít

Re: Retiring Bottles in favor of Flatpak provided by upstream

2023-01-26 Thread Michael Catanzaro

On Thu, Jan 26 2023 at 03:49:55 PM -, Patrick Griffis via devel 
 wrote:
How is an orphan package a good service to users? It will just become 
outdated and degrade over time.


Either (a) somebody else will take the package after it has been 
orphaned, or else (b) the package will be retired automatically after a 
few weeks. It won't stay orphaned for very long.


If the only problem with the package is the current Fedora maintainer 
isn't able to keep up with updates, as seems to be the case here, then 
orphaning gives a chance for somebody else to try to do better. 
Hopefully a new maintainer will only take the package if confident that 
they can keep it updated.


Michael

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Some heads-ups for Rawhide users: python3-ptyprocess and systemd issues

On Thu, 2023-01-26 at 12:41 +0100, Florian Weimer wrote:
> * Adam Williamson:
> 
> > 6 (__libc_message.cold+0x5) [0x7fbae3c2560f]
> > Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 6: 
> > /lib64/libc.so.6 (malloc_printerr+0x15) [0x7fbae3c96a05]
> > Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 7: 
> > /lib64/libc.so.6 (_int_free+0x9e5) [0x7fbae3c98de5]
> > Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 8: 
> > /lib64/libc.so.6 (__libc_free+0x7e) [0x7fbae3c9b42e]
> > Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 9: 
> > /usr/lib64/dri/zink_dri.so (__driDriverGetExtensions_zink+0x9e70) 
> > [0x7fbad82b8180]
> > Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 10: 
> > /lib64/libgbm.so.1 (gbm_format_get_name+0xe81) [0x7fbae3229361]
> > Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 11: 
> > /lib64/libgbm.so.1 (gbm_format_get_name+0x1018) [0x7fbae32294f8]
> > Jan 25 13:38:47 fedora /usr/libexec/gdm-x-session[1040]: (EE) 12: 
> > /lib64/libgbm.so.1 (gbm_format_get_name+0x121a) [0x7fbae32296fa]
> 
> I saw this during the latest glibc update, but given that the update
> wasn't tested in isolation, I waived it through because the update
> addresses the known sprintf issue.
> 
> I'm not aware of anything in glibc this might have caused this.  The
> crashes related to -D_FORTIFY_SOURCE=3 look different (they try to crash
> before causing heap corruption!), and it's not the sprintf assertion
> failure in __printf_buffer_as_file_commit, either.
> 
No, it's definitely mesa that causes it - I verified that with manual
local testing, updating only mesa causes the bug to start happening,
downgrading it makes it go away. This is now being tracked/investigated
as https://bugzilla.redhat.com/show_bug.cgi?id=2164667 .
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Delayed openQA test execution

Hey folks! Wanted to send a note out for any maintainers who may be
waiting on openQA test results for critical path updates etc. Tests are
currently taking much longer than usual to be completed because there's
a large backlog. The Rawhide mass rebuild, plus the three critical bugs
(python-ptyprocess, systemd, and mesa) that I posted about yesterday,
caused 2-3 days' worth of Rawhide update tests to fail. After finally
sorting out those problems enough that the tests now pass, I
rescheduled that whole backlog, which turned out to be over 2000 tests.
The system is working its way through the backlog but it'll take a
while (I expect it should be clear by end of day today or so, it
depends a bit on how many updates are created in the mean time), and
until that gets done, it may take much longer for the tests for any
given update to be completed after the update is created.

I do apologize for this; with hindsight it might've been better to try
and hack up a way to reduce the priority on the backlogged Rawhide
update tests so tests for stable release updates ran first, but I
didn't think of that yesterday.

If there are any urgent security or critical bug fix updates for stable
releases which are waiting on testing and really need it run ASAP, let
me know and I can manually bump the priority of those tests so they run
sooner.

Thanks folks!
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

On Thu, 2023-01-26 at 14:55 +0100, Jiri Eischmann wrote:
> Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400:
> > On 1/26/23 8:42 AM, Jiri Eischmann wrote:
> > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100:
> > > > 
> > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a):
> > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch
> > > > > 
> > > > > wrote:
> > > > > > I am not user of Bottles so I won't complain about this
> > > > > > particular case,
> > > > > > but the push towards (upstream) Flatpaks is unfortunate :/
> > > > > Can you elaborate on why you feel that way?
> > > > 
> > > > 
> > > > I don't trust upstream Flatpacks. I don't trust they follow any
> > > > standard
> > > > except standard of their authors.
> > > 
> > > I maintain both packages in Fedora and flatpaks on Flathub, so I
> > > can
> > > compare. The review to get an app to Flathub was as thorough as
> > > Fedora
> > > package review. In some ways even stricter. It's not like "it
> > > builds,
> > > it runs, you're good to go". They care about some standards, about
> > > builds being verifiable etc.
> > 
> > That doesn't seems to be enforced because many builds scripts just 
> > download binaries built by other projects, for example;
> > 
> > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89
> > 
> > Note: building the entire pandoc and TeX toolchain is very hard and I
> > understand this example packager decision, but It doesn't make more 
> > trustful that version that one on Fedora.
> > > 
> Flathub is definitely more flexible at that. I was involved in the deal
> with Mozilla which was not willing to do special builds in Flathub
> infra since from their point of view it was more secure to use builds
> done in their infra and just upload them to Flathub. We still found
> having official builds from Mozilla and Mozilla officially endorsing
> Flathub more beneficial than having Firefox rebuilt by a 3rd party in
> Flathub infra.
> 
> But Flathub is still a curated repo. If you want to deviate from
> standards you have to justify it, if you're doing something fishy your
> flatpak may be taken out. But ultimetaly you have to trust the author,
> but that applies to Fedora, too, just to lesser extend.

Firefox is an interesting example, though, because it's *exactly* a
case where I trust the Fedora builds more than I trust upstream's.
Mozilla makes some, to me, sub-optimal choices in search of revenue;
this isn't a dilemma Fedora has. (This is also why I run Fennec, not
Mozilla's Firefox, on Android). This was one of the main nits I had
running Silverblue on my main system for a while, actually - the baked-
in Fedora firefox package couldn't play h264 video, to which a common
'fix' is to just install the Mozilla flatpak instead, but I didn't want
to do that because I'd much rather have a Fedora packaged build.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

On Thu, 2023-01-26 at 15:49 +, Patrick Griffis via devel wrote:
> > IMHO, retiring a Fedora package in favor of an upstream binary of
> > whatever 
> > kind (Flatpak, Snap, AppImage, RPM, binary tarball, whatever) is a
> > major 
> > disservice to Fedora users and defeats the whole point of having a 
> > distribution to begin with.
> 
> How is an orphan package a good service to users? It will just become
> outdated and degrade over time. I think it is far more responsible,
> and respectful of users, to accept that some packages are better
> maintained elsewhere.

Orphaned packages get automatically retired after a short period of
time if nobody adopts them. So orphaning is a courtesy to give someone
else a *chance* to adopt the package; if nobody does, it'll then get
retired without you having to do anything extra.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream