On 10/7/19 8:55 PM, Simo Sorce wrote:
I have to ask,
given containers are so popular and can deal with any dependency
without conflicting with system installed binaries, should we really
continue with this very complicated modular design ?
There are only few people who fully understand how modu
On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> On 10/10/19 4:57 PM, Orion Poplawski wrote:
> > On 10/10/19 9:23 AM, Kevin Fenzi wrote:
[...]
> > > Pretty please can you all indicate approximately when (UTC) you were
> > > seeing the slowness? I suspect it may be the nightly database
FPC 3.2.0 hasn't been released yet - this Change Proposal is a bit of a early
heads-up. The FPC website says it should be out before the end of the year.
Once it's released, after updating rawhide, a COPR repo can be prepared.
___
devel mailing list --
I don't think containers can replace modularity. They need to coexist.
> If we want to create containers built on top of a distribution (no
> randomly picked bits from the internet, reproducible builds, security,
> ...), we need a way to distribute multiple versions of the software
> (module stream
Yes, dependent packages should use %{fpc_arches}. FPC itself doesn't do that.
I imagine the reason is that this allows us to add new architectures to FPC and
do some trial-and-error builds of FPC without affecting dependent packages - if
FPC itself used %{fpc_arches}, then adding new architectur
Hi All,
Per the
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
procedure here is a mail to let people know I have filed a request to
unretire tolua++: https://pagure.io/releng/issue/8895
tolua++ was retired as part of the recen
Hi All,
Per the
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
procedure here is a mail to let people know I have filed a request to
unretire tolua++: https://pagure.io/releng/issue/8895
tolua++ was retired as part of the recen
* Jerry James:
> On Thu, Oct 10, 2019 at 12:39 AM Florian Weimer wrote:
>> Sorry, I wasn't aware that you were trying to rebuild gcc this week. I
>> spoke to Jakub about the glibc32 change, and he had no objections.
>>
>> It's not clear how you are handling the transition. Why do you need to
>>
On 11. 10. 19 12:11, Hans de Goede wrote:
Hi All,
Per the
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
procedure here is a mail to let people know I have filed a request to
unretire tolua++: https://pagure.io/releng/issue/
Hi,
On 10/11/19 1:20 PM, Miro Hrončok wrote:
On 11. 10. 19 12:11, Hans de Goede wrote:
Hi All,
Per the
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
procedure here is a mail to let people know I have filed a request to
unreti
Il 11/10/19 11:39, Artur Iwicki ha scritto:
> Yes, dependent packages should use %{fpc_arches}. FPC itself doesn't do that.
>
Ah, I misunderstood the phrase `Add AArch64 and ppc64le to the
`ExclusiveArch:` tag in the package spec.`.
I thought you were saying to add those ExclusiveArch to all pack
On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka wrote:
> Seeing the reaction of the Modularity WG ... I do not understand how it is
> possible that such important decisions are taken by 4 people without any
> Fedora wide discussions like this. And yet, it seems a little bit that even
> opinions on
On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote:
> On 10/7/19 8:55 PM, Simo Sorce wrote:
> > I have to ask,
> > given containers are so popular and can deal with any dependency
> > without conflicting with system installed binaries, should we really
> > continue with this very complicated modu
On Fri, Oct 11, 2019 at 10:13 AM Dominik 'Rathann' Mierzejewski
wrote:
>
> On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> > On 10/10/19 4:57 PM, Orion Poplawski wrote:
> > > On 10/10/19 9:23 AM, Kevin Fenzi wrote:
> [...]
> > > > Pretty please can you all indicate approximately when
On Fri, 11 Oct 2019 at 09:19, Peter Robinson wrote:
>
> On Fri, Oct 11, 2019 at 10:13 AM Dominik 'Rathann' Mierzejewski
> wrote:
> >
> > On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> > > On 10/10/19 4:57 PM, Orion Poplawski wrote:
> > > > On 10/10/19 9:23 AM, Kevin Fenzi wrote:
>
On Thu, Oct 10, 2019 at 10:35:23AM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Free_Pascal_Compiler_3.2.0
>
> == Summary ==
> Update the Free Pascal Compiler used within Fedora to version 3.2.0,
> once it is published, and enable building (previously unsupported)
> AArch64 an
On Wed, Oct 09, 2019 at 08:21:37AM -0700, Adam Williamson wrote:
> 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 t
Hello,
Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
2.0.0 to libdav1d.so.3.0.0.
I will be updating it next week on F31/32, consumers of these libraries
(ffmpeg, xine-lib, vlc) will need to rebuild their packages.
Best regards,
Robert-André
On Fri, Oct 11, 2019 at 5:08 AM Florian Weimer wrote:
> And did not bump soname at the same time? I suspected as much once I
> stared at the problem some more.
Yes, that's exactly right.
> Oh, if mpfr and mpc had bumped soname at the same time, the
> BuildRequires: change would not have been ne
OLD: Fedora-31-20191010.n.0
NEW: Fedora-31-20191011.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 2
Dropped packages:1
Upgraded packages: 50
Downgraded packages: 0
Size of added packages: 7.63 MiB
Size of dropped packages:834.47 KiB
Dne 11. 10. 19 v 1:27 Orion Poplawski napsal(a):
I continue to run into strange (at least to me) issues with modules on EL8. RHEL8 ships a 'rhn-tools' module that ships
only the "koan" package from the cobbler srpm [1]. When this module is enabled, I cannot install cobbler from my copr -
dnf r
Le 11/10/2019 à 16:10, Robert-André Mauchin a écrit :
Hello,
Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
2.0.0 to libdav1d.so.3.0.0.
I will be updating it next week on F31/32, consumers of these libraries
(ffmpeg, xine-lib, vlc) will need to rebuild their packages.
On Thu, 10 Oct 2019 at 20:33, Kevin Kofler wrote:
>
> Matthew Miller wrote:
> > On Thu, Oct 10, 2019 at 12:28:37AM +0200, Kevin Kofler wrote:
> >> 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
> >
Le ven. 11 oct. 2019 à 16:33, Xavier Bachelot a écrit :
>
> Le 11/10/2019 à 16:10, Robert-André Mauchin a écrit :
> > Hello,
> >
> > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> > 2.0.0 to libdav1d.so.3.0.0.
> > I will be updating it next week on F31/32, consumers o
On Thu, 10 Oct 2019 at 19:28, Orion Poplawski wrote:
>
> I continue to run into strange (at least to me) issues with modules on
> EL8. RHEL8 ships a 'rhn-tools' module that ships only the "koan"
> package from the cobbler srpm [1]. When this module is enabled, I
> cannot install cobbler from my
On 14. 08. 19 14:23, Miro Hrončok wrote:
Hello.
Recently, a couple hundred packages were retired from rawhide (Fedora 31 at that
time) based on the Fedora Failed to Build From Source Policy [1]. From various
reactions over several threads it seems this policy is not ideal. This is an
attempt
No missing expected images.
Failed openQA tests: 5/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191010.n.0):
ID: 467475 Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/467475
ID: 467476 Test: x86_64 Serve
Hello,
In accordance with Fedora's non-responsive maintainer policy, I'm
sending this message in attempt to contact Jamie Nguyen (jamielinux).
Required non-responsive maintainer bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1760898
Open unaddressed bugs (219 in total):
https://bugzilla.redhat
> "AI" == Artur Iwicki writes:
AI> I imagine the reason is that this allows us to add new
AI> architectures to FPC and do some trial-and-error builds of FPC
AI> without affecting dependent packages - if FPC itself used
AI> %{fpc_arches}, then adding new architectures to FPC would require
AI>
Hi,
https://src.fedoraproject.org/modules/ returns 404, and
https://src.fedoraproject.org/browse/projects/ seems to list rpms/
(though there's 622 pages of output, so I'm not sure).
Is there a way to browse through module repos?
Zbyszek
___
devel maili
If you go to any modular repo:
https://src.fedoraproject.org/modules/eclipse
And click on "modules" in the path at the top, it takes you to:
https://src.fedoraproject.org/projects/modules/%2A
Which lists them all.
- Original Message -
> From: "Zbigniew Jędrzejewski-Szmek"
> To:
On Mon, Oct 07, 2019 at 04:34:21PM -0400, Matthew Miller wrote:
> On Mon, Oct 07, 2019 at 08:13:17PM +0200, Fabio Valentini wrote:
> > To quote you from the other ongoing thread: "The default stream for a
> > package shouldn't be updated in disruptive ways in shipped releases"
> > If that's the cas
Hi everyone,
Welcome to the CPE team weekly project update mail!
Background: The Community Platform Engineering group is the Red Hat team
combining IT and release engineering from Fedora and CentOS. Our goal is to
keep core servers and services running and maintained, build releases, and
other s
On Fri, Oct 11, 2019 at 09:22:11AM -0400, Stephen John Smoogen wrote:
> On Fri, 11 Oct 2019 at 09:19, Peter Robinson wrote:
> >
> > On Fri, Oct 11, 2019 at 10:13 AM Dominik 'Rathann' Mierzejewski
> > wrote:
> > >
> > > On Friday, 11 October 2019 at 04:36, Orion Poplawski wrote:
> > > > On 10/10/1
On Fri, Oct 11, 2019 at 6:57 AM Simo Sorce wrote:
>
> On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote:
> > On 10/7/19 8:55 PM, Simo Sorce wrote:
> > > I have to ask,
> > > given containers are so popular and can deal with any dependency
> > > without conflicting with system installed binaries
On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher wrote:
>
>
>
> On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka wrote:
>>
>> Seeing the reaction of the Modularity WG ... I do not understand how it is
>> possible that such important decisions are taken by 4 people without any
>> Fedora wide disc
Chris Murphy writes:
> On Fri, Oct 11, 2019 at 6:57 AM Simo Sorce wrote:
>> On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote:
>>> On 10/7/19 8:55 PM, Simo Sorce wrote:
I have to ask, given containers are so popular and can deal with
any dependency without conflicting with system in
Just a random thought I had but I actually have no idea which
contributors/packagers are closest to me here in Mississippi, USA.
That got me thinking it would be pretty neat if a map could be
automagically creating showing where everyone is. Wouldn't need exact
addresses for privacy reasons but so
On Fri, Oct 11, 2019 at 2:48 PM Richard Shaw wrote:
>
> Just a random thought I had but I actually have no idea which
> contributors/packagers are closest to me here in Mississippi, USA.
>
> That got me thinking it would be pretty neat if a map could be automagically
> creating showing where eve
On Fri, 2019-10-11 at 14:42 -0400, Robbie Harwood wrote:
>
> I believe the point most of us are struggling with is: there's no
> definition of what advantages of modularity are. There may or may not
> be some idea of what the advantages could be, which is a different
> thing. This makes it reall
On Fri, Oct 11, 2019, 8:48 PM Richard Shaw wrote:
>
> That got me thinking it would be pretty neat if a map could be
> automagically creating showing where everyone is. Wouldn't need exact
> addresses for privacy reasons but something that gets you close like a zip
> code (or equivalent).
>
> Tho
On Fri, Oct 11, 2019 at 1:51 PM Neal Gompa wrote:
> On Fri, Oct 11, 2019 at 2:48 PM Richard Shaw wrote:
> >
> > Just a random thought I had but I actually have no idea which
> contributors/packagers are closest to me here in Mississippi, USA.
> >
> > That got me thinking it would be pretty neat
On Fri, Oct 11, 2019 at 3:02 PM Richard Shaw wrote:
>
> On Fri, Oct 11, 2019 at 1:51 PM Neal Gompa wrote:
>>
>> On Fri, Oct 11, 2019 at 2:48 PM Richard Shaw wrote:
>> >
>> > Just a random thought I had but I actually have no idea which
>> > contributors/packagers are closest to me here in Missi
As part of creating Fedora CoreOS (and derivatives like Red Hat Enterprise
Linux CoreOS), we are making some fairly fundamental changes to how the
operating system works - while OSTree isn't new to Fedora, Ignition is - and
more broadly than that, using Ignition implies something much more simil
- Original Message -
> From: "Neal Gompa"
> To: "Development discussions related to Fedora"
>
> Sent: Friday, October 11, 2019 2:36:58 PM
> Subject: Re: Modularity and the system-upgrade path
>
> On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher
> wrote:
> >
> >
> >
> > On Thu, Oct 10,
Next week is the Go/No-Go meeting. Wouldn't it be great if this was
the last blocker status email?
Action summary
Accepted blockers
-
1. mutter — can't turn zoom off once enabled — POST
ACTION: upstream to merge fixes
2. distribution — Cannot upgrade to Fedor
On 10/11/19 12:47 PM, Richard Shaw wrote:
> Just a random thought I had but I actually have no idea which
> contributors/packagers are closest to me here in Mississippi, USA.
>
> That got me thinking it would be pretty neat if a map could be automagically
> creating showing where everyone is. Woul
On 10/11/19 12:20 PM, Kevin Fenzi wrote:
> So to update this thread some:
>
> * Load is fine/responsiveness is fine as long as we aren't doing a
> database dump.
> * When we do, things slow down and load goes way up.
>
> We did find one very odd/bad thing on the virthost the server is on (one
>
On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> No. Resolving conflicts implies that you need to do an actual merge,
> NOT a
> fast forward. Fast-forwarding means that I am shipping the SAME
> commit on
> all branches, so the changelog must be identical (unless I play games
> with
> %if
Hi folks! I'm proposing we cancel the QA meeting for Monday. Once again
I don't think there's anything urgent right now (the Xen criterion
probably isn't urgent again as it looks like we have a fix for the bug
there) and we're focused on F31 release testing right now. There will
be a blocker review
# F31 Blocker Review meeting
# Date: 2019-10-14
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 6 proposed Final blockers and 11 proposed Final freeze
exception to review, so let's have a Fedora 31 blocker review meeting
on Monday!
If you have time today
On Fri, 2019-10-11 at 17:10 -0400, Randy Barlow wrote:
> On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> > No. Resolving conflicts implies that you need to do an actual merge,
> > NOT a
> > fast forward. Fast-forwarding means that I am shipping the SAME
> > commit on
> > all branches, so
On Fri, 11 Oct 2019 at 14:29, Chris Murphy wrote:
>
> > My main gripe is the current situation where users are thrown under the
> > bus and then we give them a business card and say: read these
> > instruction to figure out how to save yourself.
> > I think this is unacceptable.
>
> Ordinary ever
> systemctl daemon-reload?
Thanks Dridi. I had forgotten to mention that I had tried daemon-reload and
that did not help.
> Isn't this handled automatically by the %systemd scriptlets?
%systemd_post macro is a no-op for upgrade case -
https://github.com/systemd/systemd/blob/master/src/core/mac
On Fri, Oct 11, 2019 at 02:59:19PM -0600, Orion Poplawski wrote:
> On 10/11/19 12:47 PM, Richard Shaw wrote:
> > Just a random thought I had but I actually have no idea which
> > contributors/packagers are closest to me here in Mississippi, USA.
> >
> > That got me thinking it would be pretty neat
No missing expected images.
Compose FAILS proposed Rawhide gating check!
3 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 Fri, Oct 11, 2019 at 03:02:20PM -0600, Orion Poplawski wrote:
> On 10/11/19 12:20 PM, Kevin Fenzi wrote:
> > So to update this thread some:
> >
> > * Load is fine/responsiveness is fine as long as we aren't doing a
> > database dump.
> > * When we do, things slow down and load goes way up.
>
OLD: Fedora-Rawhide-20191010.n.0
NEW: Fedora-Rawhide-20191011.n.1
= SUMMARY =
Added images:0
Dropped images: 2
Added packages: 9
Dropped packages:63
Upgraded packages: 245
Downgraded packages: 0
Size of added packages: 15.61 MiB
Size of dropped packages
> Hello,
>
> Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
> 2.0.0 to libdav1d.so.3.0.0.
> I will be updating it next week on F31/32, consumers of these libraries
> (ffmpeg, xine-lib, vlc) will need to rebuild their packages.
>
> Best regards,
>
> Robert-André
I'm
On Fri, 2019-10-11 at 14:34 -0700, Adam Williamson wrote:
> That seems like a personal call, really. I very much like being able
> to
> keep branches in sync without merge commits as it means I can do
> stuff
> like:
>
> for i in el6 epel7 f29 f30 f31 master; do fedpkg switch-branch $i;
> git
> pu
On Thu, 2019-10-03 at 19:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> > As pointed out elsewhere, we would have fewer conflicts if we could
> > get
> > the version, release, and changelog out of the spec file, and then
> > I
> > think maintaining different spec in different release branches
> > w
> You need something like this in a scriptlet:
> if systemctl is-enabled A; systemctl reenable A; done
>
> This will remove the old links and create the new ones.
Thanks Zbigniew for the idea. It seemed very promising and I tried it.
Unfortunately, it still did not help because "reenable" command
62 matches
Mail list logo
