Enhancement: cache key optimization

EOM uses Redis as a key-value store for several components (Auth, Governor). If the keys include the token (f.e Auth) then they need to be optimized to ensure that they will remain fixed length in order to get maximum performance out of Redis or any future key-value store that may be utilized.

In EOM Auth, a tuple is converted to a string (see https://github.com/racker/eom/blob/master/eom/auth.py#L132). This result just need to be hashed (e.g SHA-1/SHA-256/MD5/etc)


Add AustraliaCapitalTerritory 2017 Family Day.

It seems that most of the time, it is the last Monday of September. Except for 2011 and 2012

you can rebase from master now, sorry for the delay


Cannot install python SDK on Raspbian Linux

Installation is failing on raspbian bookworm.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

After running python -m pip openmeteo-sdk the installation reports success.
Python version: Python 3.11.2
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Collecting openmeteo-sdk
  Using cached https://www.piwheels.org/simple/openmeteo-sdk/openmeteo_sdk-1.8.0-py3-none-any.whl (6.4 kB)
Requirement already satisfied: flatbuffers>=23.0.0 in /ssd/dev/venv/openmeteo/lib/python3.11/site-packages (from openmeteo-sdk)<PHONE_NUMBER>0633)
Installing collected packages: openmeteo-sdk
Successfully installed openmeteo-sdk-1.8.0

Although in site-packages I only have a dist-info directory but no python application files.
drwxr-xr-x  2 pi raspberry 4096 Feb  3 10:45 idna-3.6.dist-info
drwxr-xr-x  3 pi raspberry 4096 Feb  3 10:45 openmeteo_requests
drwxr-xr-x  3 pi raspberry 4096 Feb  3 10:45 openmeteo_requests-1.1.0.dist-info
drwxr-xr-x  3 pi raspberry 4096 Feb  4 12:20 openmeteo_sdk-1.8.0.dist-info  # Only Directory, no openmeteo_sdk directory and files
drwxr-xr-x  5 pi raspberry 4096 Feb  3 22:10 pip

Running through the same process on Ubuntu 20.04 focal and 22.04 jammy works as expected and I can run queries.
Any help would be appreciated.

Hi,
thanks for the report. Unfortunately, I have no clue why openmeteo_sdk is not installing correctly for Raspbian, but openmeteo_requests works correctly. The build process is mostly the same.

As a workaround I've been able to untar the .tar.gz manually and use openmeteo_sdk as a local package. I did notice openmeteo_requests installs correctly into site_packages. I'll provide an update it I find something else out.

I had the same error on my Debian Bullseye raspberry pi.

Missing the package directory
No errors at all while installing using pip on a python3.9 environment
My code errors out in a ModuleNotFound error referencing to the openmeteo_sdk package

I tried to download the archive and install it manually from my project using
cd openmeteo_sdk
pip install . --force-reinstall

Which gave me the same results as before.
I tried to narrow down the cause and I found the the hatch building system one way or another causes this issue.
When I change the pyproject.toml file to use the default setuptools package, the installation goes perfectly and my program works using openmeteo 🥳
This is my pyproject.toml file:
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[project]
name =  "openmeteo_sdk"
version = "1.11.4"
authors = [
    {name = "Patrick Zippenfenig", email =<EMAIL_ADDRESS>]
description = "Open-Meteo Python SDK"
readme = "README.md"
classifiers = [
    "Development Status :: 3 - Alpha",
    "Intended Audience :: Developers",
    "License :: OSI Approved :: MIT License",
    "Programming Language :: Python :: 3 :: Only",
    "Programming Language :: Python :: 3.8",
    "Programming Language :: Python :: 3.9",
    "Programming Language :: Python :: 3.10",
    "Programming Language :: Python :: 3.11"
]
requires-python = ">=3.8.1"
dependencies = [
  "flatbuffers>=24.0.0",
]

[project.urls]
Documentation = "https://github.com/open-meteo/sdk/tree/main#readme"
Source = "https://github.com/open-meteo/sdk"
Tracker = "https://github.com/open-meteo/sdk/issues"

Not sure for this moment to make a PR, I hope some of you guys could test my solution and prove all functionalities (I use only limited openmeteo api) seem to work. And the sdk package seem to use some overhead multiprogramming language system to auto fill package versions etc. Some advice needed on this end.
Kind regards
Hacor

Thanks for the hint about setuptools. IIRC setuptools had another issue with the automated build system and therefore I switched to hatchling. I think the issue was related to the path prefix python/openmeteo_sdk. Is it possible to reproduce the error in Docker?

I made some changes to the python build configuration. Could someone effected by this issue test version 1.14.0? Thanks!

Issue seems to be fixed now!


Installation error

I install anaconda on the server, create and acitvate a virtual environment, but I can't find where is the download files of expert in the environment, what's wrong with my installation pipeline?

Thanks for reaching out. I suppose you've already installed EXPERT using pip, right?
If so, you can find your installation files of EXPERT by pip show expert-mst. If you cannot execute expert command, then I guess you have to add installed pip packages to your system PATH. See here.

Thanks for your replying, I have sovled the problem now.
------------------ 原始邮件 ------------------
发件人: @.>;
发送时间: 2021年12月14日(星期二) 下午2:52
收件人: @.>;
抄送: @.>; @.>;
主题: Re: [HUST-NingKang-Lab/EXPERT] Installation error (Issue #9)
Thanks for reaching out. I suppose you've already installed EXPERT using pip, right?
If so, you can find your installation files of EXPERT by pip show expert-mst. If you cannot execute expert command, then I guess you have to add installed pip packages to your system PATH. See here.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

OKay! Good luck.


BUG :  Displaying Sign In Page While User Is Already Logged In

Describe the bug
after user successfully logged in into the website  the user still access the sign in and sign up page
That user is create a new account or log in with another account still their is logged in
To Reproduce
Steps to reproduce the behavior:

Log in to the website using valid credentials.
After successful login, attempt to access the Sign In page again.
Notice that the Sign In page remains accessible instead of redirecting the user elsewhere.

Expected behavior
A clear and concise description of what you expected to happen.
After the User Logged In Sign in and Sign Up page will not Accessible
Screenshots

Please Assign Me this issue , i want to work on this
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@CoderSwarup okay go ahead


Discussion of Gitea roadmap

@go-gitea/maintainers
After #1029 closed, I think we should make a new plan about next big step. Any idea about that?

A plugin (including theme) solution for extending gitea.

Would it be possible add proper OS packages to the build process? I have been trying to put something together for fedora but go seems kind of a mess to package. #31 kind of talks about this but still seems to be open.

We are using ansible to deploy the tarball on Debian system, this is not very handy but it works. Repositories for the most common distros would be nice, but it needs to be put in place and maintained.

A few suggestions:

Option to automatically integrate Drone CI/CD into Gitea during the build process.
More Site Administration configurability from the Gitea UI, post-install. For example, I'd like to be able to change the stuff in Service Configuration from the Configuration page.
Option to make a user hidden from the Explore page.

Federated pull requests / issues / forks

Federated pull requests / issues / forks

Maybe not federated in the Fediverse sense of the word (ActivityPub, OStatus, diaspora*, etc.) but I would like the ability to interact with remote instances from one's own: fork a project from remote to local as if it had been from local to local, issues, pull requests, etc.
It might also be cool to have teams and organisations made of users from across multiple instances, though that would likely be incredibly difficult to implement.

Two suggestions from the POV of an end user with minimal coding skills who tries to help open source projects I use by reporting bugs and giving UX feedback:

Help standardize ForgeFed! I would love the UX of filing bugs on instance of Gitea (and other community-hosted code forges) to be like one huge, decentralized GH.
Make each part of a project a Git repo, so issues, wiki etc, can be easily pulled from, branched, pushed to, or forked. GL and sr.ht do this with at least some of their components. As well as just being useful, this would potentially help with point 1)

The ability to reply to tickets by email would be a big step forward for usability

Allow the edition of all the config from the UI (and maybe change the config file format on the process)

Maybe store majority of config within database and provide proper cli and api for it

@sapk @tboerger I'd say we should switch to viper for config, that way we could get rid of ini (and some of the bugs we had with it) and get stuff like reloading the config while Gitea is running and proper env variables.

I am for Viper too. I was trying to do it 2 years ago, but had no time to finish it... but I can try it again :)

I'm for getting a more minimal config file... A lot of these settings doesn't need to be set via a static config file and could be easily added to the db and and get cached for performance reasons.

I think we could at first add a database config table and move most changeable config items there from ini file and only left items which need to reload.

@lunny and all: agree moving many settings to the database and letting them be configured in the Web interface (either site wide or repo wide) feels like a good step forward. It would also then be easy to have a tool like tea or gitea itself be able to change those values from the command line, so you could still script a default setup.

