where is mariadb-10.0.21-1.fc23 ?

[Sérgio Basto]

Hi, 

Where is mariadb-10.0.21-1.fc23 ? [1] says that have been push to stable
but upgrading my system, mariadb is downgraded from mariadb-10.0.21 to
mariadb-10.0.20 ! 

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13442 


Other strange case is the package perl-Event-RPC-1.06-1.fc21  [2] 
even more strange [3] comment 16 says that push
perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says
perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ...


[2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882


When I started to write this message thought I had found more cases, but
in end of review all my 6000 package installed just found these two
cases and in different situations ...

-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Ralf Corsepius]

On 11/11/2015 03:26 AM, Sérgio Basto wrote:

Hi,

Where is mariadb-10.0.21-1.fc23 ? [1] says that have been push to stable
but upgrading my system, mariadb is downgraded from mariadb-10.0.21 to
mariadb-10.0.20 !

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13442


Broken upgrade path.

The NEVR of mariadb in fc23 is less than that in fc22:

dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/m/mariadb-common-10.0.21-1.fc22.x86_64.rpm
dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/m/mariadb-common-10.0.20-3.fc23.x86_64.rpm


Other strange case is the package perl-Event-RPC-1.06-1.fc21  [2]
even more strange [3] comment 16 says that push
perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says
perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ...


[2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882


Similar - broken upgrade path:

dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/p/perl-Event-RPC-1.07-1.fc22.noarch.rpm
dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm



Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Adam Williamson]

On Wed, 2015-11-11 at 07:02 +0100, Ralf Corsepius wrote:
> Other strange case is the package perl-Event-RPC-1.06-1.fc21  [2]
> > even more strange [3] comment 16 says that push
> > perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says
> > perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ...
> > 
> > 
> > [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882
> 
> Similar - broken upgrade path:
> 
> dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/p/perl-Event-RPC-1.07-1.fc22.noarch.rpm
> dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm

No, the OP had it right. In some cases, we can wind up with older
updates being pushed over newer ones. That is, if an update 'foo-2.0-1' 
is submitted, then an update 'foo-2.0-2' is submitted, then 'foo-2.0-2' 
is pushed stable, then 'foo-2.0-1' is pushed stable *later* (which can
happen with auto-karma if the foo-2.0-1 update is never withdrawn),
2.0-1 can be pushed over the top of 2.0-2.

There are some safeguards against this, I think, but it does still
sometimes seem to happen in some circumstances, like this one. In this
case it seems like they got pushed stable in the same transaction, but
1.06-1.fc23 was ordered slightly later than 1.07-1.fc23:

https://bodhi.fedoraproject.org/updates/perl-Event-RPC-1.07-1.fc23#comment-332357
 (18:03:30.614903)
https://bodhi.fedoraproject.org/updates/perl-Event-RPC-1.06-1.fc23#comment-332364
 (18:03:31.486243)

and 1.06-1.fc23 won. In
https://dl.fedoraproject.org/pub/fedora/linux/releases/23/Everything/x86_64/os/Packages/p/
, we find:

https://dl.fedoraproject.org/pub/fedora/linux/releases/23/Everything/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm

not 1.07-1.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Ralf Corsepius]

On 11/11/2015 09:29 AM, Adam Williamson wrote:

On Wed, 2015-11-11 at 07:02 +0100, Ralf Corsepius wrote:

Other strange case is the package perl-Event-RPC-1.06-1.fc21  [2]

even more strange [3] comment 16 says that push
perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says
perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ...


[2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882


Similar - broken upgrade path:

dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/p/perl-Event-RPC-1.07-1.fc22.noarch.rpm
dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm


No, the OP had it right. In some cases, we can wind up with older
updates being pushed over newer ones.  That is, if an update 'foo-2.0-1'
is submitted, then an update 'foo-2.0-2' is submitted, then 'foo-2.0-2'
is pushed stable, then 'foo-2.0-1' is pushed stable *later* (which can
happen with auto-karma if the foo-2.0-1 update is never withdrawn),
2.0-1 can be pushed over the top of 2.0-2.


NVRs in later fedora release/updates *must* be greater than those in 
older release, at all times.


This is a defect of the release process, which needs to be fixed.

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Kevin Fenzi]

On Wed, 11 Nov 2015 00:29:10 -0800
Adam Williamson  wrote:

> No, the OP had it right. In some cases, we can wind up with older
> updates being pushed over newer ones. That is, if an update
> 'foo-2.0-1' is submitted, then an update 'foo-2.0-2' is submitted,
> then 'foo-2.0-2' is pushed stable, then 'foo-2.0-1' is pushed stable
> *later* (which can happen with auto-karma if the foo-2.0-1 update is
> never withdrawn), 2.0-1 can be pushed over the top of 2.0-2.
> 
> There are some safeguards against this, I think, but it does still
> sometimes seem to happen in some circumstances, like this one. 

