Re: Multilib inconsistencies between fedora/updates/updates-testing composes

[Dennis Gilmore]

https://pagure.io/releng/issue/4084 its an issue that has existed for
nearly a decade and not been solved. Time was not taken to fixing it
after we disabled installing multilib by default as there was no
reports of it for years.

Dennis

El mié, 12-12-2018 a las 11:32 +0100, Florian Weimer escribió:
> We have seen reports that glibc-headers.i686 comes and goes from the
> x86_64 updates compose.  Previously, we have seen this only for the
> updates-testing compose: 
> 
> This leads to a very bad update experience.  Users file bugs against
> the
> glibc package, but I don't think we can do anything on our side, at
> least not until we know what the actual compose bug is and what
> triggers
> it.
> 
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Multilib inconsistencies between fedora/updates/updates-testing composes

[Carlos O'Donell]

On 12/14/18 1:50 PM, Kevin Fenzi wrote:
> On 12/14/18 4:06 AM, Florian Weimer wrote:
>> * Florian Weimer:
>>
>>> We have seen reports that glibc-headers.i686 comes and goes from the
>>> x86_64 updates compose.  Previously, we have seen this only for the
>>> updates-testing compose: 
>>>
>>> This leads to a very bad update experience.  Users file bugs against the
>>> glibc package, but I don't think we can do anything on our side, at
>>> least not until we know what the actual compose bug is and what triggers
>>> it.
>>
>> We really need to fix this issue, it breaks updates for many users.
>>
>> Any suggestion how we can move this forward?
> 
> I had another question for lsedlar, but the prepopulate might work. That
> means we bloat our updates/updates-testing repos by all the .i686 stuff
> that was in the GA repo, but at least it means it will always be there.

Yes please. Consistency is the key here. Either all gone, or all there.
 
> This also would mean it would require changing this list if someone
> changed a package in a update such that it was no longer multilib, but
> hopefully that doesn't happen too often.

This is so rare I've never observed it ;-)

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Multilib inconsistencies between fedora/updates/updates-testing composes

[Kevin Fenzi]

On 12/14/18 4:06 AM, Florian Weimer wrote:
> * Florian Weimer:
> 
>> We have seen reports that glibc-headers.i686 comes and goes from the
>> x86_64 updates compose.  Previously, we have seen this only for the
>> updates-testing compose: 
>>
>> This leads to a very bad update experience.  Users file bugs against the
>> glibc package, but I don't think we can do anything on our side, at
>> least not until we know what the actual compose bug is and what triggers
>> it.
> 
> We really need to fix this issue, it breaks updates for many users.
> 
> Any suggestion how we can move this forward?

I had another question for lsedlar, but the prepopulate might work. That
means we bloat our updates/updates-testing repos by all the .i686 stuff
that was in the GA repo, but at least it means it will always be there.

This also would mean it would require changing this list if someone
changed a package in a update such that it was no longer multilib, but
hopefully that doesn't happen too often.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Multilib inconsistencies between fedora/updates/updates-testing composes

[Florian Weimer]

* Florian Weimer:

> We have seen reports that glibc-headers.i686 comes and goes from the
> x86_64 updates compose.  Previously, we have seen this only for the
> updates-testing compose: 
>
> This leads to a very bad update experience.  Users file bugs against the
> glibc package, but I don't think we can do anything on our side, at
> least not until we know what the actual compose bug is and what triggers
> it.

We really need to fix this issue, it breaks updates for many users.

Any suggestion how we can move this forward?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Multilib inconsistencies between fedora/updates/updates-testing composes

[Tom Stellard]

On 12/12/2018 02:32 AM, Florian Weimer wrote:
> We have seen reports that glibc-headers.i686 comes and goes from the
> x86_64 updates compose.  Previously, we have seen this only for the
> updates-testing compose: 
> 
> This leads to a very bad update experience.  Users file bugs against the
> glibc package, but I don't think we can do anything on our side, at
> least not until we know what the actual compose bug is and what triggers
> it.
> 

We've seen this same problem with the compiler-rt package for the last
few releases:

https://bugzilla.redhat.com/show_bug.cgi?id=1513286
https://bugzilla.redhat.com/show_bug.cgi?id=1615016

-Tom

> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Multilib inconsistencies between fedora/updates/updates-testing composes

[Florian Weimer]

We have seen reports that glibc-headers.i686 comes and goes from the
x86_64 updates compose.  Previously, we have seen this only for the
updates-testing compose: 

This leads to a very bad update experience.  Users file bugs against the
glibc package, but I don't think we can do anything on our side, at
least not until we know what the actual compose bug is and what triggers
it.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org