Module system sounds great. I believe there are many people out there willing to add new functionality to gitea.

@belliash @sapk IMO plugins/modules cannot be implemented efficiently without refactoring the models package completely and adding more abstraction. I've tested multiple technologies like the native plugin support of Go.
The result was giant binaries which are hard-depended on the Gitea binary.
I think improving webhook support and adding custom pages by webhooks is more realistic to become implemented since we already have a quiet mature API that can be used for database operations.

@jonasfranz I'd be very much in favour of refactoring models to remove a lot of its dependencies.
go list -f  '{{ .Imports }}' code.gitea.io/gitea/models

reveals 98 (!) direct imports. 50 of which are non-go core.
go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

reveals 437 (!!) transitive dependencies. (304 of which are non-go core)

Look at the drone source, there we got a lot of pluggable stuff based on webhooks.
Beside that a plugin model like packer makes sense, a grpc-based plugin system.

@tboerger Can you provide a example from drone's pluggable stuff? Do you mean the plugin system based on docker images?

I'm talking about the extensions for configs, secrets and so on, the interfaces should be defined at https://github.com/drone/drone/tree/master/plugin

I agree with you, Gitea's next big step should be plugin system. I'm also thinking this these days. I will give the plugin system a try.
I think it should be similar with drone's plugin system but have more. We have to allow a plugin have a UI and should login with Gitea's OAuth2 automatically. And we should have some security policy on the plugins. and etc.

I want to share a comparison table we made in circa 2016 to decide which hosting platform to choose for the Open Source Geospatial Foundation. In that table we listed features that were important for us. Gitea is in one of the columns:
https://wiki.osgeo.org/wiki/GitInfrastructureComparison
You will see that an important feature which was missing in 2016 is still missing today: reply-by-mail (comment/reply) --- some others have been implemented as of today.

@strk tool to migrate from github and Comments on diff lines are done.

Need mail template customization
See #6037

So there's quite a bit of template customisation already possible - the subject line is the only thing I don't think we have.
What we really should be doing however is enabling i18n for email and the git serv hook messages.

Reverting a pull request needed.
See #6375

Full support of tags in the UI. Create, assign, change, delete, etc. I really miss this feature.

I am in favor of config in database (with cli or api to configure it, like create user and authentication ldap,etc..) and plugin system.
Those two should push gitea a big step forward.

LFS

[ ] We need some way of managing LFS files in a repository - at present they're totally opaque #7199 is an attempt to provide this - but to be efficient likely needs...

[ ] Bloom filter for blob lookup - it would be very good to have some slightly efficient way of finding the commit and at what tree path that introduced a blob

[ ] At present there is no reliable way of restarting an upload to LFS - so very large uploads can repeatly fail. Implement tus.io as per #1723
[ ] We should provide an option to just use .gitattributes for determining if a file is an LFS pointer rather than just assuming that any file that looks like a pointer is a pointer. Although that is likely to make functionality in  #7199 very difficult...
[ ] LFS files should be viewable in the diff view.

Hardening
Shutdown and the beginning of making Gitea really clusterable

[ ] We need to harden Gitea's response to shutdown.

[ ] This means graceful shutdown of listening connections, particularly the inbuilt SSH - which currently could cause corruption of git repositories through abrupt shutdown. #7274 is a start of an attempt to fix this.
[ ] but also it means that notification like jobs need to be serializable - e.g. indexing queues should through on-disk or db queues, similarly mail queues, etc. We have some of this already but these queues don't gracefully shutdown.

[ ] As a corollary to the above, we should separate the action of indexing from searching. Graceful shutdown requires this in any case - but it's part of the step towards clustering. I'm not certain which architecture we should take but, there are multiple options - separate the indexer out to a separate process & have Gitea read-only the index, or export the whole indexing out.

Diff and Reading data of arbitrary length in to memory

[ ] Diff code needs refactoring - it's fragile, reads the entire diff into memory and requires huge diffs to be parsed by the browser before the user can respond. This requires both UI and server changes - presumably an infinite scroll backed with Ajax is the correct technique for this. At present a sufficiently evil large diff could take down both server and browser.
[ ] Our diff architecture currently pollutes the base repository with pre-merged branches and objects.
[ ] In general we MUST stop just reading data of arbitrary length into memory. If there is a place where the browser might want this - we should limit what we read and then use either an infinite scroll technique or full link with browser rendering or rendered in a pipeline to ensure that it is not buffered entirely in memory. Even relatively new code still suffers from this problem.
[ ] (If we are running a git process which may return arbitrarily long data we should try to avoid reading all of it directly into a stdout buffer entirely but do more go-routine pipelines.)

Merge

[ ] We must refactor merge to use the git index entirely as we currently do a sparse checkout for merging - basically because git merge will drop down to https://git-scm.com/docs/git-merge-one-file to handle non-fast-forward merges. This forces the creation of semi-arbitrary paths on the server - which are unnecessary and dependent on the charset/filesystem factors. It's not necessary to do this - we can do these merges with temporary files, hashing and adding to the index directly.

Escaping and Repository locations

[ ] We must check everywhere for escaping. Legacy Gogs code was poorly escaped in general and has been responsible for multiple security issues.
[ ] The assumption that the username and repository names don't need escaping is forcing an architecture decision on us that we don't need. It didn't even protect us properly for git signatures hence #5774.
[ ] Although it's pleasant for users to have the underlying repository location match the filesystem location - e.g. $GITEA_ROOT/owner/reponame it's a bad architectural decision IMHO and leads to assumptions by users that our repositories can still be used by git on the server without further thought - THEY SHOULD NOT. We should move to $GITEA_ROOT/repository-$ID, possibly sharded. (Doing this would allow the removal of a lot of calls to repo.MustOwner() or repo.GetOwner())

[ ] Once we move to the above and we're escaping everything properly we can then relax constraints on the usernames and repository names - although this would have to be carefully thought about to ensure that we do it in a way that doesn't allow faking through issues similar to #5774.

[ ] We should enforce server git processes to have to run with a sufficient Gitea environment - there are repeated users who try to use Gitea's repositories on the server without going through Gitea so then complain that Gitea is not updated etc. #6961 is a necessary step to this and following the merging of this we simply change https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 to enforce the setting of SSH_ORIGINAL_COMMAND or otherwise enforce that the rest of the standard environment is set.
[ ] We should be able to cope with NO_EXEC mounted repositories - and in fact we should probably recommend this. It's probably not actually difficult to do - simply change the .git/config or the central .gitconfig core.hooksPath variable and think about where we're going to place hooks otherwise.

API / SDK

[ ] It's crazy the amount of work that we have to do to build an API when we go to all the effort to have swagger. We should just autogenerate this from swagger, or autogenerate as much as possible as we can
[ ] We have no way testing a fixed API version against our development Gitea so we can't tell when we're making breaking changes.
[ ] We should be able to use an autogenerated API/SDK to create simple test harnesses

Testing

[ ] We currently run our unit tests at TRACE level - this limits our ability to add proper trace to things. Since https://gitea.com/gitea/log/pulls/3 and if we backport into Gitea we can change this from our makefile.
[ ] Need more Unit tests and consider if some of the integration tests are actually unit and vice versa. e.g. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
[ ] We need more integration tests that try to run through user stories. That is - A user logins, does X, then Y and Z happens. It's fine to test things in isolation eg. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go but that's not really integrated and it misses testing what the user experiences. I keep saying this but more tests should look like: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go and https://github.com/go-gitea/gitea/blob/master/integrations/git_test.go which actually test whether a feature integrates correctly.
[ ] Our testing regime takes too long - CI is taking 30-40 minutes to run at present! We should be running these in parallel.
[ ] There is no easy way to create migration tests.

Go Package Architecture
Models

[ ] code.gitea.io/gitea/models depends on way too many things this has to stop.
[ ] models.x must be destroyed. It's a terrible architectural decision.
[ ] For too many of the models it's way too easy to cause a nil pointer dereference because you don't know what state it is in. Can we use go's typing system a bit better here?
[ ] We should just stick OwnerName in the repository table as every time we get a repository we then have to go and get the Owner. It's silly and a waste of time. Repositories don't change owner very often so the cost of having to handle that is not major.
[ ] Too many things are still done in models and more should be moved out.
[ ] It may make sense to split models into core and non-core.

Modules

[ ] There are essentially two type of modules: those that depend on models and those that models depend on. Let's separate these, one could be called services.

Macaron

[ ] I think we should take seriously the move to gin proposed by @lunny
[ ] Our codebase is splattered with dependencies on macaron this should not be the case

Setting

[ ] Depends on macaron too(!)
[ ] Is tightly linked to go-ini, another dependency we should consider disconnecting ourselves from.