Yeah. Bodhi will normally obsolete an older update when you submit the
newer one, however thats not always possible: 

* The older update may be locked in a currently happening push. 
* The older update may be part of an update with 10 other packages.

The main bug/issue here is that when bodhi pushes things it asks koji
to move the tags as required, but there's no ordering to that request.
So, it says: "hey koji, move the tags on these 100 packages over to f23
for me" and koji does them in whatever order it wants, then whatever is
the thing last tagged "wins" as far as being the one thats pushed out.
Luke is aware of this bug and is working on a way to detect/fix this
stuff, but it's not easy. 


> In this
> case it seems like they got pushed stable in the same transaction,
>> but
> 1.06-1.fc23 was ordered slightly later than 1.07-1.fc23:
> 
> https://bodhi.fedoraproject.org/updates/perl-Event-RPC-1.07-1.fc23#comment-332357
> (18:03:30.614903)
> https://bodhi.fedoraproject.org/updates/perl-Event-RPC-1.06-1.fc23#comment-332364
> (18:03:31.486243)
> 
> and 1.06-1.fc23 won. In
> https://dl.fedoraproject.org/pub/fedora/linux/releases/23/Everything/x86_64/os/Packages/p/
> , we find:
> 
> https://dl.fedoraproject.org/pub/fedora/linux/releases/23/Everything/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm
> 
> not 1.07-1.

The best thing we can do about these cases right now is for maintainers
to PAY ATTENTION. If you have multiple updates in flight for the same
package, please make sure they don't both go stable at the same time. 

Failing that, when you notice these issues after the fact, file a
releng ticket and we can retag things in the right order so it gets
fixed.

kevin


pgp_DZlkLG35O.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Petr Pisar]

On 2015-11-11, Kevin Fenzi  wrote:
> The best thing we can do about these cases right now is for maintainers
> to PAY ATTENTION. If you have multiple updates in flight for the same
> package, please make sure they don't both go stable at the same time.=20
>
That's ridiculous. Should I request for stable in one branch, then wait
few days until the packages is actually pushed, and then request for
stable into older Fedora?

The serialization should be handled by releng's tool that do the push.

> Failing that, when you notice these issues after the fact, file a
> releng ticket and we can retag things in the right order so it gets
> fixed.
>
In otherwords always disable autokarma. I push builds into testing and
sombody raises karma over a weekend and when I come to the mailbox
later, I only see F22 was pushed into stable before F23. There is
nothing a mainter can do besides disabling default Bodhi features.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Petr Pisar]

On 2015-11-11, Kevin Fenzi  wrote:
> Failing that, when you notice these issues after the fact, file a
> releng ticket and we can retag things in the right order so it gets
> fixed.
>
Here  it is.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Andrew Lutomirski]

On Nov 11, 2015 11:34 PM, "Petr Pisar"  wrote:
>
> On 2015-11-11, Kevin Fenzi  wrote:
> > The best thing we can do about these cases right now is for maintainers
> > to PAY ATTENTION. If you have multiple updates in flight for the same
> > package, please make sure they don't both go stable at the same time.=20
> >
> That's ridiculous. Should I request for stable in one branch, then wait
> few days until the packages is actually pushed, and then request for
> stable into older Fedora?
>
> The serialization should be handled by releng's tool that do the push.
>
> > Failing that, when you notice these issues after the fact, file a
> > releng ticket and we can retag things in the right order so it gets
> > fixed.
> >
> In otherwords always disable autokarma. I push builds into testing and
> sombody raises karma over a weekend and when I come to the mailbox
> later, I only see F22 was pushed into stable before F23. There is
> nothing a mainter can do besides disabling default Bodhi features.

This is very much related to a thread I started a couple weeks ago.  I
really think that Bodhi should be able to understand that a pair of updates
to different branches match and to push them together.

Also, compose should maybe learn to do branches together - right now I have
a broken upgrade path just because F22 finished its push while my F23 push
is still pending.

--Andy

>
> -- Petr
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Reindl Harald]

Am 12.11.2015 um 15:34 schrieb Andrew Lutomirski:

On Nov 11, 2015 11:34 PM, "Petr Pisar"  In otherwords always disable autokarma. I push builds into testing and
 > sombody raises karma over a weekend and when I come to the mailbox
 > later, I only see F22 was pushed into stable before F23. There is
 > nothing a mainter can do besides disabling default Bodhi features.

This is very much related to a thread I started a couple weeks ago.  I
really think that Bodhi should be able to understand that a pair of
updates to different branches match and to push them together


who says you that a update for F22 would behave identical on F23 or the 
other direction when half of the OS has different versions of libraries 
and the whole userland?


