dropping tellonym.py: error: the following arguments are required: user error

hello
Im not that advanced at python. for my entire life, i was coding html and css.
Im getting this issue after running the script with python tellonym.py
usage: tellonym.py [-h] [-i INPUT_FILE] [-t TIMES] [-r RETRIES] [-T TIMEOUT] [-R RATE] user
tellonym.py: error: the following arguments are required: user

I will be really happy if u can help me!
Thanks for your time
Fajtik

import requests
import sys
user = input('user_tellonym -> ')
url = "https://api.tellonym.me/profiles/name/"+user
print("""

0wW    Ww0800
(O)\  /(O)  wWw   wWw   wWw
. \/ .'   (O)_  (O)_  (O)_      \  /    .' __).' __).' __)     /  \   (  _) (  _) (  _)     .' /\ .  )/    )/    )/
(.'  `.)(     (     (
""")

payload = ""
headers = {
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9",
"X-Parse-Installation-Id": "25cfde8f-7204-434e-a7fb-dde295ee4f70",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36",
"Connection": "close",
"X-Parse-Application-Id": "RTE8CXsUiVWfG1XlXOyJAxfonvt",
"Host": "api.tellonym.me",
"Accept-Encoding": "gzip, deflate",
"Upgrade-Insecure-Requests": "1",
"Accept-Language": "en-US,en;q=0.9",
"X-Parse-Client-Version": "i1.17.3",
"X-Parse-Session-Token": "r:4b71c2de73f5b1b1671c93107fa379f7",
"X-Parse-OS-Version": "12.9 (saud)"
}
response = requests.request("GET", url, data=payload, headers=headers)
print(response.text)

I don't know how I can explain it further than the cli parser already tells you. "user" should be the user you want to spam so something like python tellonym.py -i input_file.txt john_doe in case the user has that username

في خميس، 23 مارس، 2023 في 10:54 ص، كتب target_ @.***>:

Closed #10 https://github.com/target111/py-onym/issues/10 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/target111/py-onym/issues/10#event-8824319016, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AVFJPE5THRYCIPRTY4RQRRLW5P6U7ANCNFSM5FAL7CIA
.
You are receiving this because you commented.Message ID:
@.***>

Can you give me your twitter or instagram? I want to ask you something
about this.
null

My instagram is sqalzSent from my iPhoneOn 23 Mar 2023, at 12:13 PM, introvert2 @.> wrote:
في خميس، 23 مارس، 2023 في 10:54 ص، كتب target_ @.>:

Closed #10 https://github.com/target111/py-onym/issues/10 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/target111/py-onym/issues/10#event-8824319016, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AVFJPE5THRYCIPRTY4RQRRLW5P6U7ANCNFSM5FAL7CIA
.
You are receiving this because you commented.Message ID:
@.***>

Can you give me your twitter or instagram? I want to ask you something
about this.
null
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>


[BUG] Regression in hinges

Describe the bug
Sample hinges no longer look right
Code To Reproduce Bug
include <BOSL2/std.scad>
include <BOSL2/hinges.scad>
$fn=32;
cuboid([20,40,2])
  position(TOP+RIGHT) orient(anchor=RIGHT)
    knuckle_hinge(length=35, segs=9, offset=3, arm_height=0,
          arm_angle=90, pin_fn=8, clear_top=true);

Expected behavior
Look like the example in hinges documentation
Screenshots

Additional context
Git bisect shows commit 5719439b052c355a084184b0020acb8c9acd6c01 introduced the problem

This bug is caused by a problem with anchors in offset_sweep.  The default anchor needs to be "origin" for that function/module.  Apparently it was somehow working for the hinge before when anchoring was more broadly broken.   The PR fixes this.

This should be fixed.


Add new workflows

fix #20

LGTM then, as with devops of this nature, if there are bugs after merge we'll just sort them out


[Bug] Duplicate in FF

We are using this library to display a terminal. It works properly on Chrome but noticed that anything on the page gets duplicated in Firefox:
Terminal on Chrome

Terminal on FF

