Will it be possible to document and modernize the configuration to build
a rpm package in Fedora? It will be really great to make the guideline
seamless and less messy.
Luya
On 2019-10-08 12:38 p.m., Przemek Klosowski via devel wrote:
On 10/8/19 6:04 AM, Ankur Sinha wrote:
Would anyone else
On 10/7/19 09:25, Kalev Lember wrote:
Hi all,
This week is GNOME 3.34.1 release. I'm collecting builds in f31-gnome
side tag and going to submit everything in a single megaupdate to Bodhi
later this week. Please use 'fedpkg build --target f31-gnome' if you are
helping with builds.
Tonight also
On 10/8/19 3:26 PM, Ankur Sinha wrote:
On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote:
Look, I'm no more in love with the traditional layout than anybody, I'm just
saying changing the default is not as simple as you'd like to think. Anybody
wanting to work on changing the default i
On 09. 10. 19 4:34, Nico Kadel-Garcia wrote:
On Tue, Oct 8, 2019 at 1:56 PM Irina Boverman wrote:
Using "BuildRequires: python%{python3_pkgversion}-devel" results in this error:
fedpkg scratch-build
DEBUG util.py:593: No matching package to install: 'python36-devel'
A lot of Fedora .spec
> * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37)
> * AGREED: We disagree with merging default streams into the main repo
> as non-modular packages. Our approach is to implement a mechanism of
> following default streams to give people the experience they want.
>
On Wed, Oct 9, 2019 at 6:08 AM Jun Aruga wrote:
>
> > * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37)
> > * AGREED: We disagree with merging default streams into the main repo
> > as non-modular packages. Our approach is to implement a mechanism of
> > following def
On Tue, Oct 8, 2019, 23:18 Langdon White wrote:
> Minutes:
> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.html
> Minutes (text):
> https://meetbot.fedoraproject.org/fedora-meeting-3/2019-10-08/modularity.2019-10-08-15.08.txt
> Log:
> https://meetbot.fe
On 04. 10. 19 21:31, Miro Hrončok wrote:
On 04. 10. 19 16:57, Stephen Gallagher wrote:
Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.
1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Sele
On Wed, Oct 9, 2019, 12:29 Miro Hrončok wrote:
> On 04. 10. 19 21:31, Miro Hrončok wrote:
> > On 04. 10. 19 16:57, Stephen Gallagher wrote:
> >> Right now, there are two conflicting requirements in Fedora Modularity
> >> that we need to resolve.
> >>
> >> 1. Once a user has selected a stream, upd
On Wed, Oct 9, 2019 at 6:32 AM Fabio Valentini wrote:
>
> On Wed, Oct 9, 2019, 12:29 Miro Hrončok wrote:
>>
>> On 04. 10. 19 21:31, Miro Hrončok wrote:
>> > On 04. 10. 19 16:57, Stephen Gallagher wrote:
>> >> Right now, there are two conflicting requirements in Fedora Modularity
>> >> that we nee
On Wed, Oct 09, 2019 11:52:28 +0300, Panu Matilainen wrote:
> On 10/8/19 3:26 PM, Ankur Sinha wrote:
> > On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote:
> > >
> > >
> > > Look, I'm no more in love with the traditional layout than anybody, I'm
> > > just
> > > saying changing the defa
On Wed, Oct 9, 2019 at 5:33 AM Miro Hrončok wrote:
>
> On 09. 10. 19 4:34, Nico Kadel-Garcia wrote:
> > On Tue, Oct 8, 2019 at 1:56 PM Irina Boverman wrote:
> >>
> >> Using "BuildRequires: python%{python3_pkgversion}-devel" results in this
> >> error:
> >>
> >> fedpkg scratch-build
> >> DEBUG u
On Tue, Oct 08, 2019 at 06:03:26PM +0200, Jun Aruga wrote:
> Someone, could give us advice about below situation, if the new
> package htslib's "/usr/lib64/libhts.so.1.9" is valid?
> "1.9" is upstream software's version. "2" is ABI's version (so version).
The patterns used in filenames of so objec
On Tue, 2019-10-08 at 18:42 +0100, Tomasz Kłoczko wrote:
> IMO above shows clearly that adding "aspell-en" in mc or aspell
> dependencies does not solve issue .. at all.
> Kind of mitigation of that problem should be IMO change aspell error
> message (by add Fedora/any rpm based distro patch) infor
On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
It's going to be a while before EPEL gets all of the "python36"
labeled packages rebuilt to say "Provides: python3-module" as well as
"Provides: python36-module" for complete consistency with the altered
name used by RHEL. The epel-rpm-macros packag
Hi all,
decided to disable aspell support in mc as a whole. Note it is disabled by
default configure option in mc anyway. A beneficial side effect is we have
now even smaller dependency footprint and the annoying message while
editing *any* file goes away without aspell + friends installed.
This
I intend to unretire the "libresample" package in Fedora, now that I have
it building properly from source again. It needs a re-review, which I've
asked for at https://bugzilla.redhat.com/show_bug.cgi?id=1759928.
I will open a Rel-Eng ticket for unretirement once the package has been
re-reviewed.
On Wed, Oct 9, 2019 at 7:47 AM Jared K. Smith
wrote:
> I intend to unretire the "libresample" package in Fedora, now that I have
> it building properly from source again. It needs a re-review, which I've
> asked for at https://bugzilla.redhat.com/show_bug.cgi?id=1759928.
>
I can take it unless
https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy
Note that this was originally discussed on the devel mailing list:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQX67DLC/#TBWSCGWFSGUFFYIBEAIOSPSP43WYQ7WI
== Summary ==
Thi
On Wed, Oct 9, 2019 at 8:57 AM Richard Shaw wrote:
> I can take it unless someone gets to it first. I'm in training today and
> then have to catch up everything else once I'm done so it may be a few days
> :)
>
Thanks... let me know if you'd like me to review one of your packages in
return.
--
On Wed, Oct 9, 2019 at 9:15 AM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy
>
> Note that this was originally discussed on the devel mailing list:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RQW6L265IIVHUIHNXPELEFMIBQ
On 09. 10. 19 16:00, Neal Gompa wrote:
Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people
can start using it? Aside from the Obsoletes and the symlinks, there's
no particular reason that we couldn't have it in F31, and conditioning
for below F32 would make things easier...
I
You may have seen this posted in a few places, but the Open TestCon
CfP is open through 31 October. This conference is focused on testing
quality in open source projects. It will be held 30–31 March 2020 in
Beijing, CN.
Additionally, the DevConf.CZ (24–26 January in Brno, CZ) CfP is open
through 1
You may have seen this posted in a few places, but the DevConf.CZ Call
for Proposals is open. As in years past, there is a dedicated Fedora
track in addition to tracks on Community, IoT, cloud/containers,
microservices, networking, desktop, and more. DevConf.CZ is 24–26
Jaunary 2020 in Brno, CZ.
O
On 09. 10. 19 16:08, Miro Hrončok wrote:
On 09. 10. 19 16:00, Neal Gompa wrote:
Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people
can start using it? Aside from the Obsoletes and the symlinks, there's
no particular reason that we couldn't have it in F31, and conditioning
for
Hey folks! Just to let folks know that the openQA job scheduling robot
(for the production instance) had a bad day and needed to go lie down
for a bit, so it didn't schedule any tests for any new composes or
critpath updates that appeared from about Oct 07 17:08:42 UTC until
about Oct 09 15:00:00 (
On 09. 10. 19 17:19, Miro Hrončok wrote:
On 09. 10. 19 16:08, Miro Hrončok wrote:
On 09. 10. 19 16:00, Neal Gompa wrote:
Could we get Breezy in Fedora 31 (not replacing Bazaar) so that people
can start using it? Aside from the Obsoletes and the symlinks, there's
no particular reason that we cou
On Wed, Oct 09, 2019 at 06:39:07AM -0400, Neal Gompa wrote:
> It's being pushed so hard because it has been promoted as a top level
> objective, and because it's in RHEL now, no one can afford to let it
> fail. It *has* to succeed for RHEL, and for Fedora to remain a natural
> upstream for RHEL, it
OLD: Fedora-Rawhide-20191007.n.0
NEW: Fedora-Rawhide-20191009.n.0
= SUMMARY =
Added images:0
Dropped images: 3
Added packages: 31
Dropped packages:42
Upgraded packages: 176
Downgraded packages: 2
Size of added packages: 56.16 MiB
Size of dropped packages
Dear all,
The Go/No-Go meeting for the Fedora 31 Beta release will be held on
Thursday, 2019-10-17 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
View the meeting on Fedocal at:
https://apps.fedoraproject.org/calendar/Fedora%20release
On Wed, Oct 9, 2019 at 1:20 PM Ben Cotton wrote:
>
> The Go/No-Go meeting for the Fedora 31 Beta release will be held on
I mean final, of course.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
test-anno
On Tue, 2019-10-08 at 10:07 -0500, Richard Shaw wrote:
> On Tue, Oct 8, 2019 at 1:35 AM Ralf Corsepius wrote:
>
> > On 10/8/19 8:03 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Mon, Oct 07, 2019 at 04:34:28PM -0400, Scott Talbert wrote:
> > > > On Mon, 7 Oct 2019, Richard Shaw wrote:
> > > >
Stupid question: does FreeCAD have nightly packages (like openscad)?
If so, how complicate would it be to run the coin4 version there for a
while so people can monkey with it and find issues? Then give some
time; if it seems to work happy, make it production.
Just my two pesos Russos.
Hi,
Some minutes before started "Final Freeze" we send some packages to
stable on bodhi [1], but bodhi didn't push then ... .
I.e After final freeze announce could we have the last bodhi push ? I
my point of view is not fair as a developer , having to deal with Bodhi
delays ...
Thanks
[1]
http
On Wed, Oct 09, 2019 11:54:14 +0100, Ankur Sinha wrote:
> On Wed, Oct 09, 2019 11:52:28 +0300, Panu Matilainen wrote:
> > On 10/8/19 3:26 PM, Ankur Sinha wrote:
> > > On Tue, Oct 08, 2019 13:03:48 +0300, Panu Matilainen wrote:
> > > >
> > > >
> > > > Look, I'm no more in love with the traditional
Change in package status over the last 168 hours
0 packages were orphaned
0 packages were retired
0 packages unorphaned
-
0 packages were unretired
0
Dear all,
Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 31
Final Release Readiness meeting. This meeting will be held on
Thursday, 2019-10-17 at 19:00 UTC.
We will meet to make sure we are coordinated and ready for the release
of Fedora 31 Final. Please note that this meeting w
OLD: Fedora-31-20191008.n.1
NEW: Fedora-31-20191009.n.0
= SUMMARY =
Added images:3
Dropped images: 2
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
> On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote:
>
>> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
>> It's going to be a while before EPEL gets all of the "python36"
>> labeled packages rebuilt to say "Provides: python3-module" as well as
>> "Provides: python36-module" for complete consisten
On Wed, 9 Oct 2019 at 15:24, Nico Kadel-Garcia wrote:
>
>
>
> > On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote:
> >
> >> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
> >> It's going to be a while before EPEL gets all of the "python36"
> >> labeled packages rebuilt to say "Provides: python3-modu
Hello everyone,
You are all invited to attend the Open NeuroFedora team meeting this week
on Thursday (10th October) at 1500UTC in #fedora-neuro on IRC (Freenode):
https://webchat.freenode.net/?channels=#fedora-neuro
You can convert the meeting time to your local time using:
$ date --date='TZ="U
https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
Enable module default streams in the buildroot repository for modular
and non-modular RPMs.
== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provi
On 09. 10. 19 18:30, Matthew Miller wrote:
The problem is that the RHEL approach to modules only works because
RHEL is centrally developed and can be correctly coordinated to
overcome issues in the design. This is not true in Fedora, and there
doesn't seem to be allowances for this difference.
On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:
On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote:
On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
It's going to be a while before EPEL gets all of the "python36"
labeled packages rebuilt to say "Provides: python3-module" as well as
"Provides: python36
Jun Aruga wrote:
> Someone, could give us advice about below situation, if the new
> package htslib's "/usr/lib64/libhts.so.1.9" is valid?
> "1.9" is upstream software's version. "2" is ABI's version (so version).
This can happen with non-autotools, non-libtool projects. libtool enforces
some str
Dridi Boukelmoune wrote:
> Modularity should have been opt-in until major bugs are ironed out,
> and maybe we would have realized in time that either it's great or it
> doesn't solve anything the problem it's addressing.
+1
Kevin Kofler
___
deve
Matthew Miller wrote:
> Yeah, I agree that there's a problem with non-parallel-installable modules
> that aren't effectively leaves.
The problem does not only happen if the module is a non-leaf at module
level, but there can also be conflicts at package level, if the modules
bundle non-leaf pack
Miro Hrončok wrote:
> I disagree strongly with the reasons provided in the logs, but clearly, we
> should aim for solution 1. if solution 2. is not negotiable by the
> modularity WG.
+1
Kevin Kofler
___
devel mailing list -- devel@lists.fedorapr
Fabio Valentini wrote:
> Why am I not getting rid of the feeling that Modularity is getting shoved
> down our throats no matter the objections we raise?
I have had that feeling from day one. Things have not improved since. So you
are not alone with that feeling.
Kevin Kofler
Robbie Harwood wrote:
> What's missing from a more Debian-style solution [1] (for instance) is a
> more full understanding of dependencies. We could implement "Provides:"
> (or something like it) and be done with it. This also could have the
> side affect of making package version upgrades more c
On 09. 10. 19 22:46, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
Enable module default streams in the buildroot repository for modular
and non-modular RPMs.
== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-
On Wed, 9 Oct 2019 at 18:46, Miro Hrončok wrote:
>
> What I miss in the description is:
>
> 1. How does this thing actually work? is there an additional repository
> composed
> from the default streams available in Koji only?
>
> 2. How are conflicts between packages from the default streams and
On 10. 10. 19 1:44, Stephen John Smoogen wrote:
On Wed, 9 Oct 2019 at 18:46, Miro Hrončok wrote:
What I miss in the description is:
1. How does this thing actually work? is there an additional repository composed
from the default streams available in Koji only?
2. How are conflicts betwee
No missing expected images.
Failed openQA tests: 4/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191008.n.1):
ID: 465842 Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/465842
Old failures (same test failed in Fedora-31-2019
No missing expected images.
Failed openQA tests: 8/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191007.n.0):
ID: 464926 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/464926
ID: 464927 Test: x86_64 KDE-live-iso desktop_
No missing expected images.
Compose FAILS proposed Rawhide gating check!
2 of 45 required tests failed, 2 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.clo
On Wed, Oct 9, 2019 at 6:24 PM Miro Hrončok wrote:
>
> On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:
> >> On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote:
> >>> On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
> >>> It's going to be a while before EPEL gets all of the "python36"
> >>> labeled packa
On 10. 10. 19 2:11, Nico Kadel-Garcia wrote:
On Wed, Oct 9, 2019 at 6:24 PM Miro Hrončok wrote:
On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:
On Oct 9, 2019, at 8:03 AM, Miro Hrončok wrote:
On 09. 10. 19 13:47, Nico Kadel-Garcia wrote:
It's going to be a while before EPEL gets all of the
On 09. 10. 19 21:23, Nico Kadel-Garcia wrote:
I'm not happy that RHEL upstream selected to use "python3" instead of
"python36" as the package name for their release of Python 3.6. Like
modularity, it's solving one problem but generating others.
All RHEL python3 packages also provide their pytho
Sérgio Basto wrote on 2019/10/10 3:06:
Hi,
Some minutes before started "Final Freeze" we send some packages to
stable on bodhi [1], but bodhi didn't push then ... .
I.e After final freeze announce could we have the last bodhi push ? I
my point of view is not fair as a developer , having to deal
Missing expected images:
Soas live x86_64
Failed openQA tests: 2/31 (x86_64)
ID: 466138 Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/466138
ID: 466148 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.
On Tue, Oct 8, 2019 at 3:54 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:
> On Tue, Oct 08, 2019 at 08:32:47AM +0200, Ralf Corsepius wrote:
> > >
> > >Those are fairly substantial changes, but time is of essence here.
> > I could not disagree more. Quality and stability is of more ess
Hi all,
I'm in the midst of the mpfr 4 rebuilds. I just tried to kick off a
long chain build, the first build of which is the final gcc rebuild
that will give us an mpfr 4-using gcc. Unfortunately, not all of its
dependencies could be installed on s390x; root.log says:
DEBUG util.py:593: No ma
Anyone else seeing this? If so, anyone know the reason and plans to
fix? Thanks!
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301
On Wed, Oct 9, 2019 at 8:25 PM Jerry James wrote:
> The previous build managed to grab the last build of glibc32 for
> s390x, it seems. I'm going to assume that this means that s390x
> should be removed from the multilib_64_arches variable in the gcc
> spec, just so I can keep these builds going.
* Jerry James:
> On Wed, Oct 9, 2019 at 8:25 PM Jerry James wrote:
>> The previous build managed to grab the last build of glibc32 for
>> s390x, it seems. I'm going to assume that this means that s390x
>> should be removed from the multilib_64_arches variable in the gcc
>> spec, just so I can ke
66 matches
Mail list logo