it may often work that way but to assume it is so by definition is a 
dangerous game, i saw enough Fedora bugs the past 8 years after 
dist-upgrades where the affected application had exactly the same 
version as before the upgrade and behaved wrong or failed completly





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Andrew Lutomirski]

On Nov 12, 2015 6:39 AM, "Reindl Harald"  wrote:
>
>
>
> Am 12.11.2015 um 15:34 schrieb Andrew Lutomirski:
>>
>> On Nov 11, 2015 11:34 PM, "Petr Pisar" >  > In otherwords always disable autokarma. I push builds into testing and
>>  > sombody raises karma over a weekend and when I come to the mailbox
>>  > later, I only see F22 was pushed into stable before F23. There is
>>  > nothing a mainter can do besides disabling default Bodhi features.
>>
>> This is very much related to a thread I started a couple weeks ago.  I
>> really think that Bodhi should be able to understand that a pair of
>> updates to different branches match and to push them together
>
>
> who says you that a update for F22 would behave identical on F23 or the
other direction when half of the OS has different versions of libraries and
the whole userland?
>
> it may often work that way but to assume it is so by definition is a
dangerous game, i saw enough Fedora bugs the past 8 years after
dist-upgrades where the affected application had exactly the same version
as before the upgrade and behaved wrong or failed completly
>

I said no such thing.  (Can you please try to stop being combative by
default?)

I think that Bodhi should arrange, at least by default, to push things in
the correct order.  Whether that means that karma is required separately
for each branch is an orthogonal issue, except insofar as allowing karma
from one branch to carry over to another would also require Bodhi to track
that two updates are the same thing but just to different branches.

At the very least, Bodhi should *not* push to F22 due to autokarma until
F23 stable is requested.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Josh Boyer]

On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski  wrote:
>
> On Nov 12, 2015 6:39 AM, "Reindl Harald"  wrote:
>>
>>
>>
>> Am 12.11.2015 um 15:34 schrieb Andrew Lutomirski:
>>>
>>> On Nov 11, 2015 11:34 PM, "Petr Pisar" >>  > In otherwords always disable autokarma. I push builds into testing and
>>>  > sombody raises karma over a weekend and when I come to the mailbox
>>>  > later, I only see F22 was pushed into stable before F23. There is
>>>  > nothing a mainter can do besides disabling default Bodhi features.
>>>
>>> This is very much related to a thread I started a couple weeks ago.  I
>>> really think that Bodhi should be able to understand that a pair of
>>> updates to different branches match and to push them together
>>
>>
>> who says you that a update for F22 would behave identical on F23 or the
>> other direction when half of the OS has different versions of libraries and
>> the whole userland?
>>
>> it may often work that way but to assume it is so by definition is a
>> dangerous game, i saw enough Fedora bugs the past 8 years after
>> dist-upgrades where the affected application had exactly the same version as
>> before the upgrade and behaved wrong or failed completly
>>
>
> I said no such thing.  (Can you please try to stop being combative by
> default?)
>
> I think that Bodhi should arrange, at least by default, to push things in
> the correct order.  Whether that means that karma is required separately for
> each branch is an orthogonal issue, except insofar as allowing karma from
> one branch to carry over to another would also require Bodhi to track that
> two updates are the same thing but just to different branches.

Two updates in separate branches are never the same thing.  They may
be the same version of the specific package, but there is no guarantee
that:

a) they were built with the same toolchain
b) they were built with the same configuration options
c) they were built for the same reasons

While it would be convenient for developers to tell bodhi they are the
same, it's a lie we all tell ourselves.  I don't think we should code
our update tool to lie.

> At the very least, Bodhi should *not* push to F22 due to autokarma until F23
> stable is requested.

I certainly agree with this in principle, but it would force
everything (including rawhide composes) to be serial and the slowdown
would be significant.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Reindl Harald]

Am 12.11.2015 um 16:16 schrieb Andrew Lutomirski:

On Nov 12, 2015 6:39 AM, "Reindl Harald"  who says you that a update for F22 would behave identical on F23 or
the other direction when half of the OS has different versions of
libraries and the whole userland?
 >
 > it may often work that way but to assume it is so by definition is a
dangerous game, i saw enough Fedora bugs the past 8 years after
dist-upgrades where the affected application had exactly the same
version as before the upgrade and behaved wrong or failed completly

I said no such thing.  (Can you please try to stop being combative by
default?)


can you please stop accuse somebody beeing combative?


I think that Bodhi should arrange, at least by default, to push things
in the correct order.  Whether that means that karma is required
separately for each branch is an orthogonal issue, except insofar as
allowing karma from one branch to carry over to another would also
require Bodhi to track that two updates are the same thing but just to
different branches.

