On Thursday, October 9, 2014 2:56:12 PM UTC-6, Kylo Ginsberg wrote: > > On Thu, Oct 9, 2014 at 12:24 PM, Andy Parker <an...@puppetlabs.com > <javascript:>> wrote: > >> ** Next PR Triage Wednesday, October 15th @ 10:00 am Pacific. ** >> >> *Priorities* >> >> 1. Puppet 3.7.2 >> 2. CFacter on the march >> 3. New puppet doc implementation >> 4. Code removal for puppet 4 >> >> *Commentary* >> Puppet 3.7.2 is in full swing. The big unknown for me was the memory leak >> (PUP-3345) that had been reported, but we hadn't reproduced. Well, it's >> been reproduced. It happens when directory environments are in use and >> environment_timeout != unlimited. Whenever it refreshes the environment >> cache it seems to leak memory. This is pretty critical for us since it will >> be in the next PE version, work on which is taking a lot of our time at the >> moment. >> >> CFacter is continuing. Solaris support is still in the works and so is >> the toolchain for building it on all the various platforms. I believe you >> can see the build scripts at https://github.com/puppetlabs/cfacter-build >> > > Clarification: that repo has build support only for Solaris and Windows. > For new-enough Linux and OS X the build instructions are trivially short > and are in the readme: > https://github.com/puppetlabs/cfacter/blob/master/README.md > > Are these builds publicly consumable? On windows, I get a chocolatey error retrieving http://pl-build-tools.delivery.puppetlabs.net/Windows_NT/x86_64-4.8.2-release-win32-seh-rt_v3-rev4.7z. Did I miss a step?
i.e. PS C:\Users\bdowns\Documents\cfacter-build> make build C:/ProgramData/chocolatey/lib/make.3.81.4/tools/bin/make -e toolchain make[1]: Entering directory `C:/Users/bdowns/Documents/cfacter-build' c:\windows\system32\windowspowershell\v1.0\powershell.exe .\bin\Windows_NT\wget.ps1 http://pl-build-tools.delivery.puppetlabs.net/Windows_NT/x86_64-4.8.2-release-win32-seh-rt_v3-rev4.7z Exception calling "DownloadFile" with "2" argument(s): "The remote server returned an error: (503) Server Unavailable." At C:\Users\bdowns\Documents\cfacter-build\bin\Windows_NT\wget.ps1:3 char:1 + (New-Object net.webclient).DownloadFile($args[0], $dest) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException + FullyQualifiedErrorId : WebException make[1]: *** [fetched/x86_64-4.8.2-release-win32-seh-rt_v3-rev4.7z] Error 1 make[1]: Leaving directory `C:/Users/bdowns/Documents/cfacter-build' make: *** [build] Error 2 > Kylo > > >> Puppet-dev conversations of note: >> * PUP-1073 - How to allow installing packages with the same name in >> different packaging systems in a single catalog? >> This thread had been going on for a long time and had died off in >> March without a conclusion. The issue was brought back to my attention this >> past week and so I started the conversation up again with another proposal. >> There are some very valid concerns about what impact loosening the >> constraints will have on catalogs and flapping resources; however, it >> appears that the decision is to go ahead with the latest proposal. I still >> need to reply to the thread to conclude it and update tickets, etc, etc. >> I'm going to target a fix a 4.0. >> * Behavior of apply + ENC >> Felix presented some options about how command line arguments should >> behave wrt to environments + enc + command line overrides. There was a lot >> of agreement about a "command line args win" solution, but RI feels that >> "ENC wins" is the better solution. I'm waiting with baited breath for the >> conclusion :) >> * Removing types/providers from core >> Ah yes. This old thread. But it's going somewhere this time! Daenny >> and Kylo submitted a PR for removing nagios from core at the contributor >> summit and now Daenny is following up with working out a plant for removing >> the rest. I'd really like to see this drive to a conclusion that we take >> action on this time. At the moment a lot of things hinge on getting >> packaging setup to allow pulling in modules so that they don't live in the >> core repo, but are available in a standard puppet installation. >> >> Puppet strings 0.1.0 has been released! Hailee put a lot of work into >> this to get it ready and Charlie did a lot of great work to show that it >> can be done. The next steps are for people to try it out and send us >> feedback/fixes. >> >> Whopper has been working through the code removals for puppet 4. Not much >> else to say about that... >> >> *Data* >> >> I was hoping to have some data from our profiling information request…but >> we still don't have any :( >> >> The data trap >> [image: Inline image 1] >> -- >> Andrew Parker >> a...@puppetlabs.com <javascript:> >> Freenode: zaphod42 >> Twitter: @aparker42 >> Software Developer >> >> *Join us at **PuppetConf 2014, **September 20-24 in San Francisco - * >> www.puppetconf.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-dev+...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/CANhgQXtSbWs9O%2Bimdn14vXddxyNTCdQTN%2B0mDZ%2BiJXgcePb2wQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/puppet-dev/CANhgQXtSbWs9O%2Bimdn14vXddxyNTCdQTN%2B0mDZ%2BiJXgcePb2wQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kylo Ginsberg | ky...@puppetlabs.com <javascript:> | irc: kylo | twitter: > @kylog > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/4f503290-264b-4981-aec0-07b2c2540b3b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
