Re: Package owner required for ImageMagick

2021-10-25 Thread Luya Tshimbalanga


On 2021-10-15 21:38, Michael Cronenworth wrote:



@Luya, apologies for not providing you with a little more knowledge of 
the package. It isn't a simple package to maintain. Upgrades require 
great, great care and lots of rebuilds and alignment with other 
packages on every update.


@Michael, apologies accepted. I found out the hard way which was an 
informative lesson. At least I got a co-maintainers willing to assist me 
to align with other packages including darktable-tools-noise, part of 
Design Suite Labs.


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


Re: Pipeware issue in KDE after F34->F35

2021-10-25 Thread Adam Williamson
On Mon, 2021-10-25 at 08:48 -0700, Kevin Fenzi wrote:
> On Sun, Oct 24, 2021 at 11:34:29PM -0700, Adam Williamson wrote:
> ...snip...
> > 
> > The correct configuration is for pipewire to be enabled in the system
> > session and wireplumber or pipewire-media-session to be enable in the
> > user session (wireplumber should be the default). Either of those not
> > being the case is going to result in broken audio. Both are supposed to
> > be handled on upgrade from F34 already, but it looks like Neal spotted
> > a case where it can be missed.
> 
> pipewire is a user unit as well.
> 
> Can you expand on what you mean by system session?

Oh, indeed, my mistake, sorry. I thought it was a system unit, for some
reason. So, both should be enabled and running in the user session.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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


Re: Considering ExcludeArch: %{ix86} for webkit2gtk3

2021-10-25 Thread Tom Stellard

On 10/25/21 2:02 PM, Tom Stellard wrote:

On 10/25/21 2:00 PM, Michael Catanzaro wrote:

On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard  
wrote:

To do this, you need to add -fuse-ld=lld  -Wl,--build-id=sha1 to the linker 
flags.


Good news: ld.lld does not run out of memory.

Bad news: because it crashes. There is a low-quality backtrace here:

https://kojipkgs.fedoraproject.org//work/tasks/389/77810389/build.log

Sadly there is no easy way to get a better backtrace off the builders.



Would you be able to file a bug for this in the redhat bugzilla?



Actually, from looking at the stack trace I think lld ran out of memory here 
too.

-Tom


Thanks,
Tom


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


Re: Considering ExcludeArch: %{ix86} for webkit2gtk3

2021-10-25 Thread Tom Stellard

On 10/25/21 2:00 PM, Michael Catanzaro wrote:

On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard  
wrote:

To do this, you need to add -fuse-ld=lld  -Wl,--build-id=sha1 to the linker 
flags.


Good news: ld.lld does not run out of memory.

Bad news: because it crashes. There is a low-quality backtrace here:

https://kojipkgs.fedoraproject.org//work/tasks/389/77810389/build.log

Sadly there is no easy way to get a better backtrace off the builders.



Would you be able to file a bug for this in the redhat bugzilla?

Thanks,
Tom


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


Re: Considering ExcludeArch: %{ix86} for webkit2gtk3

2021-10-25 Thread Michael Catanzaro
On Thu, Oct 21 2021 at 05:15:37 PM -0700, Tom Stellard 
 wrote:
To do this, you need to add -fuse-ld=lld  -Wl,--build-id=sha1 to the 
linker flags.


Good news: ld.lld does not run out of memory.

Bad news: because it crashes. There is a low-quality backtrace here:

https://kojipkgs.fedoraproject.org//work/tasks/389/77810389/build.log

Sadly there is no easy way to get a better backtrace off the builders.

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


Update to python-pdfminer 20211012 includes License change