At the very least, Bodhi should *not* push to F22 due to autokarma until
F23 stable is requested


for "dnf distro-sync" or "yum distro-sync" over years that all don't 
matter because it simply downgrades a package in that case and so it 
would be better to fix other upgrade methods to act the same way


there is no point for me wait for a F22 update which fixes a bug 
reported for F22 just because there is not enough karma for the 
irrelevant F23 build




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Kevin Fenzi]

On Thu, 12 Nov 2015 07:34:10 + (UTC)
Petr Pisar  wrote:

> On 2015-11-11, Kevin Fenzi  wrote:
> > The best thing we can do about these cases right now is for
> > maintainers to PAY ATTENTION. If you have multiple updates in
> > flight for the same package, please make sure they don't both go
> > stable at the same time.=20 
> That's ridiculous. Should I request for stable in one branch, then
> wait few days until the packages is actually pushed, and then request
> for stable into older Fedora?
> 
> The serialization should be handled by releng's tool that do the push.

This is not the thing we were talking about though. 

This issue is about multiple updates in the very same branch. 

Surely you can realize as maintainer when you build foo-1.0-1.fc23 and
then later foo-1.0-2.fc23 and bodhi doesn't obsolete the older update
(for the reasons I mentioned), that you as maintainer should go look
and unpush the old update, or edit it to add the -2 version to a
multipackage update, or at the very least not push 1.0-1 and 1.0-2 to
stable at the same time?

> > Failing that, when you notice these issues after the fact, file a
> > releng ticket and we can retag things in the right order so it gets
> > fixed.
> >  
> In otherwords always disable autokarma. I push builds into testing and
> sombody raises karma over a weekend and when I come to the mailbox
> later, I only see F22 was pushed into stable before F23. There is
> nothing a mainter can do besides disabling default Bodhi features.

This is a seperate and unrelated issue that I wasn't talking about. ;) 

kevin




pgpVGvNlcI6Aq.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Andrew Lutomirski]

On Nov 12, 2015 7:21 AM, "Josh Boyer"  wrote:
>
> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski  wrote:
> >
> > I think that Bodhi should arrange, at least by default, to push things
in
> > the correct order.  Whether that means that karma is required
separately for
> > each branch is an orthogonal issue, except insofar as allowing karma
from
> > one branch to carry over to another would also require Bodhi to track
that
> > two updates are the same thing but just to different branches.
>
> Two updates in separate branches are never the same thing.  They may
> be the same version of the specific package, but there is no guarantee
> that:
>
> a) they were built with the same toolchain
> b) they were built with the same configuration options
> c) they were built for the same reasons
>
> While it would be convenient for developers to tell bodhi they are the
> same, it's a lie we all tell ourselves.  I don't think we should code
> our update tool to lie.
>
> > At the very least, Bodhi should *not* push to F22 due to autokarma
until F23
> > stable is requested.
>
> I certainly agree with this in principle, but it would force
> everything (including rawhide composes) to be serial and the slowdown
> would be significant.
>

I'm a bit confused.  Wouldn't rawhide be unaffected because rawhide can
always have newer versions without breaking the upgrade path?  It's only
the old branch (currently F22) that would be slower, no?

--Andy

--Andy

> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Josh Boyer]

On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski  wrote:
>
> On Nov 12, 2015 7:21 AM, "Josh Boyer"  wrote:
>>
>> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski  wrote:
>> >
>> > I think that Bodhi should arrange, at least by default, to push things
>> > in
>> > the correct order.  Whether that means that karma is required separately
>> > for
>> > each branch is an orthogonal issue, except insofar as allowing karma
>> > from
>> > one branch to carry over to another would also require Bodhi to track
>> > that
>> > two updates are the same thing but just to different branches.
>>
>> Two updates in separate branches are never the same thing.  They may
>> be the same version of the specific package, but there is no guarantee
>> that:
>>
>> a) they were built with the same toolchain
>> b) they were built with the same configuration options
>> c) they were built for the same reasons
>>
>> While it would be convenient for developers to tell bodhi they are the
>> same, it's a lie we all tell ourselves.  I don't think we should code
>> our update tool to lie.
>>
>> > At the very least, Bodhi should *not* push to F22 due to autokarma until
>> > F23
>> > stable is requested.
>>
>> I certainly agree with this in principle, but it would force
>> everything (including rawhide composes) to be serial and the slowdown
>> would be significant.
>>
>
> I'm a bit confused.  Wouldn't rawhide be unaffected because rawhide can
> always have newer versions without breaking the upgrade path?  It's only the
> old branch (currently F22) that would be slower, no?

If you are truly protecting upgrade paths in the manner which you
suggested, you would have to do them in this order:

rawhide, f23, f22, f21, 