I believe the culprit lies in hterm.ScrollPort.prototype.decorate:
hterm.ScrollPort.prototype.decorate = function(div) {
  // ...

  if ('mozInnerScreenX' in window)  // detect a FF only property
    this.iframe_.src = '#';

 // ...

Having the iframe src be # will duplicate whatever is on the page, including all the headers defined on the page consuming this library.

i am over the same issue. The problem is about the iframe.src property in FF.
is it is '' => FF says current location and if it is '#' => firefox say currentlocation#
In the case of hterm the src is loaded after the contentDocument so hterm creates the terminal and FF delete it and write the current location.
I have tried putting all about contentDocument in the iframe's load event, but It hasn't work until now.
please, if someone find a good fix it will be great

Is there any workaround available?


500: Internal Server Error - breaks the whole thing

After receiving a server error 500 the whole bot stops to function correctly, it's no longer receiving any messages, but it can still send them... This happened last night on several bots with completely different code, and even different version of Discord.NET (one with the latest commit on dev, the other with a bit outdated nuget...) So I guess that it's safe to assume that it's Discord server issue, however, the library should probably correctly handle it - adding another hack (if 500 then exit) doesn't seem like the right solution, even as far as hacks go...
This stack started with client.GetGuild(guid)
May 25 03:20:10 Keyra dotnet[29615]: Exception: The server responded with error 500: 500: Internal Server Error
May 25 03:20:10 Keyra dotnet[29615]: Stack:    at Discord.Net.Queue.RequestBucket.<SendAsync>d__18.MoveNext()
May 25 03:20:10 Keyra dotnet[29615]: --- End of stack trace from previous location where exception was thrown ---
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
May 25 03:20:10 Keyra dotnet[29615]:    at Discord.Net.Queue.RequestQueue.<SendAsync>d__14.MoveNext()
May 25 03:20:10 Keyra dotnet[29615]: --- End of stack trace from previous location where exception was thrown ---
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
May 25 03:20:10 Keyra dotnet[29615]:    at Discord.API.DiscordRestApiClient.<SendInternalAsync>d__62.MoveNext()
May 25 03:20:10 Keyra dotnet[29615]: --- End of stack trace from previous location where exception was thrown ---
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
May 25 03:20:10 Keyra dotnet[29615]:    at Discord.API.DiscordRestApiClient.<SendAsync>d__57`1.MoveNext()
May 25 03:20:10 Keyra dotnet[29615]: --- End of stack trace from previous location where exception was thrown ---
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
May 25 03:20:10 Keyra dotnet[29615]:    at Discord.API.DiscordRestApiClient.<GetChannelMessageAsync>d__75.MoveNext()
May 25 03:20:10 Keyra dotnet[29615]: --- End of stack trace from previous location where exception was thrown ---
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
May 25 03:20:10 Keyra dotnet[29615]:    at Discord.Rest.ChannelHelper.<GetMessageAsync>d__6.MoveNext()
May 25 03:20:10 Keyra dotnet[29615]: --- End of stack trace from previous location where exception was thrown ---
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
May 25 03:20:10 Keyra dotnet[29615]:    at Discord.WebSocket.SocketTextChannel.<GetMessageAsync>d__19.MoveNext()
May 25 03:20:10 Keyra dotnet[29615]: --- End of stack trace from previous location where exception was thrown ---
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
May 25 03:20:10 Keyra dotnet[29615]:    at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
May 25 03:20:10 Keyra dotnet[29615]:    at Botwinder.Service.SkywinderClient.<MainUpdate>d__8.MoveNext() in /home/project/Botwinder.service/Bot.cs:line 64

Here's a suggestion: make your stack traces more sensible by not merging everything into one condition. From the stack trace, it's obvious it wasn't GetGuild (at Discord.WebSocket.SocketTextChannel.<GetMessageAsync>d__19.MoveNext()) and it is impossible for it to be GetGuild anyway, for the reasons foxbot mentioned earlier.
As for the error 500: there is no way one could realistically expect us to handle this in any other way, as the way it is handled right now (throwing an exception when it's anything exceptional) is the sane way to do it. A 500 error is an exceptional case which does not happen in normal usage; hence an exception is OK.

Here's a suggestion: make your stack traces more sensible by not merging everything into one condition.

Like... if something then if something then if something then if something then do something? No thanks :D

And yes, if the issue first started appearing during a Discord outage, then the connection deadlock would be due to the outage, not the HTTP error.

Doesn't change the fact that it should correctly reconnect, or at least kill itself (in a form of "failed to reconnect" exception?) Anything is better than what it does now - nothing. Not even a disconnected event/exception. (Which makes it different than the 960 where it's still supposed to throw the dc.)

Like... if something then if something then if something then if something then do something? No thanks :D

I was suggesting something like this instead:
var mainGuild = this.Client.GetGuild(this.Config.MainGuildId);
var statusChannel = mainGuild?.GetTextChannel(this.Config.StatusChannelId);

if (mainGuild != null && statusChannel != null)
{
    var statusMessage = await.GetMessageAsync(this.Config.StatusMessageId);
    if (statusMessage != null)
    {
        // code here
    }
}

Don't put assignments in if statements. It'll only serve to confuse you later on.

I quite like the code the way it is, see, I'm that old that I'm still not used to ?., ?? and stuff... I also really dislike var (another new misfeature of the language imho) - you may know what does GetMessage return but I don't. Is it an IMessage, is it a RestMessage or what is it?

GetMessageAsync can return multiple types. As per the implementation in SocketTextChannel:
public async Task<IMessage> GetMessageAsync(ulong id, RequestOptions options = null)
{
    IMessage msg = _messages?.Get(id);
    if (msg == null)
        msg = await ChannelHelper.GetMessageAsync(this, Discord, id, options).ConfigureAwait(false);
    return msg;
}

First, we return a message from the cache, a SocketMessage, if it exists, otherwise we make a request to Discord to get the message which returns a RestMessage.


Medium severity vulnerability affecting this repo

Hi there,
We noticed that your repo has a medium severity vulnerability:

Cross-site Scripting (XSS)
Affected package: jquery <3.0.0-beta1 >2.2.0 || <2.2.0 >1.12.3 || <1.12.0 >=1.4.0

Here is the test report for this repo.
If you’d like to fix this vulnerability, Snyk lets you generate a pull request that recommends the best upgrade path - there’s a link to fix this vulnerability on the test report.
Stay secure :-)
Snyk Community

There are no cross domain ajax requests with no dataType specified in the repo


Deal with clean filters somehow

Is your feature request related to a problem? Please describe.
If you edit a file that is covered by a filter.*.clean rule, the diff detection does not work very well. I do realize this is not really possible to handle well since filters can do literally anything, but it does make a suboptimal editing experience.
Describe the solution you'd like
A non-exhaustive list of possible implementations, roughly in order of complexity:

Doing nothing, leave it as it currently is.
Show an indicator, hide the signs, etc for files affected by a clean rule. Not great, but might be better than showing a completely incorrect diff.
Add a command for opening a split buffer showing the result of the filter (preferably live, but some filters might only work on disk-saved files, I don't know the specifics), and diffing that result with the index. This would probably be as close to an optimal editing experience as one can reasonably get. Would probably be lots of effort for a niche feature, so perhaps this would be better off as a separate plugin.
Possibly augment the above with smudging the file back if applicable, but I would guess smudging is even rarer than cleaning.

Describe alternatives you've considered
Discussed above.
Additional context
Nothing in particular.

TIL about git smudging and cleaning.
If smudge/clean commands all work via stdin/stdout, we could simply apply the filters before diffing?
Would add quite a lot of complexity and probably slow things down, but not against doing this at some point.

Yeah, they use stdin/out (not sure if they even get to know the filename they're working on). The problem (at least how I understand it) is how to display the diff in the editor; even with a simple filter such as tac, the diff lines don't really map onto editor lines.

Don't we just need to adapt the output of git show <path> and pass it through the filter which can then be compared to the working copy (the buffer contents)?

I'm not really familiar with git show; it seems to show diffs for the latest commit?
From what I've noticed, git diff diffs between the raw index file and the cleaned working copy, rather than between the smudged index file and the raw working copy. Though I agree that for realtime editing, including the raw working copy, and therefore the smudged index file, would make more sense. (Please excuse me if I'm getting the terminology wrong.)

git show :0:<path> will output the version of the file in the index (e.g. git show :0:Makefile.

From what I've noticed, git diff diffs between the raw index file and the cleaned working copy

We can do this.

Though I agree that for realtime editing, including the raw working copy, and therefore the smudged index file, would make more sense. (Please excuse me if I'm getting the terminology wrong.)

I don't really know which one makes more sense, I've never used these filters.
Both versions of the diff input are available as string variables in the plugin so we can filter either one in whatever way we want. The question is will the outputs be usable? If a filter is just changing single words in a file, then it would work. If they are removing/adding lines of text, then the signs will be wrong. Maybe if the line count changes we go with your option 2?

If you (or anyone) wants to prototype anything, the diff happens here: https://github.com/lewis6991/gitsigns.nvim/blob/06aefb1867687ee2b1d206fd5d19a2b254c62f2c/teal/gitsigns/manager.tl#L321, you just need to augment bcache.compare_text, or buftext.

I'm not really familiar with git show; it seems to show diffs for the latest commit?
From what I've noticed, git diff diffs between the raw index file and the cleaned working copy, rather than between the smudged index file and the raw working copy. Though I agree that for realtime editing, including the raw working copy, and therefore the smudged index file, would make more sense. (Please excuse me if I'm getting the terminology wrong.)

Hi, I was just experimenting with the filter functionality in Git and came across this issue with gitsigns.nvim. I wanted to add that using the smudged index file would not work in all cases, as smudge and clean are not necessarily complementary to each other. A good example would be to have a formatter in clean and nothing for smudge. The Git documentation actually shows this in an example. Under the image they use indent for cleaning, while smudge is just cat, which does nothing.

The problem still persists when using git-crypt.
Is there any news related to this issue outside of this issue. (pardon the redundancy)

Nope


Setting up llamacpp

Hi @gsuuon thanks for sharing this plugin for neovim! I'm new to the ecosystem, so apologies in advance if this questions is obvious. I'm trying to get your plugin running with a local llamacpp server. The llamacpp server is running fine and I can send requests to it. However, when I try to set it up with llm.nvim with the following configuration:
require('lazy').setup({
  'gsuuon/llm.nvim'
})

require('llm').setup({
  default_prompt = require('llm.providers.llamacpp').default_prompt
})

I get the following error when I start nvim:
Error detected while processing /Users/rhsimplex/.config/nvim/init.lua:
E5113: Error while calling lua chunk: vim/shared.lua:0: stack overflow
stack traceback:
        vim/shared.lua: in function ''
        vim/shared.lua: in function 'validate'
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        ...
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function ''
        vim/shared.lua: in function 'tbl_deep_extend'
        ...nderson/.local/share/nvim/lazy/llm.nvim/lua/llm/init.lua:198: in function 'setup'
        /Users/rhsimplex/.config/nvim/init.lua:18: in main chunk

Many thanks if you have any ideas!

Hi @gsuuon thanks for taking some time to help me out. UnfortunateIy couldn't get it working =(  I realize this has something to do with lazy.nvim, and not llm.nvim, so just posting this here in case someone else hits the same issue. I'll keep looking into it. I certainly don't expect you to dedicate any more time to this!
The first approach appears to generate a circular dependency (I assume?):
 Sorry I'm not familiar with Lua, so I'm taking a shot in the dark:
Error detected while processing /Users/rhsimplex/.config/nvim/init.lua:
E5113: Error while calling lua chunk: /Users/rhsimplex/.config/nvim/init.lua:19: module 'llm.providers.llamacpp' not found:
        no field package.preload['llm.providers.llamacpp']
        no file './llm/providers/llamacpp.lua'
        no file '/opt/homebrew/share/luajit-2.1/llm/providers/llamacpp.lua'
        no file '/usr/local/share/lua/5.1/llm/providers/llamacpp.lua'
        no file '/usr/local/share/lua/5.1/llm/providers/llamacpp/init.lua'
        no file '/opt/homebrew/share/lua/5.1/llm/providers/llamacpp.lua'
        no file '/opt/homebrew/share/lua/5.1/llm/providers/llamacpp/init.lua'
        no file './llm/providers/llamacpp.so'
        no file '/usr/local/lib/lua/5.1/llm/providers/llamacpp.so'
        no file '/opt/homebrew/lib/lua/5.1/llm/providers/llamacpp.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
        no file './llm.so'
        no file '/usr/local/lib/lua/5.1/llm.so'
        no file '/opt/homebrew/lib/lua/5.1/llm.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
        [C]: in function 'require'
        /Users/rhsimplex/.config/nvim/init.lua:19: in main chunk

I'd expect the first approach at least to work - I'll take a look, might be a bug.

@rhsimplex I've pushed a fix, please give it another try. It also looks like the correct way to use opts while requiring from the plugin is to provide a function:
require('lazy').setup({
  {
    'gsuuon/llm.nvim',
    opts = function()
      return {
        default_prompt = require('llm.providers.llamacpp').default_prompt
      }
    end
  }
})

Yes thank you! Works great!


Custom nginx-ddev-site.conf no longer required

The custom nginx-ddev configuration is no longer required.  DDEV and Grav play much nicer together with current defaults.

There will be a pull request shortly for updated learn.getgrav.org documentation on ddev and grav setup


fix(seed): Fixed issue with atLeast test always failing

Closes #16668

Pre-Submission Checklist

[x] Your pull request targets the staging branch of freeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[x] Addressed currently open issue (replace XXXXX with an issue no in next line)

Description

Fixed seed to check correct elements in the assertion array instead of just the first element.

Great catch and thanks for the fix @iabrenne :+1:
Sorry for the delay


Using another HTML element as popover content

I intended to add this comment to https://github.com/twbs/bootstrap/issues/3722 but it's locked, so I'm creating this issue here in hopes that it helps other people.
We wanted to be able to specify a sibling element as the content of the popover. This is the approach we used:
// We provide support for naming a sibling selector that can contain
// the information that we want to show in the popover. If the popover
// has html: true then we use the HTML content, otherwise we use text.
//
// .parent
//   div data-behavior="popover" data-content-src=".popover-content-source"
//   .hidden.popover-content-source
//     | Popover content here
function allowSiblingAsContentSource() {
  var $this, contentSrcSelector, contentSrc, content;

  $this = $(this);
  contentSrcSelector = $this.data('content-src');

  if (contentSrcSelector) {
    contentSrc = $this.siblings(contentSrcSelector);

    if ($this.data('html')) {
      content = contentSrc.html();
    } else {
      content = contentSrc.text();
    }

    // We cache the content on the element so popover events use it directly
    $this.attr('data-content', content);

    return content;
  }
}

$('[data-toggle~="popover"]').popover({
  // This behaves as a fallback if data-content isn't provided on the element.
  content: allowSiblingAsContentSource
});

It's not an issue, so closed.


Consider attempting CDLL with SONAMEs first

Hi! I noticed gpuctypes uses ctypes.util.find_library to dlopen libraries like libcuda.so by direct paths, instead of relying on the dynamic loader to choose the library by name:
https://github.com/tinygrad/gpuctypes/blob/77b94adaf8e27fa5ef7caa0bdd949bd528576d4b/gpuctypes/cuda.py#L146-L148
Just loading libraries by name (CDLL("libcuda.so")) might often be already sufficient, because the dynamic loader is fairly configurable and the users may adjust its behaviour as is fit for their specific environment: it respects the LD_LIBRARY_PATH environment variable, it checks for the optional /etc/ld.so.conf, and certain entries in the executable's headers.
Additionally, note that the find_library routine doesn't have any clear semantics and it might return the current host's libraries, or it might randomly return a target platform's libraries accidentally found using e.g. gcc. Perhaps you could make find_library an optional "fallback mode"?
Also note that both CDLL("libcuda.so") and find_library("libcuda.so") require extra steps from the user to work, albeit hidden: on the commonly used distributions those would likely succeed and locate libcuda.so through /etc/ld.so.{cache,conf}, but these may not exist or not contain the records about all of the software available on the system. E.g. in Nixpkgs we're going to patch the referenced file(s) with our own paths. Generally, the solution is to explicitly declare the dependency in advance. Cf. e.g. https://discuss.python.org/t/pep-725-specifying-external-dependencies-in-pyproject-toml/31888 for more context
Thanks

This should probably be done for the HIP as well since it's not guaranteed that HIP is installed in /opt/rocm, see #17.


Run error

"Image = TF.rotate(image,angle)" in "dataset.py" reports an error at runtime "TypeError: function takes exactly 1 argument (3 given)" How to solve it, thank you very much!

Looks like one of your arguments to TF.rotate() is a tuple? Can you print the dimensions of image data?
You could also disable rotation augmentation by setting rot=0 when you load the dataset in train.py.


Add hack/create-bundle

To create + push bundle image + index image for local testing.
The README is misleading, as there are no images on quay.io/openshift yet... Use common sense.

Tested it and it appears to work.

/lgtm


How to migrate data between Gitea servers?

Feature Description
My old server is Centosos, and my new server is Docker Gitea,
I have tried many methods, but it took me a few days without success. Either the Docker container cannot start after the migration is completed, or it cannot be accessed after successful startup without any errors
I also checked a lot of fragmented information, such as https://github.com/go-gitea/gitea/issues/7858, and it seems that no one is useful either
Can  provide a command to migrate?? such as gitea -- migrate newsever.com newadmintoken
Screenshots
No response

Have you tried using the gitea backup and restore command ?
https://docs.gitea.com/administration/backup-and-restore#using-docker-dump
In docker, you just have to copy the data from the docker volume to your new system and put it in the same docker volume
It works flawlessly everyday for me, I recreate the running full server on a spare one.

Have you tried using the gitea backup and restore command ? https://docs.gitea.com/administration/backup-and-restore#using-docker-dump
In docker, you just have to copy the data from the docker volume to your new system and put it in the same docker volume
It works flawlessly everyday for me, I recreate the running full server on a spare one.

Yes, I have tried before, but the first few attempts have all failed (without any error messages or normal access). Yesterday, I manually processed the files and permissions and finally managed to use them

I hope Gitea can backup and restore with just one click. Whether it's native app or docker


Please add online subtitles

Please add online subtitles finding feature in the app🥺🥺

SubHub, sublite, Get Subtitles

Has this already been tested to work (using SubHub, sublite, Get Subtitles )? in case the file is a link (streaming) like streamio, would these extra applications like SubHub, sublite, Get Subtitles work?
Or do they only work if the file is located locally on our device?

in case the file is a link (streaming) like streamio, would these extra applications like SubHub, sublite, Get Subtitles work?

If the video is coming from other apps, they can already provide extra subtitle using the commonly used (MX Player) API. This already works (#262) when the sender app supports that.


Some initial commits to get this going

Dude, awesome, however... this is meant to be more like awesome lists on github for code. Our company name is Hofstadter as an homage.
Could you move the README to DOUGIE.md?

oh, and can you make an assets folder for the images?


SluggableBahavior targetAttributes does not appear to check those attributes

I have a post table with an ID, Title, Slug, Year, and Month (among many other fields).  I'm trying to configure the SluggableBehavior so that when it generates a new slug, it takes not only the slug into consideration, but also the year and month (a post slug only needs to be unique within a give year and month).
For example, the following is what I would expect

id
title
slug
year
month

1
New Post
new-post
2016
1

2
New Post
new-post
2016
2

3
New Post
new-post-2
2016
2

Since id 3 has the same title but was post in the same year and month as 2, the slug needs to be different.
I have the following rule that appears to be working as expected in that if I try to save a record with the same slug, year, and month, validation fails.
[['slug'], 'unique', 'targetAttribute' => ['year', 'month'', 'slug']],

The SluggableBehavior is configured as follows.
'SluggableBehavior' => [
    'class' => SluggableBehavior::className(),
    'attribute' => ['title'],
    'immutable' => true,
    'ensureUnique' => true,
    'uniqueValidator' => ['targetAttribute' => ['year', 'month', 'slug']],
],

With that configuration, the same slug of 'new-post' gets created and the validate fails because the rule catches it.  If I were to remove the uniqueValidator parameter entirely and just let the behavior perform normally, it will generate 'new-post-2' for id 3, exactly as it should because 'new-post' is already taken.
Shouldn't specifying the year, month, and slug as the targetAttribute ensure that the combination of those three fields is unique when generating the slug?

Closing since this is NOT an issue.
The year and month are being set in the beforeValidate based on either the current time or the publish date selected by the user.  However, I was calling the parent implementation of beforeValidate before the year and month were being set.  So, year and month field were null as the sluggable bahavior was generating a slug.  Moving the call to the parent beforeValidate appears to have resolved the issue as now the year and month are properly being considered when generating the slug.


Update - info_page Component

tasks - 2024.01.28

Update info_page_v0.1.0

on mobile - close all windows by default - 6min
on mobile - fixed various bugs - 1h34min
created and logged tasks - 14min
@output :package: info_page_v0.1.1

worklog
worklog-196

feedback

proposals


Enabling SUSE buildpacks on Cloud Controller

Description
This PR intends to enable SUSE buildpacks(buildpacks built with SLE stemcell) on the Cloud Controller.
Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code has security implications.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

This task is now unblocked by:
https://github.com/SUSE/kubecf/issues/156
https://github.com/SUSE/scf/pull/3092

@bikramnehra can this PR move to review?

Closing in favor of https://github.com/SUSE/kubecf/pull/314


[WIP] Improve test setup

To simplify the test setup and decrease the amount of environment variables, the test configuration is now handled through its own config file: test.js.
Still to do:

[ ] Dockerize tests so they run on Travis

Rebased the branch and opened a new PR on #107


Tree KDE with integration and demo pipeline

Complete tree kde implementation, with bootstrapped quantile estimation and grid caching as well. Also added a new pipeline to run contrib operators, and some new logic to process scoped YAML configurations. Main files to look at:

ExtendedBatchPipeline, BatchTransformFactory: supports running batch pipelines with new contrib operators
TKDEEstimator: main TKDE logic
TKDEConf: conf object for all tkde parameters, supports loading from yaml string
MacrobaseConf: some modification to allow for loading scoped subconfigs
tools/demos/kde/kde.yaml : example pipeline using new kde operator, works on demo dataset

./bin/batch.sh tools/demos/kde/kde.yaml should give good results after the demo data is loaded

Coverage decreased (-0.02%) to 94.099% when pulling 7be09ec7c8596efca61c51b282aafdd1d3c7005c on kdeclassify into 18bace3d41f9401ce615fcc0f87c249f8481a506 on tkde_foundations.

Coverage decreased (-0.02%) to 94.099% when pulling fdf7816ca2e846162dbd484d0c92871b83cdb406 on kdeclassify into 18bace3d41f9401ce615fcc0f87c249f8481a506 on tkde_foundations.

@edgan8: is this ready for review?

Coverage decreased (-0.02%) to 94.21% when pulling 8eb8dda5c3d46ab4c30ffd1f98e76a7c1bf0aeca on kdeclassify into 36a1e93dbd18e20b5772e2dca69deb36437ba240 on tkde_foundations.

@edgan8 how's this looking?

Closing due to inactivity; see also https://github.com/stanford-futuredata/tKDC


GDPR Commpliant Simple Web Application template

This template deploys the infrastructure components to deploy and host a simple Web Application.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: lzieba91 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Permissions

please add perms!

Please tell me more specifically…

Yea i also noticed it, texter.command.txt should be set to op not true

If you only want to use op, you can configure it in Config

This issue closed because there is no reply from the proposer. Please reply if there is anything else


'jobject' must not be IntPtr.Zero

After updating to 2.1.0 I am getting the following error every time I go back a page.
'jobject' must not be IntPtr.Zero.
Parameter name: jobject

Anyone else having this issue or know what may cause it?

This would be be to do with Fresh more a Xamarin.Forms issue I would think.
We use it on 2.1 in many projects.
Let me know if it is fresh.
On Saturday, 21 May 2016, JoshuaNovak919<EMAIL_ADDRESS>wrote:

After updating to 2.1.0 I am getting the following error every time I go
back a page.
'jobject' must not be IntPtr.Zero.
Parameter name: jobject
Anyone else having this issue or know what may cause it?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/rid00z/FreshMvvm/issues/73

--
Michael Ridland | Technical Director | Xamarin MVP
XAM Consulting - Mobile Technology Specialists
www.xam-consulting.com
Blog: www.michaelridland.com

@rid00z Hmm i'll have to dig in deeper. It didn't happen until I updated to 2.1.0, so it's kind of odd. Did anything big change from 2.0.1 to 2.1.0?

Actually this could be us. If u have time just download the code and hook
up the project into your project. See if you can find the exact location of
issue.
On Saturday, 21 May 2016, JoshuaNovak919<EMAIL_ADDRESS>wrote:

@rid00z https://github.com/rid00z Hmm i'll have to dig in deeper. It
didn't happen until I updated to 2.1.0, so it's kind of odd. Did anything
big change from 2.0.1 to 2.1.0?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/rid00z/FreshMvvm/issues/73#issuecomment-220740289

--
Michael Ridland | Technical Director | Xamarin MVP
XAM Consulting - Mobile Technology Specialists
www.xam-consulting.com
Blog: www.michaelridland.com

@JoshuaNovak919  Is this still a issue?

@rid00z Yes, but I haven't had a chance to narrow it down more. I'll try and knock it out tomorrow.


san diego contributor summit blog

blog post for the contributor summit

/lgtm

/hold
some quick fixes in while getting an approve

/approve

/lgtm
release the hold when ready 👍

Looks good. Is the branch up to date? I don't see the list of currently published blogs in the right hand nav? I may be looking at an old preview though.

/hold cancel


ArgumentError thrown from auto-instrumentation code when running Datadog in parallel

Description of the bug
I have Datadog and Opentelemetry initialized in my Ruby on Rails application. We are trying to move to OpenTelemetry so we  decided to keep the datadog instrumentation code until the migration is complete. But the application is throwing ArgumentError when both datadog and opentelemetry are trying to auto-instrument the code.
It appears that datadog instrumentation is clashing with the opentelemetry instrumentation. I briefly looked at the ddtrace code and it has this method annotate_span_with_response! that takes 3 arguments and opentelemetry code has the same method annotate_span_with_response! that takes 2 arguments.  The ArgumentError we received was for this particular method where opentelemetry expected 2 arguments but received 3 (likely from the datadog instrumentation). Although, they have their own separate name spaces, I'm not sure why datadog called the opentelemetry library code.

Share details about your runtime
Operating system details: Linux
RUBY_ENGINE: "ruby"
RUBY_VERSION: "2.6.10"
RUBY_DESCRIPTION: "ruby 2.6.10p210 (2022-04-12 revision 67958) [x86_64-linux]"
Share a simplified reproduction if possible
Below are the details of my opentelemetry configuration.
# Gemfile
gem 'opentelemetry-sdk', '~> 1.1.0'
gem 'opentelemetry-instrumentation-all'

# OpenTelemetry configuration
require 'opentelemetry/sdk'
require 'opentelemetry/instrumentation/all'

OpenTelemetry::SDK.configure do |c|
  c.service_name = 'my-service'
  c.use 'OpenTelemetry::Instrumentation::ActiveSupport'
  c.use 'OpenTelemetry::Instrumentation::Rack'
  c.use 'OpenTelemetry::Instrumentation::AwsSdk'
  c.use 'OpenTelemetry::Instrumentation::HTTP'
  c.use 'OpenTelemetry::Instrumentation::ConcurrentRuby'
  c.use 'OpenTelemetry::Instrumentation::Dalli'
  c.use 'OpenTelemetry::Instrumentation::Ethon'
  c.use 'OpenTelemetry::Instrumentation::Faraday'
  c.use 'OpenTelemetry::Instrumentation::HttpClient'
  c.use 'OpenTelemetry::Instrumentation::Net::HTTP'
  c.use 'OpenTelemetry::Instrumentation::Rake'
  c.use 'OpenTelemetry::Instrumentation::Redis'
  c.use 'OpenTelemetry::Instrumentation::RestClient'
  c.use 'OpenTelemetry::Instrumentation::Sidekiq'
end

Below is the complete stack trace for the ArgumentError when running datadog and opentelemetry in parallel.
/usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-instrumentation-net_http-0.21.1/lib/opentelemetry/instrumentation/net/http/patches/instrumentation.rb:77:in `annotate_span_with_response!': wrong number of arguments (given 3, expected 2) (ArgumentError)
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/contrib/http/instrumentation.rb:59:in `block in request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/trace_operation.rb:192:in `block in measure'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/span_operation.rb:150:in `measure'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/trace_operation.rb:192:in `measure'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/tracer.rb:380:in `start_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/tracer.rb:160:in `block in trace'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/context.rb:43:in `activate!'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/tracer.rb:159:in `trace'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing.rb:16:in `trace'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/contrib/http/instrumentation.rb:40:in `request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-instrumentation-net_http-0.21.1/lib/opentelemetry/instrumentation/net/http/patches/instrumentation.rb:38:in `block in request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72:in `block in with_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:87:in `with_value'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72:in `with_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace/tracer.rb:29:in `in_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-instrumentation-net_http-0.21.1/lib/opentelemetry/instrumentation/net/http/patches/instrumentation.rb:31:in `request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/webmock-3.6.2/lib/webmock/http_lib_adapters/net_http.rb:97:in `block in request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/webmock-3.6.2/lib/webmock/http_lib_adapters/net_http.rb:110:in `block in request'
	from /usr/local/lib/ruby/2.6.0/net/http.rb:920:in `start'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/webmock-3.6.2/lib/webmock/http_lib_adapters/net_http.rb:109:in `request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/sentry-ruby-5.5.0/lib/sentry/net/http.rb:29:in `request'
	from /usr/local/lib/ruby/2.6.0/net/http.rb:1228:in `get'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/adapter/net_http.rb:85:in `perform_request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/adapter/net_http.rb:43:in `block in call'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/adapter/net_http.rb:92:in `with_net_http_connection'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/adapter/net_http.rb:38:in `call'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/request/url_encoded.rb:15:in `call'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/rack_builder.rb:143:in `build_response'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/connection.rb:387:in `run_request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday/connection.rb:138:in `get'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/faraday-0.15.4/lib/faraday.rb:103:in `method_missing'
	from /usr/src/app/lib/avant/webpack/webpack.rb:55:in `load_manifest'
	from /usr/src/app/lib/avant/webpack/webpack.rb:44:in `initialize'
	from /usr/src/app/lib/avant/webpack/webpack.rb:12:in `new'
	from /usr/src/app/lib/avant/webpack/webpack.rb:12:in `manifest'
	from /usr/src/app/config/initializers/webpack.rb:9:in `block in <top (required)>'
	from /usr/src/app/config/initializers/webpack.rb:9:in `each'
	from /usr/src/app/config/initializers/webpack.rb:9:in `<top (required)>'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:268:in `load'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:268:in `block in load'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:240:in `load_dependency'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:268:in `load'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:652:in `block in load_config_initializer'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:166:in `instrument'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:651:in `load_config_initializer'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:616:in `block (2 levels) in <class:Engine>'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:615:in `each'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:615:in `block in <class:Engine>'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:30:in `instance_exec'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:30:in `run'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:55:in `block in run_initializers'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:228:in `block in tsort_each'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:350:in `block (2 levels) in each_strongly_connected_component'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:422:in `block (2 levels) in each_strongly_connected_component_from'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:431:in `each_strongly_connected_component_from'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:421:in `block in each_strongly_connected_component_from'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:44:in `each'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:44:in `tsort_each_child'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:415:in `call'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:415:in `each_strongly_connected_component_from'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:349:in `block in each_strongly_connected_component'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `each'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `call'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:347:in `each_strongly_connected_component'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:226:in `tsort_each'
	from /usr/local/lib/ruby/2.6.0/tsort.rb:205:in `tsort_each'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/initializable.rb:54:in `run_initializers'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/application.rb:352:in `initialize!'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/railtie.rb:194:in `public_send'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/railties-<IP_ADDRESS>/lib/rails/railtie.rb:194:in `method_missing'
	from /usr/src/app/config/environment.rb:5:in `<top (required)>'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:274:in `require'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:274:in `block in require'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:240:in `load_dependency'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/dependencies.rb:274:in `require'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/sidekiq-4.2.10/lib/sidekiq/cli.rb:244:in `boot_system'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/sidekiq-4.2.10/lib/sidekiq/cli.rb:50:in `run'
	from /usr/src/app/vendor/gems/sidekiq-ent-1.5.4/lib/sidekiq-ent/swarm.rb:179:in `block in forkit'
	from /usr/src/app/vendor/gems/sidekiq-ent-1.5.4/lib/sidekiq-ent/swarm.rb:175:in `fork'
	from /usr/src/app/vendor/gems/sidekiq-ent-1.5.4/lib/sidekiq-ent/swarm.rb:175:in `forkit'
	from /usr/src/app/vendor/gems/sidekiq-ent-1.5.4/lib/sidekiq-ent/swarm.rb:171:in `spawn'
	from /usr/src/app/vendor/gems/sidekiq-ent-1.5.4/lib/sidekiq-ent/swarm.rb:82:in `monitor'
	from /usr/src/app/vendor/gems/sidekiq-ent-1.5.4/lib/sidekiq-ent/swarm.rb:42:in `start_and_monitor'
	from /usr/src/app/vendor/gems/sidekiq-ent-1.5.4/bin/sidekiqswarm:51:in `<top (required)>'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/bin/sidekiqswarm:23:in `load'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/bin/sidekiqswarm:23:in `<top (required)>'
	from /usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:74:in `load'
	from /usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:74:in `kernel_load'
	from /usr/local/lib/ruby/2.6.0/bundler/cli/exec.rb:28:in `run'
	from /usr/local/lib/ruby/2.6.0/bundler/cli.rb:463:in `exec'
	from /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
	from /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
	from /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
	from /usr/local/lib/ruby/2.6.0/bundler/cli.rb:27:in `dispatch'
	from /usr/local/lib/ruby/2.6.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
	from /usr/local/lib/ruby/2.6.0/bundler/cli.rb:18:in `start'
	from /usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.2/exe/bundle:30:in `block in <top (required)>'
	from /usr/local/lib/ruby/2.6.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
	from /usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.2/exe/bundle:22:in `<top (required)>'
	from /usr/local/bin/bundle:23:in `load'
	from /usr/local/bin/bundle:23:in `<main>'

Gem versions
ddtrace | 1.10.1
opentelemetry-api | 1.1.0
opentelemetry-common | 0.19.7
opentelemetry-instrumentation-all | 0.33.0
opentelemetry-instrumentation-sidekiq | 0.22.1
opentelemetry-instrumentation-net_http | 0.21.1

Thank you @anandhasudhan for the report.
We do not provide product support for vendor specific distributions.
Please open an issue with Datadog or contact them via your support contract: https://github.com/DataDog/dd-trace-rb/issues

@arielvalentin I've created a bug report with the dd-trace-rb team and they are currently investigating. (link)
I just wanted to provide additional context here in case it helps. I had initialized 1_datadog.rb first and then 2_opentelemetry.rb. I tried changing the order to initialize 1_opentelemetry.rb first and then 2_datadog.rb. The opposite seems to happen. ie. open telemetry code ends up calling data dog code and throws the ArgumentError.

Argument Error Stack trace
ArgumentError: wrong number of arguments (given 2, expected 3)
/usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/contrib/http/instrumentation.rb:91:in `annotate_span_with_response!': wrong number of arguments (given 2, expected 3) (ArgumentError)
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-instrumentation-net_http-0.21.1/lib/opentelemetry/instrumentation/net/http/patches/instrumentation.rb:39:in `block (2 levels) in request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-instrumentation-net_http-0.21.1/lib/opentelemetry/instrumentation/net/http/patches/instrumentation.rb:38:in `tap'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-instrumentation-net_http-0.21.1/lib/opentelemetry/instrumentation/net/http/patches/instrumentation.rb:38:in `block in request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72:in `block in with_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:87:in `with_value'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace.rb:72:in `with_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/trace/tracer.rb:29:in `in_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-instrumentation-net_http-0.21.1/lib/opentelemetry/instrumentation/net/http/patches/instrumentation.rb:31:in `request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/contrib/http/instrumentation.rb:55:in `block in request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/trace_operation.rb:192:in `block in measure'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/span_operation.rb:150:in `measure'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/trace_operation.rb:192:in `measure'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/tracer.rb:380:in `start_span'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/tracer.rb:160:in `block in trace'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/context.rb:43:in `activate!'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/tracer.rb:159:in `trace'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing.rb:16:in `trace'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/ddtrace-1.10.1/lib/datadog/tracing/contrib/http/instrumentation.rb:40:in `request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-exporter-otlp-0.23.0/lib/opentelemetry/exporter/otlp/exporter.rb:163:in `block (2 levels) in send_bytes'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-exporter-otlp-0.23.0/lib/opentelemetry/exporter/otlp/exporter.rb:237:in `measure_request_duration'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-exporter-otlp-0.23.0/lib/opentelemetry/exporter/otlp/exporter.rb:163:in `block in send_bytes'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-exporter-otlp-0.23.0/lib/opentelemetry/exporter/otlp/exporter.rb:131:in `block in around_request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-common-0.19.7/lib/opentelemetry/common/utilities.rb:92:in `block in untraced'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-api-1.1.0/lib/opentelemetry/context.rb:87:in `with_value'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-common-0.19.7/lib/opentelemetry/common/utilities.rb:91:in `untraced'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-exporter-otlp-0.23.0/lib/opentelemetry/exporter/otlp/exporter.rb:131:in `around_request'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-exporter-otlp-0.23.0/lib/opentelemetry/exporter/otlp/exporter.rb:155:in `send_bytes'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-exporter-otlp-0.23.0/lib/opentelemetry/exporter/otlp/exporter.rb:89:in `export'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-sdk-1.1.0/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb:187:in `block in export_batch'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-sdk-1.1.0/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb:187:in `synchronize'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-sdk-1.1.0/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb:187:in `export_batch'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-sdk-1.1.0/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb:170:in `block in work'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-sdk-1.1.0/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb:159:in `loop'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-sdk-1.1.0/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb:159:in `work'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/opentelemetry-sdk-1.1.0/lib/opentelemetry/sdk/trace/export/batch_span_processor.rb:180:in `block in reset_on_fork'
	from /usr/src/app/vendor/bundle/ruby/2.6.0/gems/hamelin-1.1.3/lib/hamelin/core_ext/threads.rb:14:in `block in initialize'

I came across this PR where it indicates that opentelemetry tracers have been built using the datadog auto-instrumentation library as a starting point and wonder if that could have any impact here.

@anandhasudhan Yes, you are correct that the inspiration for the OTel instrumentation libraries came from DD Trace and was largely contributed by non-Datadog engineers.
We do not have any intention on maintaining interoperability with DD trace other than using it as a reference when implementing OTel Instrumentation.
Datadog does not provide any engineering support to the OTel Ruby instrumentation since that donation, and I will reiterate that we do not provide guarantees for compatibility with other distributions or 3rd party tracers. If we choose to, we will only provide interoperability with what is available in the specification, which is limited to non-vendor distributions of OpenTracing and OpenCensus.
In addition to that, we do not provide support for EoL versions of Ruby like 2.6 so if this is an issue with e.g. Net::HTTP having changed its method signature between versions, then you will have to downgrade to an earlier version of the instrumentations where that was compatible for both DD Trace and OTel.


libsteam_api.so missing from nightly-107 onwards

The Cove-Application fails to start on Linux starting from nightly-107
Culprit of this seems to be that libsteam_api.so is missing from the zip file.

Simply re-adding the file fixes this issue apparently.

If you copy the libsteam_api.so to the newer versions dose it work?

yes, that's precisely how I fixed it for the time being

Should be fixed in the latest commit!


Update release notes

Updated release notes.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: ankoshe1 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@ankoshe1 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@ankoshe1 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.


uid() function

https://wiki.php.net/rfc/deprecate-uniqid

https://github.com/ventoviro/windwalker-framework/blob/d999ef12cf2b289733e2ca3aaca0cd775f574448/packages/utilities/src/functions.php#L171-L194

https://github.com/ventoviro/windwalker-framework/commit/fa8e95be27cb30c3062df3965cf695df572c6f3b#diff-ee7d5a32a997815ddf7dc4ed1fe82253531b750490c9c500af94c89a0c0bc083


Snappy Scroll

Added this attribute

You mean CSS Scroll Snap? It's already on the site: https://caniuse.com/#feat=css-snappoints

You mean CSS Scroll Snap? It's already on the site: https://caniuse.com/#feat=css-snappoints

Thank you so much


Travis build broken (PR #99)

PR #99 has broken the Travis build - it looks like it fails to build the expand example.
Here is the relevant travis build.

Fixed by #102


Weird looking time input

Description
The input field for times looks weird... The Buttons are way too high on the right side... Could you please fix this?
Repro Steps
Just add type="time" to a input field.
http://codepen.io/croghs/pen/pRqozJ
Screenshots / Codepen

Happens to me too, It does look good on mobile through.. there is another problem with this, the lable for such input won't go "dirty", check #4168

Time input is now supported wth the time picker component


Rancher2 Node Template docs are broken

What happened?
Go to: https://www.pulumi.com/registry/packages/rancher2/api-docs/nodetemplate/
Looks like this:

Example
n/a
Output of pulumi about
n/a
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

This will hopefully be fixed by the next bridge release.
Related to https://github.com/pulumi/registry/issues/5095


Container stalls after "Starting Zabbix Agent"

I've got the following log
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 00-functions: applying...
[fix-attrs.d] 00-functions: exited 0.
[fix-attrs.d] 01-s6: applying...
[fix-attrs.d] 01-s6: exited 0.
[fix-attrs.d] 02-zabbix: applying...
[fix-attrs.d] 02-zabbix: exited 0.
[fix-attrs.d] 03-logrotate: applying...
[fix-attrs.d] 03-logrotate: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-startup: executing...
[cont-init.d] 00-startup: exited 0.
[cont-init.d] 01-timezone: executing...
[NOTICE] ** [timezone] Timezone: Setting to 'America/New_York' from 'Etc/GMT'
[cont-init.d] 01-timezone: exited 0.
[cont-init.d] 02-permissions: executing...
[cont-init.d] 02-permissions: exited 0.
[cont-init.d] 03-zabbix: executing...
[cont-init.d] 03-zabbix: exited 0.
[cont-init.d] 04-cron: executing...
[NOTICE] ** [cron] Disabling Cron
[cont-init.d] 04-cron: exited 0.
[cont-init.d] 05-smtp: executing...
[NOTICE] ** [smtp] Disabling SMTP Features
[cont-init.d] 05-smtp: exited 0.
[cont-init.d] 10-cloudflare-companion: executing...
[NOTICE] ** [traefik-cloudflare-companion] Setting Traefik 2.x Mode
[cont-init.d] 10-cloudflare-companion: exited 0.
[cont-init.d] 99-container: executing...
[cont-init.d] 99-container: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[INFO] ** [traefik-cloudflare-companion] Starting Traefik Cloudflare Companion
[INFO] ** [zabbix] Starting Zabbix Agent

My docker-compose looks like this:
    image: tiredofit/traefik-cloudflare-companion:latest
    container_name: cloudflare-companion
    networks:
     - traefik_proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - TIMEZONE=$TZ
      - TRAEFIK_VERSION=2
      - CF_EMAIL=$CLOUDFLARE_EMAIL
      - CF_TOKEN=$CLOUDFLARE_API_KEY
      - TARGET_DOMAIN=$DOMAINNAME
      - DOMAIN1=$DOMAINNAME
      - DOMAIN1_ZONE_ID=$CLOUDFLARE_ZONEID
      - DOMAIN1_PROXIED=FALSE
    restart: always
    deploy:
      placement:
        constraints:
          - "node.role==manager"

Logging into the container and executing the items in /etc/cont-init.d/ shows only a single issue with "03-zabbix" as shown below
mkdir: can't create directory '': No such file or directory
chown: unknown user
chown: unknown user

My cursory glance is showing its failing to create a logfile somewhere along the line and then dropping out of the whole thing.

You can turn Zabbix off: ENABLE_ZABBIX=FALSE
All looks normal to me, can you give me the output of a ps -ef
Thanks

Sure can. See below
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
   31 root      0:00 s6-supervise s6-fdholderd
  758 root      0:00 s6-supervise 03-zabbix
  760 root      0:00 s6-supervise 10-cloudflare-companion
  762 zabbix    0:00 zabbix_agentd -f
  764 root      0:01 python -u /usr/sbin/cloudflare-companion
  798 zabbix    0:00 zabbix_agentd: collector [idle 1 sec]
  799 zabbix    0:00 zabbix_agentd: listener #1 [waiting for connection]
  800 zabbix    0:00 zabbix_agentd: listener #2 [waiting for connection]
  801 zabbix    0:00 zabbix_agentd: active checks #1 [idle 1 sec]
  841 root      0:00 bash
  846 root      0:00 ps -ef

PID 764 shows that he container is running, as is Zabbix.
I find that with some of the changes I've made with the base images lately just running the scripts inside cont-init.d won't; give you the expected output you want as it's hardcoded to look for a different path (I believe /var/run/s6/cont-init.d).
But back to the matter at hand, you'll only get output from the python script if it can find a matching rule in your Traefik labels section.
Try this on a sample container:
 labels:
      - traefik.enable=true
      - traefik.http.routers.example.rule=Host(`dns.example.com`)

I have a helloworld container running with the following lables:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.helloworld.rule=HostHeader(`helloworld2.$DOMAINNAME`)"
        #- "traefik.http.routers.helloworld.rule=Host(`helloworld2.$DOMAINNAME`)"
        - "traefik.http.routers.helloworld.rule=Host(`helloworld2.tld.org`)"
        - "traefik.http.routers.helloworld.entrypoints=websecure"
        - "traefik.http.routers.helloworld.tls.certresolver=dns-cloudflare"
        - "traefik.http.services.helloworld.loadbalancer.server.port=80"
        #HTTPS Redirect Code
        - "traefik.http.middlewares.helloworld-https.redirectscheme.scheme=https"
        - "traefik.http.routers.helloworld-insecure.middlewares=helloworld-https@docker"
        - "traefik.http.routers.helloworld-insecure.rule=Host(`helloworld2.$DOMAINNAME`)"
        - "traefik.http.routers.helloworld-insecure.entrypoints=web"

Where $DOMAINNAME = tld.org

That should definitely do it.
It should be monitoring the docker socket and showing some sort of response like so:
 ** git.tiredofit.ca - 81053 An A, AAAA or CNAME record already exists with that host.
cloudflare-companion    | container rule value:  Host(`dns.example.com`)
cloudflare-companion    | extracted_domains from rule:  [u'dns.example.com']
cloudflare-companion    | Found Container: 670c82dc337067c35c7603969211e701b5d0fe6f28c60e4c92a7f77a038739e2 with Hostname dns.example.com

FWIW, I'm running docker-swarm across a few machines, but the cloudflare-companion container is able to ping the traefik container with ease.
But I'm a bit befuddled as to why it doesn't work.

Typically when running swarm your socket would be network related. How do you have the network socket connected with Traefik? We're assuming that you are using /var/run/docker.sock on your system, which is where I believe this issue is occurring.
You can change the socket entry point to something tcp oriented by setting the environment variable DOCKER_ENTRYPOINT
Hopefully someone else can speak up on this one, there are an awful lot of users of this image (and its companion nginx-proxy-cloudflare-companion) where I would think someone must have figured this out.

Yep. That's how I'm doing it.
      - /var/run/docker.sock:/var/run/docker.sock:ro

Both containers are bound to the same manager host as well.
I'm honestly pretty new to the whole docker ecosystem, so I need to find some good documentation on choosing socket entry points.

From inside your cloudflare companion container, can you make sure you can talk to the socket?
This command will show all your images pulled onto your Docker Host
curl --unix-socket /var/run/docker.sock http:/v1.24/images/json
I don't need to see the output really, but lets just make sure that its showing a json list of images. (Should be a series of ID and Parent IDs)

I've got a big json string, each element has an ID (starts with sha256:). There is a "ParentId" tag as well, but its value is null for all containers.
I DO see all my running and expected containers though.

OK< good enough. So at least we can talk to the socket which is where all the info is coming up, I truly am stumped here as to what could be happening. The image itself is pretty basic in what it does in a very hackish way. I'm going to reach out to some of my clients and see if we are running in a swarm environment to see if there is something that is being missed here.

Any word from your clients?

I have a few who are running swarm and on the TCP socket yet none are reporting issues. I'll test on a burner system today to see if I can recreate. We did have some nasty stuff happening in the past week with Traefik 2.2.2+ and finally resolved when we moved to 2.2.6 - but the cloudflare container wouldn't have been affected by it.

I setup a Ubuntu 20.04 server last night and exposed the Docker Socket via TCP and ran a few tests both from the local machine and a remote machine. I used the value of DOCKER_ENTRYPOINT=tcp://(host_ip):2376. My Docker socket was listening on <IP_ADDRESS> and I turned off any firewalls to limit access.
On test #1 (same machine to docker socket) it worked as expected
On test #2 (remote cloudflare-companion image pointing at the remote IP host) it again worked as expected.
There has to be something else that is blocking this. I didn't do anything fancy with my setup, had it up and running within 10 minutes after first boot. I'm back to being stumped and hoping someone is able to step in..

Have a peek at this PR.
The submitter added TLS support and also some additional variables which might be solving your problem. Assuming it is TLS related. Note, you'd probably have to export a data volume for your docker certificates as well, and there is an environment variable built to support that. Let me know if that changes anything?

Hi there,
I am also having this issue.  I am running traefik v2.2.7 in swarm mode on a single node.  The "manual" service for a non-docker service works and the CNAME in CF has been added correctly.  The dockerized services are not being found.
I've been trying to figure out what's been happening and just doing straight comparison on the difference between the cf-companion service and all my other services...
I am not too well versed in the coding, but how/where is the cf-companion looking for the labels?  My 30 second google-fu shows that there might be a difference between service labels and container labels.  In Portainer, all of my services have service labels and not container labels.  I noticed that the manual entry on the cf-service shows up as a container label, not a service label.
cf-companion labels:

random-other-service labels:

The only difference I see between the yml for cf-companion and all my services is the deploy command:
#My regular services yml
deploy:
  labels:
    - "LABELS"

versus
#CF-Companion yml
labels:
  - "LABELS"

Can you give me the output (fuzz it if you need to) of one of your containers with labels?
docker inspect (containername)
You may be onto something here... We're pulling them from the json key of Config: , Labels:

I navigated down to the Config:Labels area.  I see no mention of the traefik labels... or anything that would show the Host('etc....
So I did docker service inspect, and tada!

OK then. This helps tremendously. Going to think about it for a night and lets see what I can come up with.

I don't know much about it, but perhaps SWARM_MODE:TRUE might be good if it can be directed to the service labels versus the container labels.  And then if it is swarm_mode, the "non-dockerized services" can be under the deploy in the cf-companion.yml as well.  Unfortunately I don't know enough about coding to do a PR!

I like the SWARM_MODE idea. I've put together a test version on Docker Hub. Can you try pulling tiredofit/traefik-cloudflare-companion:develop with SWARM_MODE=TRUE as an environment variable?

Got this in the logs:
[INFO] ** [traefik-cloudflare-companion] Starting Traefik Cloudflare Companion,
  File "/usr/sbin/cloudflare-companion", line 59, in <module>,
  File "/usr/sbin/cloudflare-companion", line 49, in init,
    init(),
AttributeError: 'NoneType' object has no attribute 'get',
    for prop in c.attrs.get(u'Spec').get(u'Labels'):,
  File "/usr/sbin/cloudflare-companion", line 29, in check_container,
    check_container(c),
Traceback (most recent call last):```

Can you send me privately the entire inspect output? Based on the indenting of the output above I may be missing a key. I'm dave at tiredofit dot ca .

Sent!

Odd. still haven't seen it. No sign on my MTA either.

Sent it again.  It might be because I pasted it as plain text in the email... so this time I sent it as a .txt attachment.

Received (oddly at same time). I'm going to need a few days (week max) to parse and setup a test environment. My 'real world' role has just required more time than I have anticipated. I'll be in touch.

Docker swarm support now available in tiredofit/traefik-cloudflare-companion:5.0.0

See tiredofit/traefik-cloudflare-companion:6.0.0 for working SWARM_MODE=TRUE.


0.2 release plan

Tomorrow morning around 9am PST:

HackerNews
Reddit
Lobste.rs — though I don't have an account here — does anyone else?
Twitter, with our current 4 followers
Issue 1 in this repo (which maybe we transition away from? I've been bad at keeping it updated. But maybe people aren't on Twitter?)

CC @prql

I'd say keep the issue #1 - it would be a best bet to reach me.
It shouldn't get too much updates, only the major releases anyway.


SmartBulkCopy was fast only initially but slowed down for last heavy tables

I am trying to move ~1TB of data from one sql server to another sql and it has many tables with ~10heavy tables( more than~700gb size). I set the config file with 2 threads initially and then later 8 and then 12 threads. I observed that SmartBulkCopy(SBC) ran quickly with good network speed  used up the threads and later slowly degraded once most of the small to medium sized tables are finished and left with ~5 heavy tables and also network speed dropped too. Finally we end up with ~4hours to migrate ~1TB of data. Why is this happening and how to speed up the process here?
What are your recommendations to migrate heavy tables?
How can we ensure the parallel threads use up network speed?
FYI, We disabled foreign key indexes and dropped non-clustered index to move fast

Hard to say, looking at the wait_stats (both on the source and the destination) in SQL Server could help to see what could be the bottlenecks. Btw, if you have a 1Gbps network, you're most likely saturating the bandwidth. 1TB in 4 hours is something like 72Mb/sec, which needs to be doubled given that SBC must read and write at the same time, so you get 125 MB/sec which is 1Gbps limit.


Allow user customization of system fonts

As a user, I'd like to have the ability to customize the system fonts that are used when I use Roth_UI.  This way, the experience will be consistent for me, no matter which fonts I decide to use.  When complete, I should be able to visit the addon section of the interface menu and select a font to use for larger, more impactful text and another for smaller, harder to read text.  The font selection I have available to me should be driven by LibSharedMedia, so that I can easily add my own fonts without having to modify Roth_UI itself.

Okay, pull request opened.


Add importWallet() functionality

closed - https://github.com/getsafle/vault-mantle-controller/pull/8


Quickstart: add SEV annotations information

SEV configuration no longer requires updating the Kata config file directly. Instead, configuration can be done via pod annotation.
CC: @ryansavino @jimcadden

@confidential-containers/documentation-maintainers can someone take a look at this

I'm going to add this stuff as part of another PR that is coming soon.


change test, add retention_size, minifix config

Fixes #197

lgtm

Closed due to exceeding dependency caching quota for open PR


Add event documentation for Modal-Carousel and Modal-Fullscreen

Developers should get to informed about your plugin's events to learn which entry points are available for custom handling or markup modification before/while/after the carousel was (re)moved from/to the modal dialog.

Hi, these events are listed in the modal-local documentation (https://noreiller.github.io/bootstrap-modal-carousel/modal-local.html#events).
The plugin detects the show and hidden events from the modal and detach or replace the carousel from/to its native place.

Mabe you can add an "events" section on your site for these two sections and add this hint as event documentation for those who don't know this like me because it's not obvious and nobody wants to start investigating your scripts or bug you just for that info. To get to be told this would be very kind and helpful of you. Thanks.

You are right, I will add it. Thanks for your comments.


"is not exported" when importing CJS library from worker, but not outside worker

Describe the bug
I tried to upgrade https://github.com/jakebailey/esbuild-playground to vite v6, but hit an issue with a CJS library I use in a worker. It looks like vite (or rollup?) can't find one of the exports, while vite v5 can.
Notably, doing the same import but not in a worker seems to operate correctly. It also works fine in dev mode.
I've created a minimal repro on stackblitz, included below, along with logs that are just in that stackblitz.
Reproduction
https://stackblitz.com/edit/vitejs-vite-cc7pyv?file=src%2Fmain.ts&view=editor
Steps to reproduce

npm install
npm run build

System Info
System:
    OS: Linux 6.11 Arch Linux
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 10.12 GB / 15.41 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 22.10.0 - /run/user/1000/fnm_multishells/582535_1732647819061/bin/node
    pnpm: 9.12.2 - /run/user/1000/fnm_multishells/582535_1732647819061/bin/pnpm
    bun: 1.1.37 - /usr/bin/bun
  npmPackages:
    @vitejs/plugin-react: ^4.3.3 => 4.3.3
    vite: ^5.4.10 => 5.4.10

Used Package Manager
npm
Logs

Click to expand!
><EMAIL_ADDRESS>build
> tsc && vite build

vite v6.0.0 building for production...
✓ 7 modules transformed.
x Build failed in 752ms
error during build:
[vite:worker] src/worker.ts (1:9): "createFileSystem" is not exported by "node_modules/wasi-js/dist/index.js", imported by "src/worker.ts".
file: /home/projects/vitejs-vite-cc7pyv/src/worker.ts?worker:1:9

1: import { createFileSystem } from 'wasi-js';
            ^
2:
3: createFileSystem([

    at getRollupError (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/parseAst.js:558:41)
    at Module.error (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/parseAst.js:554:42)
    at Module.error (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:15618:29)
    at Module.traceVariable (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:16067:29)
    at ModuleScope.findVariable (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:13850:39)
    at Identifier.bind (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:5096:40)
    at CallExpression.bind (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:2683:23)
    at CallExpression.bind (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:11314:15)
    at ExpressionStatement.bind (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:2683:23)
    at Program.bind (file:///home/projects/vitejs-vite-cc7pyv/node_modules/rollup/dist/es/shared/node-entry.js:2679:28)

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I had this same issue with an worker as well.
error during build:
[vite:worker-import-meta-url] node_modules/styled-components/dist/styled-components.browser.esm.js (4:12): "useRef" is not exported by "node_modules/react/index.js", imported by "node_modules/styled-components/dist/styled-components.browser.esm.js".
file: ...functions.ts:4:12

It looks like this is because perEnvironmentPlugin's applyToEnvironment is not resolved for worker build.
https://github.com/vitejs/vite/blob/31cc61b7404b2b22d956856f97eeebd0a62f3b4d/packages/vite/src/node/build.ts#L479

I'm running into the same issue with the fastpriorityqueue npm package, which is using CJS. When I'm building my client which pulls this file in in a worker, Vite errors with:
error during build:
[vite-plugin-pwa:build] athena/Radius.tsx (1:7): "default" is not exported by<EMAIL_ADDRESS>imported by "athena/Radius.tsx".
file: /home/runner/work/athena-crisis-universe/athena-crisis-universe/hera/workers/gameAction.tsx?worker:1:7
The code for this is open source at https://github.com/nkzw-tech/athena-crisis but this particular build step is not. If you'd like to build a repro, I recommend creating a vite.config.js that bundles files in the hera folder. Happy to help.

Seems like this is all good in vite 6.0.1. Thank you!!


Swiper component add a "loop" property

Version
<EMAIL_ADDRESS>Android or iOS, which browser?
All browser
Expected behavior and actual behavior.
Like swiper

I tried but found it hard because I have to change the animation design.
PR is welcome ~