Fedora rawhide compose report: 20180822.n.0 changes

OLD: Fedora-Rawhide-20180820.n.3 NEW: Fedora-Rawhide-20180822.n.0 = SUMMARY = Added images:7 Dropped images: 0 Added packages: 5 Dropped packages:0 Upgraded packages: 125 Downgraded packages: 0 Size of added packages: 603.93 KiB Size of dropped packages:0

Re: Fedora 30 System-Wide Change proposal: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

On 08/23/2018 07:23 AM, Elliott Sales de Andrade wrote: On Wed, 22 Aug 2018 at 17:18, Ben Cotton > wrote: https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition == Summary == Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long

Re: Why is i686 package missing from x86_64 updates repo?

On 08/23/2018 04:38 AM, Tom Stellard wrote: I'm trying to resolvehttps://bugzilla.redhat.com/show_bug.cgi?id=1615016 and can't figure out why the i686 package is missing from the x86_64 updates repo. It's a bug in the generation of the updates-testing compose: https://pagure.io/releng/issue/

Non-responsive maintainer for python-pytz

It hasn't been updated in almost a year, and it's updates are sorely needed. Trying to get updated before the beta freeze. https://bugzilla.redhat.com/show_bug.cgi?id=1508227 Joseph D. Wagner ___ devel mailing list -- devel@lists.fedoraproject.org T

Non-responsive maintainer for python-simplejson

It hasn't been updated in over a year, and it's updates are sorely needed. Trying to get updated before the beta freeze. https://bugzilla.redhat.com/show_bug.cgi?id=1462583 Joseph D. Wagner ___ devel mailing list -- devel@lists.fedoraproject.org To un

Re: Fedora 30 System-Wide Change proposal: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

On Wed, 22 Aug 2018 at 17:18, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition > > == Summary == > Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double > ABI. > > == Owner == > * Name: Carlos O'Donell (codonell) > * Email: car...@redhat.

libgsf build help - MinGW edition

Recent versions of libgsf (since 1.14.43) have begun to fail to build in MinGW environments. The error is straightforward enough - a function signature definition differs between its forward declaration and its implementation. But I don't see any clear way that it differs. The same code compiles cl

Why is i686 package missing from x86_64 updates repo?

Hi, I'm trying to resolve https://bugzilla.redhat.com/show_bug.cgi?id=1615016 and can't figure out why the i686 package is missing from the x86_64 updates repo. It is present in the fedora repo, so it seems like this issue is specific to updates. Does anyone know why this might be happening? Be

Re: Orphaning procedure for python-assimulo

Hey, Kindly assign it to me. On Wed, 22 Aug 2018, 23:32 Antonio Trande, wrote: > Hello everyone. > > I'm leaving the maintenance of 'python-assimulo' package; if someone > wishes take care of it, please reply here. > > Regards. > -- > --- > Antonio Trande > Fedora Project > mailto 'sagitter at

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

On 23.8.2018 00:31, Artur Iwicki wrote: If we remove the Group: tag from existing packages (assuming 100% accuracy), this would mean that the only way for a package to have the Group: tag would be to: a) have a maintainer add it back in b) accept a new package with the Group: tag present If we

Intent to drop python2-behave

There is a cluster of PRs: https://src.fedoraproject.org/rpms/python-behave/pull-request/2 https://src.fedoraproject.org/rpms/python-docx/pull-request/2 https://src.fedoraproject.org/rpms/python-parse_type/pull-request/2 That allows us to drop python2-behave as nothing will depend on it. I'm gi

Re: Mono - Do we have a maintainer?

On Wed, 22 Aug 2018 13:59:51 -0400, you wrote: >* Dan Horák [2018-08-22 03:55]: >> a nice thing on Mono is that it is fully multi-arch, supporting all >> Fedora arches. Won't be multi-arch problem for msbuild or .NET Core? > >Oh. Right, that would be a problem. .NET Core upstream essentially >sup

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

On 08/23/2018 12:31 AM, Artur Iwicki wrote: > If we remove the Group: tag from existing packages (assuming 100% accuracy), > this would mean that the only way for a package to have the Group: tag would > be to: > a) have a maintainer add it back in > b) accept a new package with the Group: tag pr

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

If we remove the Group: tag from existing packages (assuming 100% accuracy), this would mean that the only way for a package to have the Group: tag would be to: a) have a maintainer add it back in b) accept a new package with the Group: tag present If we assume option a) to be unlikely, then wou

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