so that updates to f23 do not break the upgrade path to rawhide.

Complicating things even more is that as a release grows older, the
compose time for its updates repository also grows longer.  The more
updates, the more to compose.  Which means that from a time
perspective you might still be composing the oldest release (f21 in
this example) when it's time to start the next day's rawhide and now
you cannot.  You lose the predictability of rawhide.

If we ignore rawhide and focus only on stable releases, your
suggestion becomes more feasible.  I'm not really sure it's worth it
in the long run though.  From a practical standpoint, serializing
everything to protect upgrade path isn't really a solution to a
prevalent problem.  The newer release (containing the equivalent
package update) will complete typically within a few hours of the
older release, and with mirror synchronization time taken into account
it isn't usually a major issue.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Andrew Lutomirski]

On Nov 12, 2015 8:17 AM, "Josh Boyer"  wrote:
>
> On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski  wrote:
> >
> > On Nov 12, 2015 7:21 AM, "Josh Boyer"  wrote:
> >>
> >> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski 
wrote:
> >> >
> >> > I think that Bodhi should arrange, at least by default, to push
things
> >> > in
> >> > the correct order.  Whether that means that karma is required
separately
> >> > for
> >> > each branch is an orthogonal issue, except insofar as allowing karma
> >> > from
> >> > one branch to carry over to another would also require Bodhi to track
> >> > that
> >> > two updates are the same thing but just to different branches.
> >>
> >> Two updates in separate branches are never the same thing.  They may
> >> be the same version of the specific package, but there is no guarantee
> >> that:
> >>
> >> a) they were built with the same toolchain
> >> b) they were built with the same configuration options
> >> c) they were built for the same reasons
> >>
> >> While it would be convenient for developers to tell bodhi they are the
> >> same, it's a lie we all tell ourselves.  I don't think we should code
> >> our update tool to lie.
> >>
> >> > At the very least, Bodhi should *not* push to F22 due to autokarma
until
> >> > F23
> >> > stable is requested.
> >>
> >> I certainly agree with this in principle, but it would force
> >> everything (including rawhide composes) to be serial and the slowdown
> >> would be significant.
> >>
> >
> > I'm a bit confused.  Wouldn't rawhide be unaffected because rawhide can
> > always have newer versions without breaking the upgrade path?  It's
only the
> > old branch (currently F22) that would be slower, no?
>
> If you are truly protecting upgrade paths in the manner which you
> suggested, you would have to do them in this order:
>
> rawhide, f23, f22, f21, 
>
> so that updates to f23 do not break the upgrade path to rawhide.
>
> Complicating things even more is that as a release grows older, the
> compose time for its updates repository also grows longer.  The more
> updates, the more to compose.  Which means that from a time
> perspective you might still be composing the oldest release (f21 in
> this example) when it's time to start the next day's rawhide and now
> you cannot.  You lose the predictability of rawhide.
>
> If we ignore rawhide and focus only on stable releases, your
> suggestion becomes more feasible.  I'm not really sure it's worth it
> in the long run though.  From a practical standpoint, serializing
> everything to protect upgrade path isn't really a solution to a
> prevalent problem.  The newer release (containing the equivalent
> package update) will complete typically within a few hours of the
> older release, and with mirror synchronization time taken into account
> it isn't usually a major issue.

Fair enough.

We could start with a much more modest variant, though: ignore compose and
just make autokarma pushes to any repo depend on the same or newer NVR
being either pushed *or requested* for all the newer branches.  That would
avoid multi-day issues.

--Andy

>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Josh Boyer]

