text:
Enhance YouTube transcript retrieval logic

fixes #245
/claim #245
Summary
This PR improves the logic for handling YouTube transcript retrieval within the application. Key changes include:

Updated the tool invocation handler to check if the YouTube transcript is successfully retrieved based on the selected videos.
Improved the message filtering logic to exclude assistant messages that indicate a transcript retrieval issue if the transcript was successfully retrieved.
Added state management for transcript retrieval status to enhance user experience and feedback.
Ensured that the component correctly displays success or error messages based on the state of transcript retrieval.

Testing
https://github.com/user-attachments/assets/311c1447-031d-4232-815f-5285d8dc2e29
In the video demonstration, third video example does not have transcripts provided by Youtube. Hence throws error as expected.

@akhilender-bongirwar
Critique of the Pull Request (PR)
The PR aims to address an issue in the File Organizer 2000 Obsidian plugin where the AI assistant incorrectly states that it couldn't retrieve a YouTube transcript, even when the transcript was successfully fetched. The current approach attempts to filter out such erroneous messages on the frontend.

Analysis
Strengths:

Identifies the Problem: The PR correctly identifies that unwanted error messages are displayed to the user even when the transcript retrieval was successful.
Attempts a Fix: By filtering messages and excluding certain assistant messages based on conditions, it tries to prevent the incorrect error message from appearing.

Weaknesses:

Frontend Filtering is Fragile:

Race Conditions: The state transcriptRetrieved may not update synchronously with the arrival of messages, leading to inconsistent filtering.
Incomplete Filtering: The assistant's message may contain valuable information alongside the error message, which could be improperly filtered out.

Complexity in Message Handling:

Filtering messages based on content strings and roles adds unnecessary complexity to the component.
The approach relies on hardcoded error messages, which is not scalable or maintainable.

Root Cause Not Addressed:

The assistant should not generate incorrect error messages in the first place. The PR addresses the symptom (the message) rather than the root cause (the assistant's logic).

Recommendations for Improvement

Handle Errors at the Source

Modify the Tool Invocation Logic:

Ensure that the assistant only mentions the inability to retrieve the transcript when the retrieval actually fails.
a. Update handleToolCall Function

if (toolCall.toolName === "getYouTubeTranscript") {
const args = toolCall.args as { videoId: string };
const { videoId } = args;
try {
const transcript = await getYouTubeTranscript(videoId);
const title = await getYouTubeVideoTitle(videoId);
setSelectedYouTubeVideos(prev => [
...prev,
{ videoId, title, transcript },
]);
addToolResult({
toolCallId: toolCall.toolCallId,
result: { transcript, title, videoId },
});
// Indicate success explicitly
return { success: true };
} catch (error) {
console.error("Error fetching YouTube transcript:", error);
// Return error details to the assistant
return { success: false, error: error.message };
}
}
```
 - **b. Adjust Assistant's Response Logic**
   ```tsx

// Pseudo-code representation of assistant logic
if (toolResult.success) {
// Proceed with using the transcript
assistantMessage = I've successfully retrieved the transcript for the video titled "${title}". How can I assist you further with it?;
} else {
// Inform the user of the failure
assistantMessage = I couldn't retrieve the transcript for the YouTube video with the ID "${videoId}". ${toolResult.error};
}
```

Remove Frontend Message Filtering

Since the assistant will now only generate appropriate messages, you can eliminate the frontend filtering logic. This reduces complexity and the potential for bugs related to state management and message synchronization.
Remove the Following Code:

const errorMessages = [
"don't have access to the transcript for the YouTube video",
"couldn't retrieve the transcript for the YouTube video",
];
// ...
const filteredMessages = messages.filter(message => {
const isAssistantMessage =
message.role === "assistant" && message.content.includes("transcript");
const isErrorMessage = errorMessages.some(errorMessage =>
message.content.includes(errorMessage)
);
return !(isAssistantMessage && isErrorMessage && transcriptRetrieved);
});
```

Update the message rendering to use messages directly:

{messages.map(message => (
// ... render messages without filtering
))}
```

Improve Assistant's Prompt or Backend Logic

If using a backend AI service or language model, adjust the prompt engineering or the backend logic to handle the success and error cases more effectively.
Example Prompt Adjustment:

Before:
Whenever you attempt to retrieve a YouTube transcript, inform the user if you cannot access it.

After:
When you attempt to retrieve a YouTube transcript, only inform the user if the retrieval fails. If successful, proceed without mentioning any errors.

Provide Clear User Feedback

If the transcript is successfully retrieved, consider informing the user explicitly. This enhances the user experience by confirming that their request was fulfilled.
Example Assistant Message Upon Success:I've successfully retrieved the transcript for the video titled "Your Video Title". How can I assist you further with it?

Is There a Better Approach?
Yes, handling the error at the source (during the tool invocation) and ensuring the assistant constructs messages based on the actual outcome is a better approach. This avoids the need for frontend message filtering, reduces complexity, and provides a cleaner, more maintainable codebase.

Conclusion

Current PR Limitations: While the PR attempts to fix the issue, it doesn't address the root cause and introduces complexity through frontend filtering.
Recommended Solution: Handle success and failure cases within the tool invocation logic and adjust the assistant's response accordingly. Remove unnecessary frontend filtering.

Benefits

Reliability: Ensures that messages accurately reflect the outcome of transcript retrieval.
Maintainability: Reduces code complexity and potential bugs.
User Experience: Provides clear and accurate feedback to the user.

Improved Code Snippets

In chat.tsx:

// Remove error messages array and filtering logic
// const errorMessages = [...];
// Remove filteredMessages and use messages directly in rendering
// const filteredMessages = ...
// In handleToolCall function
const handleToolCall = async ({ toolCall }) => {
if (toolCall.toolName === "getYouTubeTranscript") {
const args = toolCall.args as { videoId: string };
const { videoId } = args;
try {
const transcript = await getYouTubeTranscript(videoId);
const title = await getYouTubeVideoTitle(videoId);
setSelectedYouTubeVideos(prev => [
...prev,
{ videoId, title, transcript },
]);
addToolResult({
toolCallId: toolCall.toolCallId,
result: { transcript, title, videoId },
});
// Return success flag
return { success: true, transcriptRetrieved: true, title };
} catch (error) {
console.error("Error fetching YouTube transcript:", error);
return { success: false, transcriptRetrieved: false, error: error.message };
}
}
// ... handle other tools
};

- **In Assistant Logic or Prompt:**
```tsx
// Ensure that the assistant constructs its response based on the success flag.

Summary
By handling success and failure cases explicitly during the tool invocation and adjusting the assistant's response logic, we can ensure accurate communication with the user without relying on fragile frontend filtering. This results in a more robust and maintainable solution.

@akhilender-bongirwar thanks for the PR. This approach does however not work consistently. Here are some suggestions on how to implement a better solution:

@aexshafii,  Thank you for your detailed feedback and suggestions. I understand your concerns regarding frontend filtering, and I agree that addressing issues at the source is typically a better approach. However, in this particular case, I chose to implement the filtering logic on the frontend for a specific reason:
Whenever I provide a YouTube video link and request a transcript, the response from the OpenAI API results from the assistant: one initiating the tool call and the other an error message indicating that the transcript could not be retrieved (shown in image below). This happens consistently, even when the transcript is successfully fetched. The error message is part of the assistant's response, which makes it difficult to prevent from being displayed on the frontend.
Since I can't control the response generation from the OpenAI API (using useChat from the ai-sdk), I realized that filtering these messages based on the context where the transcript is stored was the most reliable approach. The logic ensures that if the transcript is successfully retrieved and stored in the context, I can confidently filter out the erroneous error message. This approach guarantees that only valid messages are displayed, without impacting any further interactions regarding the video.
I acknowledge that frontend filtering adds a layer of complexity, and it's not an ideal long-term solution. However, given the constraints where I cannot modify the underlying API behavior, this solution effectively prevents the erroneous error message from being shown while maintaining the integrity of the information stored in the context. Even if I were to implement success flags as you suggested, they would still be dependent on the AI's response, which includes the error message by default. As a result, I would still need to filter the messages based on the content.

@akhilender-bongirwar thanks for your help with this issue but for now I estimated the other solution was satisfactory and introduced minimal changes. I will make sure to reward you with the bounty if we do implement this solution later on 🙏

@akhilender-bongirwar thanks for your help with this issue but for now I estimated the other solution was satisfactory and introduced minimal changes. I will make sure to reward you with the bounty if we do implement this solution later on 🙏

@aexshafii, Thank you for your consideration, but these changes correctly ensure the successful retrieval of YouTube transcripts.

@aexshafii, I just wanted to follow up, as it's been a week since I made the changes. I was wondering if you’ve had a chance to test them and whether you've encountered any issues. I made sure everything aligns with what’s shown on fileorganizer2000.com for retrieving YouTube transcripts and interacting with the content.

Thanks so much for your time, and I appreciate your feedback.

authors: aexshafii akhilender-bongirwar


text:
allow spanning multiple relations (issue #93) [DO NOT MERGE]

it's rough and incomplete so I put it here more for discussion than merging

allows only forward foreign keys for chained_field right now
since it's using native django filter syntax for chained_model_field,
it probably works via any relations

class BaseModel(Model):
    def __unicode__(self):
        return u"%s %d" % (self._meta.model_name, self.id)

    class Meta:
        ordering = ("id", )
        abstract = True

class A(BaseModel):
    pass

class B(BaseModel):
    a = ForeignKey(A)

class C(BaseModel):
    a = ForeignKey(A)

class D(BaseModel):
    c = ForeignKey(C)

class Main(BaseModel):
    b = ForeignKey(B)
    d = ChainedForeignKey(D, chained_field = "b__a", chained_model_field = "c__a")

Edit (by blag): Formatted with GFM.

Can you rebase this off of master?

that's over year old... so not really - in the end I stopped using smart_selects.

The AJAX autocomplete endpoint exposes all models with a ChainedForeignKey or ChainedManyToManyField on them and does zero permissions checking on that. I have included a warning at the top of the README to warn developers of that caveat, but...
I'm afraid that any implementation of this functionality would allow arbitrary access to all related related models as well, and that is simply a security incident or improper information disclosure waiting to happen.
Because of that I'm closing this PR and - unless somebody has a workable, generic way of controlling access that we can include by default - I won't be accepting any PRs implementing this functionality at all. 😖
But thank you for trying to implement it!

source: gharchive/pull-request

authors: blag mkaluza

license_type: permissive

license_source: bigquery


text:
Delete tags/images

Whalerator should provide the ability to delete tags or entire images/repositories from a registry (given appropriate permissions).

Depends on #9

source: gharchive/issue

repo: digimarc-corp/whalerator

license_source: github-api


text:
Exception to log

Added an additional column called error-message in datasette log table for endpoints which are failing. Added error message for endpoints returning empty status as well as a error status code. This particular change makes sure that the log.csv created for each collection has that additional column.
Concerned Ticket: https://trello.com/c/fRwiKwEP/78-spike-review-of-endpoint-collection-logs

Codecov Report
Patch coverage: 50.00% and project coverage change: -0.02 :warning:

Comparison is base (d989d26) 77.68% compared to head (241ad3b) 77.67%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #125      +/-   ##
==========================================
- Coverage   77.68%   77.67%   -0.02%
==========================================
  Files          66       66
  Lines        3218     3220       +2
==========================================
+ Hits         2500     2501       +1
- Misses        718      719       +1

Impacted Files
Coverage Δ

digital_land/schema.py
100.00% <ø> (ø)

digital_land/collect.py
86.91% <50.00%> (-0.71%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

authors: codecov-commenter ssadhu-sl

repo: digital-land/digital-land-python

license: MIT


text:
TypeError: Cannot read properties of undefined (reading 'catch')

Hello! I recently installed this package and ran into an error on first use. I followed the documentation to the best of my knowledge, and am a little stuck. Here's the full error stack:
file:///workspaces/monorepo-tools/node_modules/.pnpm/@digitak+tsc-esm@3.1.1/node_modules/@digitak/tsc-esm/binary/tsc-esm.js:3
build().catch(error => {

TypeError: Cannot read properties of undefined (reading 'catch')
    at file:///workspaces/monorepo-tools/node_modules/.pnpm/@digitak+tsc-esm@3.1.1/node_modules/@digitak/tsc-esm/binary/tsc-esm.js:3:8
    at ModuleJob.run (node:internal/modules/esm/module_job:185:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24)
    at async loadESM (node:internal/process/esm_loader:88:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12)
 ELIFECYCLE  Command failed with exit code 1.
 ```

 Here's my TSConfig

 ```
 {
  "exclude": ["node_modules"],
  "extends": "@kienleholdings/base-tsconfig",
  "include": ["./src"],
  "compilerOptions": {
    "lib": ["ESNext", "DOM"],
    "module": "es2020",
    "outDir": "lib",
    "target": "es2021",
    "types": ["node"]
  }
}

And here's the relevant portion of my package.json
{
  ...
  "type": "module",
  "scripts": {
    "build": "tsc-esm"
  },
  "devDependencies": {
    "@digitak/tsc-esm": "^3.1.1",
    "typescript": "^4.5.5"
  }
  ...
}

Let me know if there's any other information you need! I love this solution to the esm importing problem, and hopefully one day it'll simply be a part of TypeScript

Just realized that this might be a dupe of #2 - I'd be willing to close this as long as one of the tickets gets addressed :)

Indeed, I now close this thanks to @jrkienle fix (available from version 3.1.2).

authors: Gin-Quin jrkienle

repo: digital-loukoum/tsc-esm


text:
Add deafrica_tools.app modules

Adding the modules in deafrica_tools.app

Do we keep the app entries as part of the list, or split it out to a new section?
https://digital-earth-africa--35.org.readthedocs.build/en/35/sandbox/api.html

repo: digitalearthafrica/deafrica-docs


text:
New function: receive a hint

We need some kind of concept here probably? Maybe a kind of scrabble or hangman-style.

Display hint button during session

If pressed, show user first letter and word length

If pressed, input can only achieve "almost correct" status

Delayed to a later point.

repo: digitalfabrik/visual-vocabulary-trainer


text:
Connecting interface not seaching device from seach mode

Environment

Python version:    3.5.2
NetBox version:   2.5.9

Steps to Reproduce
1.I have a rack, with a server, with interfaces. I select one interface to connect to a switch
2. When I'm searching the device, with select mode, the search isn't working
https://******************/dcim/interfaces/1607/connect/?return_url=/dcim/devices/128/

I have to do select mode like:

Expected Behavior
Select device faster.
This method was working before ( before update i was working on 2.5.1 )

Observed Behavior
I need to search by site, rack, device
Thanks

Duplicate #3044

authors: DanSheps gil-obradors

repo: digitalocean/netbox


text:
Add NATURAL_ORDERING opt to disable natsort

Fixes:
With a lot of objects, the sort query took more than 2s to complete, each time they were listed. Making the concession to disable natural ordering sort reduces this time to 0.1s, making the listing views and homepage snappier in our case.
Add an option to disable or not the natural ordering sort in Netbox for the DCIM models.

Related to issue #2732


text:
Slugs do not initialize

When mongoid-slug is added to an existing application, the Model.slugs field is blank until every document is re-saved.
Suggestion:  have a rake task or some default logic in mongoid-slug that will handle this initial case.  Applications with large data sets that have business logic around "updated_at" may not want to re-save each instance to get the slug behavior.
Thanks!

Yea, would be nice to have it generated initially for existing documents, was confused why it didn't work.
:+1:

agreed, at least for me .  . . very grateful for this issue.

@digitalplaywright  I am looking into this issue and wrote a rake task that will set slug for existing records, to load this task into Rails we need to use Rails::Railtie, that will be Rails specific. Do you want this task to support any other frameworks ?

@anuja-joshi You can add just task file and inform users to load that rake tasks file into their rake stack.

A rake task was added in https://github.com/digitalplaywright/mongoid-slug/commit/8abb60d6c263f532e51b1ea064b88e6df25b2658.

authors: anuja-joshi dblock pencilcheck simi tbbooher vanboom

repo: digitalplaywright/mongoid-slug

license: mit


text:
⚠ eid has degraded performance

In 04410b5, eid (https://eid.digitalservicebund.de/api/v1/health) experienced degraded performance:

HTTP code: 200
Response time: 6093 ms

Resolved: eid performance has improved in e178362.

repo: digitalservicebund/uptime-monitor


text:
Update http4s-ember-server to 0.21.28

Updates org.http4s:http4s-ember-server from 0.21.14 to 0.21.28.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s", artifactId = "http4s-ember-server" } ]

labels: library-update, semver-patch

Superseded by #48.

repo: dimitarg/bb-webhook


text:
cronus doesn't parse blob column

I have a blob column, but when I generate the annotations, this field don't come

Done.

authors: diogocavilha otaavioo

repo: diogocavilha/cronus


text:
Extendable cleanup.

Proposed Semver Increment Bump: [MAJOR/MINOR/PATCH]
N/a
Changes Proposed in this Pull Request (List new items in CHANGELOG.MD)

Minimized processing (running the same function multiple times).

(If Applicable) What Issue does it fix?
Fixes... performance.

Already in #255

repo: dirigeants/komada


text:
Not everyone uses MySQL

An error occurred while installing mysql2 (0.4.4), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.4.4'` succeeds before bundling.

@derwiki: Fixed in 06c1dea! And just cut a new version.

authors: derwiki dirk

repo: dirk/lita-markov


text:
Look into process manager for douma-api and config-server

Config-editor and douma-app are just static files being served, so no processes running.
PM2 might be an option: http://pm2.keymetrics.io/

If we go for a containerised solution then this becomes a bit complicated.
The container can still be alive while the process can stop. We might also run the two processes in different images. It would be easier to run in one image.

repo: disarm-platform/standalone


text:
Revamp the contribution process

Hey 👋
The current process of contributing to diodb requires:

a GitHub account
basic knowledge of git which not all potential contributors have
in worst-case ability to resolve merge conflicts and time and energy needed to achieve the resolution

To address all of the issues I propose two solutions. We may implement both of them.

Google Form
GitHub issue forms

@jmanoto as we've discussed this topic, I'd like to hear your feedback 😃
Google Form
Removes all three aforementioned requirements. Can be scripted with Apps Script to make a PR from a submission. But we can start with handling submissions manually.
Example: https://forms.gle/VXCWJX3hRTVQArT39
GitHub issue forms
Solves 2nd and 3rd of the aforementioned requirements. We can create three templates (for addition, edit, and delete) and a workflow_dispatch workflow to make one PR from all currently open issues (and add authors of those issues to the commits so that they count as contributors). I can prototype it later.

Perhaps, #346 will become obsolete once we solve this issue.

We can also use https://www.typeform.com as Google Forms alternative

Partially done in #404

repo: disclose/diodb


text:
docs: call setEmitters before load

Suggest to add additional documentation to the guide, to call setEmitters before load or loadAll. Otherwise it will trigger AkairoError [INVALID_TYPE]: Value of 'emitter' was not an EventEmitter. API users should not usually have to concern themselves with what is going on behind the scenes, therefore documentation should state if certain steps have to be carried out in a specific order.

I think "...before loadAll" should be "before loading".

repo: discord-akairo/discord-akairo


text:
🛑 MonitoRSS-Ambler is down

In fe12534, MonitoRSS-Ambler ($MONITORSS_AMBLER) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MonitoRSS-Ambler is back up in d05dbc5 after 24 minutes.

repo: discord-creator/upptime


text:
(types): ApplicationCommandNumberOptionBase is not extending base properly

Issue description
Since the 13.4.0 Djs release, compiling to js fails due to this error:
node_modules/@discordjs/builders/dist/index.d.ts(516,5): error TS2416: Property 'toJSON' in type 'ApplicationCommandNumberOptionBase' is not assignable to the same property in base type 'ApplicationCommandOptionWithChoicesBase<number>'.
         Type '() => { min_value: number; max_value: number; type: ApplicationCommandOptionType.String | ApplicationCommandOptionType.Integer | ApplicationCommandOptionType.Number; ... 4 more ...; required?: boolean; } | ... 5 more ... | { ...; }' is not assignable to type '() => APIApplicationCommandOption'.
           Type '{ min_value: number; max_value: number; type: ApplicationCommandOptionType.String | ApplicationCommandOptionType.Integer | ApplicationCommandOptionType.Number; ... 4 more ...; required?: boolean; } | ... 5 more ... | { ...; }' is not assignable to type 'APIApplicationCommandOption'.
             Type '{ min_value: number; max_value: number; type: ApplicationCommandOptionType.Subcommand | ApplicationCommandOptionType.SubcommandGroup; options?: APIApplicationCommandOption[]; name: string; description: string; required?: boolean; autocomplete?: undefined; }' is not assignable to type 'APIApplicationCommandOption'.
               Type '{ min_value: number; max_value: number; type: ApplicationCommandOptionType.Subcommand | ApplicationCommandOptionType.SubcommandGroup; options?: APIApplicationCommandOption[]; name: string; description: string; required?: boolean; autocomplete?: undefined; }' is not assignable to type 'APIApplicationCommandNumericAutocompleteOptions'.
                 Types of property 'type' are incompatible.
                   Type 'ApplicationCommandOptionType.Subcommand | ApplicationCommandOptionType.SubcommandGroup' is not assignable to type 'ApplicationCommandOptionType.Integer | ApplicationCommandOptionType.Number'.
                     Type 'ApplicationCommandOptionType.Subcommand' is not assignable to type 'ApplicationCommandOptionType.Integer | ApplicationCommandOptionType.Number'.

Code sample
No response
@discordjs/builders version
0.10.0
Node.js version
nodejs: 16.6.1, typescript: 4.5.4
Operating system
No response
Priority this issue should have
High (immediate attention needed)

Expected, conflicting versions of discord-api-types happened :(
We're planning on fixing this very soon!

Hey! Will this be fixed soon?

I think this has already been fixed with the latest PR! Just needs to be published

Oh, then I'm waiting (i really need it );)

Todays release did not fix the issue for me. You were talking about #68?

Yep! Make sure you installed the latest version of builders 👀

Yep! Make sure you installed the latest version of builders 👀

My bad, another non-discordjs related problem popped up.

authors: S222em papsavas pixeldev vladfrangu

repo: discordjs/builders


text:
FEATURE: include tag and category context in search

Previous to this we just included title/body.. tags and category
structure can be very critical for decision making.

thanks @vinothkannans was thinking about this and there are some N+1s here ... not sure how easy it is to fix though ... its all in a background job and most of the time you are waiting for LLM, but maybe I should fix.

repo: discourse/discourse-ai


text:
Running as root user, why?

registry still runs as root user. (as of 2.6.0-rc.1)
"If a service can run without privileges, use USER to change to a non-root user."
https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/user

#34

Please submit a PR.

Closing as wildly outdated.

authors: exdrunmeswt milosgajdos rmoriz stevvooe

repo: distribution/distribution-library-image


text:
Manifest rewrites inaccessible using internal registry API

With the current client API there is no way to access ephemeral manifests generated by e.g. convertSchema2Manifest.
This is because we must retrieve a manifest by tag using two steps; first querying the tag name through TagService to get a descriptor and then using the descriptor to get the actual manifest payload.
The first step ultimately issues a HEAD request to the registry backend. Suppose the manifest behind the tag I'm querying is schema2 and I only support schema1. Then the server will rewrite the schema2 manifest as schema1 and return the digest of the rewritten manifest.
In the second step I issue a GET request with the digest given in the first step. However, since that digest represented an ephermal manifest I get a 404. From what I can tell there is no way to fix this issue aside from registrying support for schema2; I cannot access the rewritten manifest using the client API. Additionally, updating the TagService to not allow rewrites is not an option since rewrites are not allowed to happen in the second step when querying by digest.
In my opinion the following things should be done

There should be a way to go directly from tag to manifest payload
TagService should never return an ephermal digest as there is no way to effectively use this digest and it leads to confusing situations like the code snippet below.

This code demonstrates the problem with the API and the general confusion caused by rewrites
package main

import (
  "context"
  "log"

  "github.com/distribution/distribution/v3/reference"
  "github.com/distribution/distribution/v3/registry/client"
  _ "github.com/distribution/distribution/v3/manifest/schema1"
)

func main() {
  ctx := context.Background()

  baseURL := "http://127.0.0.1:5000"
  repoName := "myrepo"
  tagName := "mytag"

  namedRepo, err := reference.WithName(repoName)
  if err != nil {
    log.Fatalf("failed to parse repo name")
  }

  repo, err := client.NewRepository(namedRepo, baseURL, nil)
  if err != nil {
    log.Fatalf("failed to initialize repository client '%s'", err)
  }

  tagService := repo.Tags(ctx)

  desc, err := tagService.Get(ctx, tagName)
  if err != nil {
    log.Fatalf("failed to retrieve tag descriptor '%s'", err)
  }
  log.Printf("Found tag descriptor '%s'", desc.Digest)

  manifestService, err := repo.Manifests(ctx)
  if err != nil {
    log.Fatalf("failed to get manifest service '%s'", err)
  }

  _, err = manifestService.Get(ctx, desc.Digest)
  if err != nil {
    log.Fatalf("failed to get manifest '%s'", err)
  }
}

2021/04/30 20:07:46 Found tag descriptor 'sha256:233a0e9677a02df6851b2123d33b1b9450bc3b34fe732a89089ba72d348295f5'
2021/04/30 20:07:46 failed to get manifest 'manifest unknown: manifest unknown'
exit status 1

@msg555 Currently, API clients must advertise support for schema 2 manifests if they want to be able to pull them down by tag. The fix here should be ensuring that this client code is properly advertising support. We can't change this API behavior without a major version bump.
There's some weirdness created by hiding this registry access via API behind the mid-level internal storage service interfaces. The main implementation of the tag service works as you've described.

repo: distribution/distribution


text:
Convert backslashes to slashes before passing through XSLT resolve-uri function

Particular fix for #2243
Convert backslashes to slashes before passing through XSLT resolve-uri function

This is a workaround in 2.2 branch and should be reverted from 2.3.

authors: jelovirt raducoravu

repo: dita-ot/dita-ot


text:
Fix MiramoPDF link

Good day!
Would it be possible to change the link for MiramoPDF to point to our website: https://www.miramo.com
(at the moment it points to https://www.miramo.com/english/pdfs/MiramoPDF_DITA_2018.pdf which no longer exists - my bad)
Many thanks!

Thanks for reporting this. 🙏
We prefer to link to a stable URL for a product page when possible, but in the absence of that we can point to the home page as long as the product is mentioned there.
I see that https://www.miramo.com currently redirects to https://www.miramo.com/english/overview/overview.html, but we'll stick with the cleaner URL as suggested in case your site structure changes again.

authors: MiramoPDF infotexture

repo: dita-ot/website


text:
Fix user search bug, add user search functionality (#55)

closes #55
Also fixed javascript typo in users file

attaching a screenshot to help visualize what was added

We are just going to accept #59 when they resolve their conflicts.  Thanks for the pull request and sorry about the duplicate work going on!

authors: SamTheFam codyseibert


text:
Rebase: status incorrect after failure

Trying to perform a change that fails, e.g because it causes a conflict, results in a SUCCESS message even though the change failed.
Reproduction steps:

Commit a change
Commit another change in closely related line.
Try moving the second commit "UP" by hitting u
"STATUS" should not change, but it shows e.g:

Successfully moved 6435b68 up. Undo available.

Nothing else (hash/order) seems to change.

error-log.json.zip

Could you check if #534 has the same issue?

Not in the same manner, see the branch I just pushed: https://github.com/divmain/GitSavvy/tree/pull-request-534-with-560

I can reproduce it. I thought about how to resolve conflicts when manipulating commits, but it requires a lot of work.

I have updated #534, 4095e85 should fix this.

I think rebase view originally allowed conflict resolution, maybe only for
some commands.
Need to test this
On Tue, Nov 8, 2016, 21:32 Randy Lai notifications@github.com wrote:

I have updated #534 https://github.com/divmain/GitSavvy/pull/534,
4095e85
https://github.com/divmain/GitSavvy/commit/4095e85af344aeca74c1b79b5254658914a7cb07
should fix this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/divmain/GitSavvy/issues/560#issuecomment-259251012,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATn8CgoPL0rSRts1QykoDc-a-hAHmUfks5q8NxWgaJpZM4Ksnsa
.

Only the [r] key rebase supports resolving conflicts. All other manipulations does not.

repo: divmain/GitSavvy


text:
Other: implement tests

close #195

The basic testing skeleton is done.
The tests are written using DeferrableTestCase, it allows the runtime yield to UI until a condition is met or pause a certain time after the async calls are begin execuating.
It will be our next tasks to write some tests.
@divmain Please enable travis, appveyor and coveralls for the repo. The above badges are linking to my fork.

What is appveyor.yml?
Looks cool

Appveyor is a CI service for Windows. https://ci.appveyor.com/project/randy3k/gitsavvy

Should we have appveyor and travis?

Travis only supports linux and mac. With appveyor, we provide full coverage for all users. Why not use both?

I think that is cool. I just did not think of it.

Just checked that it works with #556 .

I will definitely write some docs about DeferrableTestCase.

@randy3k I can't wait to get this merged,  I want to add at least a basic assertion of all principal command functionality, for easier detection of misses like I just had on #558

I guess it is ready to be merged. But the tests may need to be rewritten. The examples which I provided are just for illustration purpose. We also need @divmain to enable the CI services.

I created an issue at  Package Control Channel repo https://github.com/wbond/package_control_channel/issues/5942.
I somehow think that we can go for a second option. Create a banche called release where we squash all commit from last release and remove test folder. Then tell Package Control to look at that branch. Still keep all development on  master.

I guess we just need to tag from the release branch, it is not necessary to tell PC to look at that the release branch.

oh yes thats correct 👍

@asfaltboy, when you get a chance, can you mark your review as "Approved" (if you think its ready)?  I'm taking a look also.

As for the style of testing,

the unit tests for core/git_mixins like git status and git add should be easily done
functional tests for core/commands and core/interface are a bit complicated. Especially when the quick panel is involved. It is unclear to me how we could interact with the quick panel. (Can the quick panel be controlled programmatically at all?)

If there are no objections, I would like to push this to GitSavvy/dev or GitSavvy/test to see how it will go.

@randy3k sorry to leave this idle for so long.  I have a strong preference for CircleCI but, honestly, you've done all the work here.  So I consider this ready to merge.  I'll setup Travis as soon as that happens, if you think its ready.

Currently, circleci only has limited support over multiple os. I thing it would be easier to stick with Travis. This should be ready to be merged. You may need to also enable appveyor for the windows platform and coverage.io for the test coverage.

Sounds great.  Thanks again @randy3k!

authors: asfaltboy divmain randy3k stoivo


text:
Update home-manager to 22.11

This commit updates the home-manager flake input to the 22.11 release and creates additional support for the new homeManagerConfiguration setup that is introduced there.
~The new release of home-manager introduces a dependency to numtide/flake-utils, which already exists in deploy-rs. To reduce the amount of different versions, this commit makes the input of deploy-rs follow the respective one of home-manager.~ (see my comment below on why I dropped this)
Regarding homeManagerConfiguration, some arguments that were previously in use, now need to be used inside the new modules argument (check here for more details).
The stateVersion is additionally explicitly defined to be the same as the home-manager's release version, so that existing configurations do not break when they upgrade their home-manager flake input.

The current CI failure is not a result of changes made in this PR. Rebasing now or after #497 should resolve the issue.

#497 is merged.

I have rebased this PR and took @Sohalt's suggestion to keep the stateVersion open to the users. In the meantime, I have also simplified the home-manager configuration in Digga by keeping only the 22.11 version and updated the home-manager input in every example.

I have also simplified the home-manager configuration in Digga by keeping only the 22.11 version

Checks are passing, but let me know if you prefer the previous version, so that Digga users could still use home-manager 22.05 and Digga from the main branch.

authors: Lord-Valen blaggacao jokogr

repo: divnix/digga


text:
🛑 Phillips is down

In 749b581, Phillips (https://www.phillips.com/) was down:

HTTP code: 500
Response time: 319 ms

Resolved: Phillips is back up in f968e91 after 5 minutes.

repo: divtiply/artupptime


text:
🛑 Dixneuf19 website is down

In cf80277, Dixneuf19 website (https://www.dixneuf19.me) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Dixneuf19 website is back up in 759e5b4 after 13 hours, 33 minutes.


text:
Wifi not running until xochitl is launched

As xochitl is disabled and draft enabled at startup, then the Wifi stack is not running !
If I launch Wikipedia (for example), nothing work because it is not able to fetch data, the wifi is not started.
If I launch first xochitl (from draft launcher) then quit (using Menu -> Settings -> Restart), as codex is still running the Wifi stay active, then launch of Wikipedia will be able to fetch data from the web.
Any workaround ? A way to start the Wifi stack from Draft launcher ?

You would need to write a script to set things up on startup by starting wpa_supplicant and send it credentials over dbus.

Thanks for your answer. This is exactly what tarnish/oxide is doing by connecting all spa_supplicant. Draft should do that also ..

Draft doesn't run itself in the background like the tarnish daemon in Oxide. Draft is just a dumb launcher that doesn't know anything about the system other than how to launch applications. I know that @dixonary was going to work on a completely new version of draft that has more features, but I'm not sure if he's had time to do that recently.
I'd be willing to move the wifi management code out of tarnish into a daemon that could be used by other projects if there is enough interest. But that would require a request on the Oxide repo instead of here.

authors: Eeems Julaye

repo: dixonary/draft-reMarkable


text:
Issues with pformat for contexts

When contexts are extremely large, the pformat calls in panels/templates/panel.py can take >15 seconds.
Would you be amenable to a pull request that allows for a setting that would replace pformat with a call to repr (or something similar)?

Yes.

authors: bradshjg tim-schilling


text:
Update changelog.rst

Please review if anything is missing to make a new release

@bmihelac can you review? After adding django 2.0 support and maybe some other PR it would be good to have a new release.

I'll to throught list ASAP

All, I just did an accounting and verified that this PR does include all the PRs merged up through and including #585 on Mar 17, 2017.  Which means all these commits are not yet reflected:
https://github.com/django-import-export/django-import-export/compare/cc61562a54b5e86ea8eface48e8c7c814e616ede...0.5.1
I'm starting on that process now.

OK, I have the rest in #679.

authors: beruic bmihelac manelclos mgrdcm


text:
hi what happen with SMTPRecipientsRefused at /checkout/preview/

check place order then become this error
and i added oscar-resful-api (is this problem??)

Hi there. We use Github only for managing bugs and feature requests, and not for support. We recommend that you ask for help on Stack Overflow using the django-oscar tag, or joining our slack workspace and asking a question there. Thanks.

authors: ojodan solarissmoke

repo: django-oscar/django-oscar


text:
Fixed #33380 -- Prioritize likely user files when watching for file changes in auto-reloader

This is an intial attempt at fixing #33380 by putting the user's project files at the start of all the files returned by iter_modules_and_files
This patch doesn't put only the user's project files first, there are some non-project files that shouldn't get as high a priority as project files, but for now I'm not sure how to filter those out. For example, for my installation of python, most of the project files are put at the very start, but a few files like ...\ProgramData\Anaconda3\DLLs\_socket.pyd also appear near the start. I'm not sure how to fix that.

I think sorting just the file paths returned by iter_modules_and_files won't be enough. I've just noticed that iter_modules_and_files is not returning all of my project files that I was testing it with. Crucially, it didn't return my/project/directory/app2/views.py and my/project/directory/app3/views.py for the test project I had set up.
They were returned later, at the very end, possibly by BaseReloader.watched_files() when it yields from self.extra_files (although I'm not 100% sure about that).
iter_modules_and_files() returned 577 files for the test project, and BaseReloader.snapshot_files() returned 718 files.

@hrushikeshrv Do you have time to keep working on this?

@felixxm I will be happy to work on this starting next week, if that's okay.

@felixxm I've updated the checks to now correctly order by priority, but I can't figure out why tests in gis_tests are failing.

authors: felixxm hrushikeshrv

repo: django/django


text:
Fixed #24369 -- Prevented crash when flushing before db migration

Thanks Thomas Tanner for the report.

If there's no test, I think a comment should be added so the purpose of that check is clear and so there's less of a chance it will be inadvertently removed.

Does that comment make sense?

Yes, I'd omit the comma and probably the ticket # since it doesn't really provide much additional info. Up to you though.

authors: claudep timgraham


text:
Fixed #23718 -- Fixed DB alias TEST['MIRROR'] setting.

Ticket #23718 -> https://code.djangoproject.com/ticket/23718

I have also refactored the tests so I hope it is fine now.

Hi @IlianIliev.
Thanks for the effort here. As it stands this is OK now. I think it's testing what it's meant to be.
My concern is with the mocking. It seems unnecessary here. If we just define a replica alias then we can do without it.
In settings:
    'replica': {
        'ENGINE': 'django.db.backends.sqlite3',
        'TEST': {
            'MIRROR': 'default',
        }
    },

The test in test_runner just becomes:
from django import db

self.assertEqual(db.connections['default'], db.connections['replica'])

This could be a single case in settings_tests.tests.TestDatabaseMirror (just to keep it all together).

The issue with this approach is that it would require updating test settings files (for Jenkins and devs running the test suite) with other DBs.
@timgraham: what's your thought here? Which way would you prefer?

@carltongibson I like the idea, it shouldn't affect other tests performance and will make it much simple and ease the creation of future tests using that feature. I'll wait for Tim to speak up before changing it but if he agrees it should be a quick change on my side.
I am not super familiar with Jenkins so probably there is a reason for that, but why isn't the Jenkins configuration part of this repo?

@timgraham The test in settings_tests is actually to verify that the ORM is behaving correctly if you have two connections that actually share the same connection object. If the settings fix works correctly the connections object should behave in this way, but I understand what you mean and yes the settings_tests is not the correct place for this test.
Do you think that queries is a better place to move this test?
As for how the tests are testing the mirror - as I explained above the one in settings_tests verifies that the behaviour is correct if there are two keys in the connection dictionary pointing to the same connection object.
Then the test in test_runner actually verifies that if the runner is instantiated with the mirror setting it will result in having the "two keys to the same object" behaviour described above.
I understand that it looks a bit confusing and messy but this is because I don't see other way than mocking to modify the connections without messing the connections object for all tests that follow.
Going with the separate replica setting like @carltongibson propose will allows us to avoid the whole mocking part and have only the test in settings_tests to verify the mirror behaviour.

...they pass without the fix...

Hmmm. Well, yes, because we're mocking the connections dict, when the very issue here is that that dict is incorrect. I'm not at all convinced by the mocking: it doesn't seem like we're actually testing what we're claiming to fix.
(Whilst it's a bit of a pain updating the other configs I think adding the replica alias would be better — and the tests would fail without the fix.)

...settings_tests is not the correct place for this test...

This is an issue on TEST['MIRROR'] setting. I'd imagined a single case (in settings_tests) with the following checks:

Optional: create in default and other, fetch single item from default.
Create in default and replica, fetch two items from default.
assert that default and replica have the same connection.

(i.e. the tests here but just all in one place.)
I know at the first two are querying tests, but they're how we know the setting is working as expected.
Happy to accept another approach but that was my thought.

I pushed (rough) edits of the version of this with a new replica alias here.
Without the patch this version fails the new test:

 django.db.utils.OperationalError: database table is locked

Two connections trying to use the same DB table in the same transaction.
In order to go with this we'd need to:

Update the role files for each config in the django-box VM project, rebuild and publish.
Same for Jenkins.
Update the docs on Using another settings file to say "you need three aliases" (etc.)
Possibly, add a (temporary?) check in runtests.py to make sure the alias was defined, and give a helpful message if not.
... anything else...?

I'm happy to do those bits if this is the way to go.
Alternatively we can just move the tests and use the mocking approach, as per Tim's previous comment. I'm not sure it's testing the bug, but maybe it's good enough.

I think https://github.com/django/django/pull/9940 might be sufficient. The ORM tests proposed in settings_tests are testing other areas of code that are probably tested elsewhere. At least, the test in the other PR seems to cover the change in behavior for this fix.

Then this is a documentation issue, or it looks like one:
This passes without any changes:
class TestDatabaseMirror(TransactionTestCase):
    available_apps = ['settings_tests']

    def test_replica_writes_to_default_db(self):
        with transaction.atomic():
            Simple.objects.using('default').create()
        with transaction.atomic():
            Simple.objects.using('replica').create()
        self.assertEqual(Simple.objects.count(), 2)

So a Note saying that you have to do it this way to get the expected results should be enough no?

What @charettes says makes sense to me and in this case @carltongibson is right that this is a documentation issue. We just need to add a note with more details for the behaviour.
But in this case what do you think should be the behaviour of fixtures and any DB interaction during the test setUp?
I'll verify the current behaviour on Monday but I was wondering whether they are/should be executed as an atomic transaction so all data created during the fixtures/setUp is available both in the master DB and the replica.

authors: IlianIliev carltongibson timgraham


text:
Random mode

Hi! Can you explaine how random mode works? It’s generating 3 start points and start check parallel this start 3 points or it’s checks first point until it’s calculated 1billion variants the second point and etc. tnx

More starting points are generated, depends on settings and video card, shows random three

@RastaDollo  For example I have generated 53m points and I have three start points, what’s next ? Thank you

repo: djarumlights/BitCrack


text:
Implement a simple FAQ style

Using the details/summary html5 tags implement a simple accordion based FAQ heading and Body

[x] Define new styles in word
[x] Convert those styles into div.faqHeading and div.faqBody
[ ] Post process those into details and summary tags
[ ] Figure out how to style them properly

Post process
Should have a sequence of

About this task template?

This collection of building blocks is provided for you to reuse, adapt, re-order, discard, and add to when developing a one-....

To convert into

repo: djplaner/word-to-canvas-module


text:
🛑 Writeguard is down

In 6f626b4, Writeguard (https://www.writeguard.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Writeguard is back up in 5b250a4.


text:
Connectivity Issues

From what I've observed, it looks like once someone begins writing a new card, anyone trying to view the board get's "Internal Server Error" until the other user has completed their card.

This was on a private board that I've now made public.  I looked through your issue reports and didn't see anyone else that encountered this issue. Based on that, I'm wondering if the majority of people are using public boards and this issue is specific to private boards. I tested this theory by having people edit cards on our public board and that's working just fine. So it does appear to be specific to private boards.

Didn't mean to close the issue, my bad!

repo: djthread/lucidboard


text:
Issue with Payloads Detail Index out of Range

Looks like it doesn't like something in the payloads index.
2022-05-18 14:19:11 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 137, in _handle_refresh_interval     await self._async_refresh(log_failures=True, scheduled=True)   File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 270, in _async_refresh     update_callback()   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 533, in async_write_ha_state     self._async_write_ha_state()   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 571, in _async_write_ha_state     state = self._stringify_state(available)   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 539, in _stringify_state     if (state := self.state) is None:   File "/config/custom_components/spacex/sensor.py", line 559, in state     self._state = launch_data["payloads_detail"][0]["name"] IndexError: list index out of range
--
Adam

Same here, sometimes just flooding the log:
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 137, in _handle_refresh_interval
    await self._async_refresh(log_failures=True, scheduled=True)
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 270, in _async_refresh
    update_callback()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 533, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 571, in _async_write_ha_state
    state = self._stringify_state(available)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 539, in _stringify_state
    if (state := self.state) is None:
  File "/config/custom_components/spacex/sensor.py", line 559, in state
    self._state = launch_data["payloads_detail"][0]["name"]
IndexError: list index out of range

The value spacex_next_launch_payload (sensor.next_launch_payload) is unavailable. Looking at the API response (https://api.spacexdata.com/v4/launches/next) I see the payload very well undefined:
  "fairings": {
    "reused": null,
    "recovery_attempt": null,
    "recovered": null,
    "ships": []
  },
  "links": {
    "patch": {
      "small": null,
      "large": null
    },
    "reddit": {
      "campaign": null,
      "launch": null,
      "media": null,
      "recovery": null
    },
    "flickr": {
      "small": [],
      "original": []
    },
    "presskit": null,
    "webcast": null,
    "youtube_id": null,
    "article": null,
    "wikipedia": null
  },
  "static_fire_date_utc": null,
  "static_fire_date_unix": null,
  "net": false,
  "window": null,
  "rocket": "5e9d0d95eda69973a809d1ec",
  "success": null,
  "failures": [],
  "details": null,
  "crew": [],
  "ships": [],
  "capsules": [],
  "payloads": [],
  "launchpad": "5e9e4501f509094ba4566f84",
  "flight_number": 165,
  "name": "Transporter-5",
  "date_utc": "2022-05-25T18:27:00.000Z",
  "date_unix": 1653503220,
  "date_local": "2022-05-25T14:27:00-04:00",
  "date_precision": "hour",
  "upcoming": true,
  "cores": [
    {
      "core": "5f57c53d0622a6330279009f",
      "flight": 8,
      "gridfins": true,
      "legs": true,
      "reused": true,
      "landing_attempt": null,
      "landing_success": null,
      "landing_type": null,
      "landpad": null
    }
  ],
  "auto_update": true,
  "tbd": false,
  "launch_library_id": "949421ac-3802-499b-b383-d8274de7e147",
  "id": "6243ae24af52800c6e919258"
}

I guess this needs to be caught in code as SpaceX is not providing this data for each launch. I wonder if there is more values which might be missing and the code path should handle this accordingly.

Looks like it is happening again.
2022-06-20 14:50:50 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 137, in _handle_refresh_interval     await self._async_refresh(log_failures=True, scheduled=True)   File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 270, in _async_refresh     update_callback()   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 533, in async_write_ha_state     self._async_write_ha_state()   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 571, in _async_write_ha_state     state = self._stringify_state(available)   File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 539, in _stringify_state     if (state := self.state) is None:   File "/config/custom_components/spacex/sensor.py", line 559, in state     self._state = launch_data["payloads_detail"][0]["name"] IndexError: list index out of range

authors: adam-olson jensihnow

repo: djtimca/HASpaceX


text:
Add American Chronicle

[X] Project URL: https://github.com/ryanipete/AmericanChronicle
[X] Update contents.json instead of README
[X] One project per pull request
[X] Project added at the end of the list (a script sorts projects automatically)
[X] Avoid iOS or open-source in description as it is assumed
[X] Use this commit title format if applicable: Add app-name by @github-username
[X] Use approved format for your entry

Thx!

authors: dkhamsing ryanipete

repo: dkhamsing/open-source-ios-apps


text:
Bot ignore Azure pipelines failures

Seen in https://github.com/dlang/dmd/pull/11286
It broke HEAD a few weeks ago.
I'm going to go out of a hunch and guess that's because Azure pipeline are Github checks. A way to confirm this theory would be to have an always-failing Github CI check and see if the bot merges.

Yes, dlang-bot is a lot older than the GitHub checks, so yep it isn't even aware of them.

Is this a dupe of #243?

authors: CyberShadow Geod24 wilzbach

repo: dlang/dlang-bot


text:
Resolve playlist of local songs vs spotify streaming

Can spotify player play local songs?
If not, keep them in separate song / playlist models.

closed by pull request #102


text:
Fix docs

Docs are missing some files

The missing files were fixed with PR #40


text:
First shot for pipelling support

@johnhtodd
This PR is a draft to validate the concept of pipelines in configuration.

This seems to be working with no problems - I've put a few tens of millions of queries through it so far.  Testing has not been exhaustive, but other than the Prometheus bug (unrelated to this pipeline support) I'd say it's going well.

Well, perhaps I was a bit premature in my comment.  I tried adding a dnstap output, and that doesn't seem to quite work:
  - name: godnsconnector-next
    dnstap:
      remote-address: 127.0.0.1
      remote-port: 59311

  - name: apple-txt
    dnsmessage:
      matching:
        include:
          dns.qtype: "TXT"
          dns.qname: "^*.apple.com$"
      policy: "drop-unmatched"
    transforms:
      atags:
        tags: [ "TXT:apple" ]
    routes: [ outputfile,godnsconnector-next ]

Adding those lines causes this error:
. . .
INFO: 2023/12/15 22:26:27.808298 [tag-queries] collector=dnsmessage - enabled
panic: main - routing error: stage godnscollector-next doest not exist
goroutine 1 [running]:
main.InitPipelines(0xc000436840?, 0x13ba7b6?, 0xc000415300, 0x0?)
/home/jtodd/go-dnscollector/go-dnscollector-pipeline-branch/go-dnscollector/pipeline.go:156 +0x1474
main.main()
/home/jtodd/go-dnscollector/go-dnscollector-pipeline-branch/go-dnscollector/dnscollector.go:114 +0x508
root@ub20template:/home/jtodd/go-dnscollector/go-dnscollector-pipeline-branch/go-dnscollector#

Well, perhaps I was a bit premature in my comment. I tried adding a dnstap output, and that doesn't seem to quite work:

The panic error should only occur during routing initialization. If a route is missing in the configuration, the application will be stopped.
After copying and pasting your configuration on my end, it's working fine without any panics. Can you confirm if you have this log on startup?
INFO: 2023/12/17 10:48:47.415533 [godnsconnector-next] logger=dnstap - running in background...
I will add more log messages to show the routing initialization process.

Thanks - this was a typo on my part during testing.  Works as expected!

yaml model improved with latest commit
with include/exclude section and more
  - name: apple-txt
    dnsmessage:
      matching:
        include:
          dns.opcode: 0
          dns.length:
            greater-than: 50
          dns.qname:
            file-list: "./testsdata/filtering_keep_domains_regex.txt"
            file-kind: "domain_list"
        exclude:
          dns.qtype: [ "TXT", "MX" ]
          dns.qname:
            - ".*\\.github\\.com$"
            - "^www\\.google\\.com$"
      policy: "drop-unmatched"
    transforms:
      atags:
        tags: [ "TXT:apple", "TXT:google" ]
    routes: [ outputfile, console ]

The new syntax to use:
  - name: apple-txt
    dnsmessage:
      matching:
        include:
          dns.opcode: 0
          dns.length:
            greater-than: 50
          dns.qname:
            match-source: "file://./testsdata/filtering_keep_domains_regex.txt"
            source-kind: "regexp_list"
          dnstap.operation:
            match-source: "http://127.0.0.1/operation.txt"
            source-kind: "string_list"
        exclude:
          dns.qtype: [ "TXT", "MX" ]
          dns.qname:
            - ".*\\.github\\.com$"
            - "^www\\.google\\.com$"
      policy: "drop-unmatched"
    transforms:
      atags:
        tags: [ "TXT:apple", "TXT:google" ]
    routes: [ outputfile, console ]

@johnhtodd
The matching functionality has been extended to support any value in a list, such as dns.resource-records or atags.tags.
For example, to match specific answers only with a TTL greater than 300 and RDATA equal to a list of IPs.
include:
  dns.resource-records.an.*.ttl:
    greater-than: 300
  dns.resource-records.an.*.rdata:
    - "^142\\.250\\.185\\.(196|132)$"
    - "^143\\.251\\.185\\.(196|132)$"

Second example to match a tag at position 0
include:
  atags.tags.0: "TXT:apple"

fantastic - will also try this tomorrow if I can before leaving for family travel.  This is looking very promising!

New syntax for routing definition between stanza /!\ https://github.com/dmachard/go-dnscollector/issues/521
The default key  is used to configure where to send all matched/accepted dns messages.
And the dropped  key can be used to send unmached packets to another stanza in the config.
    routing-policy:
      dropped: [ outputfile ]
      default: [ console ]

authors: dmachard johnhtodd

repo: dmachard/go-dnscollector


text:
Make saturation configurable

As much as I like the visual style of this library, I would like to be able to customize the saturation of the icons so that they will fit the visual scheme of my website better.
It would be great to have saturation be configurable instead of always being 0.5.

That is a great idea! I will think of how this is best implemented and hopefully, this will be included in the next version. Thanks for the suggestion!

No, thank you :)

authors: dalgard dmester

repo: dmester/jdenticon


text:
PR for #6 Add missing unit tests (XWwwFormUrlEncodedEntity)

linking to #6
@dmfs This could be reviewed and merged now, I will create separate PR for other tests.
(Not sure at the moment when I will continue with them.)

Since = and & are special characters in this context, there should be a test to make sure these are properly encoded in values and keys.

Updated XWwwFormUrlEncodedEntity to ignore Entrys with empty keys and added the test cases for = and & as well.
Ready for review.

authors: dmfs lemonboston


text:
New release

Hey @dmitrirussu, could you please release a new version? We're running into issue https://github.com/dmitrirussu/php-sepa-xml-generator/issues/34 (abstract method implementation) which is fixed on master but not available on packagist.
Thanks!

You can use the 1.0.8.x-dev branch release. For example with composer require dmitrirussu/php-sepa-xml-generator 1.0.8.x-dev.

done, Thanks

authors: PhoneixS dmitrirussu mbardelmeijer

repo: dmitrirussu/php-sepa-xml-generator