On Wed, Aug 22, 2018 at 6:00 PM Omair Majid wrote: > > * Ben Cotton [2018-08-22 16:38]: > > 9420 source packages (43% of the total count) come closer to > > compliance with Fedora's packaging guidelines. The Group: tag has > > been in a "should not use" state since March of 2017. > > Can rpmlint

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> Can we patch rpm not to show this useless line? In the context of what I wrote, there's no "useless line". I assume you're talking about rpm -qi output, but I was being more general than that. Certainly we wouldn't patch out the GROUP query

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

* Ben Cotton [2018-08-22 16:38]: > 9420 source packages (43% of the total count) come closer to > compliance with Fedora's packaging guidelines. The Group: tag has > been in a "should not use" state since March of 2017. Can rpmlint be patched to warn about using the 'Group:' tag? Omair -- PGP

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

On 08/22/2018 01:28 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Remove_Group_Tag > > == Summary == > Remove the Group: tag from over 9000 source packages. > > == Owner == > * Name: Jason Tibbitts (tibbs) > * Email: ti...@math.uh.edu > > == Detailed Description == > I will remo

Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

On Wed, Aug 22, 2018 at 04:28:16PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Remove_Group_Tag > > == Summary == > Remove the Group: tag from over 9000 source packages. > > == Owner == > * Name: Jason Tibbitts (tibbs) > * Email: ti...@math.uh.edu > > == Detailed Descriptio

Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

https://fedoraproject.org/wiki/Changes/Remove_Group_Tag == Summary == Remove the Group: tag from over 9000 source packages. == Owner == * Name: Jason Tibbitts (tibbs) * Email: ti...@math.uh.edu == Detailed Description == I will remove the Group: tag from all specfiles in Fedora dist-git which st

Fedora 30 System-Wide Change proposal: Remove glibc-all-langpacks from buildroot

https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot == Summary == glibc-minimal-langpack is added to @Buildsystem group and installed into the minimal buildroot instead of glibc-all-langpacks. Packages which need more locales than plain C/C.UTF-8/POSIX need to pull the

Fedora 30 System-Wide Change proposal: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition == Summary == Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI. == Owner == * Name: Carlos O'Donell (codonell) * Email: car...@redhat.com == Detailed Description == IBM has designed a new long double

Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error

https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error == Summary == The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot policy script will be changed to make the build fail when it sees an ambiguous python shebang, such as #!/usr/bin/python or #!/usr/bin/env python. (The sc

Fedora 29-20180822.n.0 compose check report

Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Failed openQA tests: 19/130 (x86_64), 5/24 (i386), 1/2 (arm) ID: 268290 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/268290 ID: 268291 Test: x86_64 Server-d

Fedora 30 Self-Contained Change proposal: No more automagic Python bytecompilation (phase 2)

https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation_phase_2 == Summary == See https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation Now we are changing the default to be %global _python_bytecompile_extra 0. == Owner == * Name: Miro Hrončok (C

Re: Mono - Do we have a maintainer?

* Dan Horák [2018-08-22 03:55]: > a nice thing on Mono is that it is fully multi-arch, supporting all > Fedora arches. Won't be multi-arch problem for msbuild or .NET Core? Oh. Right, that would be a problem. .NET Core upstream essentially supports x86_64 only. arm-hfp, aarch64 and x86 are suppor

Fedora 29 compose report: 20180822.n.0 changes

OLD: Fedora-29-20180821.n.0 NEW: Fedora-29-20180822.n.0 = SUMMARY = Added images:7 Dropped images: 2 Added packages: 7 Dropped packages:0 Upgraded packages: 66 Downgraded packages: 0 Size of added packages: 38.07 MiB Size of dropped packages:0 B Size of

Orphaning procedure for python-assimulo

Hello everyone. I'm leaving the maintenance of 'python-assimulo' package; if someone wishes take care of it, please reply here. Regards. -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x5E212EE1D35568BE GPG key server: https://keys.fedoraproject.org/

Re: Intent to upgrade Django in f29 to 2.1

On 22.8.2018 13:13, Matthias Runge wrote: On Wed, Aug 22, 2018 at 11:51:34AM +0200, Miro Hrončok wrote: On 22.8.2018 10:59, Matthias Runge wrote: Hello, sorry for the late notice; Django 2.1 was recently released, and I intend to update Django in F29 to version 2.1. Apparently, all depending

Re: [modularity] Managing module lifecycles — let's talk!

What are the possibilities for how a stream is maintained? The cases I can think of: * Indefinite - rolling forward with upstream - "master" "stable" etc. * Tied to an upstream version and it's EOL - a "2.1" stream of django * [less common] tied to a particular version of Fedora - the "29" str

Help needed with FTBFS of package cpl in i686 and Fedora>=29

Hello, I'm trying to fix a FTBFS bug in cpl, a C library. The package fails in i686 on Fedora>=29 and compiles in Fedora<=28 https://koji.fedoraproject.org/koji/taskinfo?taskID=29215071 https://kojipkgs.fedoraproject.org//work/tasks/5071/29215071/build.log I imagine that, after enabling SSE2 in

Re: Orphaning procedure for python-ivi -vxi11 -usbtmc -testify

On 22.8.2018 15:52, Manas Mangaonkar wrote: Thanks for the link,will do :) If you are going to take care of those packages, I'd appreciate if you remove the python2 bits from them. On Wed, 22 Aug 2018, 15:15 Antonio Trande, > wrote: At this point, the pa

