Buildbot now fails to build wine dependencies

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Buildbot now fails to build wine dependencies

Ryan Schmidt-24
We used to be able to build wine on the buildbot, but we aren't anymore:

https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/32791

The error occurs when installing dependencies, specifically cairo:

> ----> Installing dependency (28 of 120) 'glib2' with variants '+universal+x11'
> ...
> --->  Deactivating glib2 @2.52.3_0+universal+x11
> ...

> ----> Installing dependency (55 of 120) 'cairo' with variants '+quartz+universal+x11'
> ...
> Error: glib2: Variant quartz conflicts with x11

The cairo port has for years had both x11 and quartz variants that are both enabled by default. The glib2 port recently got x11 and quartz variants added, and they conflict with one another, as they do in most ports that have them; the user must choose one or the other. The default is x11, as it is for other ports that have this choice.

I think the problem is that mpbb is explicitly specifying the variants when installing the dependencies, particularly since wine is 32-bit so it needs the dependencies installed with the universal variant, and when installing cairo with x11, quartz and universal, it is passing those variants down to cairo's dependencies, including glib2.

I don't know why mpbb is specifying all the variants when building dependencies. It seems like it would be enough to just specify universal, and let the port's default variants take care of the rest.

Many years ago, cairo used to require the user to select whether to use x11 or quartz, but then it became possible to use both at once, and the variants were kept in case there turned out to be some situations where having both backends available caused some problem. As far as I know, no such problem was found, so I could just remove the variants from the cairo port, which would fix the problem for cairo, but would not fix it for all the other ports that have conflicting x11 and quartz variants and depend on glib2, and there are a couple of those:

$ port echo variant:quartz and variant:x11 and depends:glib2
cairo                          
cairo-devel                    
gtk3                            
librsvg                        
libVLC                          
pango                          
pango-devel                    
pidgin                          
pspp                            
pspp-devel                      
VLC                            
webkit2-gtk                    
webkit2-gtk-devel              

