text:
Dependabot-bundler error on Ruby 2.7.0: Could not find gem 'Ruby (~> 2.7.0.0)' in the local ruby installation.

We recently updated our Rails application to Ruby 2.7, but now dependabot-bundler is failing with the message Could not find gem 'Ruby (~> 2.7.0.0)' in the local ruby installation:
Fetching gem metadata from https://rubygems.org/.........
Fetching source index from https://rubygems.org/
/data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker/shared_bundler_helpers.rb:133:in `handle_bundler_errors': Bundler::GemNotFound with message: Could not find gem 'Ruby (~> 2.7.0.0)' in the local ruby installation. (Dependabot::DependencyFileNotResolvable)
The source contains 'Ruby' at: 2.6.5.114
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker/shared_bundler_helpers.rb:63:in `rescue in in_a_temporary_bundler_context'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker/shared_bundler_helpers.rb:38:in `in_a_temporary_bundler_context'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker/version_resolver.rb:78:in `block in fetch_latest_resolvable_version_details'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.116.3/lib/dependabot/shared_helpers.rb:141:in `with_git_configured'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker/version_resolver.rb:77:in `fetch_latest_resolvable_version_details'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker/version_resolver.rb:43:in `latest_resolvable_version_details'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker.rb:189:in `latest_resolvable_version_details'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-bundler-0.116.3/lib/dependabot/bundler/update_checker.rb:26:in `latest_resolvable_version'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.116.3/lib/dependabot/update_checkers/base.rb:70:in `preferred_resolvable_version'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.116.3/lib/dependabot/update_checkers/base.rb:233:in `preferred_version_resolvable_with_unlock?'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.116.3/lib/dependabot/update_checkers/base.rb:225:in `numeric_version_can_update?'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.116.3/lib/dependabot/update_checkers/base.rb:175:in `version_can_update?'
	from /data/gitlab-builds/NMS/dependabot-script/vendor/ruby/2.6.0/gems/dependabot-common-0.116.3/lib/dependabot/update_checkers/base.rb:38:in `can_update?'
	from ./gitlab-update-script.rb:108:in `block in <main>'
	from ./gitlab-update-script.rb:91:in `each'
	from ./gitlab-update-script.rb:91:in `<main>'

I'm assuming the Ruby version of the application it tries to update the dependencies for, should not affect the working on Dependabot because it runs in its own container using its own Ruby version. Am I missing something?
Thanks in advance for checking!

Sorry @martijnversluis for not replying to this ticket earlier. Are you still having this issue? I have not seen this error for a long time so I believe it's actually fixed!

authors: deivid-rodriguez martijnversluis

repo: dependabot/dependabot-core


text:
v0.140.0

v0.140.0, 7 April 2021

Bundler: Detecting and using the correct major Bundler version is now enabled by default
Python: Add versions 3.8.9, 3.9.3 and 3.9.4
Bump friendsofphp/php-cs-fixer in /composer/helpers/v1
Bump friendsofphp/php-cs-fixer in /composer/helpers/v2

Bumped minor version vs patch on the grounds Bundler behaviour is now different by default.

source: gharchive/pull-request

license: MIT

license_type: permissive

license_source: github-api


text:
Add more helpful error messaging when a vulnerable dependency cannot be upgraded

This PR adds a new method, #explain_fix_unavailable, which adds an explanation key to the fix_unavailable object when the UpdateChecker returns an update_not_possible error.
This explanation key is also used in the ConflictingDependencies check which is printed out after a failed job run and also shows up in the Dependabot security alert view.
The UpdateChecker should always raise with an :update_not_possible by this point since the call from #latest_version_resolvable_with_full_unlock? will not have any viable audit results and thus no fix available

🙃
I'm getting an error from the "behaves like an update checker" test:
https://github.com/dependabot/dependabot-core/runs/7982211556?check_suite_focus=true#step:5:267
I'm pretty sure the UpdateChecker#vulnerability_audit method this PR introduces will need to be public to be accessed from the Updater (we include Dependabot Core as a gem there, so we should only access the public interface)
For #conflicting_dependencies, we added as a method to the UpdateChecker base class even though it's only used in the bundler and npm_and_yarn ecosystems
https://github.com/dependabot/dependabot-core/blob/main/common/lib/dependabot/update_checkers/base.rb#L97-L105
I think the best course of action for the #vulnerability_audit method is to also add it to the UpdateChecker base class and note that it's used for npm transitive dependency updates.
Does anyone have other suggestions?

🙃 I'm getting an error from the "behaves like an update checker" test: https://github.com/dependabot/dependabot-core/runs/7982211556?check_suite_focus=true#step:5:267
I'm pretty sure the UpdateChecker#vulnerability_audit method this PR introduces will need to be public to be accessed from the Updater (we include Dependabot Core as a gem there, so we should only access the public interface)
For #conflicting_dependencies, we added as a method to the UpdateChecker base class even though it's only used in the bundler and npm_and_yarn ecosystems https://github.com/dependabot/dependabot-core/blob/main/common/lib/dependabot/update_checkers/base.rb#L97-L105
I think the best course of action for the #vulnerability_audit method is to also add it to the UpdateChecker base class and note that it's used for npm transitive dependency updates.
Does anyone have other suggestions?

Can you represent the error message in the #conflicting_dependencies result? #conflicting_dependencies is fairly generic and could be implemented by more ecosystems if we had the time to do so. #vulnerability_audit seems much more specific to our npm implementation so it doesn't seem as likely we'd expose that for any other ecosystem.

Reverting this in https://github.com/dependabot/dependabot-core/pull/5613 because of a TypeError. Will fix, add tests, and re-deploy.

authors: Nishnha mctofu


text:
Required PHP version missing in v7.0.0-rc7

I think that the required version of PHP should be kept in composer.json.

And requirement for ext-json.

This should be fixed in release.yaml workflow. Probably we can switch from bash to google/zx (also my project) there.

While doing this PR, I wondered if the config properties are really required.

source: gharchive/issue

authors: antonmedv benoitchantre

repo: deployphp/deployer


text:
Shell on your server is not POSIX-compliant. Please change to sh, bash or similar.

Q
A

Issue Type
Question

Deployer Version
Using .phar version, 3.3.0

Local Machine OS
Windows 7

Remote Machine OS
Debian 8

Description
I can't connect to my server with Deployer, but "normal SSH" connexion is working (through Git Bash, OpenSSH, Putty...).
Content of deploy.php
<?php
require 'recipe/symfony.php';
set('ssh_type','ext-ssh2');

server('preprod', 'XX.XX.XX.XXX')
    ->user('user')
    ->configFile('C:/Users/user/.ssh/config')
    ->stage('production')
    ->env('deploy_path', '/var/www/path/www');

set('repository', 'https://pwd@bitbucket.org/user/repo.git');

Output log
$ php deployer.phar deploy preprod -vvv
Ô×ñ Executing task ←[32mdeploy:prepare←[39m
Ôå│ on [preprod]
←[31m>←[39m echo $0

Warning: ssh2_connect(): Unable to connect to XX.XX.XX.XXX on port 22 in phar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/Session.php o
n line 153

Warning: ssh2_connect(): Unable to connect to XX.XX.XX.XXX in phar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/Session.php on line 153
←[37;41m                                                                                ←[39;49m
←[37;41m  Shell on your server is not POSIX-compliant. Please change to sh, bash or similar.  ←[39;49m
←[37;41m  Usually, you can change your shell to bash by running: chsh -s /bin/bash            ←[39;49m
←[37;41m                                                                                ←[39;49m
←[37;41m                              ←[39;49m
←[37;41m  [RuntimeException]          ←[39;49m
←[37;41m  The SSH connection failed.  ←[39;49m
←[37;41m                              ←[39;49m

←[33mException trace:←[39m
 () at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/Session.php:134←[39m
 Ssh\Session->createResource() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/AbstractResourceHolder.php:25←[39m
 Ssh\AbstractResourceHolder->getResource() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/Subsystem.php:39←[39m
 Ssh\Subsystem->getSessionResource() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/Exec.php:18←[39m
 Ssh\Exec->createResource() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/AbstractResourceHolder.php:25←[39m
 Ssh\AbstractResourceHolder->getResource() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/herzult/php-ssh/src/Ssh/Exec.php:24←[39m
 Ssh\Exec->run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/src/Server/Remote/SshExtension.php:116←[39m
 Deployer\Server\Remote\SshExtension->run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/src/functions.php:296←[39m
 run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/recipe/common.php:110←[39m
 {closure}() at ←[32mn/a:n/a←[39m
 call_user_func() at ←[32mphar://C:/wamp/www/repo/deployer.phar/src/Task/Task.php:79←[39m
 Deployer\Task\Task->run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/src/Executor/SeriesExecutor.php:43←[39m
 Deployer\Executor\SeriesExecutor->run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/src/Console/TaskCommand.php:82←[39m
 Deployer\Console\TaskCommand->execute() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/symfony/console/Command/Command.php:256←[39m
 Symfony\Component\Console\Command\Command->run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/symfony/console/Application.php:791←[39m
 Symfony\Component\Console\Application->doRunCommand() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/symfony/console/Application.php:186←[39m
 Symfony\Component\Console\Application->doRun() at ←[32mphar://C:/wamp/www/repo/deployer.phar/vendor/symfony/console/Application.php:117←[39m
 Symfony\Component\Console\Application->run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/src/Deployer.php:101←[39m
 Deployer\Deployer->run() at ←[32mphar://C:/wamp/www/repo/deployer.phar/bin/dep:63←[39m
 require() at ←[32mC:\wamp\www\repo\deployer.phar:4←[39m

←[32mdeploy [-p|--parallel]←[39m

@elfet This seems like an ssh2 extension bug

@oanhnn Has this bug been reported to ssh2 developers?

@bilougit https://bugs.php.net/bug.php?id=60436

Do I have another solution to connect to my server in the meantime?

Is there any solution for this problem? Or is that mean that ext-ssh2 doesn't work in deployer?

It's working. In Deployer v4 you can use native ssh implementation.

Is v4 released ? The doc/website still mention v3.3.

v4 in still in progress. Will be releases soon i hope.

Ok thanks! Can't wait, still using the old version of Capifony here...

If you want to support Deployer development you can become backer on https://www.patreon.com/deployer

Still doesn't work for me in 4.0.1 :/

@sebastianlp
What is method you used? ssh2, phpseclib or native ssh ?
Can you try with other method?

You can close it, now it's working with native ssh.

Cool.

I have the same issue.
and I find out echo $0 will output '-bash'.
yes, with leading "-".
using native ssh and deployer 4.2.1
but phpseclib is okay.

I'm having this issue too. Has is been resolved and if so, how?

closed but no comment on how to fix this @antonmedv

Open new issue

authors: antonmedv bartlomiejmarszal bilougit elfet johanpi kbsali oanhnn picks44 sebastianlp wppd


text:
Added command argument recognition, removed "/" from command events, updated example

Added argument recognition to command event (will add multiple arguments later), removed "/" from the event, and modified event args to send command/args only and the entire message object separately.

Thanks a lot. Kindly please put your name in contributor. :+1:

authors: fivepointseven shernshiou

repo: depoio/node-telegram-bot

license: mit

license_source: bigquery


text:
False positive for insecure dependencies

https://deps.rs/repo/github/IMI-eRnD-Be/twine
This project is a library and does not have a Cargo.lock. The crate regex is marked as insecure but in this case it should be considered secure since cargo will take the latest available version.

Oh wait it's "maybe insecure". Maybe it won't show up after I update heck...

The badge now says "maybe insecure"... I guess that's okay


text:
Add github actions

Noticed the other day that there is no CI/CD for this library. We should have at least two:

branch build - run generation, ensure no changes, quick test
tag build - publish to npm

Pushing a tag now pushes the nodejs client to npm and python to gemfury. I'll get another ticket open to migrate to pypi in a separate task.
There are a few more github actions that I'm thinking about, but this was definitely one of the more toilsome tasks.

repo: depscloud/api


text:
Multiple TypeFilter for input

Hi, Thanks for great plugin.
I just want to ask if multiple typeFilter is possible?
For me, TypeFilter.ESTABLISHMENT and TypeFilter.ADDRESS really useful at the same time.

Same question ?

authors: ejulfaey jeansebastienZ


text:
Sometimes go test inside delve/proctl will fail on TestNextGeneral and/or TestNextGoroutine

Most of the time all tests pass, sometimes TestNextGeneral or TestNextGoroutine (or both) fail:
--- FAIL: TestNextGeneral-4 (2.57s)
proctl_test.go:248: Program did not continue to correct next location expected 23 was testnextprog.go:40

(this always seems to happen after the message "thread context changed from X to X")
--- FAIL: TestNextGoroutine-4 (0.74s)
proctl_test.go:54: failed assertion at proctl_test.go:244: Next() returned an error : process 9596 has exited with status 0

--- FAIL: TestNextGoroutine-4 (0.23s)
proctl_test.go:54: failed assertion at proctl_test.go:234: Continue() : process 10201 has exited with status 0

I'm using the latest revision of delve, compiled with go version 1.4.2 under Ubuntu 14.04.2

@aarzilli Can you try and reproduce this again with the latest master build? Lots of work has been done around this area recently.

Perhaps I wasn't clear, my test failures were with the latest revision of master as of yesterday (i.e. 19a98fb49c9d1110da83008342c827ef0db5a083). But I can still reproduce the errors even with the current master (i.e. f9c64d30c205c3b869bf8bad4fe6ed92cf799115):
--- FAIL: TestNextGoroutine-4 (0.74s)
    proctl_test.go:54: failed assertion at proctl_test.go:244: Next() returned an error : could not get registers: no such process

--- FAIL: TestNextGoroutine-4 (0.25s)
    proctl_test.go:54: failed assertion at proctl_test.go:234: Continue() : process 29222 has exited with status 0

--- FAIL: TestNextGeneral-4 (2.42s)
    proctl_test.go:248: Program did not continue to correct next location expected 23 was testnextprog.go:40

--- FAIL: TestNextFunctionReturn-4 (0.25s)
    proctl_test.go:54: failed assertion at proctl_test.go:234: Continue() : process 29824 has exited with status 0

I have done some personal investingation of this bug.
It seems to be caused by an interaction between clone(2) and hardware breakpoints. Either setting GOMAXPROCS=1 or disabling the code that sets hardware breakpoints gets rid of those errors.
I should probably have mentioned that I had GOMAXPROCS set to 4 in my original error report but I had forgotten.
Further investigation reveals that resetting hardware breakpoints on DebuggedProcess.addThread with this loop:
for i, v := range dbp.HWBreakPoints {
	if v != nil {
		setHardwareBreakpoint(i, tid, 0)
		setHardwareBreakpoint(i, tid, v.Addr)
	}
}

gets rid of some errors. I have no idea why this actually works, btw.
The errors that remain are like this:
--- FAIL: TestNextGoroutine-4 (0.51s)
proctl_test.go:54: failed assertion at proctl_test.go:243: Next() returned an error : process 32501 has exited with status 0
(line numbers may not match, I have local changes). If u_debugreg happens to be thread local (which seems plausible) this would be completely expected, Next() sets a temp breakpoint for the current thread (did I read the code wrong?) but TestNextGoroutine expects the call to Next to break into a goroutine different than the current one and this could happen on the same os thread or not.

@aarzilli great catch, I definitely agree that's likely the issue. Can hopefully have a fix up today.

authors: aarzilli derekparker ironcladlou

repo: derekparker/delve


text:
DailyMotion Videos don't work

DailyMotion videos do not work anymore.
Example Url's:
https://dai.ly/x6xaldv
https://www.dailymotion.com/video/x6x4shm
How to reproduce:
https://sandbox.dereuromark.de/sandbox/media-embed
Entering them there gives an error in parsing URL.

Amy idea how to fix?

@dereuromark
Check out my PR. hope is cool. ;)

authors: dereuromark netstyler

repo: dereuromark/MediaEmbed


text:
fix: MT5 gold product urgent fix

PR is created from @raslan-deriv fork

LGTM!

repo: deriv-com/flutter-deriv-api


text:
core branch for pg data handler fix-upsert-blocks-for-pos

core branch for pg data handler fix-upsert-blocks-for-pos
core branch for pg data handler fix-upsert-blocks-for-pos
core branch for pg data handler fix-upsert-blocks-for-pos
core branch for pg data handler fix-upsert-blocks-for-pos
build

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1249  👈
#1194
feature/proof-of-stake

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @lazynina and the rest of your teammates on  Graphite

repo: deso-protocol/core


text:
Deprecate ignoreOverridden in name rules

The rules:

BooleanPropertyNaming
ConstructorParameterNaming
FunctionNaming
VariableNaming

Have the ignoreOverridden configuration flag but it have really little sense. There's nothing you can do about those names. So it should not be a configuration. It should be by default in all those rules.
So my proposal is to deprecate those configurations to simplify a bit our configuration that is long enough. We should also include the ones that will be included with #5590
There are also two other rules were I don't have it so clear:

FunctionParameterNaming: in this case you can rename them but that's a really bad idea. So deprecate it and always ignore deprecate seems like a sane decission.
~MemberNameEqualsClassName: I don't fully understand how this rule could help my code. But I imagine that keep it here have sense. Because in this one you can act on the issue. You can change the name of the class.~

Agree with top 4. Also with FunctionParameterNaming. I would keep for MemberNameEqualsClassName because in that case you have control over the class name at least if you choose to disable the flag.

MemberNameEqualsClassName I don't fully understand how this rule could help my code.

It helps with Java migration (in people's brains) to not accidentally create class Foo { fun Foo() } thinking it's a constructor, and additionally it helps when your action in the class is the same as the name, which is almost never the same word, so for class Generator { fun generator() } you get a flag to rename it, and hopefully do fun generate() instead. So essentially simple sanity checks similar to min-max naming.

Ok let's forget about MemberNameEqualsClassName. This PR is ready to grab. Remove the ignoreOverridden flag from those rules. The rule should behaves as that flag was always on.

authors: BraisGabin TWiStErRob

repo: detekt/detekt


text:
Find the parent for suspend check

Fixes https://github.com/detekt/detekt/issues/6176
Traverse in the parent for finding the suitable property or argument for suspension check

Failing TCs(as per the main code) which got fixed

cc @cortinico @BraisGabin PTAL


text:
hosting

localhost working okay both login and registration but live server doesnot work

Haven't got any response for a long time. Closing

authors: detronetdip foroduor

repo: detronetdip/E-commerce


text:
hato-botのCI反映

ベース: https://github.com/dev-hato/sudden-death/pull/38
hato-botのCIをそのまま取り込もうとすると、突然の死の枠部分 ( 人人 ) でtextlintがエラーになるので修正しています。
＿人人人人人人＿
＞　突然の死　＜
￣Y^Y^Y^Y^Y￣

具体的には https://github.com/textlint-ja/textlint-rule-ja-no-successive-word が突然の死の枠部分に適用されないようにしました。

この変更、hato-botの方に入れてからそれを持ってきたほうがいいかなと。
そうしないと、次回からこの差分を意識しながらもってこないといけなくなりそうなきがしました

sudden-deathでマージされたら手動でhato-botに反映しようかと思ってましたが、それもありかも

hato-botの方でPR出したので ( https://github.com/dev-hato/hato-bot/pull/418  )、こちらはclose

authors: Goryudyuma massongit

repo: dev-hato/sudden-death


text:
Listado de empleadores

Basado en este template
http://codeminifier.com/workio-job-board-template/workio/grid-employers.html

.

@HommyDeJ Puedes hacerle un watch a los issues sin gustas 😅

authors: DannyFeliz HommyDeJ eatskolnikov


text:
10.0.0-alpha.2 - React Developer Tools not active

I use Preact in two of my private projects together with Parcel.js as module bundler. In the last stable version I just had to import 'preact/devtools' in my index.js where the first render function from Preact will be called and then I could use to React Developer Tools too see my current context. Since Preact X this import is no longer available and I had to remove it. I just read in the release notes that the developer tools git a complete rewrite and the support for the Developer Tools was improved. But in both of my projects, the  Developer tools are not active and when I click on the Developer Tools icon, I get only "This page doesn’t appear to be using React."
So my question is what do I have todo to make the Developer tools usable in my project? Maybe it should work out of the box with Preact X but then I would like to know how I could find out, why it's not active in my projects.
The package.json where all the additional config for is made can be found here: https://github.com/janbaer/mdwiki/tree/feature/migration_to_preactx. But thanks to parcel.js there's not so much to configure additionally.

Hi @janbaer
Just import preact/debug where you previously included preact/devtools and the react devtools will start working again.

Thanks @Kanaye, works great. It should be mentioned in the release notes.

I'll reopen this until we've added it to the notes 👍

Back home again and I added a section about that to our release notes :+1: Thanks again for spotting this :)

authors: Kanaye janbaer marvinhagemeister

repo: developit/preact


text:
Add prepublishOnly script

Related to: #820
This PR adds a prepublishOnly script which removes unnecessary keys from the package.json.
Feedback is welcome :)

Coverage remained the same at 100.0% when pulling 0d5a99e4c31a7feef6d9ebf145425d6f4fc75997 on rubenmoya:820-add-prepublish-script into 0dea3b77ee0677987815347c1e6bd23821728aa2 on developit:master.

Coverage remained the same at 100.0% when pulling 7e40d2312b974935201785fadb8ce2adf78d05c4 on rubenmoya:820-add-prepublish-script into 0dea3b77ee0677987815347c1e6bd23821728aa2 on developit:master.

Changes Unknown when pulling 538123293f30e2eff37498cdd2c2aeab40bf884e on rubenmoya:820-add-prepublish-script into ** on developit:master**.

authors: coveralls rubenmoya


text:
minimal/vector only geolambda

For users who only need vector operations.
Thoughts on adding a minimal version with only:

GDAL
GEOS
PROJ

Actually, it appears to work just fine if I remove the so files I don't care about.

Nevermind, this is still needed.

Just re-read the readme. Guess this is not something of interest for a general version push to docker-hub.

repo: developmentseed/geolambda


text:
switch to pytest-postgresql

closes #176

For some reason the tests works on CI but I can't make them pass locally 😬
I'm getting some weird datetime/timezone issues.

we need to set the DB to UTC: https://github.com/stac-utils/titiler-pgstac/pull/188/files#diff-e52e4ddd58b7ef887ab03c04116e676f6280b824ab7469d5d3080e5cba4f2128R64-R67

repo: developmentseed/tipg


text:
Simplify band loading

What I am changing

Simplify and improve default band selection in RGB viewer for both COG and STAC images

How I did it

Removed the special band selection logic that applied to the blue band but not the others.
Simplified the loading logic so the first three image bands are loaded into the R+G+B channels, respectively, in the viewer.
Tested by running the app and manually checking things worked as expected

How you can test it

Run the server, load a COG or STAC item

Related Issues

#685

🙏 thanks @tayden

authors: tayden vincentsarago

repo: developmentseed/titiler


text:
Endless reconcile loop when using inline configmap in a devworkspace

Description
If a devworkspace includes an inlined configmap component that is mounted via pod & container overrides, the devworkspace-controller-manager will enter an endless reconcile loop. From my current investigation, it seems that the basicDiffFunc() is returning false when comparing the workspace's deployment on the cluster compared to the expected deployment spec.  It seems we might have a subtle bug in the deploymentDiffOpts we're using that's failing for this case.
How To Reproduce

Apply the following devworkspace:

kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha2
metadata:
  name: plain-devworkspace-inline-cm
spec:
  started: true
  routingClass: 'basic'
  template:
    components:
      - name: cm-config-volume
        openshift:
          deployByDefault: true
          inlined: |
            apiVersion: v1
            kind: ConfigMap
            metadata:
              name: my-configmap
            data:
              demo-txt: |
                key1=value1
                key2=value2
      - name: web-terminal
        attributes:
          pod-overrides:
            spec:
              volumes:
              - name: demo-config-map
                configMap:
                  name: my-configmap
                  items:
                  - key: demo-txt
                    path: demo.txt
          container-overrides:
            volumeMounts:
            - mountPath: /projects/config-map
              name: demo-config-map
        container:
          image: quay.io/wto/web-terminal-tooling:next
          memoryRequest: 256Mi
          memoryLimit: 512Mi
          mountSources: true
          command:
           - "tail"
           - "-f"
           - "/dev/null"

Notice that the workspace never progresses past the Starting: Waiting for workspace deployment phase, and the controller enters an endless reconcile loop until the workspace times out.

Expected behavior
The workspace should progress to the READY phase and the controller should not enter an endless reconcile loop.
Additional context
Upstream Che issue

It turned out that the configmap volume defined in the pod overrides of the devworkspace was missing the defaultMode field, which was then getting set to a default value on the cluster. When DWO was comparing the workspace deployments expected spec to the cluster spec, it saw the difference in the defaultMode field, leading to an endless reconcile loop.
Closing as this was caused by a misconfigured devworkspace object. See https://github.com/eclipse-che/che/issues/23011#issuecomment-2197418862

repo: devfile/devworkspace-operator


text:
Default path for each category

Hello, I discovered this repo today so forgive me if this is already possible in any other way !
It would be nice being able to have custom folders paths for clips/videos/highlights instead of the current setup where i have to select every time the path
It would look like something like that for example:

Seconded, it would be nice and it would save so much time if we could set up folder paths in settings instead of having to pick the folder each time.

authors: adan-ea ccrowles

repo: devhotteok/TwitchLink