Product team group | XCP-ng and XO forum

stormi

@rzr said:

As this is my first time installing these update candidates,

Actually we moved first batch of packages that landed in testing to candidates repo, to avoid mix up in the second batch that just landed in testing repo. Since nothing new appeared in candidate you should probably already had them before, home this is clarifying what is actually happening

Next yum update should just pull the latest stable versions?

Not if you already have installed then from testing (or candidate) repo, because versions are same, it's only the distribution channel that change, no impact for testers.

I'm not sure what you understood from @scarfantennae's question, but that we moved packages from xcp-ng-testing to xcp-ng-candidates doesn't seem on topic here.

The question is: "now that I've applied this update candidates from the testing repositories, am I definitively in testing mode?".

The answer is: no, because:

The --enable-repo switch only applies to the two commands you ran: clearing the cache and applying updates. The repositories remain disabled by default, so yes, next time you update you'll only get stable updates if there are any.
Either the exact packages that you installed will be pushed as official updates (in which case there will be nothing for you to do), or we'll push newer updates that will supersede them automatically next time you update.

Hope it's clear.

stormi

@rzr said:

Thank you again for feedback we will try to address reported issues on next batch (to come soon).

Note that some issues are not related to this specific update batch, but might have been introduced on previous ones (TBC).

Not knowing myself what it meant, I asked Philippe: it's about the nslookup issue. And potentially the issue reported by @ph7 but it's not clear to me yet if there was a problem with XCP-ng or Xen Orchestra.

Anyway, basically this means that there's no known issue caused by this batch of updates, and that we'll keep addressing any relevant issue in the next updates if necessary, as usual.

stormi

@Andrew We'll publish a fix for bind-utils, indeed, even if it's not part of the officially supported additional packages for XCP-ng, as it can be useful and we don't have strong reasons not to fix it.

Regarding other packages affected by the openssl update, @rzr handled many of them as part of the OpenSSL update back then already, so now we'll mostly rely on reports such as yours in case we missed something which is actually used by the user community.

Product team

Posts

Member List