On Thu, Nov 12, 2015 at 11:29 AM, Andrew Lutomirski  wrote:
>
> On Nov 12, 2015 8:17 AM, "Josh Boyer"  wrote:
>>
>> On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski  wrote:
>> >
>> > On Nov 12, 2015 7:21 AM, "Josh Boyer"  wrote:
>> >>
>> >> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski 
>> >> wrote:
>> >> >
>> >> > I think that Bodhi should arrange, at least by default, to push
>> >> > things
>> >> > in
>> >> > the correct order.  Whether that means that karma is required
>> >> > separately
>> >> > for
>> >> > each branch is an orthogonal issue, except insofar as allowing karma
>> >> > from
>> >> > one branch to carry over to another would also require Bodhi to track
>> >> > that
>> >> > two updates are the same thing but just to different branches.
>> >>
>> >> Two updates in separate branches are never the same thing.  They may
>> >> be the same version of the specific package, but there is no guarantee
>> >> that:
>> >>
>> >> a) they were built with the same toolchain
>> >> b) they were built with the same configuration options
>> >> c) they were built for the same reasons
>> >>
>> >> While it would be convenient for developers to tell bodhi they are the
>> >> same, it's a lie we all tell ourselves.  I don't think we should code
>> >> our update tool to lie.
>> >>
>> >> > At the very least, Bodhi should *not* push to F22 due to autokarma
>> >> > until
>> >> > F23
>> >> > stable is requested.
>> >>
>> >> I certainly agree with this in principle, but it would force
>> >> everything (including rawhide composes) to be serial and the slowdown
>> >> would be significant.
>> >>
>> >
>> > I'm a bit confused.  Wouldn't rawhide be unaffected because rawhide can
>> > always have newer versions without breaking the upgrade path?  It's only
>> > the
>> > old branch (currently F22) that would be slower, no?
>>
>> If you are truly protecting upgrade paths in the manner which you
>> suggested, you would have to do them in this order:
>>
>> rawhide, f23, f22, f21, 
>>
>> so that updates to f23 do not break the upgrade path to rawhide.
>>
>> Complicating things even more is that as a release grows older, the
>> compose time for its updates repository also grows longer.  The more
>> updates, the more to compose.  Which means that from a time
>> perspective you might still be composing the oldest release (f21 in
>> this example) when it's time to start the next day's rawhide and now
>> you cannot.  You lose the predictability of rawhide.
>>
>> If we ignore rawhide and focus only on stable releases, your
>> suggestion becomes more feasible.  I'm not really sure it's worth it
>> in the long run though.  From a practical standpoint, serializing
>> everything to protect upgrade path isn't really a solution to a
>> prevalent problem.  The newer release (containing the equivalent
>> package update) will complete typically within a few hours of the
>> older release, and with mirror synchronization time taken into account
>> it isn't usually a major issue.
>
> Fair enough.
>
> We could start with a much more modest variant, though: ignore compose and
> just make autokarma pushes to any repo depend on the same or newer NVR being
> either pushed *or requested* for all the newer branches.  That would avoid
> multi-day issues.

Sounds like a reasonable RFE to file, yes :).

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Andrew Lutomirski]

On Thu, Nov 12, 2015 at 8:31 AM, Josh Boyer  wrote:
> On Thu, Nov 12, 2015 at 11:29 AM, Andrew Lutomirski  wrote:
>>
>> On Nov 12, 2015 8:17 AM, "Josh Boyer"  wrote:
>>>
>>> On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski  wrote:
>>> >
>>> > On Nov 12, 2015 7:21 AM, "Josh Boyer"  wrote:
>>> >>
>>> >> On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski 
>>> >> wrote:
>>> >> >
>>> >> > I think that Bodhi should arrange, at least by default, to push
>>> >> > things
>>> >> > in
>>> >> > the correct order.  Whether that means that karma is required
>>> >> > separately
>>> >> > for
>>> >> > each branch is an orthogonal issue, except insofar as allowing karma
>>> >> > from
>>> >> > one branch to carry over to another would also require Bodhi to track
>>> >> > that
>>> >> > two updates are the same thing but just to different branches.
>>> >>
>>> >> Two updates in separate branches are never the same thing.  They may
>>> >> be the same version of the specific package, but there is no guarantee
>>> >> that:
>>> >>
>>> >> a) they were built with the same toolchain
>>> >> b) they were built with the same configuration options
>>> >> c) they were built for the same reasons
>>> >>
>>> >> While it would be convenient for developers to tell bodhi they are the
>>> >> same, it's a lie we all tell ourselves.  I don't think we should code
>>> >> our update tool to lie.
>>> >>
>>> >> > At the very least, Bodhi should *not* push to F22 due to autokarma
>>> >> > until
>>> >> > F23
>>> >> > stable is requested.
>>> >>
>>> >> I certainly agree with this in principle, but it would force
>>> >> everything (including rawhide composes) to be serial and the slowdown
>>> >> would be significant.
>>> >>
>>> >
>>> > I'm a bit confused.  Wouldn't rawhide be unaffected because rawhide can
>>> > always have newer versions without breaking the upgrade path?  It's only
>>> > the
>>> > old branch (currently F22) that would be slower, no?
>>>
>>> If you are truly protecting upgrade paths in the manner which you
>>> suggested, you would have to do them in this order:
>>>
>>> rawhide, f23, f22, f21, 
>>>
>>> so that updates to f23 do not break the upgrade path to rawhide.
>>>
>>> Complicating things even more is that as a release grows older, the
>>> compose time for its updates repository also grows longer.  The more
>>> updates, the more to compose.  Which means that from a time
>>> perspective you might still be composing the oldest release (f21 in
>>> this example) when it's time to start the next day's rawhide and now
>>> you cannot.  You lose the predictability of rawhide.
>>>
>>> If we ignore rawhide and focus only on stable releases, your
>>> suggestion becomes more feasible.  I'm not really sure it's worth it
>>> in the long run though.  From a practical standpoint, serializing
>>> everything to protect upgrade path isn't really a solution to a
>>> prevalent problem.  The newer release (containing the equivalent
>>> package update) will complete typically within a few hours of the
>>> older release, and with mirror synchronization time taken into account
>>> it isn't usually a major issue.
>>
>> Fair enough.
>>
>> We could start with a much more modest variant, though: ignore compose and
>> just make autokarma pushes to any repo depend on the same or newer NVR being
>> either pushed *or requested* for all the newer branches.  That would avoid
>> multi-day issues.
>
> Sounds like a reasonable RFE to file, yes :).