2021-10-25 Thread Ben Beasley
With the upcoming update to version 20211012 
(https://src.fedoraproject.org/rpms/python-pdfminer/pull-request/5), the 
python-pdfminer License field gains yet another term due to some new 
SASL code based on pyHanko and ultimately derived from python-pymongo 
(mongo-python-driver).


Instead of “MIT and Public Domain and APAFML and BSD”, it is now “MIT 
and Public Domain and APAFML and BSD and (ASL 2.0 and MIT)”.

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


Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

2021-10-25 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Oct 25, 2021 at 03:09:00PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
> 
> == Summary ==
> All binaries (executables and shared libraries) are annotated with an
> ELF note that identifies the rpm for which this file was built. This
> allows binaries to be identified when they are distributed without any
> of the rpm metadata. `systemd-coredump` uses this to log package
> versions when reporting crashes.

This is a resubmission of the proposal for F35 which was (narrowly)
rejected at the time. We added copious descriptions of motivations
for the change, and analysis of impact on upgrades, and more links
to documentation.

Zbyszek

> == Owner ==
> * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
> * Email: zbys...@in.waw.pl
> * Name: Lennart Poettering
> * Email: mzsrq...@0pointer.net
> 
> 
> == Detailed Description ==
> People mix binaries (programs and libraries) from different
> distributions (for example using Fedora containers on Debian or vice
> versa), and distribute binaries without packaging metadata (for
> example by stripping everything except the binary from a container
> image, also removing `/usr/lib/.build-id/*`), compile their own rpm
> packages (for internal distribution and installation), and compile and
> distribute their own binaries. Sometimes we need to introspect a
> binary and figure out its provenance, for example when a program
> crashes and we are looking at a core dump, but also when we have a
> binary without the packaging metadata. When the need to introspect a
> binary arises, we have some very good mechanisms to show the
> provenance: when a file is installed through the package manager we
> can directly list the providing package, but even without this we can
> use build-ids embedded in the binary to uniquely identify the
> originating build. But those mechanisms work best when we're in the
> realm of a single distribution. In particular, build-ids can be easily
> tied to a source rpm, but only when we have the source rpm is part of
> the distribution and the build-id was registered in the appropriate
> database which maps build-ids to real package names. When we move
> outside of the realm of a single distribution, it can be hard to
> figure out where a given binary originates from. If we know that a
> binary is from a given distribution, we may be able to use some
> distro-specific mechanism to figure out this information. But those
> mechanisms will be different for different distributions and will
> often require network access. With this change we aim to provide a
> mechanism that is is very simple, provides a "human-readable" origin
> information without further processing, is portable across distros,
> and works without network access.
> 
> The directly motivating use case is display of core dumps. Right now
> we have build-ids, but those are just opaque hexadecimal numbers that
> are not meaningful to users. We would like to immediately list
> versions of packages involved in the crash (including both the program
> and any libraries it links to). It is not enough to query the rpm
> database to do the equivalent of `rpm -qf …`: very often programs
> crash after some packages have been upgraded and the binaries loaded
> into memory are not the binaries that are currently present on disk,
> or when through some mishap, the binaries on disk do not match the
> installed rpms.  A mechanism that works without rpm database lookup or
> network access allows this information to be showed immediately in
> `coredumpctl` listings and journal entries about the crash. This
> includes crashes that happen in the initrd and sandboxed containers.
> 
> A second motivating use case is when users distribute their own
> binaries and would like to collect crash information. Build-ids are a
> solution that is technically possible, but easy to get wrong in
> practice: users would need to immediately record the build-id after
> the build and store the mapping to program names, versions, and build
> number in some database. It's much easier to be able to record
> something during the build in the build product itself.
> 
> A third motivating use case is the general mixing of Fedora binaries
> with programs and libraries from different distributions, both with
> our binaries being used as the base for foreign binaries, and the
> other way around. Whilst most distributions provide some mechanism to
> figure out the source build information, those mechanisms vary by
> distribution and may not be easy to access from a "foreign" system.
> Such mixing is expected with containers, flatpaks, snaps, Python
> binary wheels, anaconda packages, and quite often when somebody
> compiles a binary and puts it up on the web for other people to
> download.
> 
> We propose a new mechanism which is designed to be very simple but
> extensible: a small JSON document is embedded in an section in the ELF
> binary. This document can be easily read by 

F36 Change: Package information on ELF objects (System-Wide Change proposal)

2021-10-25 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects

== Summary ==
All binaries (executables and shared libraries) are annotated with an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrq...@0pointer.net


== Detailed Description ==
People mix binaries (programs and libraries) from different
distributions (for example using Fedora containers on Debian or vice
versa), and distribute binaries without packaging metadata (for
example by stripping everything except the binary from a container
image, also removing `/usr/lib/.build-id/*`), compile their own rpm
packages (for internal distribution and installation), and compile and
distribute their own binaries. Sometimes we need to introspect a
binary and figure out its provenance, for example when a program
crashes and we are looking at a core dump, but also when we have a
binary without the packaging metadata. When the need to introspect a
binary arises, we have some very good mechanisms to show the
provenance: when a file is installed through the package manager we
can directly list the providing package, but even without this we can
use build-ids embedded in the binary to uniquely identify the
originating build. But those mechanisms work best when we're in the
realm of a single distribution. In particular, build-ids can be easily
tied to a source rpm, but only when we have the source rpm is part of
the distribution and the build-id was registered in the appropriate
database which maps build-ids to real package names. When we move
outside of the realm of a single distribution, it can be hard to
figure out where a given binary originates from. If we know that a
binary is from a given distribution, we may be able to use some
distro-specific mechanism to figure out this information. But those
mechanisms will be different for different distributions and will
often require network access. With this change we aim to provide a
mechanism that is is very simple, provides a "human-readable" origin
information without further processing, is portable across distros,
and works without network access.

The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers that
are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the program
and any libraries it links to). It is not enough to query the rpm
database to do the equivalent of `rpm -qf …`: very often programs
crash after some packages have been upgraded and the binaries loaded
into memory are not the binaries that are currently present on disk,
or when through some mishap, the binaries on disk do not match the
installed rpms.  A mechanism that works without rpm database lookup or
network access allows this information to be showed immediately in
`coredumpctl` listings and journal entries about the crash. This
includes crashes that happen in the initrd and sandboxed containers.

