The only way I can restrict my module build to certain platform is to build for all, then cancel the builds I don't want. There must be a better way....

CC @mizdebsk Hi, do you have any insight? I was trying to avoid building my module for rawhide by limiting the platforms on which my module builds, but I was unable to find a way.

@mbooth that is quite odd that it builds for f30 when platform is []. In the meantime, if you'd like to build for everything but rawhide, you could do something like platform: [-f31], which builds for all available platforms but excludes f31.

Oh that is interesting, by using the [-f31] notation, I was able to successfully submit a build -- thanks for the hint!

Obviously the original problem still stands, since I assume the [f30] notation should also still work.

This is most likely bug in MBS caused by a fact that we pull-in the buildrequires based on the platform stream_version against which the module has been built. Instead, we should pull-in based on the requires.

The javapackages-tools buildrequires platform:f28, but requires any platform stream - platform:[].

When the "tycho" module limits the platform to platform:[f30], MBS won't pull-in the javapackages-tools, because it checks that it was built against platform:f28.

When the "tycho" module buildrequires platform:[-f31], it will pull it in, because it also builds against platform:f28.

Instead of watching on "buildrequires" for deps, we should watch for "requires".

I see, so unless this is fixed all modules that rely on javapackages-tools are likely to stop building when F28 goes EOL in one month.

BTW, if I want to avoid building on F28, I have to build for my favourite release and F28, then subsequently cancel the F28 build.

Hey guys, any progress?

I'm pretty concerned my modules will stop building when F28 goes EOL...

@lucarval any thoughts on when we can schedule this?

I've added this to our next sprint (starting on May 15th). It looks like Fedora 28 is gonna go EOL on May 28th.

Thanks for taking a look

I've just hit this issue too. F28 is about to go EOL, but I can't rebuild my modules against F29 due to this bug.

@mizdebsk, this is quite complex issue to solve on MBS side. Would you be able to rebuild javapackage-tools against all supported fedora versions instead of building it just on f28?

@mprahl, this might be tricky to fix properly... MBS will need to store the "requires" of a module in database in a similar way as "buildrequires", but the difference is that we need a way how to express:

• General platform: [streams] requires.
• Negative platform: [-streams] requires.
• Multiple requires: platform: [stream1] and requires: platform: [stream2] MMD records.

Based on that info, we can find out latest platform streams which are required by a module.

I have patch locally which implements storing positive/negative platform streams, but I need to rework that to support multiple requires.

I will see what I can do as workaround to have the module built. Switching to MSE builds (one build per platform) is one of possibilities.

We did short IRC meeting with contyk and Igor about this issue and did following doc:

https://docs.google.com/document/d/1mMLR-RBr6ZtDhNIcx5eJtUtkOUDJgM6o6EK3S2crxJs/edit#

I'm going to implement the "Final decision" part of this on Friday.

What's going on with this?

Today fedpkg module-build stopped working with this:

$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
Cannot find any module builds for javapackages-tools:201801

What's going on with this?
Today fedpkg module-build stopped working with this:
$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
Cannot find any module builds for javapackages-tools:201801

Since javapackages-tools:201801 was built with platform:f28, this issue is likely due to https://pagure.io/fedora-infrastructure/issue/7862. As part of that ticket, we retired platform:f28 so no new builds could be built against platform:f28, but from my understanding of how depsolving works in MBS (@jkaluza is the expert on that), this also keeps the modules built against platform:f28 from being buildrequired.

The simple workaround would be to reenable platform:f28. It may require a manual database edit, which I don't have access to do but can request it.

The simple workaround would be to reenable platform:f28. It may require a manual database edit, which I don't have access to do but can request it.

Right now any module that BRs the javapackages-tools module cannot be built because of this bug, so I would appreciate that if at all possible.

https://pagure.io/fm-orchestrator/pull-request/1281

\ó/ :tada:

Thanks! I will this as soon as I'm able

@mbooth it's not deployed in Fedora infra yet, but I can let you know when it is.

@mbooth it's not deployed in Fedora infra yet, but I can let you know when it is.

Gah, clearly I am too excited by it :-)

Thanks for working on this

@mbooth this is now deployed in Fedora Infra. Your testing is appreciated. :smile:

@jkaluza @mprahl I'm reopening because my original use-case still doesn't work:

I want to restrict builds of a module to f30 (because I don't care about f28 or f29):

https://src.fedoraproject.org/modules/tycho/c/e2fd1f31b7c1f3c70a311d8f1c68dc325d959d6c?branch=1.4

    dependencies:
        - buildrequires:
              javapackages-tools: [201801]
              tycho: [1.4]
              platform: [f30]
          requires:
              javapackages-tools: [201801]
              platform: []

And when I try to build I still get the error:

[mbooth@thinkpad-p50 tycho]$ git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 506 bytes | 506.00 KiB/s, done.
Total 5 (delta 3), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 2 commits
remote: Sending to redis to log activity and send commit notification emails
remote: * Publishing information for 2 commits
To ssh://pkgs.fedoraproject.org/modules/tycho
   d75e578..e2fd1f3  1.4 -> 1.4
[mbooth@thinkpad-p50 tycho]$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
Cannot find any module builds for javapackages-tools:201801

This makes @mbooth a sad programmer :-(

It's not at all obvious to me why platform: [f30] DOES NOT work but platform: [-f29] DOES work -- especially now that F28 has been re-retired...

@jkaluza could you please take a look at this when you get back from Flock?

@mbooth can you try once more now? I've changed the MBS configuration and also changed the platform:f28 configuration so it should work now. I've also submitted testmodule build against platform:f30 which builrequires javapackages-tools built against platform:f28 and it worked for me:

https://mbs.fedoraproject.org/module-build-service/2/module-builds/6045

@jkaluza Hi I tried building the eclipse module with this change [0] and it looks much better now [1] (the build started and some components completed before it failed for unrelated reasons) so thanks!

[0] https://src.fedoraproject.org/modules/eclipse/c/e8ef414dd5542f2496663d6782a224a8eabafba7?branch=2019-06
[1] https://mbs.fedoraproject.org/module-build-service/2/module-builds/6113

I get this again today :-(

When building the HEAD of this branch: https://src.fedoraproject.org/modules/eclipse/tree/2019-06

$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
Cannot find any module builds for javapackages-tools:201801

As discussed in #fedora-modularity, MBS will need to be updated. A freeze break exception was requested at:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/LCJO7Q7HUFOOIHDHZOOLEGPVLU43B3OD/

As discussed in #fedora-modularity, MBS will need to be updated. A freeze break exception was requested at:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/LCJO7Q7HUFOOIHDHZOOLEGPVLU43B3OD/

Looks like I am now able to kick off builds since this upgrade was done -- many thanks.

Commit 77647ac4 fixes this issue

Commit 77647ac4 fixes this issue

Dead link :-(