Re: Improving the glibc32 situation

2018-03-13 Thread Mark Wielaard
Hi, On Tue, Mar 13, 2018 at 03:31:40PM +0100, Florian Weimer wrote: > On 03/13/2018 03:03 PM, Jakub Jelinek wrote: > > The right fix would be to make koji deal with multilibs properly, > > mock can handle that fine already, then glibc32 wouldn't be needed at all. > > I think we requested these fe

Re: Improving the glibc32 situation

2018-03-13 Thread Florian Weimer
On 03/13/2018 03:03 PM, Jakub Jelinek wrote: On Tue, Mar 13, 2018 at 02:58:37PM +0100, Mark Wielaard wrote: On Fri, 2018-03-09 at 14:07 +0100, Florian Weimer wrote: Some x86_64 packages need a 32-bit glibc during build time.  Koji does not provide it. [...] Comments?  Suggestions? Why don't w

Re: Improving the glibc32 situation

2018-03-13 Thread Jakub Jelinek
On Tue, Mar 13, 2018 at 02:58:37PM +0100, Mark Wielaard wrote: > On Fri, 2018-03-09 at 14:07 +0100, Florian Weimer wrote: > > Some x86_64 packages need a 32-bit glibc during build time.  Koji > > does not provide it. > > [...] > > Comments?  Suggestions? > > Why don't we just make koji provide it?

Re: Improving the glibc32 situation

2018-03-13 Thread Mark Wielaard
On Fri, 2018-03-09 at 14:07 +0100, Florian Weimer wrote: > Some x86_64 packages need a 32-bit glibc during build time.  Koji > does not provide it. > [...] > Comments?  Suggestions? Why don't we just make koji provide it? That is how a normal 64bit Fedora install looks like. Those have the 32bit p

Re: Improving the glibc32 situation

2018-03-09 Thread Florian Weimer
On 03/09/2018 03:01 PM, Dennis Gilmore wrote: El vie, 09-03-2018 a las 14:55 +0100, Florian Weimer escribió: On 03/09/2018 02:52 PM, Josh Boyer wrote: Stepping back a bit, I'm curious why glibc32 would land in the composes. It shouldn't... it should only be tagged in the fNN- build tags, whi

Re: Improving the glibc32 situation

2018-03-09 Thread Dennis Gilmore
El vie, 09-03-2018 a las 14:55 +0100, Florian Weimer escribió: > On 03/09/2018 02:52 PM, Josh Boyer wrote: > > > Stepping back a bit, I'm curious why glibc32 would land in the > > composes. It shouldn't... it should only be tagged in the fNN- > > build > > tags, which the composes should not pul

Re: Improving the glibc32 situation

2018-03-09 Thread Florian Weimer
On 03/09/2018 02:52 PM, Josh Boyer wrote: Stepping back a bit, I'm curious why glibc32 would land in the composes. It shouldn't... it should only be tagged in the fNN-build tags, which the composes should not pull from. Where do we have recent issues of it getting pulled into a compose? It

Re: Improving the glibc32 situation

2018-03-09 Thread Josh Boyer
On Fri, Mar 9, 2018 at 8:44 AM, Florian Weimer wrote: > On 03/09/2018 02:21 PM, Josh Boyer wrote: > >>> So as a stop-gap measure, I'd like to add this: >>> >>> Conflicts: kernel >> >> >> That's a metapackage now, which isn't actually required for installs. >> Better to do it on kernel-core, howeve

Re: Improving the glibc32 situation

2018-03-09 Thread Florian Weimer
On 03/09/2018 02:21 PM, Josh Boyer wrote: So as a stop-gap measure, I'd like to add this: Conflicts: kernel That's a metapackage now, which isn't actually required for installs. Better to do it on kernel-core, however.. Noted. to the glibc32 package, to make it very unlikely that end user

Re: Improving the glibc32 situation

2018-03-09 Thread Josh Boyer
On Fri, Mar 9, 2018 at 8:07 AM, Florian Weimer wrote: > Some x86_64 packages need a 32-bit glibc during build time. Koji does not > provide it. > > Unfortunately, there is no way to permanently block glibc32 from entering > composes. We have repeatedly asked for it. It simply does not happen.