A second motivating use case is when users distribute their own
binaries and would like to collect crash information. Build-ids are a
solution that is technically possible, but easy to get wrong in
practice: users would need to immediately record the build-id after
the build and store the mapping to program names, versions, and build
number in some database. It's much easier to be able to record
something during the build in the build product itself.

A third motivating use case is the general mixing of Fedora binaries
with programs and libraries from different distributions, both with
our binaries being used as the base for foreign binaries, and the
other way around. Whilst most distributions provide some mechanism to
figure out the source build information, those mechanisms vary by
distribution and may not be easy to access from a "foreign" system.
Such mixing is expected with containers, flatpaks, snaps, Python
binary wheels, anaconda packages, and quite often when somebody
compiles a binary and puts it up on the web for other people to
download.

We propose a new mechanism which is designed to be very simple but
extensible: a small JSON document is embedded in an section in the ELF
binary. This document can be easily read by a human if necessary, but
it is also well-defined and can be processed programatically. For
example, `systemd-coredump` will immediately make use of this to
display package ''nevra'' information for crashes. The format is also
easy to generate, so it can be added to any build system, either using
the helpers that we provide or even reimplemented from scratch.

For the case where we mix binaries from different distros (the third
motivating use case 

Re: Considering ExcludeArch: %{ix86} for webkit2gtk3

2021-10-25 Thread Michael Catanzaro
On Mon, Oct 25 2021 at 08:33:42 AM -0500, Michael Catanzaro 
 wrote:
I'll try this one as a last-ditch effort, but I don't think it will 
work. We'll find out. I expect this will reduce the memory required 
*during* linking, but I think the problem here is the *resulting 
executable* is just too big.


It failed with a different error message:

/usr/bin/ld: final link failed: memory exhausted
collect2: error: ld returned 1 exit status



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


No FESCo meeting today (2021-10-25)

2021-10-25 Thread Zbigniew Jędrzejewski-Szmek
There is nothing on the agenda, so I'm cancelling the meeting.
I'll chair the next one too.

= Discussed and Voted in the Ticket =

#2677 F37 Change: Python 3.11
https://pagure.io/fesco/issue/2677
APPROVED (+7,0,-0)

#2676 F36 Change: Setuptools 58+ 
https://pagure.io/fesco/issue/2676
APPROVED (+6,0,-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 on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Pipeware issue in KDE after F34->F35

2021-10-25 Thread Kevin Fenzi
On Sun, Oct 24, 2021 at 11:34:29PM -0700, Adam Williamson wrote:
...snip...
> 
> The correct configuration is for pipewire to be enabled in the system
> session and wireplumber or pipewire-media-session to be enable in the
> user session (wireplumber should be the default). Either of those not
> being the case is going to result in broken audio. Both are supposed to
> be handled on upgrade from F34 already, but it looks like Neal spotted
> a case where it can be missed.

pipewire is a user unit as well.

Can you expand on what you mean by system session?

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


License correction: python-fastavro is “MIT and ASL 2.0”

2021-10-25 Thread Ben Beasley
The License field of the python-fastavro package has been corrected from 
“ASL 2.0” to “MIT and ASL 2.0”.


The primary upstream license is MIT 
(https://github.com/fastavro/fastavro/blob/1.4.6/LICENSE), but the 
project is derived from Apache Avro, which is under the ASL 2.0 license 
(https://github.com/fastavro/fastavro/blob/1.4.6/NOTICE.txt).

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


Re: F36 Change: Retire the NIS(+) user-space utility programs (System-Wide Change proposal)

2021-10-25 Thread Miro Hrončok

On 21. 10. 21 22:37, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/retire_NIS_user_space_utils


== Summary ==

This change is about retiring the ypbind, yp-tools, and ypserv
packages, and removal of the {nis,yp}domainname user-space utility
programs from the hostname package...


Possibly stupid question, but I am really confused by what "NIS" is in 
packaging terms.


In EL 9, we added this to Python:

"Build without the legacy nis module"

https://gitlab.com/redhat/centos-stream/rpms/python3.9/-/merge_requests/1/

It removes the dependency on libnsl2 and libtirpc. However neither is listed in 
this change proposal. Would we remove the nis Python module on Fedora as well, 
or not?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: update F34 - f35 postgresql module issue

2021-10-25 Thread Petr Pisar
V Sat, Oct 23, 2021 at 11:40:25PM +0200, Peter Boy napsal(a):
> I just tested the dnf upgrade procedure on one of our standby backup systems
> which happens to have the F34 postgresql module version 9.6 installed. 
> 
> The module was overwritten with version 13 without warning.

I guess DNF reported "disabling postgresql:9.6 stream" among all packages to
upgrade and you had to approve the DNF transaction explicitly. If it is not
that case, then report a bug against DNF. I think DNF shuld not silently
uninstall a module stream.

However, if PostgreSQL maintainers did not provide postgresql:9.6 stream for
Fedora 35, then DNF has no much options except of aborting the upgrade. Modules
are always built for a specific Fedora release and are not portable to another
release.

> Given the data incompatibility, this is a very unattractive practice. As far
> as I remember, one could rely on the fact that with an upgrade the
> respective module was updated in the installed version. 
> 
I don't understand what you remember. In Fedora, there is currently no
mechanism for transitioning between module streams. E.g. from postgresql:9.6 to
postgresql:13.

The mechanism
 was planned
for Fedora 35, but it was postponed to Fedora 36. When the machanism is
implemented, then DNF will advertise that postgresql:9.6 ends its life on
2021-12-01 and the users are advised to migrate to postgresql:10. Maybe DNF
will offer switching from the old stream to the new stream during an upgrade
transaction. However, the mechanism won't provide any software-specific
migration tools, like convertingdatabase files from one format to another one.

Nowdays the end-of-life date can be obtained at

web page.

> Fedora 35 comes obviously without Postgres module 9.6.

Yes, I confirm it. It only delivers PostgresSQL 10 to 14.

> Unfortunately, the release change set doesn’t mention that. We need a clear
> indication and warning of this. 
>
If you believe that removal of a postgresql stream from a new Fedora release
is an important change and suitable for Fedora release notes, that file a bug
against that module stream
.
I cannot see any change like that on Fedora 35's list of changes
.

Also the maintainers could build postgresql:9.6 for F35 and support it there
until 2021-12-01. Maybe they only forgot to build it there.

-- Petr


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


Re: Considering ExcludeArch: %{ix86} for webkit2gtk3

2021-10-25 Thread Michael Catanzaro
On Mon, Oct 25 2021 at 01:14:31 PM +0200, Petr Pisar 
 wrote:

   --reduce-memory-overheads


I'll try this one as a last-ditch effort, but I don't think it will 
work. We'll find out. I expect this will reduce the memory required 
*during* linking, but I think the problem here is the *resulting 
executable* is just too big.


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


Re: sssd-2.6.0 update in F35 breaks klist/kinit here

2021-10-25 Thread Ankur Sinha
On Mon, Oct 25, 2021 10:41:44 +0200, Pavel Březina wrote:
> 
> I've unpushed the package so far, so it won't be pushed to stable. Please
> open a bugzilla with KCM logs attached. Also please, provide output of
> failing klist with krb5 tracing enabled (KRB5_TRACE=/dev/stderr).

Thanks very much. I filed the initial report here:
https://bugzilla.redhat.com/show_bug.cgi?id=2016992

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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


Re: Orphaned packages looking for new maintainers​

2021-10-25 Thread Jens-Ulrik Petersen
On Mon, Oct 25, 2021 at 6:43 PM Miro Hrončok  wrote:

> ghc-HStringTemplate   orphan   2 weeks
> ago
> ghc-filestore orphan   2 weeks
> ago
> ghc-hoauth2   orphan   2 weeks
> ago
> ghc-recaptcha orphan   2 weeks
> ago
> ghc-uri   orphan   2 weeks
> ago
> ghc-uri-bytestring-aeson  orphan   2 weeks
> ago
> ghc-url   orphan   2 weeks
> ago
> gitit orphan   2 weeks
> ago


I went ahead and took these.
But if anyone is keen to help maintain any of them, don't hesitate to let
me know.

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


Re: Considering ExcludeArch: %{ix86} for webkit2gtk3

2021-10-25 Thread Petr Pisar
V Fri, Oct 22, 2021 at 04:58:35PM -0500, Michael Catanzaro napsal(a):
> I've tried almost everything I can think of: -g0, -Os, disabled LTO. None of
> this worked.

bfd linker has these options:

   --no-keep-memory
   ld normally optimizes for speed over memory usage by caching the
   symbol tables of input files in memory.  This option tells ld to
   instead optimize for memory usage, by rereading the symbol tables
   as necessary.  This may be required if ld runs out of memory space
   while linking a large executable.

   --hash-size=number
   Set the default size of the linker's hash tables to a prime number
   close to number.  Increasing this value can reduce the length of
   time it takes the linker to perform its tasks, at the expense of
   increasing the linker's memory requirements.  Similarly reducing
   this value can reduce the memory requirements at the expense of
   speed.

   --reduce-memory-overheads
   This option reduces memory requirements at ld runtime, at the
   expense of linking speed.  This was introduced to select the old
   O(n^2) algorithm for link map file generation, rather than the new
   O(n) algorithm which uses about 40% more memory for symbol storage.

   Another effect of the switch is to set the default hash table size
   to 1021, which again saves memory at the cost of lengthening the
   linker's run time.  This is not done however if the --hash-size
   switch has been used.

   The --reduce-memory-overheads switch may be also be used to enable
   other tradeoffs in future versions of the linker.

-- Petr


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


Orphaned packages looking for new maintainers​

2021-10-25 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-10-25.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

bitlbee-discord   orphan   2 weeks ago
cAudioorphan   2 weeks ago
crcimgorphan   2 weeks ago
elog  orphan   2 weeks ago
erlang-certifierlang-maint-sig, orphan 0 weeks ago
erlang-cf erlang-maint-sig, orphan 0 weeks ago
erlang-cth_readable   erlang-maint-sig, orphan 0 weeks ago
erlang-erlware_commonserlang-maint-sig, orphan 0 weeks ago
erlang-eunit_formatters   erlang-maint-sig, orphan 0 weeks ago
erlang-hex_core   erlang-maint-sig, orphan 0 weeks ago
erlang-providers  erlang-maint-sig, orphan 0 weeks ago
erlang-relx   erlang-maint-sig, orphan 0 weeks ago
erlang-ssl_verify_fun erlang-maint-sig, orphan 0 weeks ago
fedmodnphilipp, orphan 4 weeks ago
gauche-gl orphan   2 weeks ago
gfm   orphan   2 weeks ago
ghc-HStringTemplate   orphan   2 weeks ago
ghc-filestore orphan   2 weeks ago
ghc-hoauth2   orphan   2 weeks ago
ghc-recaptcha orphan   2 weeks ago
ghc-uri   orphan   2 weeks ago
ghc-uri-bytestring-aeson  orphan   2 weeks ago
ghc-url   orphan   2 weeks ago
gitit orphan   2 weeks ago
golang-github-dgraph-io-badgerorphan   2 weeks ago
golang-github-dgraph-io-  orphan   2 weeks ago
ristretto
golang-github-geziyor orphan   2 weeks ago
golang-github-jacobsa-crypto  orphan   3 weeks ago
golang-github-jacobsa-oglemockorphan   3 weeks ago
golang-github-jacobsa-ogletestorphan   3 weeks ago
golang-github-jacobsa-reqtraceorphan   3 weeks ago
golang-github-milochristiansen-   go-sig, orphan   2 weeks ago
axis2
golang-github-milochristiansen-   go-sig, orphan   2 weeks ago
lua
golang-github-rfjakob-gocryptfs   orphan   3 weeks ago
golang-github-sabhiram-   orphan   3 weeks ago
gitignore
hddfancontrol orphan   2 weeks ago
hyperrogueorphan   2 weeks ago
kdevelop-python   dvratil, jgrulich, kde-sig,  4 weeks ago
  orphan
kdocker   kde-sig, orphan, rdieter 4 weeks ago
libcxlorphan   1 weeks ago
libocxl   orphan   1 weeks ago
libsocorphan   2 weeks ago
libticables2  orphan   2 weeks ago
libticalcs2   orphan   2 weeks ago
libticonv orphan   2 weeks ago
libtifiles2   orphan   2 weeks ago
mantisorphan   2 weeks ago
maven-indexer  

Re: update F34 - f35 postgresql module issue

2021-10-25 Thread Peter Boy


> Am 24.10.2021 um 04:55 schrieb Samuel Sieb :
> 
> On 10/23/21 14:40, Peter Boy wrote:
>> I just tested the dnf upgrade procedure on one of our standby backup systems 
>> which happens to have the F34 postgresql module version 9.6 installed.
>> The module was overwritten with version 13 without warning. Given the data 
>> incompatibility, this is a very unattractive practice. As far as I remember, 
>> one could rely on the fact that with an upgrade the respective module was 
>> updated in the installed version.
>> Fedora 35 comes obviously without Postgres module 9.6. Unfortunately, the 
>> release change set doesn’t mention that. We need a clear indication and 
>> warning of this.
> 
> I've never used the modules, but with rpms, you get the postgresql-upgrade 
> package installed as well in order to upgrade the database.  Is this not 
> available with modules?


I’m not sure either. According to module list it only provides server and 
client. But that’s not a problem for me. We used modules to avoid upgrading. 
And we have an old service which requires version 9.6. So upgrade is not really 
an option.

The postgresql project provides a version 9.6 rpm for Fedora 34. Don’t know if 
they will do it for Fedora 35 as well (I hope so).

My main issue is that f35 removes the postgresql module version 9.6 without 
notice in the release notes or warning during upgrade.

And now dnf always complains
"Problem: conflicting requests
  - nothing provides module(platform:f34) needed by module 
postgresql:9.6:3420210210170810:058368ca.x86_64“

although this postgresql version is no longer present on the system.

Do you know, how I get rid of that? 




Thanks
Peter

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


Next Open NeuroFedora Meeting: 1300 UTC on Monday, 25 October (Today)

2021-10-25 Thread Ankur Sinha
Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 25th
October (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat) or
Matrix. The meeting is a public meeting, and open for everyone to
attend. You can join us over:

Matrix: https://matrix.to/#/#neuro:fedoraproject.org
IRC: https://webchat.libera.chat/?channels=#fedora-neuro

You can convert the meeting time to your local time using this command
in a terminal:
$ date --date='TZ="UTC" 1300 today'

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20211025T13&p1=%3A&ah=1

The meeting will be chaired by @shaneallcroft. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: 
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-10-11-13.00.html
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- Koschei packages check: https://koschei.fedoraproject.org/groups/neuro-sig
- CompNeuro lab compose status check for F35/F36: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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


Fedora-Cloud-34-20211025.0 compose check report

2021-10-25 Thread Fedora compose checker
No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20211024.0):

ID: 1039185 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1039185
ID: 1039186 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1039186

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


Re: Fedora 35 status and testing needed

2021-10-25 Thread Jun Aruga
On Mon, Oct 25, 2021 at 10:33 AM Samuel Sieb  wrote:
>
> On 2021-10-25 01:21, Jun Aruga wrote:
> > I might find the issues about installation with the Fedora 35 64-bit
> > network install image. How and where can I report it?
> > Is the beta installation too old to test now? Thanks.
> > https://getfedora.org/en/workstation/download/
>
> The test list (t...@lists.fedoraproject.org) is the place to discuss not
> yet released Fedora versions.  Beta is too old.  There should be RC
> images somewhere.

OK. Thanks for the info.

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


Re: sssd-2.6.0 update in F35 breaks klist/kinit here

2021-10-25 Thread Pavel Březina

On 10/22/21 16:56, Ankur Sinha wrote:

Hi folks,

I just updated two F35 systems with updates-testing enabled and then
`klist` etc. stopped working for me. Some investigation seems to
indicate that the sssd-2.6.0 update may be involved---downgrading back
to 2.5.2 immediately fixes the issue on both systems. The update
however, has 3+ karma already, so it's on it's way to stable:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-360425682d

Could more folks please test it out to see if it's a package update
related bug? (I've not touched my configs at all as far as I can
remember, so it *shouldn't* be specific to my two machines).

If it's a general issue, it'll break kinit etc. for all package
maintainers as soon as they get the update. (Running `fedpkg
new-sources` was how I ran into the issue).


I've unpushed the package so far, so it won't be pushed to stable. 
Please open a bugzilla with KCM logs attached. Also please, provide 
output of failing klist with krb5 tracing enabled (KRB5_TRACE=/dev/stderr).


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


Re: Fedora 35 status and testing needed

2021-10-25 Thread Samuel Sieb

On 2021-10-25 01:21, Jun Aruga wrote:

I might find the issues about installation with the Fedora 35 64-bit
network install image. How and where can I report it?
Is the beta installation too old to test now? Thanks.
https://getfedora.org/en/workstation/download/


The test list (t...@lists.fedoraproject.org) is the place to discuss not 
yet released Fedora versions.  Beta is too old.  There should be RC 
images somewhere.

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


Re: Fedora 35 status and testing needed

2021-10-25 Thread Jun Aruga
I might find the issues about installation with the Fedora 35 64-bit
network install image. How and where can I report it?
Is the beta installation too old to test now? Thanks.
https://getfedora.org/en/workstation/download/

Jun

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


Re: Should fedora workstation incude cups by default

2021-10-25 Thread Felipe Borges
On Fri, Oct 22, 2021 at 1:42 AM Reon Beon via devel
 wrote:
>
> I don't know if it did by default on rawhide (gnome). As far as I remember.

Why would we want that? Was there a previous discussion on the
$SUBJECT that I might not be aware of?

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


Fedora-Cloud-33-20211025.0 compose check report

2021-10-25 Thread Fedora compose checker
No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20211024.0):

ID: 1039169 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1039169
ID: 1039170 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1039170

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[Test-Announce] 2021-10-25 @ 16:00 UTC - Fedora 35 Blocker Review Meeting

2021-10-25 Thread Adam Williamson
# F35 Blocker Review meeting
# Date: 2021-10-25
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.libera.chat

Hi folks! We have 2 proposed Final blockers and 4 proposed Final freeze
exceptions to review, so let's have a review meeting today (sorry for
the late notice, just realized I forgot to send this).

If you have time today, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F35 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

See you all soon!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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