Dne 6.3.2018 v 21:36 Kevin Kofler napsal(a):
> Nicolas Mailhot wrote:
>> The “never go backwards” policy means that as soon something hits devel
>> other packages can rely on your package and start adapting
>> their packages on the basis of your changes. You can not pull the carpet
>> from under
Dne 6.3.2018 v 19:26 Kevin Fenzi napsal(a):
> On 03/06/2018 07:47 AM, Pierre-Yves Chibon wrote:
>> On Tue, Mar 06, 2018 at 02:58:45PM +, Stephen Gallagher wrote:
> ...snip...
>>> But that has its own issues.
>> Sorry, just to be clear, what would have its own issues:
>> - asking rawhide users
On 03/06/2018 03:37 PM, Kevin Kofler wrote:
> But bumping Epoch, as the policy makes you do in such a case, does
> absolutely nothing to fix that. So I don't see how the current policy helps.
True, but the epoch thing also offers a bit more encouragement to fix
the package without forcing a downg
On Tue, Mar 06, 2018 at 04:47:49PM +0100, Pierre-Yves Chibon wrote:
> Sorry, just to be clear, what would have its own issues:
> - asking rawhide users to use distro-sync instead of update?
> - automatically have dnf detect it's running in rawhide and default to
> distro-sync instead of update?
On Tue, 2018-03-06 at 21:30 +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > Do note that distro-sync can downgrade packages, but can't handle
> > all
> > the cases. ie, upgrade postgresql and update all your data you
> > can't
> > just downgrade the rpm and be fine. Or any number of other
> > s
On Tue, Mar 06, 2018 at 12:56:56PM -0500, Randy Barlow wrote:
> On 03/03/2018 01:34 PM, Kevin Kofler wrote:
> > That is due to the "Rawhide can never go backwards" policy, which I still
> > do
> > not understand the point of, especially in the light of "distro-sync"
> > having
> > been supporte
On Fri, 2018-03-02 at 04:40 +0100, Kevin Kofler wrote:
>
> > I disagree entirely with the above. I think the solution is to gate
> > packages coming into rawhide and hold or reject those that break the
> > compose until they are fixed. I think being proactive is VASTLY better
> > than being reacti
Randy Barlow wrote:
> On 03/03/2018 01:34 PM, Kevin Kofler wrote:
>> That is due to the "Rawhide can never go backwards" policy, which I still
>> do not understand the point of, especially in the light of "distro-sync"
>> having been supported by both the old yum and the new dnf for years.
>
> So
Nicolas Mailhot wrote:
> The “never go backwards” policy means that as soon something hits devel
> other packages can rely on your package and start adapting
> their packages on the basis of your changes. You can not pull the carpet
> from under their feet just because you changed your mind.
This
Kevin Fenzi wrote:
> Do note that distro-sync can downgrade packages, but can't handle all
> the cases. ie, upgrade postgresql and update all your data you can't
> just downgrade the rpm and be fine. Or any number of other scriptlets
> that do things that cannot easily be reversed.
The Epoch hack
On 03/06/2018 07:47 AM, Pierre-Yves Chibon wrote:
> On Tue, Mar 06, 2018 at 02:58:45PM +, Stephen Gallagher wrote:
...snip...
>> But that has its own issues.
>
> Sorry, just to be clear, what would have its own issues:
> - asking rawhide users to use distro-sync instead of update?
> - automati
On 03/03/2018 01:34 PM, Kevin Kofler wrote:
> That is due to the "Rawhide can never go backwards" policy, which I still do
> not understand the point of, especially in the light of "distro-sync" having
> been supported by both the old yum and the new dnf for years.
Sometimes an updated package m
Le mardi 06 mars 2018 à 15:53 +0100, Pierre-Yves Chibon a écrit :
> On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> > Pierre-Yves Chibon wrote:
> >
> > > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> > > > So please let us just repeal that "Rawhide can never go
>
On Tue, Mar 06, 2018 at 02:58:45PM +, Stephen Gallagher wrote:
>On Tue, Mar 6, 2018 at 9:54 AM Pierre-Yves Chibon
>wrote:
>
> On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> > Pierre-Yves Chibon wrote:
> >
> > > On Sat, Mar 03, 2018 at 07:35:00PM +0
On Tue, Mar 6, 2018 at 9:54 AM Pierre-Yves Chibon
wrote:
> On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> > Pierre-Yves Chibon wrote:
> >
> > > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> > >> So please let us just repeal that "Rawhide can never go backwards"
On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
>
> > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> >> So please let us just repeal that "Rawhide can never go backwards"
> >> policy.
> >
> > This is actually a fair point, but I wonder wh
Pierre-Yves Chibon wrote:
> On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
>> So please let us just repeal that "Rawhide can never go backwards"
>> policy.
>
> This is actually a fair point, but I wonder what prevents us from doing it
> today.
Technically, nothing. This is purely
On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > with using Epoch's much more commonly.
>
> That is due to the "Rawhide can never go backwards" policy, which I still do
> not understand the point of, especially in the light of "distro-sync" having
> been sup
On 03/02/2018 04:04 AM, Nicolas Mailhot wrote:
> Also, how would you handle obsolete forgotten stray packages that linger
> in the repo (because they've not been killed properly, or a tool bug
> resulted in their non removal)? Gating gives any such package the power
> to block all updates in more c
On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> > * It means things will likely be broken longer as there is less urgency
> > to fix them quickly.
> This means less stress for maintainers who are usually not working full time
> on Fedora.
Which, let's not forget, is the *vast* maj
Kevin Fenzi wrote:
> * It means things will likely be broken longer as there is less urgency
> to fix them quickly.
This means less stress for maintainers who are usually not working full time
on Fedora.
I don't see why a broken dependency in some leaf application that happens to
be included on
On 03/02/2018 08:42 AM, Nicolas Mailhot wrote:
> Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit :
...snip...
>> That'd actually give us the opportunity to clean up more our repos no?
>> :)
>
> Explain that to someone who had several hours/days of builds rejected
> because of
On 03/01/2018 07:40 PM, Kevin Kofler wrote:
> And how do you propose doing that? The only reliable way to hold packages
> that break the compose would be to actually try to run the whole compose
> process after every package build. That just does not scale. The composes
> are only daily for a r
Le vendredi 02 mars 2018 à 10:52 +0100, Pierre-Yves Chibon a écrit :
> On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote:
> > Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit :
> > >
> > > I disagree entirely with the above. I think the solution is to
> > > gate
> > > package
On Fri, Mar 02, 2018 at 10:04:35AM +0100, Nicolas Mailhot wrote:
> Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit :
> >
> > I disagree entirely with the above. I think the solution is to gate
> > packages coming into rawhide and hold or reject those that break the
> > compose until they
Le jeudi 01 mars 2018 à 12:42 -0800, Kevin Fenzi a écrit :
>
> I disagree entirely with the above. I think the solution is to gate
> packages coming into rawhide and hold or reject those that break the
> compose until they are fixed.
While I don't disagree with the sentiment there needs to be a
On Fri, Mar 02, 2018 at 04:40:03AM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> >> Something needs to be done to make the compose process more robust, e.g.:
> >> * running createrepo on a stable release, so that we do not have to be
> >> able
> >> to init a chroot of the target system to com
Kevin Fenzi wrote:
>> Something needs to be done to make the compose process more robust, e.g.:
>> * running createrepo on a stable release, so that we do not have to be
>> able
>> to init a chroot of the target system to compose a repository. A broken
>> dependency, even in systemd or rpm, sho
On 02/28/2018 06:19 PM, Kevin Kofler wrote:
> Fabio Valentini wrote:
>> AFAICT, those "broken deps in rawhide" mails are only sent if there is a
>> compose, and during the past weeks, there have been few of those ... so
>> breakage is sometimes allowed to sit unnoticed (and grow increasingly
>> wor
Dusty Mabe wrote:
> FYI: atomic ostree composes are not release blocking so that is not why a
> compose will fail.
In the past we had composes failing due to something Atomic failing to
compose, I guess that changed since.
Kevin Kofler
___
deve
On 03/01/2018 11:52 AM, Kevin Kofler wrote:
> Vít Ondruch wrote:
>> Speaking of that, it seems that the Rawhide compose failed yesterday due
>> to some KDE/QT soname bump:
> [actually a typo in a Requires, as was already pointed out]
>>
>> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora
Vít Ondruch wrote:
> Speaking of that, it seems that the Rawhide compose failed yesterday due
> to some KDE/QT soname bump:
[actually a typo in a Requires, as was already pointed out]
>
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180228.n.0/logs/global/pungi.global.log
>
Dne 1.3.2018 v 14:47 Mamoru TASAKA napsal(a):
> Vít Ondruch wrote on 03/01/2018 06:44 PM:
>>
>>
>> Dne 1.3.2018 v 03:19 Kevin Kofler napsal(a):
>>> Fabio Valentini wrote:
AFAICT, those "broken deps in rawhide" mails are only sent if there
is a
compose, and during the past weeks, th
Vít Ondruch wrote on 03/01/2018 06:44 PM:
Dne 1.3.2018 v 03:19 Kevin Kofler napsal(a):
Fabio Valentini wrote:
AFAICT, those "broken deps in rawhide" mails are only sent if there is a
compose, and during the past weeks, there have been few of those ... so
breakage is sometimes allowed to sit u
Dne 1.3.2018 v 03:19 Kevin Kofler napsal(a):
> Fabio Valentini wrote:
>> AFAICT, those "broken deps in rawhide" mails are only sent if there is a
>> compose, and during the past weeks, there have been few of those ... so
>> breakage is sometimes allowed to sit unnoticed (and grow increasingly
>>
35 matches
Mail list logo