Done: https://bugzilla.redhat.com/show_bug.cgi?id=1281536

Hopefully bugzilla is the right place for this.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Kevin Kofler]

Petr Pisar wrote:
> In otherwords always disable autokarma. I push builds into testing and
> sombody raises karma over a weekend and when I come to the mailbox
> later, I only see F22 was pushed into stable before F23. There is
> nothing a mainter can do besides disabling default Bodhi features.

This was not the issue at hand here, but yes, you exactly got the point why 
autokarma should NEVER be used.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Sérgio Basto]

On Qui, 2015-11-12 at 09:06 -0800, Andrew Lutomirski wrote:
> On Thu, Nov 12, 2015 at 8:31 AM, Josh Boyer  g> wrote:
> > On Thu, Nov 12, 2015 at 11:29 AM, Andrew Lutomirski 
> > wrote:
> > > 
> > > On Nov 12, 2015 8:17 AM, "Josh Boyer" 
> > > wrote:
> > > > 
> > > > On Thu, Nov 12, 2015 at 11:07 AM, Andrew Lutomirski  > > > du> wrote:
> > > > > 
> > > > > On Nov 12, 2015 7:21 AM, "Josh Boyer"  > > > > org> wrote:
> > > > > > 
> > > > > > On Thu, Nov 12, 2015 at 10:16 AM, Andrew Lutomirski  > > > > > it.edu>
> > > > > > wrote:
> > > > > > > 
> > > > > > > I think that Bodhi should arrange, at least by default,
> > > > > > > to push
> > > > > > > things
> > > > > > > in
> > > > > > > the correct order.  Whether that means that karma is
> > > > > > > required
> > > > > > > separately
> > > > > > > for
> > > > > > > each branch is an orthogonal issue, except insofar as
> > > > > > > allowing karma
> > > > > > > from
> > > > > > > one branch to carry over to another would also require
> > > > > > > Bodhi to track
> > > > > > > that
> > > > > > > two updates are the same thing but just to different
> > > > > > > branches.
> > > > > > 
> > > > > > Two updates in separate branches are never the same
> > > > > > thing.  They may
> > > > > > be the same version of the specific package, but there is
> > > > > > no guarantee
> > > > > > that:
> > > > > > 
> > > > > > a) they were built with the same toolchain
> > > > > > b) they were built with the same configuration options
> > > > > > c) they were built for the same reasons
> > > > > > 
> > > > > > While it would be convenient for developers to tell bodhi
> > > > > > they are the
> > > > > > same, it's a lie we all tell ourselves.  I don't think we
> > > > > > should code
> > > > > > our update tool to lie.
> > > > > > 
> > > > > > > At the very least, Bodhi should *not* push to F22 due to
> > > > > > > autokarma
> > > > > > > until
> > > > > > > F23
> > > > > > > stable is requested.
> > > > > > 
> > > > > > I certainly agree with this in principle, but it would
> > > > > > force
> > > > > > everything (including rawhide composes) to be serial and
> > > > > > the slowdown
> > > > > > would be significant.
> > > > > > 
> > > > > 
> > > > > I'm a bit confused.  Wouldn't rawhide be unaffected because
> > > > > rawhide can
> > > > > always have newer versions without breaking the upgrade
> > > > > path?  It's only
> > > > > the
> > > > > old branch (currently F22) that would be slower, no?
> > > > 
> > > > If you are truly protecting upgrade paths in the manner which
> > > > you
> > > > suggested, you would have to do them in this order:
> > > > 
> > > > rawhide, f23, f22, f21, 
> > > > 
> > > > so that updates to f23 do not break the upgrade path to
> > > > rawhide.
> > > > 
> > > > Complicating things even more is that as a release grows older,
> > > > the
> > > > compose time for its updates repository also grows longer.  The
> > > > more
> > > > updates, the more to compose.  Which means that from a time
> > > > perspective you might still be composing the oldest release
> > > > (f21 in
> > > > this example) when it's time to start the next day's rawhide
> > > > and now
> > > > you cannot.  You lose the predictability of rawhide.
> > > > 
> > > > If we ignore rawhide and focus only on stable releases, your
> > > > suggestion becomes more feasible.  I'm not really sure it's
> > > > worth it
> > > > in the long run though.  From a practical standpoint,
> > > > serializing
> > > > everything to protect upgrade path isn't really a solution to a
> > > > prevalent problem.  The newer release (containing the
> > > > equivalent
> > > > package update) will complete typically within a few hours of
> > > > the
> > > > older release, and with mirror synchronization time taken into
> > > > account
> > > > it isn't usually a major issue.
> > > 
> > > Fair enough.
> > > 
> > > We could start with a much more modest variant, though: ignore
> > > compose and
> > > just make autokarma pushes to any repo depend on the same or
> > > newer NVR being
> > > either pushed *or requested* for all the newer branches.  That
> > > would avoid
> > > multi-day issues.
> > 
> > Sounds like a reasonable RFE to file, yes :).
> 
> Done: https://bugzilla.redhat.com/show_bug.cgi?id=1281536
> 
> Hopefully bugzilla is the right place for this.