Re: Orphaning procedure for python-ivi -vxi11 -usbtmc -testify

Thanks for the link,will do :) - Manas On Wed, 22 Aug 2018, 15:15 Antonio Trande, wrote: > At this point, the packages are orphaned. > > Please, follow the 'Claiming Ownership of an Orphaned Package' > guidelines: > > https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Cla

Re: Release rpkg-1.56 and fedpkg-1.35

> rpkg: https://docs.pagure.org/rpkg/releases/1.56.html > Greenwave policy could be validated when build a package with build command, > or a container with container-build command, if policy file gating.yaml is > created in the root directory inside repostiory. If the policy is valid, > build w

Re: Intent to upgrade Django in f29 to 2.1

On Wed, Aug 22, 2018 at 11:51:34AM +0200, Miro Hrončok wrote: > On 22.8.2018 10:59, Matthias Runge wrote: > > Hello, > > > > sorry for the late notice; Django 2.1 was recently released, and > > I intend to update Django in F29 to version 2.1. > > > > Apparently, all depending packages still build

[modularity] Managing module lifecycles — let's talk!

During the Modularity WG meeting yesterday [1], we've touched the topic of module lifecycles. Even though there are some ideas in the air as well as some code written, we haven't reached a state in which we would know how exactly to deal with it. So I'd like to discuss it here with a wider audience

Fwd: Soname break for glew

I'm preparing an update for glew to 2.1.0 (with soname bump) (pushed in rawhide but not built yet). https://koji.fedoraproject.org/koji/taskinfo?taskID=29087244 Given that the freeze break is next week, I will push the update in rawhide, then in f29 next. Here are the dependencies: FlightGear-Atl

Re: Intent to upgrade Django in f29 to 2.1

On 22.8.2018 10:59, Matthias Runge wrote: Hello, sorry for the late notice; Django 2.1 was recently released, and I intend to update Django in F29 to version 2.1. Apparently, all depending packages still build, all the details in https://bugzilla.redhat.com/show_bug.cgi?id=1611025 2 packages

Intent to upgrade Django in f29 to 2.1

Hello, sorry for the late notice; Django 2.1 was recently released, and I intend to update Django in F29 to version 2.1. Apparently, all depending packages still build, all the details in https://bugzilla.redhat.com/show_bug.cgi?id=1611025 If I don't hear anything against it until Monday, I'll m

Re: Orphaning procedure for python-ivi -vxi11 -usbtmc -testify

At this point, the packages are orphaned. Please, follow the 'Claiming Ownership of an Orphaned Package' guidelines: https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package On 22/08/2018 07:05, Manas Mangaonkar wrote: > Hey, > > Please

Re: Mono - Do we have a maintainer?

On Mon, 20 Aug 2018 17:13:42 -0400 Omair Majid wrote: > * Michael Cronenworth [2018-08-15 10:19]: > > On 08/15/2018 08:55 AM, Florian Weimer wrote: > > > Are you sure about that?  Ocaml does it as well. > > > > The guidelines allow an initial bootstrap from binaries, but > > subsequent builds a

Release rpkg-1.56 and fedpkg-1.35

Hi, New version rpkg-1.56 and fedpkg-1.35 are released. Release notes: * rpkg: https://docs.pagure.org/rpkg/releases/1.56.html * fedpkg: https://docs.pagure.org/fedpkg/releases/1.35.html Bodhi updates: https://bodhi.fedoraproject.org/updates/rpkg-1.56-1.fc28%20fedpkg-1.35-1.fc28 https://bodhi.