(Not all of these ports' x11 and quartz variants conflict.)

It's possible the problem only shows up when doing builds with non-default variants, which would only be universal at the moment.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Mojca Miklavec-2
On 27 June 2017 at 11:31, Ryan Schmidt wrote:

> We used to be able to build wine on the buildbot, but we aren't anymore:
>
> https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/32791
>
> The error occurs when installing dependencies, specifically cairo:
>
>> ----> Installing dependency (28 of 120) 'glib2' with variants '+universal+x11'
>> ...
>> --->  Deactivating glib2 @2.52.3_0+universal+x11
>> ...
>
>> ----> Installing dependency (55 of 120) 'cairo' with variants '+quartz+universal+x11'
>> ...
>> Error: glib2: Variant quartz conflicts with x11

I accidentally found
    https://trac.macports.org/ticket/49800

> The cairo port has for years had both x11 and quartz variants that are both enabled by default. The glib2 port recently got x11 and quartz variants added, and they conflict with one another, as they do in most ports that have them; the user must choose one or the other. The default is x11, as it is for other ports that have this choice.
>
> I think the problem is that mpbb is explicitly specifying the variants when installing the dependencies, particularly since wine is 32-bit so it needs the dependencies installed with the universal variant, and when installing cairo with x11, quartz and universal, it is passing those variants down to cairo's dependencies, including glib2.
>
> I don't know why mpbb is specifying all the variants when building dependencies. It seems like it would be enough to just specify universal, and let the port's default variants take care of the rest.

A trivial patch like this one:
https://trac.macports.org/attachment/ticket/52742/variants-master.cfg.2.diff

could be the answer for
https://trac.macports.org/ticket/35897

(I would be really grateful if this was fixed.)

So I don't like the idea of generally removing variants, but we do
need to find a solution for this problem.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Kenneth F. Cunningham
In reply to this post by Ryan Schmidt-24

On 2017-06-27, at 2:31 AM, Ryan Schmidt wrote:

> We used to be able to build wine on the buildbot, but we aren't anymore:
>
> https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/32791
>
> The error occurs when installing dependencies, specifically cairo:


This would also be why the Travis build system won't build anything I put up lately with cairo listed as a dep.


> The cairo port has for years had both x11 and quartz variants that are both enabled by default. The glib2 port recently got x11 and quartz variants added, and they conflict with one another, as they do in most ports that have them; the user must choose one or the other. The default is x11, as it is for other ports that have this choice.

If deleting the +x11 and +quartz variants for cairo is for some reason not desirable in the end, perhaps they can be defaulted to work exclusively again, and match all the other ports. That would allow everything to work again.

K
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Ryan Schmidt-24

On Jun 27, 2017, at 09:12, Ken Cunningham wrote:

If deleting the +x11 and +quartz variants for cairo is for some reason not desirable in the end, perhaps they can be defaulted to work exclusively again, and match all the other ports. That would allow everything to work again.

That would reduce functionality, so I don't think we should do that.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Mojca Miklavec-2
In reply to this post by Mojca Miklavec-2
On 27 June 2017 at 12:04, Mojca Miklavec wrote:
>
> So I don't like the idea of generally removing variants, but we do
> need to find a solution for this problem.

To clarify. I'm not claiming that the current algorithm is 100%
correct in specifying the variants, only that the functionality is
helpful. Maybe there's a way to revise and improve the exact way of
variant calculation?

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Rainer Müller-4
In reply to this post by Ryan Schmidt-24
On 2017-06-27 11:31, Ryan Schmidt wrote:
>> ----> Installing dependency (55 of 120) 'cairo' with variants '+quartz+universal+x11'
>> ...
>> Error: glib2: Variant quartz conflicts with x11
>
> The cairo port has for years had both x11 and quartz variants that are both enabled by default. The glib2 port recently got x11 and quartz variants added, and they conflict with one another, as they do in most ports that have them; the user must choose one or the other. The default is x11, as it is for other ports that have this choice.
>
> I think the problem is that mpbb is explicitly specifying the variants when installing the dependencies, particularly since wine is 32-bit so it needs the dependencies installed with the universal variant, and when installing cairo with x11, quartz and universal, it is passing those variants down to cairo's dependencies, including glib2.

Hm, interestingly the same would happen when trying to install cairo
while explicitly requesting +x11 +quartz variants on a clean prefix.
This can only be resolved by installing glib2 first.

> I don't know why mpbb is specifying all the variants when building dependencies. It seems like it would be enough to just specify universal, and let the port's default variants take care of the rest.

I think the idea was to expand default variants to the build request,
such that lookups in the failcache would match. Selecting a default
variant was supposed to have the same effect as building without
selecting variants.

Apparently this is not true, so we should revert this behavior and only
pass explicitly requested variants.

As I understand it, in the worst case, we would try to build a port
multiple times as the failcache entry would not match. I don't think
this will happen that often.

Rainer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Mojca Miklavec-2
On 3 July 2017 at 19:03, Rainer Müller wrote:

> On 2017-06-27 11:31, Ryan Schmidt wrote:
>>> ----> Installing dependency (55 of 120) 'cairo' with variants '+quartz+universal+x11'
>>> ...
>>> Error: glib2: Variant quartz conflicts with x11
>>
>> The cairo port has for years had both x11 and quartz variants that are both enabled by default. The glib2 port recently got x11 and quartz variants added, and they conflict with one another, as they do in most ports that have them; the user must choose one or the other. The default is x11, as it is for other ports that have this choice.
>>
>> I think the problem is that mpbb is explicitly specifying the variants when installing the dependencies, particularly since wine is 32-bit so it needs the dependencies installed with the universal variant, and when installing cairo with x11, quartz and universal, it is passing those variants down to cairo's dependencies, including glib2.
>
> Hm, interestingly the same would happen when trying to install cairo
> while explicitly requesting +x11 +quartz variants on a clean prefix.
> This can only be resolved by installing glib2 first.
>
>> I don't know why mpbb is specifying all the variants when building dependencies. It seems like it would be enough to just specify universal, and let the port's default variants take care of the rest.
>
> I think the idea was to expand default variants to the build request,
> such that lookups in the failcache would match. Selecting a default
> variant was supposed to have the same effect as building without
> selecting variants.
>
> Apparently this is not true, so we should revert this behavior and only
> pass explicitly requested variants.
>
> As I understand it, in the worst case, we would try to build a port
> multiple times as the failcache entry would not match. I don't think
> this will happen that often.

I think I figured out what the real problem is.

I first wanted to suggest a potential solution: getting the list of
dependencies in the right order, installing glib2 before building
cairo.

Then I realized that we already do that. The problem lies in something
that I objected from the beginning:

Installing 120 dependencies of wine-devel:
...
 - glib2 +universal+x11
...
 - cairo +quartz+universal+x11
...
----> Installing dependency (28 of 120) 'glib2' with variants '+universal+x11'
...
--->  Deactivating glib2 @2.52.3_0+universal+x11
--->  Cleaning glib2
...
----> Installing dependency (55 of 120) 'cairo' with variants
'+quartz+universal+x11'
...
--->  Computing dependencies for cairo
...
Error: glib2: Variant quartz conflicts with x11

The problem is that we loop through all dependencies and install and
*uninstall* each individual one of them. This is both inefficient and
leads to problems like this one.

The problem should be solved if we skip deactivation of dependencies.

The only advantage of current approach is that we don't activate any
dependencies if one dependency is known to fail. We could still check
for that, but we should not deactivate dependencies.

This should be easy and high priority to fix.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Rainer Müller-4
On 2017-07-03 22:26, Mojca Miklavec wrote:
> The problem is that we loop through all dependencies and install and
> *uninstall* each individual one of them. This is both inefficient and
> leads to problems like this one.
>
> The problem should be solved if we skip deactivation of dependencies.

We have to do this as we want to build all ports cleanly. Otherwise we
would not be able to detect missing dependencies.

Rainer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Mojca Miklavec-2
Hi,

One question: does a clean installation of "gtk3 +quartz" still work
now? It depends on both glib2 and cairo, so I would expect problems or
at least some weird non-determinism.

On 4 July 2017 at 00:36, Rainer Müller <[hidden email]> wrote:
> On 2017-07-03 22:26, Mojca Miklavec wrote:
>> The problem is that we loop through all dependencies and install and
>> *uninstall* each individual one of them. This is both inefficient and
>> leads to problems like this one.
>>
>> The problem should be solved if we skip deactivation of dependencies.
>
> We have to do this as we want to build all ports cleanly. Otherwise we
> would not be able to detect missing dependencies.

Ports - yes. But why are we being so picky about dependencies? On the
old buildbot we would only ever run "port install foo". OK, now we
would also upload individual dependencies to the server in case they
were not built before (which they usually should be).

We should at least provide an option to avoid such behaviour on Travis
to make the builds with already limited time frame for the build, more
efficient.

If building individual dependencies cleanly and recursively is
essential, then we need to adapt the algorithm.

I see two options:

(a) Do the installation recursively. We now list all dependencies, but
then install some dependencies (among them A), deactivate them, and
install another dependency (say B which depends on A). Variants for A
might then be wrong. We should keep the dependency list from the first
step and before installing B, install A with original variants and all
other B's dependencies. (Sorry, my sentence is probably super
confusing. What I mean is that we should explicitly install all of
cairo's dependencies before installing cairo, including "glib2 +x11".)

(b) When building cairo, we should check whether the main port was
built with any variants. If the main port was built with +quartz (that
is: once we start supporting building "gtk3 +quartz"), then keep
+quartz when installing cairo. If the main port was not built with
+quartz, only list non-default variants. We can still know which
variants were built with cairo, so we can either put those variants in
the failcache list. Or well ... as it turned out a failed "cairo +x11
+quartz" is not exactly the same as a failed "cairo" with x11 and
cairo being explicit, so two failcaches would be fine.

None of that is straightforward, but if we want to be picky about
proper build order, we should be picky to the very last bit.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Rainer Müller-4
On 2017-07-04 07:11, Mojca Miklavec wrote:
> One question: does a clean installation of "gtk3 +quartz" still work
> now? It depends on both glib2 and cairo, so I would expect problems or
> at least some weird non-determinism.

I see no problem with that. Only the explicitly specified +quartz is
passed down to dependencies. On a clean prefix this would install:
 glib2 +quartz
 cairo +quartz +x11
 gtk3 +quartz

The problem only occurs when you explicitly ask for both +x11 and
+quartz on a dependent of glib2 and glib2 was not yet installed.

> On 4 July 2017 at 00:36, Rainer Müller <[hidden email]> wrote:
>> On 2017-07-03 22:26, Mojca Miklavec wrote:
>>> The problem is that we loop through all dependencies and install and
>>> *uninstall* each individual one of them. This is both inefficient and
>>> leads to problems like this one.
>>>
>>> The problem should be solved if we skip deactivation of dependencies.
>>
>> We have to do this as we want to build all ports cleanly. Otherwise we
>> would not be able to detect missing dependencies.
>
> Ports - yes. But why are we being so picky about dependencies? On the
> old buildbot we would only ever run "port install foo". OK, now we
> would also upload individual dependencies to the server in case they
> were not built before (which they usually should be).
In order to make use of the failcache, we need to build dependencies
individually, so we can check whether they failed before.

The ideal solution would have been to schedule an individual build job
for each dependency. However, as we noticed builds just cannot be
scheduled dynamically with buildbot...

> We should at least provide an option to avoid such behaviour on Travis
> to make the builds with already limited time frame for the build, more
> efficient.

+1

Sounds reasonable for the quick check on Travis, where we mostly care
about the changed port and not about dependencies.

> (a) Do the installation recursively. We now list all dependencies, but
> then install some dependencies (among them A), deactivate them, and
> install another dependency (say B which depends on A). Variants for A
> might then be wrong. We should keep the dependency list from the first
> step and before installing B, install A with original variants and all
> other B's dependencies. (Sorry, my sentence is probably super
> confusing. What I mean is that we should explicitly install all of
> cairo's dependencies before installing cairo, including "glib2 +x11".)

I still don't understand why we pass *default* variants to dependencies
at all. As I see it, the problem would go away if we would not request
default variants explicitly...

@Clemens,
as you originally added this to mpbb/tools/dependencies.tcl, do you
still remember the reason?

I am attaching a patch to only print active variants that are not
enabled by default (or disabled default variants). To me the result
looks like what we want to have:

$ tools/dependencies.tcl wine | grep -E 'glib2|cairo'
glib2 +universal
cairo +universal
$ tools/dependencies.tcl gtk3 +quartz | grep -E 'glib2|cairo'
glib2 +quartz
cairo

I did not test this patch with a buildbot setup, though.

> (b) When building cairo, we should check whether the main port was
> built with any variants. If the main port was built with +quartz (that
> is: once we start supporting building "gtk3 +quartz"), then keep
> +quartz when installing cairo. If the main port was not built with
> +quartz, only list non-default variants. We can still know which
> variants were built with cairo, so we can either put those variants in
> the failcache list. Or well ... as it turned out a failed "cairo +x11
> +quartz" is not exactly the same as a failed "cairo" with x11 and
> cairo being explicit, so two failcaches would be fine.

Introducing special cases for +x11 and +quartz adds even more complexity
and I would not want to bless variants in any special way.

Rainer

0001-Do-not-request-default-variants-explictly.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Clemens Lang-2
Hi,

On Tue, Jul 04, 2017 at 04:23:13PM +0200, Rainer Müller wrote:
> I still don't understand why we pass *default* variants to
> dependencies at all. As I see it, the problem would go away if we
> would not request default variants explicitly...
>
> @Clemens,
> as you originally added this to mpbb/tools/dependencies.tcl, do you
> still remember the reason?

You were right on it when you mentioned the failcache. However, you only
considered the reading part of the failcache, not the writing part of
it.

We need to know the canonical (i.e., fully-expanded) set of variants for
every port we build, because even when a port is only installed as a
dependency, we update the failcache when it fails.

Failure to do this would possibly cache a build failure of what mpbb
thinks is 'cairo +quartz' (but actually is 'cairo +quartz+x11') cached
for 'cairo +quartz-x11' (i.e. canonically 'cairo +quartz').


> I am attaching a patch to only print active variants that are not
> enabled by default (or disabled default variants). To me the result
> looks like what we want to have:
>
> $ tools/dependencies.tcl wine | grep -E 'glib2|cairo'
> glib2 +universal
> cairo +universal
> $ tools/dependencies.tcl gtk3 +quartz | grep -E 'glib2|cairo'
> glib2 +quartz
> cairo

No, this won't work, because with this output you can no longer
distinguish 'cairo (default variants)' from 'cairo -quartz-x11'. This is
probably not a valid configuration for the cairo port specifically, but
you get the idea.

I think a patch that does not return a default variant if a conflicting
other variant was selected should work fine, though (and is exactly what
MacPorts itself would do in these situations, afaik).

--
Clemens
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Joshua Root-8
On 2017-7-5 06:00 , Clemens Lang wrote:

> Hi,
>
> On Tue, Jul 04, 2017 at 04:23:13PM +0200, Rainer Müller wrote:
>> I still don't understand why we pass *default* variants to
>> dependencies at all. As I see it, the problem would go away if we
>> would not request default variants explicitly...
>>
>> @Clemens,
>> as you originally added this to mpbb/tools/dependencies.tcl, do you
>> still remember the reason?
>
> You were right on it when you mentioned the failcache. However, you only
> considered the reading part of the failcache, not the writing part of
> it.
>
> We need to know the canonical (i.e., fully-expanded) set of variants for
> every port we build, because even when a port is only installed as a
> dependency, we update the failcache when it fails.
>
> Failure to do this would possibly cache a build failure of what mpbb
> thinks is 'cairo +quartz' (but actually is 'cairo +quartz+x11') cached
> for 'cairo +quartz-x11' (i.e. canonically 'cairo +quartz').
>
>
>> I am attaching a patch to only print active variants that are not
>> enabled by default (or disabled default variants). To me the result
>> looks like what we want to have:
>>
>> $ tools/dependencies.tcl wine | grep -E 'glib2|cairo'
>> glib2 +universal
>> cairo +universal
>> $ tools/dependencies.tcl gtk3 +quartz | grep -E 'glib2|cairo'
>> glib2 +quartz
>> cairo
>
> No, this won't work, because with this output you can no longer
> distinguish 'cairo (default variants)' from 'cairo -quartz-x11'. This is
> probably not a valid configuration for the cairo port specifically, but
> you get the idea.
So really we need two pieces of information: the
canonical_active_variants to use with the fail cache, and the variants
that should be actually be requested.

How about this?

- Josh

mpbb_requested_variants.diff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Clemens Lang-2
In reply to this post by Clemens Lang-2
Hey,

On Tue, Jul 04, 2017 at 10:00:16PM +0200, Clemens Lang wrote:

> > I am attaching a patch to only print active variants that are not
> > enabled by default (or disabled default variants). To me the result
> > looks like what we want to have:
> >
> > $ tools/dependencies.tcl wine | grep -E 'glib2|cairo'
> > glib2 +universal
> > cairo +universal
> > $ tools/dependencies.tcl gtk3 +quartz | grep -E 'glib2|cairo'
> > glib2 +quartz
> > cairo
>
> No, this won't work, because with this output you can no longer
> distinguish 'cairo (default variants)' from 'cairo -quartz-x11'. This
> is probably not a valid configuration for the cairo port specifically,
> but you get the idea.

I had another look at your proposed patch. In general, the idea of
printing active variants that are not enabled by default and disabled
default variants is correct. We need a string that uniquely identifies a
specific variant combination when passed to 'port install', and your
idea fulfills that property.

However, the implementation has problems:

- Due to the way how $depinfo(active_variants) works, it only contains
  positive variants. Hence $active_variants($variant) eq "-" can never
  be true and your code will never disable a default variant. This works
  in your gtk3 +quartz example for the same reason that 'port info glib2
  +quartz' does not show x11 as a default variant.
- $default_variants does not contain default variants that have been
  disabled for this port. Just because a variant is not in
  default_variants does not mean that it is not a default variant of the
  given port, it might just have been disabled for this instance. It's
  weird, I know.

Note, btw, that this did work correctly before
  https://github.com/macports/mpbb/commit/4462924d822cb61464b6ecb8badcc9949231527b
I'm adding Joshua to Cc.

Since Joshua's commit did improve speed quite a bit (turns out the extra
Portfile execution comes with a hefty performance penalty), how about
this approach:

 - Print all selected variants that are not default.
 - Intersect the set of variants explicitly disabled on the command line
   with the set of available variants of a port, and print those.

