On Wed, Oct 16, 2019 at 03:03:02PM -0400, Stephen Gallagher wrote:
> On Wed, Oct 16, 2019 at 2:56 PM Matthew Miller
> wrote:
> >
> > On Wed, Oct 16, 2019 at 01:32:49PM -0400, Stephen Gallagher wrote:
> > > remove it" or something like that. It should never be used in the
> > > general case. Not e
On Wed, Oct 16, 2019 at 8:56 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Oct 16, 2019 at 10:49:29AM -0700, Kevin Fenzi wrote:
> > On Wed, Oct 16, 2019 at 10:02:12AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > I submitted a Change for wrangling today, but I'm also putting it here
> > > fo
On Thu, Oct 17, 2019 at 9:39 AM Pierre-Yves Chibon wrote:
>
> On Wed, Oct 16, 2019 at 03:03:02PM -0400, Stephen Gallagher wrote:
> > On Wed, Oct 16, 2019 at 2:56 PM Matthew Miller
> > wrote:
> > >
> > > On Wed, Oct 16, 2019 at 01:32:49PM -0400, Stephen Gallagher wrote:
> > > > remove it" or some
On 17. 10. 19 2:27, Stephen Gallagher wrote:
So, literally every word of this is wrong. The negative feedback is
not "overwhelming". It is approximately four noisy individuals, all of
whom have expressed zero interest in understanding the actual
situation that they are trying to "fix" by endlessl
On Thu, Oct 17, 2019 at 07:46:04AM +, Dridi Boukelmoune wrote:
> I may have used yum in the past to grab and NodeJS
> dependency, but actual "node" developers will certainly use tools from
> the NodeJS ecosystem like npm. Your average developer doesn't sit
> under a waterfall and decides that t
Hello,
I cannot help you with FAS, but if you could specify what problems do
you have with the softwarecollections.org, I may be able to do
something. Is this an issue with the website itself, or with a certain
collections?
Best regards,
Jan
--
Jan Staněk
Associate Software Engineer
Red Hat E
On 16. 10. 19 20:14, Adam Samalik wrote:> == PostgreSQL ==
Started talking to the maintainers about removing systemd, python2, and to
consider skipping weak dependencies in the container use case.
Thanks! Please keep mes looped in for the python2 thing.
--
Miro Hrončok
--
Phone: +42077797480
On to, 17 loka 2019, Miro Hrončok wrote:
On 17. 10. 19 2:27, Stephen Gallagher wrote:
So, literally every word of this is wrong. The negative feedback is
not "overwhelming". It is approximately four noisy individuals, all of
whom have expressed zero interest in understanding the actual
situation
On Wed, Oct 16, 2019 22:13:16 -0600, Orion Poplawski wrote:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-497f765fe8
Thank you. I've requested a buildroot override and will build MUSIC as
soon as it is active.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fe
On 16. 10. 19 19:28, Stephen Gallagher wrote:
1) This will be solved by the new Koji/MBS feature that we've
codenamed "Ursa Prime" (as a replacement for the original "Ursa Major"
tool that was built for RHEL 8). Unlike its predecessor, it requires
no additional daemon service running to handle th
On 17. 10. 19 2:41, Stephen Gallagher wrote:
For example, we might have packages whose buildsystem
still relies on Python 2 (WAF?) but doesn't require it at runtime.
We do have them. How does that relate to modularity at all?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
__
- Original Message -
> From: "Stephen Gallagher"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, October 17, 2019 2:41:28 AM
> Subject: Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular
> Buildroot
>
> > > (And how would restricting default str
Hey, I've just noticed something that I find a bit odd:
This python38 update is on it's way to f31 stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-c26f535d3c
This newer python38 update was submitted yesterday:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-adde83b6b7
...but i
First of all, sorry for replying so late, Benjman was quite busy with
GNOME and sytemd user session transistion and is now on a longer PTO.
On Mon, 2019-09-23 at 16:29 +0200, Igor Gnatenko wrote:
> So what are we going to do about this in F32? Are we going to create
> configuration files or we wil
On Tue, 2019-09-24 at 09:08 +0200, Vít Ondruch wrote:
> This sounds interesting, but this tool is probably coming late into
> play to fix early boot thermal throttling issues such as:
We submitted a patch to the kernel to lower the severity of those
messages, because they indeed are usually not cr
On Thu, Oct 17, 2019 at 10:34 AM Miro Hrončok wrote:
>
> Hey, I've just noticed something that I find a bit odd:
>
> This python38 update is on it's way to f31 stable:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-c26f535d3c
>
> This newer python38 update was submitted yesterday:
>
> htt
Alexander Bokovoy wrote:
> On to, 17 loka 2019, Kevin Kofler wrote:
>>… which is exactly why it causes version hell.
> It does not cause version hell in a system where you cannot install
> multiple versions at the same time.
You do not necessarily do that explicitly. The conflicting versions can b
On 17. 10. 19 12:19, Peter Robinson wrote:
On Thu, Oct 17, 2019 at 10:34 AM Miro Hrončok wrote:
Hey, I've just noticed something that I find a bit odd:
This python38 update is on it's way to f31 stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-c26f535d3c
This newer python38 updat
Alexander Bokovoy wrote:
> The one thing we are using default modular stream in RHEL 8 for is to be
> able to provide access to packages in kickstart that were moved to
> modules in RHEL 8. An example is idm:client stream which is a default
> module stream in RHEL 8 exactly for this reason, to be a
On Wed, Oct 16, 2019 15:02:44 -0400, Matthew Miller wrote:
> On Wed, Oct 16, 2019 at 06:22:52PM +0200, Brian (bex) Exelbierd wrote:
> > I haven't heard anyone mention FOSDEM yet. Booth applications are due soon
> > and I'd like to see us coordinate again with our friends in CentOS. Is
> > there a
On to, 17 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
On to, 17 loka 2019, Kevin Kofler wrote:
… which is exactly why it causes version hell.
It does not cause version hell in a system where you cannot install
multiple versions at the same time.
You do not necessarily do that exp
On to, 17 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
The one thing we are using default modular stream in RHEL 8 for is to be
able to provide access to packages in kickstart that were moved to
modules in RHEL 8. An example is idm:client stream which is a default
module stream in RHE
On Thu, Oct 17, 2019 at 5:17 AM Miro Hrončok wrote:
>
> On 17. 10. 19 2:41, Stephen Gallagher wrote:
> > For example, we might have packages whose buildsystem
> > still relies on Python 2 (WAF?) but doesn't require it at runtime.
>
> We do have them. How does that relate to modularity at all?
>
T
On Thu, Oct 17, 2019 at 5:27 AM Jakub Cajka wrote:
> For Go this is oversimplification and common misconception(go built binaries
> are not uncommonly dynamically linked in the "C/ELF" sense(glibc,...) and
> statically linked in Go sense). It might work for some selected(maybe even
> most) Go
On 17. 10. 19 13:38, Alexander Bokovoy wrote:
Had there be default module streams for Java packages in buildroot, we
would have no problem.
Had there been no default modular streams but regular packages instead, we would
have no problem either.
But to extend there a bit, that would also be c
On Thu, Oct 17, 2019 at 7:42 AM Stephen Gallagher wrote:
>
> Similarly, the example of "build on Rawhide, run anywhere" was
> backwards. I should have said "build on oldest supported Fedora, carry
> through".
Modules currently fail at this because they have a platform
dependency. And we could *ea
On Thu, Oct 17, 2019 at 7:48 AM Neal Gompa wrote:
>
> On Thu, Oct 17, 2019 at 7:42 AM Stephen Gallagher wrote:
> >
> > Similarly, the example of "build on Rawhide, run anywhere" was
> > backwards. I should have said "build on oldest supported Fedora, carry
> > through".
>
> Modules currently fail
On 17. 10. 19 13:41, Stephen Gallagher wrote:
On Thu, Oct 17, 2019 at 5:17 AM Miro Hrončok wrote:
On 17. 10. 19 2:41, Stephen Gallagher wrote:
For example, we might have packages whose buildsystem
still relies on Python 2 (WAF?) but doesn't require it at runtime.
We do have them. How does t
On Thu, Oct 17, 2019 at 7:53 AM Miro Hrončok wrote:
> > That was a representative example. I came up with it at 11pm after a
> > long day. Don't read too much into the specifics. The point was that
> > builds may require newer or older software than we have available in
> > the non-modular buildro
On 17. 10. 19 14:08, Stephen Gallagher wrote:
On Thu, Oct 17, 2019 at 7:53 AM Miro Hrončok wrote:
That was a representative example. I came up with it at 11pm after a
long day. Don't read too much into the specifics. The point was that
builds may require newer or older software than we have ava
On Thu, Oct 17, 2019 at 7:53 AM Stephen Gallagher wrote:
>
> On Thu, Oct 17, 2019 at 7:48 AM Neal Gompa wrote:
> >
> > On Thu, Oct 17, 2019 at 7:42 AM Stephen Gallagher
> > wrote:
> > >
> > > Similarly, the example of "build on Rawhide, run anywhere" was
> > > backwards. I should have said "bui
On Thu, Oct 17, 2019 at 8:33 AM Neal Gompa wrote:
> People regularly look at NEVRAs to identify whether there are
> "broken"/"old" packages to clean up, and when you see .fc29 installed
> on an otherwise .fc31 system, it looks like something has gone wrong.
> If packages are intended to be built o
On Thu, Oct 17, 2019 at 8:37 AM Stephen Gallagher wrote:
>
> On Thu, Oct 17, 2019 at 8:33 AM Neal Gompa wrote:
> > People regularly look at NEVRAs to identify whether there are
> > "broken"/"old" packages to clean up, and when you see .fc29 installed
> > on an otherwise .fc31 system, it looks lik
On Wed, 16 Oct 2019 at 13:33, Stephen Gallagher wrote:
>
> On Wed, Oct 16, 2019 at 1:19 PM Przemek Klosowski via devel
> wrote:
> >
> > On 10/15/19 9:26 PM, Stephen Gallagher wrote:
> I'm saying that the policy should forbid the use of that feature
> except for an absolute emergency, requiring a
Hello,
Can you specify which packages are the A & B?
I wanted to reproduce the initial situation - that the service
requiring another will put a symlink to the "/usr/lib/systemd/system".
I forged iptables RPM containing service file mentioning
"Requires=firewalld.service" to see the link to be cr
On Thu, Oct 17, 2019 at 4:33 AM Miro Hrončok wrote:
>
> On 17. 10. 19 2:27, Stephen Gallagher wrote:
> > So, literally every word of this is wrong. The negative feedback is
> > not "overwhelming". It is approximately four noisy individuals, all of
> > whom have expressed zero interest in understan
On 17. 10. 19 15:17, Stephen Gallagher wrote:
On Thu, Oct 17, 2019 at 4:33 AM Miro Hrončok wrote:
On 17. 10. 19 2:27, Stephen Gallagher wrote:
So, literally every word of this is wrong. The negative feedback is
not "overwhelming". It is approximately four noisy individuals, all of
whom have e
On Wed, Oct 16, 2019 at 9:39 PM Kevin Kofler wrote:
>
> So it looks like I did not describe clearly enough what my proposed
> enable_modules=0 flag would do. ("Disable all module code" was apparently
> too vague.)
>
> How I think it should work would be:
> * For repositories, it completely ignores
On Thu, 17 Oct 2019 at 09:24, Miro Hrončok wrote:
>
> On 17. 10. 19 15:17, Stephen Gallagher wrote:
> > On Thu, Oct 17, 2019 at 4:33 AM Miro Hrončok wrote:
> >>
> >> On 17. 10. 19 2:27, Stephen Gallagher wrote:
> >>> So, literally every word of this is wrong. The negative feedback is
> >>> not "o
On 10/16/19 7:36 PM, Kevin Kofler wrote:
It was never designed to solve parallel installability problem.
… which is exactly why it causes version hell.
Could you expand on that? Since a modular system currently prevents
parallel version installation, it may provide suboptimal/obsolete
version
On Thu, Oct 17, 2019 at 03:38:39AM +0200, Kevin Kofler wrote:
> > So, literally every word of this is wrong. The negative feedback is
> > not "overwhelming". It is approximately four noisy individuals, all of
> > whom have expressed zero interest in understanding the actual
> > situation that they
On Thu, Oct 17, 2019 at 5:34 AM Miro Hrončok wrote:
>
> Hey, I've just noticed something that I find a bit odd:
>
> This python38 update is on it's way to f31 stable:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-c26f535d3c
>
> This newer python38 update was submitted yesterday:
>
> http
On Thu, Oct 17, 2019 at 10:17 AM Pierre-Yves Chibon wrote:
>
> On Thu, Oct 17, 2019 at 03:38:39AM +0200, Kevin Kofler wrote:
> > So bringing yourselves up now as "the people who can dig us out of this
> > situation" feels to me feels like intentionally making a patient sick so you
> > can "cure" t
On Thu, 2019-10-17 at 03:53 +0200, Kevin Kofler wrote:
> The user-friendly approach for that is to use a parallel-installable
> compatibility package (with a suffixed Name, such as django1.6)
> instead of a
> module.
I've always liked Gentoo's solution to "too fast too slow" (which has
been arou
OLD: Fedora-31-20191016.n.0
NEW: Fedora-31-20191017.n.0
= SUMMARY =
Added images:9
Dropped images: 0
Added packages: 1
Dropped packages:0
Upgraded packages: 3
Downgraded packages: 0
Size of added packages: 38.00 MiB
Size of dropped packages:0 B
Size of
On Wed, 16 Oct 2019 at 20:27, Stephen Gallagher wrote:
>
> So, literally every word of this is wrong. The negative feedback is
> not "overwhelming". It is approximately four noisy individuals, all of
> whom have expressed zero interest in understanding the actual
> situation that they are trying
On Thu, 17 Oct 2019 at 10:06, Przemek Klosowski via devel
wrote:
>
> On 10/16/19 7:36 PM, Kevin Kofler wrote:
>
> It was never designed to solve parallel installability problem.
>
> … which is exactly why it causes version hell.
>
> Could you expand on that? Since a modular system currently preven
No missing expected images.
Failed openQA tests: 3/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191016.n.0):
ID: 471830 Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/471830
ID: 471949 Test: x86_64 Workst
On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> The one thing we are using default modular stream in RHEL 8 for is to be
> able to provide access to packages in kickstart that were moved to
> modules in RHEL 8. An example is idm:client stream which is a default
> module stre
On Thu, 2019-10-17 at 08:08 -0400, Stephen Gallagher wrote:
> One of the (often un- or misinformed) major arguments people keep
> using against Modularity is "it makes packaging harder!". This is one
> place where it makes things *much* easier on the packagers. It's a
> clear reduction in complexit
On Thu, 2019-10-17 at 11:19 +0100, Peter Robinson wrote:
> It doesn't obsolete it if it's already transitioning from testing ->
> stable because it's basically not in "testing" state. This happens
> all
> the time even during the usual cycle, it's generally just not seen
> during the usual cycle be
On Thu, 2019-10-17 at 10:52 -0400, Randy Barlow wrote:
> I've always liked Gentoo's solution to "too fast too slow"
> with their slots mechanism.
I realized it would be good if I explained what this is in more detail
for those who aren't familiar.
The slot is another field on the package, and the
On Thu, 2019-10-17 at 12:56 -0400, Randy Barlow wrote:
> I
> had to write a yaml file that listed hashes of every dependency of
> rpick, and every dependency of those dependencies, and their
> dependencies, and so on.
By the way, I didn't actually end up doing this, Igor did it for me. I
didn't me
Randy Barlow wrote:
> I'm not really sure which way would be better, but I think I lean
> towards thinking that maybe Bodhi really should wait until updates are
> all the way stable before accepting new updates for the same packages.
That would not be acceptable.
Mohan Boddhu's RFE:
https://githu
- Original Message -
> From: "Randy Barlow"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, October 17, 2019 1:18:08 PM
> Subject: Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular
> Buildroot
>
> On Thu, 2019-10-17 at 12:56 -0400, Randy Barlow wro
On Thu, 2019-10-17 at 08:08 -0400, Stephen Gallagher wrote:
> One of the (often un- or misinformed) major arguments people keep
> using against Modularity is "it makes packaging harder!".
One thing I've found to be a problem with modularity is that it's easy
to be un- or misinformed. I spent a lot
On Thu, 2019-10-17 at 13:43 +0200, Miro Hrončok wrote:
> On 17. 10. 19 13:38, Alexander Bokovoy wrote:
> > Had there be default module streams for Java packages in buildroot, we
> > would have no problem.
>
> Had there been no default modular streams but regular packages instead, we
> would
> ha
Alexander Bokovoy wrote:
> On to, 17 loka 2019, Kevin Kofler wrote:
>>Building against the distribution's version of libraries instead of some
>>arbitrarily picked version is pretty much the whole point of non-modular
>>packages.
> Right, and building against carefully chosen collection of dependen
Release status of Fedora 31 Final is NO-GO.
Due to open blocker bugs and the lack of a release candidate, Fedora
31 Final was declared "No-Go". We will reconvene at 1400 UTC (note the
departure from the usual time) on Thursday, 24 October[1] to target a
release date of Tuesday 29 October.
For mor
On 10/17/19 12:27 PM, Stephen John Smoogen wrote:
people are going to add things into their modules to make whatever
software they need. If I find that I need libfoo2-2.34 in libreoffice
and you need libfoo2-2.40 in evolution.. then only one of the two
modules can be installed.You can either have
On Thu, 17 Oct 2019 at 14:15, Randy Barlow wrote:
>
> Could we think of a solution that is simple so that packagers can more
> easily understand how it works?
The issue is how many different choices are you allowing and where you
are allowing them to be made. A lot of the gentoo and nixos seem t
On to, 17 loka 2019, Kevin Kofler wrote:
Dependencies aren't arbitrary; if they were, there would be probably no
need to waste our time in working on the whole build part. Whether that
is useful to you or other subset of Fedora maintainers is not
guaranteed. However, using modular streams allows
On Wed, Oct 16, 2019 at 03:05:43PM -0700, John M. Harris Jr wrote:
> Realistically, I believe that default streams themselves are something we
> should avoid, if the cost is low, and it is. There are many users,
> probably the vast majority of users, that don't use Modularity. It's great
> to have
Hello everyone!
The logs for the NeuroFedora team meeting on 26th September are linked below:
- HTML Logs:
https://meetbot.fedoraproject.org/fedora-neuro/2019-10-17/fedora-neuro.2019-10-17-15.00.log.html
- HTML Minutes:
https://meetbot.fedoraproject.org/fedora-neuro/2019-10-17/fedora-neuro
Hello,
I am in the process of building a new version of suricata, and IDS program
that watches network traffic. It has a new module that uses eBPF for high speed
network packet categorization. When building, it uses the following command:
/usr/bin/clang -Wall -Iinclude -O2 \
-I/usr/incl
On 17/10/2019 20:44, Steve Grubb wrote:
I don't think __x86_64__ is defined as the program is aimed at eBPF in the
kernel. In rawhide, we no longer have glibc-devel(x86-32) to allow this to
resolve. However, I think that the assumption of not having __x86_64__
defined means we are targeting i68
On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
> On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> > The one thing we are using default modular stream in RHEL 8 for is to be
> > able to provide access to packages in kickstart that were moved to
> > modules in RHEL
On Thursday, October 17, 2019 4:21:44 PM EDT Tom Hughes wrote:
> On 17/10/2019 20:44, Steve Grubb wrote:
> > I don't think __x86_64__ is defined as the program is aimed at eBPF in
> > the
> > kernel. In rawhide, we no longer have glibc-devel(x86-32) to allow this
> > to
> > resolve. However, I thin
On 10/17/19 2:35 PM, Adam Williamson wrote:
> On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
>> On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
>>> The one thing we are using default modular stream in RHEL 8 for is to be
>>> able to provide access to packages in k
On Thu, 2019-10-17 at 14:44 -0600, Orion Poplawski wrote:
> On 10/17/19 2:35 PM, Adam Williamson wrote:
> > On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
> > > On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> > > > The one thing we are using default modular stre
On 17/10/2019 21:39, Steve Grubb wrote:
On Thursday, October 17, 2019 4:21:44 PM EDT Tom Hughes wrote:
On 17/10/2019 20:44, Steve Grubb wrote:
I don't think __x86_64__ is defined as the program is aimed at eBPF in
the
kernel. In rawhide, we no longer have glibc-devel(x86-32) to allow this
to
re
On Thu, 17 Oct 2019 22:21:39 +0100
Tom Hughes wrote:
> On 17/10/2019 21:39, Steve Grubb wrote:
> > On Thursday, October 17, 2019 4:21:44 PM EDT Tom Hughes wrote:
> >> On 17/10/2019 20:44, Steve Grubb wrote:
> >>> I don't think __x86_64__ is defined as the program is aimed at
> >>> eBPF in the
> >
On Thu, Oct 17, 2019 at 9:33 PM Matthew Miller wrote:
>
> On Wed, Oct 16, 2019 at 03:05:43PM -0700, John M. Harris Jr wrote:
> > Realistically, I believe that default streams themselves are something we
> > should avoid, if the cost is low, and it is. There are many users,
> > probably the vast ma
On 10/17/19 1:32 PM, Matthew Miller wrote:
> On Wed, Oct 16, 2019 at 03:05:43PM -0700, John M. Harris Jr wrote:
>> Realistically, I believe that default streams themselves are something we
>> should avoid, if the cost is low, and it is. There are many users,
>> probably the vast majority of users,
On Thu, 2019-10-17 at 15:04 -0400, Stephen John Smoogen wrote:
> Not without using their packaging system, their build system and
> their
> other design choices.
Frankly, this is not a bad caveat. Keep in mind that we also had to
change our build system for modularity.
> Working out slots would
Alexander Bokovoy wrote:
> This does not work for server components and is not generalizable. For
> example, you cannot have multiple versions of Samba running on the same
> system. You cannot have multiple versions of FreeIPA running on the same
> system either. These server components have requir
Przemek Klosowski via devel wrote:
> 3. modularity allows choosing non-default versions, which is great for
> a particular application, but conflicts with other apps, forcing us
> to choose only one of them. This provides a working solution for at
> least some people, so it's useful fo
Stephen Gallagher wrote:
> I think that's a little harsh (but probably fair given my tone above).
> Can we agree that we're both on the same side: we want Fedora to be
> excellent?
I accept your apologies for your harsh tone (and I appreciate your much more
constructive reply this time, thank you
Adam Williamson wrote:
> Of course if you just don't modularize FreeIPA at all you don't have
> the kickstart problem, but then you *do* still have the 'we're stuck
> shipping this one version of FreeIPA for the next seventy jillion
> years' problem.
That is purely a RHEL thing though. I do not se
I've got an update I've requested stable on which is now at 15 days...
I'm assuming the pause is due to beta freeze activities?
https://bodhi.fedoraproject.org/updates/FEDORA-2019-95287d801f
Thanks,
Richard
___
devel mailing list -- devel@lists.fedorap
Hi,
AFAIK , the logic is request an freeze exception , or next push will be
just after F31 GA .
I'd like have one unfreeze and push all packages that are waiting to be
pushed to stable, when we have an NO-GO.
I already made this request in past and, in resume, the idea was
rejected with some vali
Sérgio Basto wrote:
> AFAIK , the logic is request an freeze exception , or next push will be
> just after F31 GA .
> I'd like have one unfreeze and push all packages that are waiting to be
> pushed to stable, when we have an NO-GO.
> I already made this request in past and, in resume, the idea was
On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote:
> Sérgio Basto wrote:
> > AFAIK , the logic is request an freeze exception , or next push will be
> > just after F31 GA .
> > I'd like have one unfreeze and push all packages that are waiting to be
> > pushed to stable, when we have an NO-GO.
>
83 matches
Mail list logo