Internationalisation

[ ] EMail not internationalised
[ ] Git messages not internationalised
[ ] Error messages not internationalised
[ ] We should automate stripping out our hugo website documentation so it can be internationalised with CrowdIn
[ ] It's weird that we have the languages using lowercase forms e.g. français, español in the language selector lists - this represents the start of a sentence in each of those languages so AFAICS they should be capitalised. Oui, si j'écris en français j'écris "français", mais si j'écris une liste en pointes de toutes, j'écris:

English
Français
Español

On the UI part, I would suggest to deliver two UI : - one plain HTML (similar to the currentone without js)

a full JS which rely only on API call. This would force to rethink few API but it will also allow more interaction from other external app.

think we should take seriously the move to gin proposed by @lunny

I would suggest go-chi instead of gin.

We should automate stripping out our hugo website documentation so it can be internationalised with CrowdIn

IMHO the website/docs should not be translated at all, it's anyway always outdated...

IMHO the website/docs should not be translated at all, it's anyway always outdated...

But with crowdin, it being outdated would notify people and invalidate the current translations.

Would it be possible add proper OS packages to the build process? I

Perhaps PPA style packages controlled and versioned by the GItea developers would be a good idea, but I'm not a fan of Debian-style "freeze and backport security patches" way of versioning for fast moving projects (such as GItea)

I'd still like to have https://github.com/go-gitea/gitea/issues/3840.
I think it can be implemented with backward-compatibility.
But this will become clear only after the migration of the new routing lib is settled down.
A prerequisite foundational cleanup/refactor would make it easier too.

I'd still like to have #3840.
I think it can be implemented with backward-compatibility.
But this will become clear only after the migration of the new routing lib is settled down.
A prerequisite foundational cleanup/refactor would make it easier too.

In that case it's possible that you will loose Drone support, as it's currently also not implemented for Gitlab.

I'd still like to have #3840.
I think it can be implemented with backward-compatibility.
But this will become clear only after the migration of the new routing lib is settled down.
A prerequisite foundational cleanup/refactor would make it easier too.

We probably don't need this group feature to affect repository urls, we could just make folders that repository could be palced into display but keep repo urls same as it is now

@tboerger
My thought was the URL can remain the same if a repo does not nested in a group/directory.
The URLs need to be "upgraded" only if the repo uses the group/directory feature.
But yes, the repos with the new URLs probably couldn't have Drone support out of the box.
@lafriks
That sounds like a good idea. My use scenario of the feature is to host Git modules or the subprojects of  Repo projects. So, I am not sure it covers that case.
No worries. I am reluctant to make such an extensive, and possibly breaking, change too.

This issue has a lot a good idea and we should keep them and address them.
However, when and how we should choose? This discussion can go on forever.
I would suggest either the owner pick the subjects or a vote between them and members.
What do you think?

@DblK That's right. But I think we could do that after we migrated to gitea.com. Currently we need more feedback from users.

Mercurial support
better sorting and filtering for PR and issues

Mercurial support

No please. It's called "git"ea for a reason.
I understand the desire to have wider scope but
bloat is around the corner...

mercurial import would be an alternative
On July 26, 2019 1:52:50 PM UTC, Sandro Santilli<EMAIL_ADDRESS>wrote:

Mercurial support

No please. It's called "git"ea for a reason.
I understand the desire to have wider scope but
bloat is around the corner...
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/go-gitea/gitea/issues/6998#issuecomment-515461704

Federated pull requests / issues / forks

Maybe not federated in the Fediverse sense of the word (ActivityPub, OStatus, diaspora*, etc.) but I would like the ability to interact with remote instances from one's own implemented in whatever way fits the project best.

There already is some discussion about this in #1612. ForgeFed collect some interesting ideas to get federation into code forges like Gitea. It would be awesome if this would be the next big feature of Gitea!

I'd love a visual diff tool for graphic files (JPEG, PNG, but also PDF), similar to what Github offers.

We have already a PR to diff images

We have already a PR to diff images

True, but that doesn't cover swipe or onion skin preview, only side-by-side. In addition, I don't think it covers PDF files. We're using Gitea here for development of graphic material (including manuals and brochures), and a good visual diff for PDFs would be a life changer.

I have some ideas that I just want to throw out there :smile_cat:

Use Cloud KSM to transparently encrypt/descrypt any secret. This will protect against DB hacked and exposed. The idea is that we can use a custom type with XORM encoding/decoding methods to encrypt the secret data before writing to DB. We made a demo example here: https://github.com/gomodules/ksm-xorm

OIDC Support: Return id_token in addition to oauth2 token when logged in via Gitea

Gitea user profile can show user's profile across any verified Git repo. Example: user can pin Github/Gitlab/BitBuket/Gitea repos. The idea is that users can't ignore the other ones either. So, can gitea be the one global user profile?

Custom domain support for repos (go)

Full compat with Github (I have seen some work on this front, I don't know how much is already done.)

Optional Language server integration. Something like Sourcegraph like navigation built into the UI.

I would like to contribute towards 1 & 2 in short order.

Maybe we can show diff in a form of tree of folders and files that have changed - like in BitBucket, instead of one huge page with all the changes in it. It would be much, much more readable.

Maybe an Option to aggregrate Notifications on all Repositories per day or per week.
Kind of like a summary of last weeks Activities.

Add the possibility to define custom webhooks via custom templates and a pool of standard variables.

Not a Gitea evolution but a side project that would be usefull : #7853

Feature parity with github!
Or, at the very least, an up-to-date list on the wiki, which shows all those features we still need before we achieve parity. This would be a good way to structure future development efforts.

@lonix1 take a look at https://docs.gitea.io/en-us/comparison/ for that list

@kolaente looks like we have almost all the tick marks! yeah!

I think the issue for gists would be https://github.com/go-gitea/gitea/issues/693 (linking as it doesn't seem to be referenced from here yet).

Add also Help documentation, which can be accessed by Help link. The initial source for this documentation can be from GitHub Help, with Gitea-specific modifications.

@bagasme help can not be taken from github, that would be copyright violation. Someone will have to write Gitea help from zero

Creation of issues via email (see GitLab service desk).

If more people start adopting self-hosting for sharing their open-source projects, there needs to be a way for non-registered users to submit issues without having to create an account on each instance (most everyone is extremely unlikely to  register for a bug report).

Something akin to GitLab's AutoDevOps. This means the ability to define a default CI job when no CI yaml file is in the repository.

2a. Container registry UI tab and auth.

Bots
GPG for web commits
Ability to block merges based on conditions
Ability to create file in web UI (including in a blank bare repo)
Manage snippets attached to repo via the UI (see GitLab)
Git protocol v2 support
Improved Web IDE option
Kubernetes integration (via UI plugin a la GitLab)
Add a 400ms delay before a tooltip is displayed on hover
Better CI integration (show pipelines, Concourse support, etc)
Refine UI
Enforce 2FA
File locking
Auto close linked issues with PR merge.

Some kind of plugin / extension system.
Most of the suggestions are good, but they'll create problems in the core codebase.
It would be best to have official (and unofficial) plugins. This would also mean that plugin authors could release more frequently.

@lonix1 Well, git hooks, webhooks and the Swagger API can be considered plugin connect points. I'm all for more plugin support, but stating a list with specifics could help. For example, I'd like support for a command-line equivalent of webhooks.

@guillep2k For example all the project management features discussed above. Those would be very useful - but they probably touch so many parts of the codebase that 1) they might cause issues even for those who don't use those features, and 2) because of that, such development is very slow because those responsible for merging new features know that this scenario is possible, so they are cautious.
If these new features could be released separately, they could be tried by willing users before being merged into the main branch.
And there are other examples of these sort of big new features, just scroll up.

@brandonkal GPG signing of auto generated commits is now possible with the merging of #7631

I guess the roadmap should be divided into those four categories (I added some example issues — it should be obvious that it's far from complete :wink:):
Basic functionality
There are still some basic functions that aren't working properly.
For instance:

it still needs a good search solution as mentioned in issues like #5694 #5277 #3448, #2967, #2434, #8366, #8386 and #7825
the PDF viewer is broken
the SVG viewer is broken

Security
There are also some security issues:

[ ] the Docker image still runs as root
[ ] enforcing 2FA is still not possible

Integration
I guess integration with other applications/services are a good thing in general.
Because software development usually don't just rely on a single tool.
And it will probably help to convince some folk to use Gitea in their workplace.
Those two issues would improve interoperability a lot:

[ ] automatically integrate Drone CI/CD (like @BNolet proposed earlier)
[ ] easy integration with a Container Registry
[ ] a generic webhook solution that allows users to setup custom webhooks easily (like proposed by @bkcsoft earlier)

Also generic webhooks would avoid the need of having other people knowing the internals of gitea. @guillep2k had a wonderful idea that an "external command" integration could be done similar to the generic webhook integration.
:warning: This would probably solve most of the problems on what most people in this issue want as 'plugin support'. :warning:
On-top-features
Furthermore there are obviously some nice features in competing applications (i.e. Git[Hub/Lab]) (most of them are probably rather nice to have):

[ ] Revert PRs
[ ] Improved diff for non-textual things as mentioned by @arthur-bauer
[ ] show more repository details (i.e. repository size, contributors graph, languages bar)
[ ] some wiki improvements (#823 #574)

May be use Oracle Database as option? If it possible technically.

@DemiusAcademius If xorm supports oracle better, I think that's possbile.

More and more people are starting to use Gitea, e.g. also caused by the recent GitLab tracker announcement. But GitHub/GitLab still have the network effect on their side.
Federation would be a big driver to improve the ability to collaborate between users of different Gitea instances and thereby increase the whole Gitea network: #1612

Ability to show large diffs in the UI was reported to be a limiting factor in the adoption of Gitea.
Tickets addressing it: #7341 (feature), #7495 (crasher bug)

That's a huge limitation. IMO everything @alexanderadam listed above pales in comparison to this. If I can't review large diffs by commenting inline in the code, that's a big problem.

W/R/T the anger at Microsoft and Github that caused many projects to migrate and caused high demand for federation--Gitlab has recently proposed banning employees in China and Russia, 2 of the world's largest countries by land mass and economy. The US military has shifted focus to China and Russia (among others) to weaken the barriers they pose to US imperial expansion/interests. Propaganda and financial incentives have brought Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) and even Gitlab into the industries of war, espionage, propaganda and surveillance in an offensive role.
I bring this up to give my thanks to those working on highly available open source remote repositories with few short-comings to the corporate and Pentagon-linked services we use and still rely on now--and to bring to your attention that quickly alternatives are disappearing for those who wish to use the Internet and technology as far away from history's most powerful and hostile empire.
Perhaps the topic is big enough for a separate section of the official website to track progress on this feature, along with a separate fund-raising campaign to capture this demand. Including ForgeFed in the fundraising may be beneficial and fair, seeing their work so far. It's been 17 months to the day since Microsoft bout Github, and I hope in another 17 moths we can be using federated Gitea, or have remaining parts of the 'net worth building on.

Please do not discuss politics here, let's keep to the subject - improving Gitea for everyone

@lafriks Improving Gitea means defining a niche--something unmet by substitute goods. Marketing is the process of finding external opportunities, "political" being 1 of 4 main categories of marketing analysis. A wise brand appeals to people's values equally as much as they deliver features, specs and price. There is a values-based ("political") draw to alternatives like Gitea, and failing to underline and maintain it would be a failure to understand your consumer and the market opportunity.
"Political" as a term has become a thought-terminating cliché, extinguishing discussion of racism, violence and exploitation. I simply came here to thank folks for continuing work on alternatives not associated with US concentration camps, drag-net surveillance and other imperialists interests the majority of our industry is actively aiding in. If you're saying these are not qualities Gitea stands by, I  got you wrong and I'll be leaving.

 Gitea's advantage is its simplicity.

If GitLab.com's transparency offends you, you can self-host GitLab-FOSS. It's an extremely good all-in-one product. But if you want a simple install or require lower memory requirements than GitLab or GitHub Enterprise, Gitea is a good option for the basic web features.

My 2 cents - I think this thread became too long, and it's time to open a new issue summarizing any ideas already expressed here. And close this one.

If you're saying these are not qualities Gitea stands by, I got you wrong and I'll be leaving.

This is not what is being said. What is being said is that this thread is the place for discussing what changes/improvements to Gitea can be made (specifically technical ones). These discussions are more than welcome, but not in this specific thread.
As one of the leads I will be locking this thread, as @XVilka said it right, we have solicited a lot of feedback, and it should now be evaluated for next steps.

Close as we have a plan for every release.


Write up a report / summary with feedback for mypyc

Mypyc is still alpha software (which is funny given I'm trying to integrate it with "beta" software) so there's a lot of rough edges. Now they aren't that hard to workaround but it would be great if I didn't need to do 'em in the first place. So to be a helpful user of mypyc and help push it forward, let's write some sort document containing feedback, suggestions, other things we noticed.
What follows is a draft ...

First of all, here's the relevant links:

Development branch: https://github.com/psf/black/compare/main...mypyc-support-pt2 (contains crash workarounds, optimizations, and QOL improvements) - https://github.com/psf/black/pull/2431
Wheel building workflow + other infra + project management homebase: https://github.com/ichard26/black-mypyc-wheels
Relevant issue on the psf/black repository: https://github.com/psf/black/issues/366
Performance report: https://gist.github.com/ichard26/b996ccf410422b44fcd80fb158e05b0d

The good

The performance wins are excellent: ~2x average across multiple workloads!
As long as the hot code wasn't too spread out, optimizing for mypyc wasn't that hard (tightening up types, adding lots of Final, etc.) - additional performance wins of 5-15% were achieved :D
There weren't actually that many crashes or other incompatibilities (ignoring dataclasses) and they all had easy enough workaround
Wheel building was pretty easy and straightforward (once some changes were made to the setup.py logic) - I did steal lots of ideas from mypyc/mypy_mypyc-wheels :P

The bad

Dataclasses were responsible for the majority of crashes and other compatibility issues. The cases that led to issues include:

an dataclass that is also subclassing ast.NodeVisitor crashes with AttributeError: attribute 'dict' of 'type' objects is not writable (maybe not fixable?)
an dataclass inheriting from Generic (already reported in https://github.com/mypyc/mypyc/issues/827)
abc.ABC + dataclass crashes too

Unanalyzed or unreachable code continues to be problematic - a "fun" case involved this:>   if sys.platform == "win32":
RuntimeError: Reached allegedly unreachable code!

This was caused by mypy.ini hard-coding platform=linux. Other interesting case was one involving a module typed as Any causing an else branch to appears as it's never ever taken. The resulting unanalyzed code crashed when hit. More details in this commit: https://github.com/psf/black/commit/acb77f7951229b2670edc3fad366ec256fa0c86f

And other various issues already reported on the mypyc issue tracker:

https://github.com/mypyc/mypyc/issues/885
https://github.com/mypyc/mypyc/issues/884
https://github.com/mypyc/mypyc/issues/864
https://github.com/mypyc/mypyc/issues/862
https://github.com/mypyc/mypyc/issues/819 bit us too :(

Suggestions

Add a note about platform=$OS being problematic
Add a note about docstrings being stripped - the click CLI toolkit uses docstrings to get command descriptions ... which ended breaking without a clear reason why (until I stumbled on some issue on mypyc issue tracker that explained why :p)
Prioritize https://github.com/mypyc/mypyc/issues/849 - while I'm OK with wheel sizes going up adding mypyc, the ~25-35x (120KB -> ~3.3MB) I observed wasn't the easiest thing to swallow. Adding CFLAGS=-g0 brought the wheels to a much more reasonable ~1MB each.
Prioritize https://github.com/python/mypy/pull/10395 - quick iteration and experimentation was slowed down by repeated cleaning up + python -c "import foo"
Perhaps add a way to skip invoking the C extension build - this would make analyzing differences at the IR or C level faster ... although I would understand if this is too low-level and shouldn't be made easier

Questions

Can anything be done about analysis + Python-to-C transcompilation being done twice during any modern wheel build? Unfortunately any evaluations of setup.py end up triggering the above and it turns out both pip wheel and python -m build call at-least two PEP 517 hooks that eventually end up evaluating setup.py. It's not a big deal, but it slows down wheel builds a little bit. Sounds hard to avoid tho (caching would be complicated).
What else can we do to help mypyc mature and overall get better?

What's next?
Currently the stability and performance data for Linux were just collected and look good so a PR was opened against psf/black. There's a lot of TODOs listed in that PR but it is progress.
The main thing is that I need to do is getting the wheels significantly more battle tested so they can eventually find their way to PyPI. First of all I need to run a mypy-primer equivalent on Windows and MacOS. Assuming that doesn't turn up anything scary, the PR will probably get merged once the reviews are over with. Then at that point, it's off to community testing where we'll be asking members of the community to use the experimental wheels and report issues. So expect updates on this issue as more stability data comes in ... but I'm sure this is already enough insights for a post ^^
Finally
As much as this is riddled with negativity and bugs, I appreciate all of the work y'all put into mypyc. It's awesome to see so much work into making Python code faster lately! :black_heart:

Whelp, I just posted the above: https://github.com/mypyc/mypyc/issues/886. I plan to update it as more data comes in from testing, but it's a good start.

This is done. Further updates will come in blog posts.


Add check to SendPaymentLocal

Fix panic. Feel free to land this while I'm out.

FYI Jenkins failed because I was experimenting with Windows agent machines.

skipping CI. I hear it's dead


count bases on spark

small example on spark

One comment to be addressed then this can be merged.


Clarify license situation

As discussed I'm trying to bring this in line with the OGL. In particular:

Avoid claiming compatibility with any particular game.
Actually include the OGL as well as the required declaration using the language from the OGL itself.
Add our own copyright notice at the end of the OGL.
Organizing the folders to make it a bit clearer what is Open Game Content under OGL and what is software under MIT.

I also decided to:

Designate our cards again as Open Game Content.

The last step is not required by OGL, but since we mostly just consume Open Game Content from upstream, it feels fair to designate the small changes wer are doing as Open Game Content again for possible downstream consumption.
@skaldarnar @fkz please confirm that you are are ok with designating our work on the cards as Open Game Content (for example, by approving this pull request).

Hm, so I'm slightly confused about the following: Do we also license the software part under the cards directory under MIT license?

I agree to designate my work on the cards themselves as Open Game Content under OGL.

Hm, so I'm slightly confused about the following: Do we also license the software part under the cards directory under MIT license?

My intention was not to do that, because OGL says it wants to be the only license. Maybe to clarify this even more, we should have the *.cls file also in subdirectory, and the main *.tex file in cards. I would prefer doing this in a follow up though.

Hm, so I'm slightly confused about the following: Do we also license the software part under the cards directory under MIT license?
My intention was not to do that, because OGL says it wants to be the only license.

From my perspective, we could say that the Open Game Content in cards/* is licensed under OGL and the source code in cards/* is licensed under a variant of MIT where people also have to follow the OGL in so far as the source code contains open game content. But I don't know how to phrase that exactly, and I think there would not be much of MIT left.


quit_on_error Flag

@carlsondev Sorry for the messy commit history, I branched from main I guess I let the examples history leak.
I added this since I realized the generator would not get closed once it failed so it would loop forever

Pylint passes locally for me, the error is from installing idk whats up

Pylint passes locally for me, the error is from installing idk whats up

I had this issue recently with mypy. If you look at the log for the specific action and it says there were connection issues (that is what happened here) then you can rerun the job (top right corner) and it should pass (assuming there are actually no formatting errors)


--location issue

Python 3.7
Command Ran
twint -s "Inondation" --since 2018-01-22 --until 2018-02-07 -o CRP_Inondation.csv --csv
Description of Issue
Hi, I'm using Twint for research and I'm using --location to obtain geotagged information for making maps. It's been something like a week that using --location makes my terminal bugged while running the same command without --location works perfectly.
Environment Details
Mac OS 10.12.6 Terminal
Thank you for your help !

It's true. I encounter this issue as well. It works smoothly without --location.

Yes, facing the same issue. It is been a week since --location is not working in twint.

Same on Windows if it makes a difference

I am also experiencing the same issue ... with the location option set to true, NO tweets are scraped

been same for me for last two weeks!

Hi, any improvements for anyone ? I'm still stuck with nothing happening while using --location.
Btw, before it breaks, I didn't have any return when I tried to extract locations' informations before 2013.
Is someone experiencing the same issue ?
Thanks


performance resvg is slower than inkscape on specific image

I wanted to render https://commons.wikimedia.org/wiki/File:Coat_of_arms_of_Venezuela.svg
resvg-time: 5.7sec
inkscape-time: 1.2sec
usvg-time: 0.2 sec
SVG

license: Public Domain
source https://commons.wikimedia.org/wiki/File:Coat_of_arms_of_Venezuela.svg

I wanted to render https://commons.wikimedia.org/wiki/File:Coat_of_arms_of_Honduras.svg
resvg-time: 1.0 sec
inkscape-time: 0.5 sec
usvg-time: 0.1 sec
SVG

license: Public Domain
source https://commons.wikimedia.org/wiki/File:Coat_of_arms_of_Honduras.svg

Performance issues are not bugs. resvg doesn't really claim to be fast. It's all about correctness.
Those files have thousands of layers + blur filters. 5s is a pretty damn good result for that.
The main issue here is the way resvg handles layers with opacity (spoiler: badly). This would be addressed in the future, but requires a significant renderer rewrite.

I have rewrote the renderer, which I planned to do for a very long time.
Coat_of_arms_of_Venezuela.svg should be rendered 35 times faster. Yes, you're reading this right - 35x faster.
Coat_of_arms_of_Honduras.svg should be 8x faster.
It's still not ready for a release. It was a nearly a complete rewrite, and even despite the fact we have thousands of tests, there are still some minor bugs I'm finding on real world file.
If you would have time, I would appreciate if you test it on some of your SVGs. Just git clone + cargo build --release. Thanks.


yt-desc refactor

Standardised the Video Object, and fixed the issue for supporting non-canonical urls.

Fantastic, thank you @dipamsen!


FEATURE: add the possibility to edit the relatedIdentifier (oai) with metadata interface.

Datacite now contains a relatedIdentifer (see: #74) for the Tables. The latter is however set to be the DOI of the containing schema.
It exists some cases where tables should not relate to their schema. ex:  starhorse in gaiadr2_contrib should relate to gaiadr2.
It would be very useful to be able to edit the relatedIdentifier via some Json entry.
We have decided (@harenk, @jochenklar and @agy-why) that this field could be set via a metadata: relatedIdentifer. In the form of a JSON entry (like contributors).
It could also be useful to add the same feature for Schemas. Usecase would be to relate all data release to each other.

After discussion we decided not to implement the front-end interface for this entry and only maintain the edition via REST API.
Therefore, after discussion with @jochenklar, there are just two places to edit:

The models: https://github.com/django-daiquiri/daiquiri/blob/master/daiquiri/metadata/models.py
The Serializers: https://github.com/django-daiquiri/daiquiri/blob/master/daiquiri/metadata/serializers/init.py

Note: since the model are changed a migration is necessary for deployment.

After the mentioned modification the metadata are properly created in the database: public.daiquiri_metadata_table/schema however it does not appear in the yaml files returned by the REST API.

This is how the datacite oai interface should deliver for:
related_identifiers = [{'related_identifier': '10.17876/gaia/edr.3',
                        'related_identifier_type': 'DOI',
                        'relation_type': 'IsPartOf'},
                        ...
]

<relatedIdentifiers>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsPartOf">10.17876/gaia/edr.3</relatedIdentifier>
    ...
</relatedIdentifiers>

This kind of JSON field can be easily integrated by adding a daiquiri.core.serializers.JSONListField in the DataciteSerializer (see: contributors and creators for examples) in https://github.com/django-daiquiri/daiquiri/blob/master/daiquiri/metadata/serializers/datacite.py

PR: #77

Possible values for relatedIdentifierType:

ARK
arXiv
bibcode
DOI
EAN13
EISSN
Handle
IGSN
ISBN
ISSN
ISTC
LISSN
LSID
PMID
PURL
UPC
URL
URN
w3id

Possible values for relationType:

IsCitedBy
Cites
IsSupplementTo
IsSupplementedBy


Documentation: Show more displayed even if no more lines

Can we determine if 'show more' is unnecessary?

https://www.nuget.org/packages/Knapcode.TorSharp
I have never added documentation to this package.

IMO,

The "Documentation" should not be shown if it does not exist for a package.
If documentation exists, the "Show more" should appear only if there is something to show more :)

How do i add documentation under this section?

@magol, if you are the owner of the package, you can click on the "Edit package" link:

On this edit page, scroll down to the Import Documentation heading:

Split into two issues: 1. Hide the "Documentation" section - https://github.com/NuGet/NuGetGallery/issues/5184
2. This issue to fix the "show more"

close it since it will be handled by new design of display package


Adding powershell and guidelines validation

Was just browsing around github a little now, and found the PSScriptAnalyzer.
I'm thinking this software could perhaps be used when validation Pull Requests (and none master branches perhaps), and since it looks like it can accept custom rules it probably can be extended to validate the guidelines for this repository (custom logic for the metadata would probably still be needed though, but it's a start).
I've not tested it out just yet though.
Thoughts?
/cc @gep13 @majkinetor @ferventcoder @pascalberger

I am OK with that as long as it is informative only. I wouldn't like, at least for the time being, to have have it blocking something (such as alias usage or non-verb named functions).  There are number of things that I disagree with with all analysers and if they are too intrusive I totally disable them.

And since it looks like it can accept custom rules it probably can be extended to validate the guidelines for this repository

I very much doubt that. There are only 2 Powershell code guides. All others would require dedicated system . For example 1.1.4 would require to have a list of licenses that allow redistribution, check if one of those licenses is set in nuspec, check if remote file sizes are lower then 150MB and only then complain about broken rule.
I am not sure that value of having guidelines check now justifies it development, at least not while we have only 2 active maintainers.

Integrating PSScriptAnalyzer would be nice (I already use it locally in Visual Studio Code through PowerShell Language Support for Visual Studio Code).
The tricky part might be how to provide the analyzing results back to the pull request. Having them posted back as comments would be nice, but AppVeyor doesn't support secret variables in pull request builds. Using a public token with a very limited scope (only permission to write comments) might be a solution.
For the part of posting the comments I have written a Cake Addin, which could be enhanced to support PSScriptAnalyzer and GitHub, but it would require to use Cake for the build.

Pester tests would seem like a better fit for some of the logic and testing of pull requests and this was something I was going to look at doing a little while ago and didn't get around to, for testing packages locally. PSScriptAnalyzer would be a good fit for testing rules on the scripts themselves such as testing for using deprecated functions etc.
As I was all set to also do a blog posts in the coming weeks on rolling your own PSScriptAnalzer rules I'm happy to pick this up but have not done any integration with Appveyor / Pull Requests so would need guidance there.

I agree that Pester seems like way better solution for guideliness check then PSScriptAnalyzer. Pester script with adequate arguments could be easily hooked into AU update process.

I will close this as there seem to be no more activity. If you feel there is more to be said, please reopen.


multiprocessing.Pool workers hold on to response body

In our app, we make use of pull task queues, and we pull large number of tasks with large bodies (e.g. ~5 MB of payloads). I noticed that it appeared we had a memory leak when running this in the python-compat runtime, with many megabytes of strings being retained. With a whole lot of hacking, I ended up tracking it down to the following:

Multiprocessing pool workers hold on to the result objects in their local variables until they get another work item.
The pool has 100 threads in the python-compat environment. This means it can retain up to ~100 items.
The requests.Response is the result type that gets cached, and it stores the body of the response.

My hack to fix it: in google/appengine/ext/vmruntime/vmstub.py, I set response._content = None right after the response protocol buffer message is parsed. This caused our process to use ~100 MB of memory, instead of ~400 MB of memory.
Hacky output from my tool that found the large strings that were being retained, showing what is holding on to it:
found new string! len=4653338
referred by<PHONE_NUMBER>97608 <type 'dict'>
-referred by<PHONE_NUMBER>40816 <class 'requests_nologs.models.Response'>
--referred by<PHONE_NUMBER>78120 <type 'tuple'>
---referred by frame /usr/lib/python2.7/multiprocessing/pool.py 102 worker
---referred by frame /usr/lib/python2.7/multiprocessing/pool.py 380 _handle_results

Thank you for your bug report!
@bryanmau1 can you take a look? This seems big enough to be a beta blocker.

FWIW: Something similar to this issue may exist in the standard environment as well. This same service increases from ~70 MB memory up to a "steady state" of ~170 MB over a few hours when we restart it. I tried running it in the flexible environment so I could try to trace if there was an actual leak. I couldn't find anything other than this issue. There is an issue report from ~2 years ago suggesting that others have observed high memory usage for big RPCs: https://code.google.com/p/googleappengine/issues/detail?id=10475

I am running into something similar (but with worker instead of _handle_results)...(still investigating the source of my Pool though)
I believe this change should fix the underlying CPython bug: https://github.com/python/cpython/commit/5084ff7ddfe68969d95af12075016f309718aea8
Unfortunately the latest CPython 2.7.13 was released five months prior to this fix. According to the release schedule, 2.7.14 will come in mid 2017.
"Unfortunately", GCE's python-compat is on debian stable (jessie), which is still running 2.7.9. So it'll likely be a long time until GCE is running debian stretch (which is currently 2.7.13, and may or may not include 2.7.14)...
I suppose the easiest option would be to have our Dockerfile to overwrite /usr/lib/python2.7/multiprocessing/Pool.py with our own patched version, though.

And if I understand things right, that's MAX_CONCURRENT_API_CALLS=100 threads per worker, and there are up to 100 workers in Flexible VM worker pools (according to the default gunicorn.conf.py).
(Correct me if I'm wrong here!) Gunicorn appears to re-use workers when possible, but the API Call threadpool appears to distribute load randomly across all blocked threads. So in high load situations, you'd quickly get 100*100=10K Response objects sitting around...

Updating the Python runtimes to cPython 2.7.13 is on my todo list.  We can cherry-pick particular patches from upstream.

FWIW this bug still manifests even outside python-compat and vmstub.py, just to a lesser extent (since it's 100 instead of 100*100).
But just to follow-up: adding in the fixed multiprocessing/pool.py appears to have significantly helped my memory issues.
Previously I would inch up to 100% memory usage within 24 hours (+0.3GB/hour), and then eventually swap-slowly, crash, and restart. Now it seems to be consistently hovering around 27%.


Experiment: visualize activity over time

Might cause recollection of 'this has gone on forever' or 'this is causing a heated debate'.
Try:

[ ] Sparklines
[ ] Heatmap, or just a gauge/thermometer

Make sure it doesn't clutter the GUI.

No, feature creep.


Merge translation files from assisted-ui-lib into one file

Related to https://github.com/openshift-assisted/assisted-ui-lib/pull/1399/
Related to https://issues.redhat.com/browse/MGMT-8156
Signed-off-by: Montse Ortega<EMAIL_ADDRESS>

@ammont82 Is this a work in progress? I have some questions and potentially some changes to request once it is ready for review.

/ok-to-test

/lgtm


absolute vs relative paths within templates using publicPaths

I'm submitting a ...  (check one with "x")
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[x ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior
Although another issue was closed stating that we could set the publicPaths to "/assets/", but it still does not allow for absolute paths for use in templates ex. using /assets/img/logo.png. Although no errors are shown, the "logo.png" files does not get placed into the public/assets folder.
  "publicPaths": {     "assets": "/assets/",     "images": "img",     "fonts": "fonts"   },
Expected/desired behavior
To be able to use "/assets/img/logo.png" when publicPaths.assets = "/assets/"
Minimal reproduction of the problem with instructions

clone a vanilla instance of repo
add a image named logo.png to src/client/assets/img/
modify header.component.html to include <img src="/assets/img/logo.png" />
modify the "publicPaths" within build-config.json to:
  "publicPaths": {  "assets": "/assets/",  "images": "img",  "fonts": "fonts" },

What is the motivation / use case for changing the behavior?
to be able to use absolute paths within templates
Environment

Angular version: 6.0.0-beta.6

Browser:

[x ] Chrome (desktop) version XX
[x] Chrome (Android) version XX
[ ] Chrome (iOS) version XX
[ ] Firefox version XX
[ ] Safari (desktop) version XX
[ ] Safari (iOS) version XX
[ ] IE version XX
[ ] Edge version XX

For Tooling issues:

Node version: 8.11.1
Platform:  Windows

Others:
all vanilla clone as instructed on the main readme

#507


Fix bug when editing any IOU information the date is automatically reduced by one

Details

When the user edits any information on the Money Request details page, the date is decreased by one because it creates a new Date object using the user's timezone.
This PR has the changes below to solve this issue:

Create a new method formatWithUTCTimeZone in the DateUtils to format the date using the UTC timezone.
Change the method getCreated in the TransactionUtils to use the method formatWithUTCTimeZone to format the created date properly.

Fixed Issues

$ https://github.com/Expensify/App/issues/30303
PROPOSAL: https://github.com/Expensify/App/issues/30303#issuecomment-1778281648
Tests

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Amount - Cash", update the value, and click on the Save button.
A message will be shown with the information about this change

[x] Ensure that the "Date" information was not changed

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Description", update the value, and click on the Save button.
A message will be shown with the information about this change

[x] Ensure that the "Date" information was not changed

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Merchant", update the value, and click on the Save button.
A message will be shown with the information about this change

[x] Ensure that the "Date" information was not changed

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Date", update the value, and click on the Save button.
A message will be shown with the information about this change

[x] Ensure that the "Date" information was changed with the selected value

Offline tests

Open a chat with a regular user
Create a Money request
Open the details page of the report
Switch to offline mode
Click on the "Description", update the value, and click on the Save button.
A message will be shown with the information about this change

[x] Ensure that the "Date" information was not changed

QA Steps

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Amount - Cash", update the value, and click on the Save button.
A message will be shown with the information about this change

[ ] Ensure that the "Date" information was not changed

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Description", update the value, and click on the Save button.
A message will be shown with the information about this change

[ ] Ensure that the "Date" information was not changed

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Merchant", update the value, and click on the Save button.
A message will be shown with the information about this change

[ ] Ensure that the "Date" information was not changed

Open a chat with a regular user
Create a Money request
Open the details page of the report
Click on the "Date", update the value, and click on the Save button.
A message will be shown with the information about this change

[ ] Ensure that the "Date" information was changed with the selected value

Open a chat with a regular user
Create a Money request
Open the details page of the report
Switch to offline mode
Click on the "Description", update the value, and click on the Save button.
A message will be shown with the information about this change

[ ] Ensure that the "Date" information was not changed

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/698363/f3278513-e3c7-4f8d-b6aa-a5dc25954659

Android: mWeb Chrome
https://github.com/Expensify/App/assets/698363/304859a2-7cfd-4898-b09b-c692cd1ea9fe

iOS: Native
https://github.com/Expensify/App/assets/698363/0a42104a-637c-458a-a639-0afb3f779f26

iOS: mWeb Safari
https://github.com/Expensify/App/assets/698363/d63029bb-1206-4c05-aa9f-45638f78ad15

MacOS: Chrome / Safari
Chrome:
https://github.com/Expensify/App/assets/698363/bbcc984f-0371-42f4-af8b-61ee41b1c512
Safari:
https://github.com/Expensify/App/assets/698363/6916f7d7-5f54-4c5f-bbe1-c1975b385b29

MacOS: Desktop
https://github.com/Expensify/App/assets/698363/92757550-9d8c-4928-a60c-0c0b46522268

Unit Tests
DateUtils unit tests:

TransactionUtils unit tests:

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/28352309/a78e3a7a-cf5d-4a9a-a38c-510ad0e2f874

Mobile Web - Chrome
https://github.com/Expensify/App/assets/28352309/695772a1-f0b7-4582-adea-b6d16cbdbc9b

Mobile Web - Safari
https://github.com/Expensify/App/assets/28352309/95f25303-249e-48fa-aed9-27e4174e6190

Desktop
https://github.com/Expensify/App/assets/28352309/059c08dc-669c-49e0-8917-0fd2d8fecb5e

iOS
https://github.com/Expensify/App/assets/28352309/4ad425ea-ec56-44b0-bc47-8baaebc66d3c

Android
https://github.com/Expensify/App/assets/28352309/e6703f98-b145-4090-b847-c86e6fd89b4d

Hi @narefyev91 do we need another approval to merge this PR?

Hi @narefyev91 do we need another approval to merge this PR?

Yes we need @techievivek to put final approval

Hi @narefyev91 do we need another approval to merge this PR?

Yes we need @techievivek to put final approval

Ok, I saw the information that needs just one approval, I thought maybe I need to do something, thank you for clarifying.
Hi @techievivek if you have any questions or suggestions, please let me know.

Sorry for the delay in review, @wlegolas. We now have conflicts in the imports section. Can you please take a look and resolve them, thanks.

Sorry for the delay in review, @wlegolas. We now have conflicts in the imports section. Can you please take a look and resolve them, thanks.

Hi @techievivek
Thank you for reviewing my PR, I solved all conflicts, could you take another review, please?

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/techievivek in version: 1.3.94-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/techievivek in version: 1.3.94-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.94-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/techievivek in version: 1.3.95-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.95-9 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Get estimates for Atonomi transactions

Create script to output gas estimations for all transactions to feed into financial models

Registration
Activation
Reputation
Add Admin
Add Manufacturer

Create node script that can be executed in a geth console
> loadScript("scripts/estimateGas.js")

When you get back, lets reprioritize this as well.

create a gas.estimates.test.js
similar to how you extracted each estimate, just create a test for each estimate and print it out as the test
example:

describe('manufacturer costs') {
     // compute gas
     it('registerDevice() = ${gas}') { /* empty test */ }
}

completed with previous commit


testMultispaceWorkspace is failing

https://vscode-python.visualstudio.com/VSCode-Python/_build/results?buildId=3895

Closing as a red herring


Fix analyze to tab separate data

Because method names include arg lists, which have commas, we can't
directly use CSV as an external format. Attempts to quote method name
field per RFC4180 didn't work with excel.
So, use tab separation. To get this into excel you need to do a text
import and specify tabs as separators.
Also add RC2-compilant xprojs so you can work with these projects in
VS2015.

@russellhadley PTAL

LGTM


Translate docs/contribute/participate/ into Japanese

This is a Feature Request

What would you like to be added

Translate docs/contribute/participate/ into Japanese
Why is this needed
This page has not been translated.
Comments

/language ja
/assign

/triage accepted


Setup standard logging and Sentry reporting

Done with https://github.com/tereus-project/tereus-api/commit/365dca826bc1e87351c6647cfacb6f37d5d84727


[change] yaml_list: sort yaml, key and encoding

Motivation for changes:

Sort yaml output: To make it more readble, the output is sorted by keys, but keeps title and key fields on the top
yaml encoding: Allow to inform the file encoding, making it usable in other languages
key field: allow to make lists with a key different from title

Detailed changes:

Sort yaml output: sort the fields and add title and key to the top, add sort_keys FALSE to the yaml_dump
yaml encoding: add encoding to the config, default utf-8 and add that encoding to the yaml_dump
key field: add key field to the config and map that key in the list

How exactly might the key option be used?

The key is what would decide if a entry is new or not!
In the entry_list a very useful functionality is the update of fields with a new entry, this was not the case here! A duplicate entries would be discarded. Based on feedback I noticed that this would be a useful thing to have, so I added the update. While doing that I noticed that managing the key would be useful, to, for example, if you have a list of series, they would be useful to make unique based on the id, and not the title.

In the entry_list a very useful functionality is the update of fields with a new entry, this was not the case here! A duplicate entries would be discarded. Based on feedback I noticed that this would be a useful thing to have, so I added the update. While doing that I noticed that managing the key would be useful, to, for example, if you have a list of series, they would be useful to make unique based on the id, and not the title.

Hmm, making this more similarly to entry_list I think is good, so doing an update rather than discarding sounds good to me. The second bit I'm not so sure of. The rest of flexget is considering entries unique based on their title and url, I'm not so sure it should change here.

The main reason is that this list will be managed by user's directly outside of flexget, that's the main use case! And when they do that, having a title that's not very user friendly only to be matched, it's not very intuitive! So the ideia was to keep the title as useful as possible, so that the user knows what he's missing with!
But for me the main changes are the file encoding (that is making this unusable) and the update!
So if you what me to remove the key to be pushed, I'll do it!

I'm not sure I'm against the 'key' thing, but separating out more bugfixy things from new features definitely makes merging faster/easier. Encoding in utf-8 (with optional override), and updating existing items are definitely 👍 from me.

I kinda think it makes sense to let the user decide (title is default) what the key is! Probably not in all the list, but since this is managed outside flexget, it kinda makes sense to let the user have that control if he needs it!
The example of the serie for me is the best! I don't care the name of the serie or if it's translation or not! I would map it by tmdb Id or trakt id. The title would be what ever I like it to be

Like I said, I'm not necessarily against it, but putting a bunch of separate changes into one PR makes it much tougher to review and get the more critical changes merged in a timely manner. I still have to think about the implications of how the 'key' feature would work, and I'm not convinced on the naming of that option either. I'd like that discussion to be in a separate PR than the other changes though. Generally, the more separate smaller PRs that can be made the easier it is to decide. (I know it can be tough when you want to do multiple changes to the same plugin though, due to merging issues if you work on the separate branches at the same time.)

Ok, @gazpachoking I'll split it!

Key is also quite ambiguous term, we have talked making some sort of unique content identifier probably close to a decade by now :D

I updated the PR to remove the key from the config... If you ask me, this should be added to all the lists, probably in the interface

Possibly, but we have other parts of the code that already expect, or require titles/urls to be unique. (Most notably seen plugin, which is enabled by default.) The seen plugin can also be configured by an user to enforce the uniqueness of other fields, like tmdb_id.

I see! We can think about this in a latter stage! For now this PR solves some issues that are damaging the usability of the plugin, that's the main priority to solve

Okay, I rewrote your fixes/improvements a bit here https://github.com/Flexget/Flexget/compare/fcd16ff7b82e...f7acbc8ea650
I hope you don't feel bad that I took over your pull request, everything is based on your work. I just ended up implementing it a bit different while I was testing the behavior.
Thanks for this!


Handle Patterns without regexes gracefully

Fixes #4.
Also fixed an existing spec that wasn't working right on my machine.

Ugh, opened the issue against first-mate by accident. Won't move it over because there's already a PR, but here's the background.


Attempt manual removal of CNI IP allocations on refresh

We previously attempted to work within CNI to do this, without success. So let's do it manually, instead. We know where the files should live, so we can remove them ourselves instead. This solves issues around sudden reboots where containers do not have time to fully tear themselves down, and leave IP address allocations which, for various reasons, are not stored in tmpfs and persist through reboot.
Fixes #5433

I really want to test this, but the whole system-restart thing kind of puts a kibosh on that. I don't think we can really mock the circumstances involved, either.

LGTM assuming happy tests

@mheon Needs a rebase

I'm not seeing that?

Rebased to pick up CI fixes

/lgtm


Touch support can be improved in webviews

VSCode Version: Insider 1.11.0
OS Version: Windows 10, Build 15046
Machine: Surface Pro 3, with latest drivers

There are several places where touch support needs improvement:

In extension description pages, scrolling by touch does not work.
In markdown preview, scrolling by touch does not work
When there is a split view, or when I just closed a tab, there is a possibility where tapping the tabs does not work. This is not reproducible every time.

Touch is an essential functionality in many senarios. I often find it easier to scroll through webpages (like markdown previews) by touch than using the trackpad. There are also times people might use VS Code without a trackpad or mouse. It would be great help if touch support can be improved.

Not sure where and who owns the touch related functionality. Hence starting with you @bpasero .

I suspect an issue with touch support in our webviews. As for the issue around tabs I suggest to file a separate bug.

@bpasero I somewhat fixed touch support in the html preview (markdown preview) with d9de64e. This change applied absolute positioning to the webview element
However I'm not sure why touch support did not work in the first place. Also, on my Surface 3, the touch support was somewhat flaky. It would sometimes refuse for work for a few seconds when first loading the html preview and I'm not sure if this was specific to my Surface 3 or not.
@mousetraps Can you please do a quick test of the latest insiders builds on your Surface Book? Just try opening up a markdown preview and interacting with it on the touch screen. Let me know if you also see any odd behavior.
If anyone else with a touch screen computer has a chance, please test out the markdown preview in the latest VSCode insiders builds and let me know what works and what doesn't

@mjbvz I'm running into the same flaky behavior. A few observations:

the issue only occurs when multiple markdown previews have been opened in the session.
tapping a few times on the webview seems to unlock it sometimes.
when the issue does occur, touch sometimes also stops working momentarily in the tab well (tapping another tab does not switch tabs as expected). This might be a totally unrelated issue, however. Touch continues working fine everywhere else as far as I can tell.
scrolling by touching the scrollbar in the webview also stops working

Any motion on this? Willing to help test. I have a Surface Book.

I'm running linux with a laptop that has touch support. Would be interested in testing any developments for this environment.

It's also not possible to move the window via the custom title bar with touch.
System:

OS: Solus 4.0 (linux)
Desktop env: Budgie
VSCode version: 1.33.1

I don't see this mentioned, but you also can't scroll the editors with touch, a very natural gesture.

In the most recent VSCode, scrolling editors with touch works :tada:.
Selecting doesn't but I think that's probably quite hard to get right anyway.

The selection through touch is still not working. It would be great to have this feature soon

@Yamilquery how would you propose it should work? double-tap, long-tap, and then drag markers?

@wmertens it would be great with long-tap I think so! 🙌


SonarQube Critical Smell - api/app/admin/csr.py

Reducing code complexity to under 15 (hopefully).

Reference: https://sonarqube-servicebc-cfms-tools.pathfinder.gov.bc.ca/project/issues?id=org.sonarqube%3Aqueue-management&open=AWilbAo78qN1sJ4xbpbL&resolved=false&severities=CRITICAL&types=CODE_SMELL


Updates for static analysis

Handful of patches related to improving static analysis tooling.
In service (ish) of eregs/notice-and-comment#332

Punting this for a bit -- defusedxml has a different interface than I was expecting (in particular, lacking to/from-unicode). We don't need parser to have this all for ATO, so I'm going to close and we can swing back later.


Plans for solana-etl?

Hey folks! Big fan of what you all are doing with blockchain-ETL and keeping this open source.
I've started going down the web3 rabbit hole and am planning to start playing around with Solana data. Just wondering if this repo is still being actively worked on or if there are any plans for Solana you can share?
Just wanna make sure that if i decide to start from scratch that isn't a wasted effort

Thanks for your interest and sorry for the late reply.
Feel free to start from scratch, no OSS work has been started yet here.

Do you support stream and kafka sync solana network data.

i'm test only support export cvs or json data.


Tests: libc: Improve code coverage

Add test cases for libc module  APIs.
Signed-off-by: Xiaofst<EMAIL_ADDRESS>

@xiaofst, have you addressed all the comments?

@xiaofst, have you addressed all the comments?

yes, all of the comments have been handled.

@enjiamai @KangJianX, please take look at it again.


Several problems in RFC citations

tools.ietf.org is not appropriate to be used in references to RFCs (long story), URLs should start with http://www.rfc-editor.org/info per RFC editor policy.  See RFC 7322 section <IP_ADDRESS> for the correct way to cite RFCs.
So for BCP 13 for example, use http://www.rfc-editor.org/info/bcp13 and for RFC 4122 it should be https://www.rfc-editor.org/info/rfc4122.   (If you really need the format that tools.ietf.org supported, https://www.rfc-editor.org/rfc/rfc4122 would be the correct location.)
See Clarifying the state of and the transition plan for tools.ietf.org  for a tiny sampling of the long story behind why not to link to tools.ietf.org in URLs.  It was a private individual's site, which has fallen out of repair, not an official RFC repository.

In addition, the document is inconsistent in terms of whether it says "RFC xxxx" vs "IETF RFC xxxx", sometimes even for the same RFC (RFC 3986 and 7405 for example are sometimes called "IETF RFC xxxx" and other times called "RFC xxxx").
And there's even a typo in one reference where "BPC" should be "BCP":

The ABNF grammar for language tags is given in BPC 47, section 2.1, production Language-Tag.

Manually closing since fixed in PR #8
@tychonievich for future reference if you put "Fixes #4" in the description of your PR, github will automatically link the PR to the issue and close the issue when the PR is merged.  See https://github.blog/2013-01-22-closing-issues-via-commit-messages/


Make findclaim only give you one version of a module

Maybe some like it the way it is, but I would prefer if "findclaim" only gave you one instance of the module, so you don't have people hording a whole bunch of the same module.

Would prefer this as an option instead of a set usage -- I personally prefer being able to !findclaim wire and get all wire related modules, for example.

Sorted out the optional part of this issue in 8563695d87662911ed6ab6c3df7a07fd60c8cb60
Now, !findclaim returns exactly one item for each search term, and !findclaimall returns everything.


Chat Interface

Add additionals fields to the chat command interface:

allowedForStreamer
allowedForFollower

Developer Names have to be saved somewhere, so that the developers can use some commands e.g. join

The follower state is not being indicated by tmi.js. I had to write an own request against the twitch api for it.
See also https://github.com/tmijs/tmi.js/issues/421
Same with Streamer. I just assumed  channelname === username to detect the streamer here.

Furthermore, with the new Twitch API you will additionally need a Client ID Token, but atm I only have a OAuth Token.
Probably the bot needs to be "properly" registered with twitch https://dev.twitch.tv/docs/irc#next-steps, but prior to this we need to specify which twitch account the bot shall use in the future. I suppose my test account "avatarbot81" with its odd naming wont suffice here. Didnt know beforehand you cannot easily change this username, or atleast after a certain (long) time only.
So I will implement the follower query, but deactivate it for now.


WIP: added coverage computation

It is not added to ci yet.

Looks mainly good, but the one issue is the unit tests need to be run separately from the component tests. I believe you can update existing coverage if pytest gets run twice.

I will try to see if the coverage data aggregate correctly, if not I say we run together for now, the test are currently rather quick.

I will try to see if the coverage data aggregate correctly, if not I say we run together for now, the test are currently rather quick.

Agreed.


Feature/forward ports #724 #739 & #740 [6460]

This PR brings to 1.9.x branch the PRs #724 #739 and #740.

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows

I've just run discovery server against this fastrtps branch and all works fine. 👍

Build status:

Linux
Mac
Windows

Mac failure seems unrelated, so merging this in.


fix: token naming issue

_prepare_transfer_to_private function was used even in flows which are not a transfer (typically during minting). For this reson I renamed the function to _prepare_private_balance_increase.

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

#9950  👈
#9943
master

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

Join @benesjan and the rest of your teammates on  Graphite

How married are you to the new name ? 😄

@sklppy88 do you hate it?

Docs Preview
Hey there! 👋 You can check your preview at https://6734ff3fa685c230886b567e--aztec-docs-dev.netlify.app

prepare_mint_or_transfer

@sklppy88 you are being severely judged now.

Merge activity

Nov 13, 3:45 PM EST: A user started a stack merge that includes this pull request via Graphite.