This will still give us a situation where disabling a non-default
variant of a port will cause a failcache miss, but your patch already
had these downsides.

Reviews please: https://github.com/macports/mpbb/pull/4

--
Clemens
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Clemens Lang-2
In reply to this post by Joshua Root-8
Hey,

On Wed, Jul 05, 2017 at 07:18:59AM +1000, Joshua Root wrote:
> So really we need two pieces of information: the
> canonical_active_variants to use with the fail cache, and the variants
> that should be actually be requested.

Yes.

> How about this?

Close, but not fully there, since neither $active_variants nor
$default_variants will ever contain explicitly disabled variants, even
if they are default.

Try this with gtk3 +quartz-x11. It should give you -x11 for all ports
that support +quartz+x11 at the same time, but it will probably give you
+quartz only, implicitly enabling +x11 (if it's the default variant).

--
Clemens
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Joshua Root-8
On 2017-7-5 09:02 , Clemens Lang wrote:

> Hey,
>
> On Wed, Jul 05, 2017 at 07:18:59AM +1000, Joshua Root wrote:
>> So really we need two pieces of information: the
>> canonical_active_variants to use with the fail cache, and the variants
>> that should be actually be requested.
>
> Yes.
>
>> How about this?
>
> Close, but not fully there, since neither $active_variants nor
> $default_variants will ever contain explicitly disabled variants, even
> if they are default.

Not so, $default_variants will contain all variants that are selected by
default, regardless of whether they are currently.

> Try this with gtk3 +quartz-x11. It should give you -x11 for all ports
> that support +quartz+x11 at the same time, but it will probably give you
> +quartz only, implicitly enabling +x11 (if it's the default variant).

Nope, works fine, e.g. "pango +quartz -x11" is output.

- Josh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Joshua Root-8
I did notice one bug with my initial patch; dependencies.tcl needs to
print "" instead of nothing when there are no active variants. Not hard
to fix.

- Josh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Clemens Lang-2
In reply to this post by Joshua Root-8
Hey,

----- On 5 Jul, 2017, at 03:15, Joshua Root [hidden email] wrote:

> Not so, $default_variants will contain all variants that are selected by
> default, regardless of whether they are currently.

I have no idea what I did in my testing yesterday, but you're right. It
was late.

Are you going to commit this change?

--
Clemens Lang
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Rainer Müller-4
In reply to this post by Joshua Root-8
On 2017-07-04 23:18, Joshua Root wrote:
> On 2017-7-5 06:00 , Clemens Lang wrote:
>> You were right on it when you mentioned the failcache. However, you only
>> considered the reading part of the failcache, not the writing part of
>> it.

Makes sense, of course we need the full set of selected variants for that.
> So really we need two pieces of information: the
> canonical_active_variants to use with the fail cache, and the variants
> that should be actually be requested.
>
> How about this?

The results from tools/dependencies.tcl with this patch look good from a
quick test.

(Yes, the empty variants would still a problem as you identified in the
other mail.)

Rainer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Joshua Root-8
In reply to this post by Clemens Lang-2
On 2017-7-5 20:21 , Clemens Lang wrote:

> Hey,
>
> ----- On 5 Jul, 2017, at 03:15, Joshua Root [hidden email] wrote:
>
>> Not so, $default_variants will contain all variants that are selected by
>> default, regardless of whether they are currently.
>
> I have no idea what I did in my testing yesterday, but you're right. It
> was late.
>
> Are you going to commit this change?

I haven't tested it actually running under buildbot yet. Anyone please
feel free to beat me to it. :)

- Josh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Buildbot now fails to build wine dependencies

Joshua Root-8
In reply to this post by Joshua Root-8
On 2017-7-5 11:27 , Joshua Root wrote:
> I did notice one bug with my initial patch; dependencies.tcl needs to
> print "" instead of nothing when there are no active variants. Not hard
> to fix.

Here's the fixed version.

- Josh

mpbb_requested_variants.diff (8K) Download Attachment
12
Loading...