On Tue, 2014-10-28 at 15:27 -0600, Chris Murphy wrote: > OK yeah, this sounds rather dire at the end, but is beyond confusing… x requires x, y requires y, z requires z. Umm what? > > > WARNING: problems were encountered during transaction test: > broken dependencies > NetworkManager-wifi-1:0.9.10.0-5.git20140704.fc21.x86_64 requires NetworkManager-wifi-1:0.9.10.0-5.git20140704.fc21.x86_64 > NetworkManager-adsl-1:0.9.10.0-5.git20140704.fc21.x86_64 requires NetworkManager-adsl-1:0.9.10.0-5.git20140704.fc21.x86_64 > NetworkManager-wwan-1:0.9.10.0-5.git20140704.fc21.x86_64 requires NetworkManager-wwan-1:0.9.10.0-5.git20140704.fc21.x86_64 > NetworkManager-bluetooth-1:0.9.10.0-5.git20140704.fc21.x86_64 requires NetworkManager-bluetooth-1:0.9.10.0-5.git20140704.fc21.x86_64 > Continue with the upgrade at your own risk. So I believe I have a theory for what's going on here, and it's kind of fun. The point of instrepo is to provide a repo for fedup to get the upgrade.img from, but I suspect it also uses it as a package repository. So this is caused by the packages we 'pull' into composes. The instructions say to use the current compose's Server tree as the 'instrepo' - because that's how we can test the 'correct' upgrade.img for the compose. However, that tree also has a package repository. The packages in that repository are *mostly* the same as the packages in the 'fedora' (stable) repository, but not quite. The compose trees are the trees used to build the images, right? So obviously, when we 'pull' packages that are not yet stable but which fix blocker/FE bugs into the compose requests, they get pulled into those trees. So if you look in https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Server/x86_64/os/Packages/ you'll see it has the packages that are being 'pulled' into the composes - the packages from http://kojipkgs.fedoraproject.org/mash/bleed/ . However, it's not a *complete* package repository. It only contains the packages needed to compose the Server DVD, because after all, that's what the tree is ultimately *for*. Have a look in https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Server/x86_64/os/Packages/n/ and you'll see it doesn't have...all those NetworkManager sub-packages your fedup run complains about. No wifi, no adsl, no wwan, no bluetooth. Reason being, those packages aren't in the Server package set. Now, NetworkManager is one of the packages we're 'pulling' into composes - we 'pull'ed 9git20140704 to fix the weird dep chain issue which caused 32-bit Workstation TC4 not to boot. So ultimately, fedup has a problem. It has 9git20140704 builds of half the NetworkManager packages, from https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Server/x86_64/os/Packages/n/ , but it doesn't have 9git20140704 builds of the rest, because they're not in any repo it has enabled (they'd be in updates-testing, but that won't usually be enabled on an upgrade from a stable release). It wants to upgrade the packages that *are* in Server to 9git, but then it can't find matching versions of the subpackages you have installed that are *not* in Server. This shouldn't be a huge issue for non-testers because by the same we release a milestone build we always try to have the packages that were 'pulled in' marked as stable properly, so people shouldn't encounter this. It's likely to be a somewhat regular occurrence for TC/RC testers, though, so long as we don't have an Everything tree with upgrade.img in it. Enabling updates-testing should always avoid it, I think (unless we've 'pulled' in a build which hasn't even made it to u-t yet, which occasionally happens), though of course it means you won't be testing an upgrade to the current 'stable' 21 package set. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