I read your RFE , "Please consider adding a Bodhi feature ... " 

This feature is: Bodhi should verify before push the package to stable,
if package have the same or lower NVR of the next branch, if not,
doesn't let you push the package and give the user the feedback why
can't push the package. When it is fixed, Bodhi maybe can push it
automatically or notify the user that already can be pushed . 


> --Andy
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Reindl Harald]

Am 12.11.2015 um 16:26 schrieb Reindl Harald:


Am 12.11.2015 um 16:16 schrieb Andrew Lutomirski:

On Nov 12, 2015 6:39 AM, "Reindl Harald"  who says you that a update for F22 would behave identical on F23 or
the other direction when half of the OS has different versions of
libraries and the whole userland?
 >
 > it may often work that way but to assume it is so by definition is a
dangerous game, i saw enough Fedora bugs the past 8 years after
dist-upgrades where the affected application had exactly the same
version as before the upgrade and behaved wrong or failed completly

I said no such thing.  (Can you please try to stop being combative by
default?)


can you please stop accuse somebody beeing combative?


and here you go:
http://www.spinics.net/linux/fedora/fedora-kde/msg16499.html

these updates are working pretty fine (as fgar as you can say that to 
KDE5 at all) on F23 while the OP now statet he is on F22 which has a 
different mesa, GCC and what not else - no, don't push packages based on 
karma for a different release and *n+* don't wait for the n-1 karma to 
release packages for the recent Fedora


see again below: the rpm version *must not* matter in case of 
dist-upgrades and *any* upgrade process which is not ablr to do a 
distro-sync is just broken



I think that Bodhi should arrange, at least by default, to push things
in the correct order.  Whether that means that karma is required
separately for each branch is an orthogonal issue, except insofar as
allowing karma from one branch to carry over to another would also
require Bodhi to track that two updates are the same thing but just to
different branches.

At the very least, Bodhi should *not* push to F22 due to autokarma until
F23 stable is requested


for "dnf distro-sync" or "yum distro-sync" over years that all don't
matter because it simply downgrades a package in that case and so it
would be better to fix other upgrade methods to act the same way

there is no point for me wait for a F22 update which fixes a bug
reported for F22 just because there is not enough karma for the
irrelevant F23 build




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Mattia Verga]

Il 11/11/2015 03:26, Sérgio Basto ha scritto:

Hi,

Where is mariadb-10.0.21-1.fc23 ? [1] says that have been push to stable
but upgrading my system, mariadb is downgraded from mariadb-10.0.21 to
mariadb-10.0.20 !

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13442


Other strange case is the package perl-Event-RPC-1.06-1.fc21  [2]
even more strange [3] comment 16 says that push
perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says
perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ...


[2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882


When I started to write this message thought I had found more cases, but
in end of review all my 6000 package installed just found these two
cases and in different situations ...


By the way, what's going on with NVR of package "sos"?:
http://koji.fedoraproject.org/koji/packageinfo?packageID=4884

I can't even find it in bodhi...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: where is mariadb-10.0.21-1.fc23 ?

[Petr Pisar]

On 2015-11-15, Sérgio Basto  wrote:
> On Qui, 2015-11-12 at 09:06 -0800, Andrew Lutomirski wrote:
>> 
>> Hopefully bugzilla is the right place for this.
>
> I read your RFE , "Please consider adding a Bodhi feature ... " 
>
> This feature is: Bodhi should verify before push the package to stable,
> if package have the same or lower NVR of the next branch, if not,
> doesn't let you push the package and give the user the feedback why
> can't push the package. When it is fixed, Bodhi maybe can push it
> automatically or notify the user that already can be pushed . 
>
This was implementd on information level by AutoQA tests. They were
disable after migrating to the new Bodhi.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct