@Marty Ewings i’ll call you in a sec

Using rspec-puppet 2.12.0]

do we have any dependency on git default branch name in any gem-related scripts? Anything known to be broken with

main

branch name? especially for a beaker hypervisor plugin

We're going to yank the puppet 8.0.0 gems and publish 8.0.1 with the correct ruby requirements. I'll file a ticket about the issue and post here later.

awesome, thanks

This message was deleted.

This message was deleted.

Dang. I found a bug in

deferrable_epp

(and missed the cutoff for a 8.X minor release). Oh well.

@binford2k ^ look out for a PR ‘coming soon’

Can’t seem to reproduce in a test, (perhaps rspec-puppet sensitive support is weird), but

epp

returns a

Sensitive

if any parameters were sensitive. The

deferrable_epp

function doesn’t allow that in its signature.

@Craig Gumbley https://github.com/puppetlabs/puppetlabs-apache/pull/2408 another one to unbreak the stdlib changes

☝️ I was just joining this channel to ask about the massive amount of Puppet Resolver issues I am seeing trying to update modules. Is this up here a big fix or should we pause updating modules?

All of them are related to stdlib from what I can see and what VSCode is telling me.

o/

what kind of issues do you see

I am trying to take a screenshot, but once I activate it it goes away. Lemme try a copypasta, @bastelfreak

I have not committed this, but this is now what I am getting trying to update all the relevant modules, though only

ghoneycutt-common

is "squiggled" in VScode:

Puppetfile Resolver could not find compatible versions for possibility named "stdlib":
  In Puppetfile:
    puppetlabs-stdlib =8.6.0

    puppetlabs-ntp =10.0.0 was resolved to Forge puppetlabs-ntp-10.0.0, which depends on
      puppetlabs-stdlib >= 4.13.1 < 9.0.0

    puppetlabs-firewall =5.0.0 was resolved to Forge puppetlabs-firewall-5.0.0, which depends on
      puppetlabs-stdlib >= 4.0.0 < 9.0.0

    puppetlabs-apache =10.0.0 was resolved to Forge puppetlabs-apache-10.0.0, which depends on
      puppetlabs-stdlib >= 4.13.1 < 9.0.0

    puppetlabs-accounts =8.0.0 was resolved to Forge puppetlabs-accounts-8.0.0, which depends on
      puppetlabs-stdlib >= 5.0.0 < 9.0.0

    puppet-extlib =6.2.0 was resolved to Forge puppet-extlib-6.2.0, which depends on
      puppetlabs-stdlib >= 4.18.0 < 9.0.0

    puppet-fail2ban =4.2.0 was resolved to Forge puppet-fail2ban-4.2.0, which depends on
      puppetlabs-stdlib >= 4.25.0 < 9.0.0

    puppet-systemd =4.2.0 was resolved to Forge puppet-systemd-4.2.0, which depends on
      puppetlabs-stdlib >= 4.13.1 < 9.0.0

    puppet-python =6.4.0 was resolved to Forge puppet-python-6.4.0, which depends on
      puppetlabs-stdlib >= 4.19.0 < 9.0.0

    puppet-postfix =3.1.0 was resolved to Forge puppet-postfix-3.1.0, which depends on
      puppetlabs-stdlib >= 4.13.0 < 9.0.0

    puppet-openssl =2.0.1 was resolved to Forge puppet-openssl-2.0.1, which depends on
      puppetlabs-stdlib >= 6.0.0 < 9.0.0

    puppet-logrotate =6.1.0 was resolved to Forge puppet-logrotate-6.1.0, which depends on
      puppetlabs-stdlib >= 4.22.0 < 9.0.0

    puppet-letsencrypt =9.2.0 was resolved to Forge puppet-letsencrypt-9.2.0, which depends on
      puppetlabs-stdlib >= 4.13.1 < 9.0.0

    puppet-php =8.2.0 was resolved to Forge puppet-php-8.2.0, which depends on
      puppetlabs-stdlib >= 4.16.0 < 9.0.0

    puppet-selinux =3.4.1 was resolved to Forge puppet-selinux-3.4.1, which depends on
      puppetlabs-stdlib >= 4.18.0 < 9.0.0

    puppet-kmod =3.2.0 was resolved to Forge puppet-kmod-3.2.0, which depends on
      puppetlabs-stdlib >= 5.0.0 < 9.0.0

    puppet-cron =3.0.0 was resolved to Forge puppet-cron-3.0.0, which depends on
      puppetlabs-stdlib >= 4.25.0 < 9.0.0

    puppet-archive =6.1.2 was resolved to Forge puppet-archive-6.1.2, which depends on
      puppetlabs-stdlib >= 4.18.0 < 9.0.0

    pcfens-filebeat =4.13.0 was resolved to Forge pcfens-filebeat-4.13.0, which depends on
      puppetlabs-stdlib >=4.13.0 < 9.0.0

    iu-aide =2.1.0 was resolved to Forge iu-aide-2.1.0, which depends on
      puppetlabs-stdlib >=4.0.0 < 9.0.0

    iu-duo_unix =4.0.0 was resolved to Forge iu-duo_unix-4.0.0, which depends on
      puppetlabs-stdlib >= 5.0.0 < 9.0.0

    herculesteam-augeasproviders_core =3.1.0 was resolved to Forge herculesteam-augeasproviders_core-3.1.0, which depends on
      puppetlabs-stdlib >= 3.2.0 < 9.0.0

    hardening-os_hardening =2.3.3 was resolved to Forge hardening-os_hardening-2.3.3, which depends on
      puppetlabs-stdlib >= 4.6.0 < 8.0.0

    ghoneycutt-ssh =4.1.0 was resolved to Forge ghoneycutt-ssh-4.1.0, which depends on
      puppetlabs-stdlib >= 8.0.0 < 9.0.0

    ghoneycutt-common =1.10.0 was resolved to Forge ghoneycutt-common-1.10.0, which depends on
      puppetlabs-stdlib >= 4.6.0 < 7.0.0

See the

ghoneycutt-common

module at https://forge.puppet.com/ghoneycutt/common?src=slack&channel=voxpupuli

that's expected

As you can see, it is pretty wide ranging and then again, it still looks like the dependencies are satisfied unless I am missing something

This message was deleted.

So what does that mean for course of action?

This message was deleted.

\o/

@Robert FD a) update stdlib and check if something breaks or b) wait until maintainers update their metadata.json and hope they actually tested it

What is the usual (average) turn around time when a new central dep like that gets updated? We usually update the modules every quarter.

"it depends" 😄

this once is a bit special. you need to understand why those major releases are happening. most modules drop puppet 6 support to be able to add puppet 8 support

so the big thing is dropping puppet 6, a major release is the symptom