text:
Gdpr compliant cookies

This pr is focused on changes required for this service to comply with gdpr cookie regulations. Previously, the service had a cookie message rendered from the deprecated template which is in current use. There are some uncertainties regarding what it means to document and store consent received from users. Currently, there is a cookie which is set when the user opts in/out. This drives the behaviour around the cookie banner and google analytics tracking.

Sorry – a couple more things from me! Firstly, I think I've spotted a couple of unused lines which could be removed – I've commented directly on the affected lines.
Secondly, I think there's probably some work to be done around DRYing this file up a little. Bare with me, because this is a little rambly. This is more of a conversation prompt – I'd be very happy to talk it through with you.
I'm noticing lots of references to window["ga-disable-UA-14565299-1"] throughout the this.render() method – either setting its value to true/false, or reading its value before calling this.trackPageView().
I wonder if there's any way to refactor this to DRY it up a bit? 🤔 I don't have a fully formed answer for this, it's just something to think about.
DRY up reads
One thought is perhaps we could move the 'is it true or false?' check into the this.trackPageView() method itself. That way, we'll only need to read that value in one area of our code, before deciding whether to go ahead with the GA tracking or not. I'm thinking something along the lines of this 'guard clause':
In fact – we may not need to check the value of this at all, since Google Analytics will refuse to track the page view so long as that value is set. We could take it a step further and simply _always_ call `this.trackPageView()`, and let Google Analytics handle those cases where consent hasn't been given.
trackPageView: function() {
  if (window["ga-disable-UA-14565299-1"]) return;

  // the rest of the method...
}

DRY up accept/reject cookie actions
I also notice that there are two ways users can accept or reject cookies – either via the cookie banner at the top of the page, or on the 'cookies' page itself. The implementation in code reflects this, but means we have some duplicate code – the accept_cookies-yes onclick event handler does exactly the same thing as the accept-cookies onclick handler.
We could DRY this up by implementing these two user actions ('accept' or 'reject' cookies) as methods which we then call in the event handlers – e.g. you could create methods this.acceptCookies() and this.rejectCookies() to handle those actions.

Some really great suggestions here @ollietreend, I have made these changes here a0300fbe4c40fdb49907e9e08757b54074564573

repo: ministryofjustice/prison-visits-public


text:
zephyr缺少DT_INST_0_MINOS_VM_CONSOLE_BASE_ADDRESS定义

zephyr编译不过，没有如下的定义。
DT_INST_0_MINOS_VM_CONSOLE_BASE_ADDRESS

需要使用 minos-aarch64分支

source: gharchive/issue

repo: minosproject/zephyr

license_type: permissive

license_source: github-api


text:
🛑 Redlib is down

In 2d7b2ce, Redlib (https://redlib.mint.lgbt) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Redlib is back up in 013d734 after 1 hour, 38 minutes.

repo: mint-lgbt/status

license: MIT


text:
🛑 Matrix is down

In c67b910, Matrix (https://matrix.mint.lgbt:8448/_matrix/federation/v1/version) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Matrix is back up in c8ad9d3 after 14 minutes.


text:
🛑 Matrix is down

In 76d0e13, Matrix (https://matrix.mint.lgbt:8448/_matrix/federation/v1/version) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Matrix is back up in 6129871 after 54 minutes.


text:
🛑 Matrix is down

In 131fead, Matrix (https://matrix.mint.lgbt:8448/_matrix/federation/v1/version) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Matrix is back up in e74cab1 after 59 minutes.


text:
Document: Thoughts about WYSIWYG

I have been thinking about WYSIWYG for this app quite a bit.
I want to document my thoughts and conclusions.

Introducing WYSIWYG would make the code a lot more complex:
Either by writing something myself and having to maintain it.
Or by relying on an external library which creates a dependency.
The app is not meant to be or become a Markdown editor.
The app is however currently linked to Markdown via the heading format.
I assume that every user maintains the captured thoughts in an extra editor.
I see no benefits of adding WYSIWYG for the given purpose of the app.
I will not implement it (unless I change my mind, but that's not very probable).

Decision to not implement it.
High complexity for little value added.
The product is meant for Markdown content.
And for people who know Markdown.

repo: minthemiddle/Quick-Capture


text:
New Electron CI

changed electron to desktop
update ./dev commands

    gen                 Check all the generated code is up to date. Otherwise run the code generation process to fix it.
    run-desktop         Run frontend desktop app for development.
    build-desktop       Builds the desktop app for the current platform.
    validate-desktop    Formats, Validates and test the desktop app
    run-site            Run sites app for development.
    build-site          Build site app for production.
    validate-site       Formats, Validates and test the site app
    run-backend         Build and run mintterd binary for the current platform.
    build-backend       Build mintterd binary for the current platform.
    run-gw-backend      Build and run backend for mintter web gateway.
    ping-p2p            Execute ping utility to check visibility.
    release             Cut a new release.

new release workflow (scoped to the release branch until I talk with @burdiyan about the tag workflow
new validate frontend code workflows (validate-site.yml and validate-desktop.yml)
lint setup (no real linting yet)
test setup (no real tests yet)
no Tauri code anymore

merged manually

source: gharchive/pull-request

repo: mintterteam/mintter


text:
Change Tree.t representation to use lazy contents values

This changes the type of trees to support lazy contents values:
- type t = Node of lazy_node | Contents of blob * metadata
+ type t = Node of lazy_node | Contents of lazy_contents

This means that contents are (internally) handled symmetrically to nodes: as unforced pointers to values in the underlying stores wherever possible. The user-facing changes are:

Tree.destruct returns unforced contents pointers that can be dereferenced with Tree.Contents.force.
Tree.of_hash and Tree.shallow now take kinded hashes with appropriate metadata.

This is motivated by https://github.com/mirage/irmin/issues/1284, which stems from the fact that we don't currently support "shallow" tree leaves. With this change, it's easy to extend Tree.shallow to support this, and I've added @smelc's now-working test case from that issue here. (Thanks!)
Fixes https://github.com/mirage/irmin/issues/1284.

That looks great and simplify quite a few bits of tree.ml which is nice (especially the merge function!). I think we used to have a kinded_hash in previous version of irmin, but that's fine to re-introduce these now that there is a clear goal (ie. work with shallow trees).

authors: CraigFe samoht

repo: mirage/irmin

license: isc

license_source: bigquery


text:
Use decode_int63 for reading old offsets

Fixing existing stores 0 and existing stores 2.
While this fixes the test, I think we should move to using the new IO in traverse_pack_file instead of the legacy_io, as the legacy_io cannot read files in V3.

I think these changes also (partially?) fix test_RW_no_version_bump (which also hits the read_offset_from_legacy_file issue)

authors: icristescu tomjridge


text:
message delete time

not sure if this is important to you or not, but the time for all deleted messages will be the same based on the following line:
    messages.update(deleted=True, deleted_at=datetime.datetime.now())

How about this instead?
    messages.update(deleted=True, deleted_at=datetime.datetime.now)

what I was getting at was, that deleted_at=datetime.datetime.now() would be evaluated the first time it's hit and the result would be remembered for the subsequent calls.  However, if you used deleted_at=datetime.datetime.now instead, then each call would get the exact time of execution. Did not look at the design so, not sure what happens later on ... so, it was just and observation. Looks good though! Any plan to make the view class-based any time soon?

repo: mirumee/django-messages


text:
Errors occur when update a page

What I'm trying to achieve
Update a Page
Steps to reproduce the problem

Call Mutation.pageUpdate  with input: {}

web_1     | ERROR saleor.graphql.errors.unhandled A query failed unexpectedly [PID:8:Thread-52]
web_1     | Traceback (most recent call last):
web_1     |   File "/usr/local/lib/python3.8/site-packages/promise/promise.py", line 489, in _resolve_from_executor
web_1     |     executor(resolve, reject)
web_1     |   File "/usr/local/lib/python3.8/site-packages/promise/promise.py", line 756, in executor
web_1     |     return resolve(f(*args, **kwargs))
web_1     |   File "/usr/local/lib/python3.8/site-packages/graphql/execution/middleware.py", line 75, in make_it_promise
web_1     |     return next(*args, **kwargs)
web_1     |   File "/app/saleor/graphql/core/mutations.py", line 279, in mutate
web_1     |     response = cls.perform_mutation(root, info, **data)
web_1     |   File "/app/saleor/graphql/core/mutations.py", line 448, in perform_mutation
web_1     |     cleaned_input = cls.clean_input(info, instance, data)
web_1     |   File "/app/saleor/graphql/page/mutations.py", line 43, in clean_input
web_1     |     cleaned_input["slug"] = slugify(cleaned_input["title"])
web_1     | KeyError: 'title'

What I expected to happen
should update a Page without error

Thanks for reporting, that's clearly a bug. This error also appears for the pageCreate mutation. Now the code assumes that title is always present while it's not required by the schema. It should be required when creating new pages and optional when updating existing ones.

authors: gsoec maarcingebala

repo: mirumee/saleor


text:
Add customers app

Quick preview:

Isn’t “price” label adjusted to the right, while all the others are aligned to the left?
Not sure if that’s intended or not.

It is planned. Every numeric ( therefore comparable ) values should be aligned to the right, so should be its label. It is easier to read and compare values this way.

Including # @dominik-zeglen? ;)

Okay, numeric and comparable :)

authors: Pacu2 dominik-zeglen mirekm


text:
slackbots.libs:utils in assert

https://github.com/mishk0/slack-bot-api/blob/master/index.js#L42
fails quite often for me.
https://app.getsentry.com/share/issue/36303035302e313030373835383634/
any ideas?

if the error still persists, please, reopen the issue.

license: mit


text:
Create folders inside dsa

create All topics folder inside Data Structure folder

assign me this


text:
Worldgen Structure Placement

An initial implementation of structure placement. Completely untested and is still missing some parts.
What already exists:

StructurePlacement class that does the chunk selection. The RandomSpreadStructurePlacement is fully implemented
StructureSet class to handle selection and placement of the structures
WorldgenStructure the structure types themselfes. Needed only for the findGenerationPoint method that determines the position within the chunk
HeightProvider implementation of the Height provider, needed for the jigsaw starting position configuration
HolderSet<T> implementation of Tags. Needed for the biome tag for allowed biomes of the structures.
Registries now have a getTagRegistry() function that returns a new Registry to hold the tags of the base type (Registry<HolderSet<T>>)

What is still missing:

[x] ConcentricRingsStructurePlacement placement
[ ] findGenerationPoint for:

[x] JigsawStructure: including template pools and structure nbt
[x] EndCityStructure
[x] WoodlandMansionStructure
[ ] MineshaftStructure: requires complete generation to determine placement
[ ] NetherFossilStructure: requires access to noise, maybe doable, probably not worth it though
[ ] OceanMonumentStructure: probably just bad performance from lots of biome access
[ ] RuinedPortalStructure: very long code, probably not worth it

[x] implementation of NoiseBasedChunkGenerator.getBaseHeight
[x] Optional entries in HolderSet (tags)
[x] ExclusionZone
[ ] Tests

[x] HeightProvider
[x] RandomSpreadStructurePlacement
[x] HolderSet
[x] FrequencyRecucer
[x] ExclusionZone
[x] ConcentricRingsStructurePlacement
[ ] more?

I've implemented the jigsaw starting pool now, including the template nbt reading. I've tested this on my map with vanilla data to confirm that the generation is identical to ingame.
It is hard to write tests for that though, as this requires so much data to work.

new ConcentricRingsStructurePlacement test is failing because of some issue in (probably) in BiomeSource.findBiomeHorizontal that leads to it not be in parity with vanilla that I can't figure out yet.

Ok, I think this is ready now. The only thing that is theoretically still missing is the findGenerationPoint for a few structure types. Those are rather complicated and probably not worth the effort.

@jacobsjo I've published a beta version of this as 0.18.0-beta.1 because I would like to get a more detailed look.  Sorry for that force push, I accidentally pushed the commit that changed the version, which caused conflicts.

Thanks! :+1:
The WorldgenRegistries was giving me issues with circular dependencies. I think you had a similar issue with density functions but your work-around only works once. I think it would make more sense to put all the registries into their respective classes.

I think it would make more sense to put all the registries into their respective classes.

Yes that seems like a sensible solution.

authors: jacobsjo misode

repo: misode/deepslate


text:
fix(server): hydrate organisme job & fiabilisation reseaux

Refacto & correction du job de récupération des organismes.
Plusieurs soucis identifiés qui impactent la fiabilisation des réseaux des organismes.
Une refacto & simplification du job.
Pour le moment pas d'optimisation de perf' mais à envisager par la suite.

Refacto fonction de récupération d'infos depuis SIRET via API Entreprise 👉🏼 https://github.com/mission-apprentissage/flux-retour-cfas/pull/2584/commits/7e3472c01fd6355e35be297b6d3702d9867e21c1 (mutualisé car appelé depuis un job + depuis un composant)
MAJ du modèle organisme pour couple UAI Siret unique via index 👉🏼 https://github.com/mission-apprentissage/flux-retour-cfas/pull/2584/commits/f3793e716169bd9f67c73a96a431af3bd75542f3
Refacto fetchOrganismes avec options par défaut : 👉🏼 https://github.com/mission-apprentissage/flux-retour-cfas/pull/2584/commits/5b63a19613ed8e509032f81d5601da6db9689d17
Refacto / correction / simplification du script de récupération des organismes 👉🏼 https://github.com/mission-apprentissage/flux-retour-cfas/pull/2584/commits/6d0d3db47685aeaccaa4c4cf4506e04e811a2769
Modif de l'infra et du CRON pour lancement des scripts chaque matin 👉🏼 https://github.com/mission-apprentissage/flux-retour-cfas/pull/2584/commits/a20d4f13119338973f2c658b1d8522672390c0ff

:tada: This PR is included in version 3.9.0 :tada:
The release is available on:

GitHub release
v3.9.0

Your semantic-release bot :package::rocket:

authors: antoinebigard sbenfares

repo: mission-apprentissage/flux-retour-cfas


text:
🛑 API Apprentissage - API is down

In 598383c, API Apprentissage - API (https://api.apprentissage.beta.gouv.fr/api/healthcheck) was down:

HTTP code: 503
Response time: 97 ms

Resolved: API Apprentissage - API is back up in 90bbcfa after 6 minutes.

repo: mission-apprentissage/upptime


text:
Add temp disable to autofire devices if they fire too fast/long (anti machine-gunning)

Autofire coils (and related devices based on autofires like in #636 like slingshots, pop bumpers, etc) should have a config option that will temporarily disable them if they fire too fast or too long. A config option could be something like "if it fires X times in Y secs then disable it for Z secs".
Since autofires are handled in hw rules, we'd have to watch for switch events which come on while the autofire is active and then temporarily disable the autofire.

We got that. I think it is called recycle time. Not all platforms support it though

I'm thinking this feature though can go longer than the 255ms that the platform(s) support. For example, in WoZ, it's possible that a ball can get "stuck" in the upper slingshot area for too long and not come down. So this setting would be more like "if this slingshot fires more than 10 times in 10 seconds, disable it for 5 secs so the ball will come down and the game will continue".

this is a real setting from woz btw, though I forget exactly how they phrase it

Makes sense. With the next platform refactoring we will probably support longer recycle ms in software but this will not help here because it actually counts the hits.

repo: missionpinball/mpf


text:
Explore updating MPF to asynchronous logging

Our logging is based on the Python 2.7 way of doing things, and in Python 3.2 they introduced a feature called asynchronous logging via the QueueListener class. It won't block threads like the old way.
Switching to this may prevent the lag associated with tons of events coming in when event logging is set to full. It's also possible that it could help things work on Windows a little better, but that might be wishful thinking.
More info: http://plumberjack.blogspot.co.uk/2010/09/improved-queuehandler-queuelistener.html
From python.org: https://docs.python.org/3.4/library/logging.handlers.html#queuehandler
and https://docs.python.org/3.4/library/logging.handlers.html#queuelistener
I don't think this is needed for 0.33, unless you think it's easy.

Should be easy. @toomanybrians already implemented most requirements for that

Oh wow. Nice find!
Yeah this should be easy because now MPF has a central logging module which is used for all logging instead of having individual logging calls scattered throughout. So changing to this will only need to be done in that one location and should be easy. (I say that having not clicked the links yet explaining it.) But as a concept, should be straightforward.

authors: GabeKnuth jabdoa2 toomanybrians


text:
emojiノードの改善

カスタム絵文字とUnicode絵文字をより扱いやすくする

(今のMisskeyでは事情により実装されてないけど):foo:形式の構文は、実はカスタム絵文字だけじゃなくてUnicode絵文字も指定することができる(例えば:+1:)ので、typeはcustomEmojiとかじゃなくてemojiCodeとかにする必要がありそう

知らなかった
emojiCodeにする方が良いね

調べたら、Emoji Shortcodesっていう名前があるらしい

修正終わった

authors: marihachi syuilo


text:
Create logo.png

Isn't this already live here: https://github.com/mistswapdex/assets/blob/master/blockchains/smartbch/assets/0x7b82A3b1417Cd21E67f745917a80cC0f53277B8C/logo.png / https://assets.mistswap.fi/blockchains/smartbch/assets/0x7b82A3b1417Cd21E67f745917a80cC0f53277B8C/logo.png

The issue is smartswap. TangoSwap logo. EVE has the old logo on smartswap tangoswap link from marketcap.cash Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Kasumi @.> Date: 2/28/22  8:45 AM  (GMT-08:00) To: mistswapdex/assets @.> Cc: PokerJ0k3r @.>, Author @.> Subject: Re: [mistswapdex/assets] Create logo.png (PR #71)
Isn't this already live here: https://github.com/mistswapdex/assets/blob/master/blockchains/smartbch/assets/0x7b82A3b1417Cd21E67f745917a80cC0f53277B8C/logo.png / https://assets.mistswap.fi/blockchains/smartbch/assets/0x7b82A3b1417Cd21E67f745917a80cC0f53277B8C/logo.png
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.Message ID: @.***>

repo: mistswapdex/assets


text:
Support access to the manifest file for AI Extensions

Extensions can already define UserLibraries and Permissions, but there's no way to create extensions that need other type of access to the manifest through Compiler.java
A first iteration of this could be to move the BroadcastReceiver code used in Texting.java to the component (with an annotation) instead of adding it directly in Compiler.java. After that, more support for things like Services, minSDK or finer grain permissions should be added.

https://github.com/mit-cml/appinventor-sources/pull/703 is the first pass at this.
I'll add Services next (whenever I can find the time!).

Hi @josmas,
Do you have any plans regarding adding an annotation for using Service? Thanks.

Hi @ShreyashSaitwal no plans at the moment.
@ewpatton is this worth adding, in your opinion? I don't currently have a use case for it, but can look into it at some stage.

@josmas
There's definitely no use case for this in the core system, but it could be very useful for extensions. I was working on an extension which needs to add some service tags in manifest, but since it's not currently possible, I'm unable to proceed further.
I'd greatly appreciate it if you could work on it.
Thanks.

@ShreyashSaitwal this could be used in core too, what I mean is that I personally do not have an use case for it at the moment, unlike when I worked on broadcast receivers.
I don't see how you can be unable to proceed though, you have the sources, you can follow https://github.com/mit-cml/appinventor-sources/pull/703 and I'm sure people here can provide feedback and suggestions, so why don't give it a go? Contributions are always welcome.

At first, I was going to try it myself, but saw this issue and hence, pinged you.
Anyways, I'll give it a try now and reach out to you here if I faced any issues.
Thanks.

Hi @josmas,
I just recently created #2217 which adds annotations for Services as well as Content Providers. Will you please review it?
Thanks.

Hey @ShreyashSaitwal thanks a million for working on this; I see it's just merged. Congrats and thanks for the contribution!

@josmas I'm going to close this for now as @ShreyashSaitwal's work has filled out most of the missing links. I think now we're just down to application-level metadata as a missing feature, which I don't think is that common.

authors: ShreyashSaitwal ewpatton josmas

repo: mit-cml/appinventor-sources


text:
Made changes to iml files that Intellij would otherwise do automatically

This avoids a dirty local repo immediately after cloning.

Reverting by discussion

authors: mit-mit mravn-google

repo: mit-mit/flutter


text:
Organizine Examples

Steps to reproduce the problem:

Visit https://github.com/mitmproxy/mitmproxy/tree/master/examples for the first time.
Be overwhelmed. (@mitmproxy/devs may not be able to reproduce this)

What went wrong?
Our examples directory has grown organically and I feel there are too many too complex examples in there that scare users away. It's not really clear where to start.
What is the expected behavior?
We should guide users to the simpler, more frequently used examples like add_header.py, filt.py, modify_response_body.py or redirect_requests.py and hide the more complex ones.
Any other comments? What have you tried so far?
I would propose to split the examples folder into "beginner" and "complex" and (after this, in a second PR) add a README in the examples folder that guides the user. The beginner examples don't have to be trivial, but they should have a high usefulness/complexity ratio.
I'd be more than happy if a new contributor wants to pick that up and let us know which examples are helpful for mitmproxy beginners and which aren't! :smiley:

I'm interested in taking a look at this. I'm just starting. Anyone else here?

I would be willing to lend a hand. I think the first thing we can do is rebuild this readme.md right now it kind of sucks.

Yeah... And maybe split a README for each folder that @mhils suggested...

I've also noticed that not all examples are covered in the current README. It would be nice to have a simple description for each one. On the other hand, I've also noticed that some files seem to have been created for reference by the docs. Maybe this makes the descriptions unnecessary....

I noticed that too and am working on the project in my fork now

Hey guys,
Thanks for picking this up! 😃 If you want to coordinate, you are more than welcome to join us on Slack and discuss things there. Other than that, the only advice I can give is to make the PRs as small as possible. 😉

Made pull request #1600 to submit my contributions to the codebase

That is nice. I'll make a PR that fixes the references in docs tomorrow.
If you don't beat me to it, of course.
:-D
On Tue, 4 Oct 2016 17:36 Shane Bradfield, notifications@github.com wrote:

Made pull request #1600 https://github.com/mitmproxy/mitmproxy/pull/1600
to submit my contributions to the codebase
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mitmproxy/mitmproxy/issues/1586#issuecomment-251505336,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAALxsXOf0Aof-PcZrxuRIQPw5UtOBL4ks5qwri3gaJpZM4KJgCA
.

By all means take care of that one.

Did it!

I looked at upsidedownintenet and got overwhelemed, by its simplicity that is.

authors: arekbulski l33tLumberjack mhils thiagoarrais

repo: mitmproxy/mitmproxy


text:
Use pytest.raises instead of our own tutils.raises

Use pytest.raises instead of our own tutils.raises implementation which should be feature-compatible. At the moment we use both - with no real distinction or reasoning behind it.

I think they aren't exactly feature-compatible as that tutils.raises also accepts a str as argument and checks the error message for that. The pytest way to do this is decribed here.

with raises(ZeroDivisionError, message="Expecting ZeroDivisionError"): looks pretty much like what we need.

I think that just specified the test failure message, not the expected error.

I'd like to retain a compact way to specify that an error should loosely contain a specified string. I find this very useful in testing.

fixed by #1980

authors: Kriechi cortesi mhils


text:
TlsException (Unexpected EOF) when connecting to SSL

Hi, I've just install mitmproxy on Bananian. Using Python 3.5 and installed v2.0.2 release version via pip3. Connecting to non-SSL sites works just fine, but when I attempt to connect to SSL sites (google.com in this case), Chrome complains. mitmdump shows various TlsExceptions.
I am posting the output below. The first errors were triggered as I was typing "google.com" into the address bar. When I pressed enter, I received a 301 error followed by the two final errors.
Any help appreciated. Happy to provide whatever additional information I can.
mitmdump -p 8181
HTTP/2 is disabled because ALPN support missing!
OpenSSL 1.0.2+ required to support HTTP/2 connections.
Use --no-http2 to silence this warning.
Proxy server listening at http://0.0.0.0:8181
192.168.101.154:52637: clientconnect
192.168.101.154:52638: clientconnect
192.168.101.154:52635: clientconnect
192.168.101.154:52636: clientconnect
192.168.101.154:52639: clientconnect
192.168.101.154:52637: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52637: clientdisconnect
192.168.101.154:52635: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52635: clientdisconnect
192.168.101.154:52638: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52638: clientdisconnect
192.168.101.154:52636: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52636: clientdisconnect
192.168.101.154:52639: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52639: clientdisconnect
192.168.101.154:52640: clientconnect
192.168.101.154:52641: clientconnect
192.168.101.154:52640: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52640: clientdisconnect
192.168.101.154:52641: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52641: clientdisconnect
192.168.101.154:52642: clientconnect
192.168.101.154:52643: clientconnect
192.168.101.154:52642: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52642: clientdisconnect
192.168.101.154:52644: clientconnect
192.168.101.154:52643: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52643: clientdisconnect
192.168.101.154:52645: clientconnect
192.168.101.154:52646: clientconnect
192.168.101.154:52644: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52644: clientdisconnect
192.168.101.154:52646: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52646: clientdisconnect
192.168.101.154:52645: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52645: clientdisconnect
192.168.101.154:52647: clientconnect
192.168.101.154:52647: GET http://google.com/
<< 301 Moved Permanently 219b
192.168.101.154:52648: clientconnect
192.168.101.154:52648: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:52648: clientdisconnect
192.168.101.154:52649: clientconnect
192.168.101.154:52649: CONNECT clients4.google.com:443
<< Cannot establish TLS with client (sni: clients4.google.com): TlsException("(-1, 'Unex
pected EOF')",)
192.168.101.154:52649: clientdisconnect
System information
#mitmproxy --version
Mitmproxy version: 2.0.2 (release version)
Python version: 3.5.2
Platform: Linux-3.4.111-bananian-armv7l-with-debian-8.8
SSL version: OpenSSL 1.0.1t  3 May 2016
Linux distro: debian 8.8

Oh, I should mention that I installed the Windows CA cert on my client machine. Mitmproxy is running on a separate Linux (Bananian) box on my network.

Did you try using a non-browser client such as cURL?

I get the same thing. Here's what I see what I attempt to download from the command line (windows):
Invoke-Webrequest https://www.google.com
Invoke-Webrequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS
secure channel.
At line:1 char:1

Invoke-Webrequest https://www.google.com

  + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
 eption
  + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

And mitmdump returns:
192.168.101.154:61833: clientconnect
192.168.101.154:61833: CONNECT www.google.com:443
<< Cannot establish TLS with client (sni: www.google.com): TlsException("(-1, 'Unexpecte
d EOF')",)
192.168.101.154:61833: clientdisconnect

I just noticed a couple more things, not sure if they are relevant or not.
When I run mitmproxy, no flows appear when I make the request, though the windows client returns the same error as above (Could not establish trust relationship). I confirmed that mitproxy is receiving the request however, because when I stop it I receive a "connection cannot be established" message.
Secondly, if I request the unencrypted url (http://www.google.com), I get two responses back:
GET http://www.googlecom/
200 text/html 44.31k 561ms
GET https://ssl.gstatic.com/gb/images/b_8d5afc09.png
200 image/png 9.53k 747ms
Seems odd that that the 2nd file came through correctly. I followed this up with another request to https://www.google.com and that broke, same as before.

The error message in https://github.com/mitmproxy/mitmproxy/issues/2403#issuecomment-309760416 indicates that your client does not trust the certificate presented by mitmproxy. Besides, you're not really using curl (https://github.com/PowerShell/PowerShell/pull/1901).

That's correct. The question is why? The certificate is installed in the client machine...?

Can you double-check that you installed the certificate as a root certificate authority?
(certmgr -> trusted root certificate authorities)

Ok, that was the problem! The certificate was installing itself in the Personal certificates directory.
Is there a link to a page with install instructions for each OS? The magic page only has Android instructions.

Well, looks like that mostly fixes it anyway. Outlook.microsoft.com is acting very strangely now. It works, but very slowly. And mitmdump is filling up with the following.
(BTW, thanks for your help so far!)
192.168.101.154:50538: clientconnect
192.168.101.154:50536: clientdisconnect
192.168.101.154:50535: CONNECT outlook.office.com:443
<< Cannot establish TLS with client (sni: outlook.office.com): TlsException("(-1, 'Unexp
ected EOF')",)
192.168.101.154:50535: clientdisconnect

Is there a link to a page with install instructions for each OS?

No, we do need better docs for that - contributions are welcome!
Closing this as the original issue seems to be fixed.


text:
2 proxies in Transparent mode. Certificate verification error for IP: Hostname mismatch (errno: 62, depth: 0)

Problem Description:
Hi,
I'm using 2 proxies in transparent mode with http2=false set.
The scheme is this: Client(Browser) <---->Mitmproxy Transparent 1 <----> Mitmproxy Transparent 2 <----> Internet.
In Mitmproxy 1, I start it with: mitmproxy --mode transparent --showhost  -s Script1.py -p 8080
The content of Script1.py is this:
from mitmproxy import http
from mitmproxy import flow
def request(flow):
	flow.request.port = 8081
	flow.request.scheme = "http"

In Mimproxy 2, I start it with: mitmproxy --mode transparent --showhost -s Script2.py  --listen-host 192.168.0.103 -p 8081
The content of Script2.py is this:
from mitmproxy import http
from mitmproxy import flow

def request(flow):
    flow.request.port = 443
    flow.request.scheme = "https"

My rules on iptables are:
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A PREROUTING -i enp2s0f1 -p tcp --dport 443 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -i enp2s0f1 -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p tcp --dport 8081 -j  DNAT --to-destination 192.168.0.103:8081
iptables -t nat -A OUTPUT -p tcp --dport 8081 -j DNAT --to-destination 192.168.0.103:8081
iptables -A OUTPUT -p tcp -m tcp --dport 8081 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --sport 8081 -j ACCEPT
iptables -t nat -A POSTROUTING -o wlx002401a70708 -j MASQUERADE

After that, if i try to enter any site on internet, what I will find in the browser and in the Mitmproxy1 is this

  <title>502 Bad Gateway</title>

502 Bad Gateway

Certificate verification error for IP: Hostname mismatch (errno: 62, depth: 0)

**IP is any IP,
and in the Mitmproxy 2 I will find this
Certificate verification error for IP: Hostname mismatch (errno: 62, depth: 0)
Everything works fine if i set ssl_insecure=true but i dont want this option.
The problem is with certification but i don't know how to resolve it.
Any suggestion?
Steps to reproduce the behavior:

Recreate the proxies scheme and iptables rules.
Try to enter any site on internet
Suggest how to resolve the problem with certification

System Information:
mitmproxy --version:
Mitmproxy: 5.2
Python:    3.6.9
OpenSSL:   OpenSSL 1.1.1g  21 Apr 2020
Platform:  Linux-4.15.0-112-generic-x86_64-with-Ubuntu-18.04-bionic

There is too much complexity in your setup for me to figure out what exactly is going on, and we don't have the time to reproduce this in its entirety.

authors: mhils sJCCJs


text:
Serve PAC file through mitmproxy HTTP service

Problem Description
It would be nice if mitmproxy could serve PAC file. This makes life easier to setup proxy in clients (e.g. browsers) that support it.
Proposal
Think of a team of developers which would like to share the same mitmproxy settings. For instance, they can all use Chrome with Proxy Switcher and Manager which they can setup with http://127.0.0.1:8080/myconfig.pac. They can also run the scommand:
mitmdump -s myaddon.py

Where myaddon.py contains:
from mitmproxy import pac

_PAC_CONTENT = '''
function FindProxyForURL(url, host) {
  if (shExpMatch(host, "mitm.it")) {
    return "PROXY 127.0.0.1:9080";
  }
  return "DIRECT";
}
'''
pac.serve('myconfig.pac', _PAC_CONTENT)

Or, the PAC content could be passed as a parameters:
mitmdump -s myaddon.py --pac myconfig.pac

Alternatives
Current workaround is to share the PAC file. If one tries to serve it from `myaddon.py you get:
 << Invalid HTTP request form (expected: authority or absolute, got: relative)

Additional context
NA

Thanks for the extensive suggestion! This works with the latest development snapshots (see https://github.com/mitmproxy/mitmproxy/issues/4632) by exposing a WSGI app from within mitmproxy. Adapted from examples/addons/wsgi-flask-app.py:
from flask import Flask
from mitmproxy.addons import asgiapp

app = Flask("pacapp")

@app.route('/myconfig.pac')
def serve_pac() -> str:
    return 'function FindProxyForURL(url, host) { ... }'

addons = [
    asgiapp.WSGIApp(app, "localhost", 8080)
]

Thinking about it, you can also adapt examples/addons/http-reply-from-proxy.py now, which probably is even a bit simpler. 😄

authors: igorgatis mhils


text:
mitmproxy doesn't install on OpenBSD

Problem Description
Installing mitmproxy (10.0.0) doesn't work on OpenBSD 7.3 through pip because mitmproxy-rs doesn't build.
Steps to reproduce the behavior:
peek$ pip3.10 install mitmproxy
Defaulting to user installation because normal site-packages is not writeable
Collecting mitmproxy
  Obtaining dependency information for mitmproxy from https://files.pythonhosted.org/packages/7a/3a/9ec933b3c556ea26690251c3928cddce4df3688ac37344b369db7975bb17/mitmproxy-10.0.0-py3-none-any.whl.metadata
  Using cached mitmproxy-10.0.0-py3-none-any.whl.metadata (8.9 kB)
Collecting aioquic-mitmproxy<0.10,>=0.9.20 (from mitmproxy)
  Using cached aioquic_mitmproxy-0.9.20.3-py3-none-any.whl (80 kB)
Collecting asgiref<3.8,>=3.2.10 (from mitmproxy)
  Obtaining dependency information for asgiref<3.8,>=3.2.10 from https://files.pythonhosted.org/packages/9b/80/b9051a4a07ad231558fcd8ffc89232711b4e618c15cb7a392a17384bbeef/asgiref-3.7.2-py3-none-any.whl.metadata
  Using cached asgiref-3.7.2-py3-none-any.whl.metadata (9.2 kB)
Requirement already satisfied: Brotli<1.1,>=1.0 in /usr/local/lib/python3.10/site-packages (from mitmproxy) (1.0.9)
Requirement already satisfied: certifi>=2019.9.11 in ./.local/lib/python3.10/site-packages (from mitmproxy) (2023.5.7)
Requirement already satisfied: cryptography<41.1,>=38.0 in /usr/local/lib/python3.10/site-packages (from mitmproxy) (39.0.1)
Collecting flask<2.4,>=1.1.1 (from mitmproxy)
  Obtaining dependency information for flask<2.4,>=1.1.1 from https://files.pythonhosted.org/packages/fd/56/26f0be8adc2b4257df20c1c4260ddd0aa396cf8e75d90ab2f7ff99bc34f9/flask-2.3.3-py3-none-any.whl.metadata
  Using cached flask-2.3.3-py3-none-any.whl.metadata (3.6 kB)
Collecting h11<0.15,>=0.11 (from mitmproxy)
  Using cached h11-0.14.0-py3-none-any.whl (58 kB)
Collecting h2<5,>=4.1 (from mitmproxy)
  Using cached h2-4.1.0-py3-none-any.whl (57 kB)
Collecting hyperframe<7,>=6.0 (from mitmproxy)
  Using cached hyperframe-6.0.1-py3-none-any.whl (12 kB)
Collecting kaitaistruct<0.11,>=0.10 (from mitmproxy)
  Using cached kaitaistruct-0.10-py2.py3-none-any.whl (7.0 kB)
Collecting ldap3<2.10,>=2.8 (from mitmproxy)
  Using cached ldap3-2.9.1-py2.py3-none-any.whl (432 kB)
Collecting mitmproxy-rs<0.3,>=0.2.0b1 (from mitmproxy)
  Using cached mitmproxy_rs-0.2.2.tar.gz (854 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting msgpack<1.1.0,>=1.0.0 (from mitmproxy)
  Using cached msgpack-1.0.6-cp310-cp310-openbsd_7_3_amd64.whl
Collecting passlib<1.8,>=1.6.5 (from mitmproxy)
  Using cached passlib-1.7.4-py2.py3-none-any.whl (525 kB)
Collecting protobuf<5,>=3.14 (from mitmproxy)
  Obtaining dependency information for protobuf<5,>=3.14 from https://files.pythonhosted.org/packages/fa/8a/e9c6b48b8f4651df1b1a9d46fe94a74ed99881141b4660aa855a798c7c53/protobuf-4.24.3-py3-none-any.whl.metadata
  Using cached protobuf-4.24.3-py3-none-any.whl.metadata (540 bytes)
Requirement already satisfied: pyOpenSSL<23.3,>=22.1 in ./.local/lib/python3.10/site-packages (from mitmproxy) (23.2.0)
Collecting pyparsing<3.2,>=2.4.2 (from mitmproxy)
  Obtaining dependency information for pyparsing<3.2,>=2.4.2 from https://files.pythonhosted.org/packages/39/92/8486ede85fcc088f1b3dba4ce92dd29d126fd96b0008ea213167940a2475/pyparsing-3.1.1-py3-none-any.whl.metadata
  Using cached pyparsing-3.1.1-py3-none-any.whl.metadata (5.1 kB)
Collecting pyperclip<1.9,>=1.6.0 (from mitmproxy)
  Using cached pyperclip-1.8.2-py3-none-any.whl
Collecting ruamel.yaml<0.18,>=0.16 (from mitmproxy)
  Obtaining dependency information for ruamel.yaml<0.18,>=0.16 from https://files.pythonhosted.org/packages/d9/0e/2a05efa11ea33513fbdf4a2e2576fe94fd8fa5ad226dbb9c660886390974/ruamel.yaml-0.17.32-py3-none-any.whl.metadata
  Using cached ruamel.yaml-0.17.32-py3-none-any.whl.metadata (17 kB)
Collecting sortedcontainers<2.5,>=2.3 (from mitmproxy)
  Using cached sortedcontainers-2.4.0-py2.py3-none-any.whl (29 kB)
Collecting tornado<7,>=6.2 (from mitmproxy)
  Using cached tornado-6.3.3-cp38-abi3-openbsd_7_3_amd64.whl
Collecting urwid-mitmproxy<2.2,>=2.1.1 (from mitmproxy)
  Using cached urwid_mitmproxy-2.1.2.1-cp310-cp310-openbsd_7_3_amd64.whl
Collecting wsproto<1.3,>=1.0 (from mitmproxy)
  Using cached wsproto-1.2.0-py3-none-any.whl (24 kB)
Collecting publicsuffix2<3,>=2.20190812 (from mitmproxy)
  Using cached publicsuffix2-2.20191221-py2.py3-none-any.whl (89 kB)
Collecting zstandard<0.22,>=0.11 (from mitmproxy)
  Using cached zstandard-0.21.0-cp310-cp310-openbsd_7_3_amd64.whl
Collecting typing-extensions<4.6,>=4.3 (from mitmproxy)
  Using cached typing_extensions-4.5.0-py3-none-any.whl (27 kB)
Collecting pylsqpack<0.4.0,>=0.3.3 (from aioquic-mitmproxy<0.10,>=0.9.20->mitmproxy)
  Using cached pylsqpack-0.3.17-cp310-cp310-openbsd_7_3_amd64.whl
Requirement already satisfied: cffi>=1.12 in /usr/local/lib/python3.10/site-packages (from cryptography<41.1,>=38.0->mitmproxy) (1.15.1)
Collecting Werkzeug>=2.3.7 (from flask<2.4,>=1.1.1->mitmproxy)
  Obtaining dependency information for Werkzeug>=2.3.7 from https://files.pythonhosted.org/packages/9b/59/a7c32e3d8d0e546a206e0552a2c04444544f15c1da4a01df8938d20c6ffc/werkzeug-2.3.7-py3-none-any.whl.metadata
  Using cached werkzeug-2.3.7-py3-none-any.whl.metadata (4.1 kB)
Collecting Jinja2>=3.1.2 (from flask<2.4,>=1.1.1->mitmproxy)
  Using cached Jinja2-3.1.2-py3-none-any.whl (133 kB)
Collecting itsdangerous>=2.1.2 (from flask<2.4,>=1.1.1->mitmproxy)
  Using cached itsdangerous-2.1.2-py3-none-any.whl (15 kB)
Requirement already satisfied: click>=8.1.3 in ./.local/lib/python3.10/site-packages (from flask<2.4,>=1.1.1->mitmproxy) (8.1.4)
Collecting blinker>=1.6.2 (from flask<2.4,>=1.1.1->mitmproxy)
  Using cached blinker-1.6.2-py3-none-any.whl (13 kB)
Collecting hpack<5,>=4.0 (from h2<5,>=4.1->mitmproxy)
  Using cached hpack-4.0.0-py3-none-any.whl (32 kB)
Collecting pyasn1>=0.4.6 (from ldap3<2.10,>=2.8->mitmproxy)
  Using cached pyasn1-0.5.0-py2.py3-none-any.whl (83 kB)
Collecting ruamel.yaml.clib>=0.2.7 (from ruamel.yaml<0.18,>=0.16->mitmproxy)
  Using cached ruamel.yaml.clib-0.2.7-cp310-cp310-openbsd_7_3_amd64.whl
Requirement already satisfied: pycparser in /usr/local/lib/python3.10/site-packages (from cffi>=1.12->cryptography<41.1,>=38.0->mitmproxy) (2.21)
Collecting MarkupSafe>=2.0 (from Jinja2>=3.1.2->flask<2.4,>=1.1.1->mitmproxy)
  Using cached MarkupSafe-2.1.3-cp310-cp310-openbsd_7_3_amd64.whl
Using cached mitmproxy-10.0.0-py3-none-any.whl (1.6 MB)
Using cached asgiref-3.7.2-py3-none-any.whl (24 kB)
Using cached flask-2.3.3-py3-none-any.whl (96 kB)
Using cached protobuf-4.24.3-py3-none-any.whl (175 kB)
Using cached pyparsing-3.1.1-py3-none-any.whl (103 kB)
Using cached ruamel.yaml-0.17.32-py3-none-any.whl (112 kB)
Using cached werkzeug-2.3.7-py3-none-any.whl (242 kB)
Building wheels for collected packages: mitmproxy-rs
  Building wheel for mitmproxy-rs (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for mitmproxy-rs (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [184 lines of output]
      Running `maturin pep517 build-wheel -i /usr/local/bin/python3.10 --compatibility off`
      🍹 Building a mixed python/rust project
      🔗 Found pyo3 bindings with abi3 support for Python ≥ 3.10
      🐍 Not using a specific python interpreter
         Compiling autocfg v1.1.0
         Compiling proc-macro2 v1.0.66
         Compiling unicode-ident v1.0.11
         Compiling cfg-if v1.0.0
         Compiling libc v0.2.147
         Compiling scopeguard v1.2.0
         Compiling typenum v1.16.0
         Compiling version_check v0.9.4
         Compiling quote v1.0.31
         Compiling getrandom v0.2.10
         Compiling generic-array v0.14.7
         Compiling syn v2.0.26
         Compiling syn v1.0.109
         Compiling lock_api v0.4.10
         Compiling simd-adler32 v0.3.5
         Compiling rand_core v0.6.4
         Compiling target-lexicon v0.12.10
         Compiling semver v1.0.18
         Compiling memchr v2.5.0
         Compiling crossbeam-utils v0.8.16
         Compiling cc v1.0.79
         Compiling adler v1.0.2
         Compiling miniz_oxide v0.7.1
         Compiling crypto-common v0.1.6
         Compiling memoffset v0.9.0
         Compiling futures-core v0.3.28
         Compiling pyo3-build-config v0.18.3
         Compiling rustc_version v0.4.0
         Compiling crossbeam-epoch v0.9.15
         Compiling subtle v2.5.0
         Compiling either v1.8.1
         Compiling anyhow v1.0.72
         Compiling num_cpus v1.16.0
         Compiling futures-sink v0.3.28
         Compiling smallvec v1.11.0
         Compiling once_cell v1.18.0
         Compiling itertools v0.10.5
         Compiling pin-project-lite v0.2.10
         Compiling io-lifetimes v1.0.11
         Compiling parking_lot_core v0.9.8
         Compiling rayon-core v1.11.0
         Compiling platforms v3.0.2
         Compiling zeroize_derive v1.4.2
         Compiling crossbeam-deque v0.8.3
         Compiling crossbeam-channel v0.5.8
         Compiling backtrace v0.3.68
         Compiling indexmap v1.9.3
         Compiling gimli v0.27.3
         Compiling zeroize v1.6.0
         Compiling cpufeatures v0.2.9
         Compiling crc32fast v1.3.2
         Compiling rustix v0.37.23
         Compiling prost-derive v0.11.9
         Compiling pyo3-ffi v0.18.3
         Compiling errno v0.3.1
         Compiling object v0.31.1
         Compiling addr2line v0.20.0
         Compiling spin v0.9.8
         Compiling tempfile v3.6.0
         Compiling num-traits v0.2.15
         Compiling slab v0.4.8
         Compiling bitflags v1.3.2
         Compiling regex-syntax v0.7.4
         Compiling prettyplease v0.1.25
         Compiling bytes v1.4.0
         Compiling futures-task v0.3.28
         Compiling hashbrown v0.12.3
         Compiling rustc-demangle v0.1.23
         Compiling futures-channel v0.3.28
         Compiling regex-automata v0.3.3
         Compiling prost v0.11.9
         Compiling curve25519-dalek v4.0.0-rc.3
         Compiling parking_lot v0.12.1
         Compiling pin-project-internal v1.1.2
         Compiling inout v0.1.3
         Compiling block-buffer v0.10.4
         Compiling memoffset v0.8.0
         Compiling num-integer v0.1.45
         Compiling fastrand v1.9.0
         Compiling byteorder v1.4.3
         Compiling fixedbitset v0.4.2
         Compiling futures-util v0.3.28
         Compiling petgraph v0.6.3
         Compiling rayon v1.7.0
         Compiling pin-project v1.1.2
         Compiling digest v0.10.7
         Compiling cipher v0.4.4
         Compiling flate2 v1.0.26
         Compiling regex v1.9.1
         Compiling prost-types v0.11.9
         Compiling futures-macro v0.3.28
         Compiling curve25519-dalek-derive v0.1.0
         Compiling pyo3 v0.18.3
         Compiling which v4.4.0
         Compiling universal-hash v0.5.1
         Compiling heapless v0.7.16
         Compiling ring v0.16.20
         Compiling pyo3-macros-backend v0.18.3
         Compiling nanorand v0.7.0
         Compiling num-rational v0.4.1
         Compiling tokio v1.29.1
         Compiling log v0.4.19
         Compiling heck v0.4.1
         Compiling protoc-bin-vendored-linux-aarch_64 v3.0.0
         Compiling protoc-bin-vendored-win32 v3.0.0
         Compiling weezl v0.1.7
         Compiling protoc-bin-vendored-linux-x86_32 v3.0.0
         Compiling protoc-bin-vendored-linux-x86_64 v3.0.0
         Compiling opaque-debug v0.3.0
         Compiling lazy_static v1.4.0
         Compiling futures-io v0.3.28
         Compiling pin-utils v0.1.0
         Compiling protoc-bin-vendored-macos-x86_64 v3.0.0
         Compiling multimap v0.8.3
         Compiling protoc-bin-vendored-linux-ppcle_64 v3.0.0
         Compiling protoc-bin-vendored v3.0.0
         Compiling prost-build v0.11.9
         Compiling poly1305 v0.8.0
         Compiling flume v0.10.14
         Compiling pyo3-macros v0.18.3
         Compiling jpeg-decoder v0.3.0
         Compiling chacha20 v0.9.1
         Compiling hash32 v0.2.1
         Compiling tracing-core v0.1.31
         Compiling tokio-macros v2.1.0
         Compiling tracing-attributes v0.1.26
         Compiling aead v0.5.2
         Compiling fdeflate v0.3.0
         Compiling zune-inflate v0.2.54
         Compiling mio v0.8.8
         Compiling socket2 v0.4.9
         Compiling bit_field v0.10.2
         Compiling stable_deref_trait v1.2.0
         Compiling indoc v1.0.9
         Compiling half v2.2.1
         Compiling color_quant v1.1.0
         Compiling bytemuck v1.13.1
         Compiling ip_network_table-deps-treebitmap v0.5.0
         Compiling ip_network v0.4.1
         Compiling async-trait v0.1.71
         Compiling unindent v0.1.11
         Compiling untrusted v0.7.1
         Compiling spin v0.5.2
         Compiling smoltcp v0.10.0
         Compiling lebe v0.5.2
         Compiling exr v1.7.0
         Compiling ip_network_table v0.2.0
         Compiling qoi v0.4.1
         Compiling gif v0.12.0
         Compiling tracing v0.1.37
         Compiling png v0.17.9
         Compiling chacha20poly1305 v0.10.1
         Compiling tiff v0.8.1
         Compiling futures-executor v0.3.28
         Compiling x25519-dalek v2.0.0-rc.3
         Compiling mitmproxy v0.2.2 (/tmp/pip-install-4pg1xk6b/mitmproxy-rs_623666e421a44090991e6dfd98033f03/local_dependencies/mitmproxy)
         Compiling blake2 v0.10.6
         Compiling hmac v0.12.1
         Compiling managed v0.8.0
         Compiling base64 v0.13.1
         Compiling hex v0.4.3
         Compiling untrusted v0.9.0
      error: failed to run custom build command for `mitmproxy v0.2.2 (/tmp/pip-install-4pg1xk6b/mitmproxy-rs_623666e421a44090991e6dfd98033f03/local_dependencies/mitmproxy)`

      Caused by:
        process didn't exit successfully: `/tmp/pip-install-4pg1xk6b/mitmproxy-rs_623666e421a44090991e6dfd98033f03/target/release/build/mitmproxy-75b8ff35a79a5eef/build-script-build` (exit status: 101)
        --- stderr
        thread 'main' panicked at 'Could not find `protoc` installation and this build crate cannot proceed without
            this knowledge. If `protoc` is installed and this crate had trouble finding
            it, you can set the `PROTOC` environment variable with the specific path to your
            installed `protoc` binary.You can download it from https://github.com/protocolbuffers/protobuf/releases or from your package manager.

        For more information: https://docs.rs/prost-build/#sourcing-protoc
        ', /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/prost-build-0.11.9/src/lib.rs:1457:10
        note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
      warning: build failed, waiting for other jobs to finish...
      💥 maturin failed
        Caused by: Failed to build a native library through cargo
        Caused by: Cargo build finished with "exit status: 101": `PYTHON_SYS_EXECUTABLE="/usr/local/bin/python3.10" "cargo" "rustc" "--release" "--manifest-path" "/tmp/pip-install-4pg1xk6b/mitmproxy-rs_623666e421a44090991e6dfd98033f03/Cargo.toml" "--message-format" "json" "--lib"`
      Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/usr/local/bin/python3.10', '--compatibility', 'off'] returned non-zero exit status 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for mitmproxy-rs
Failed to build mitmproxy-rs
ERROR: Could not build wheels for mitmproxy-rs, which is required to install pyproject.toml-based projects

System Information
peek$ pip3.10 --version
pip 23.2.1 from /home/floort/.local/lib/python3.10/site-packages/pip (python 3.10)
peek$ uname -prs
OpenBSD 7.3 amd64

See the stderr message in your output - you need to provide PROTOC. :)

Thank you. I only noticed now that I somehow got a different error message before. I now get the same one as before after installing protoc.
peek$ pip3.10 install mitmproxy
Defaulting to user installation because normal site-packages is not writeable
Collecting mitmproxy
  Obtaining dependency information for mitmproxy from https://files.pythonhosted.org/packages/7a/3a/9ec933b3c556ea26690251c3928cddce4df3688ac37344b369db7975bb17/mitmproxy-10.0.0-py3-none-any.whl.metadata
  Using cached mitmproxy-10.0.0-py3-none-any.whl.metadata (8.9 kB)
Collecting aioquic-mitmproxy<0.10,>=0.9.20 (from mitmproxy)
  Using cached aioquic_mitmproxy-0.9.20.3-py3-none-any.whl (80 kB)
Collecting asgiref<3.8,>=3.2.10 (from mitmproxy)
  Obtaining dependency information for asgiref<3.8,>=3.2.10 from https://files.pythonhosted.org/packages/9b/80/b9051a4a07ad231558fcd8ffc89232711b4e618c15cb7a392a17384bbeef/asgiref-3.7.2-py3-none-any.whl.metadata
  Using cached asgiref-3.7.2-py3-none-any.whl.metadata (9.2 kB)
Requirement already satisfied: Brotli<1.1,>=1.0 in /usr/local/lib/python3.10/site-packages (from mitmproxy) (1.0.9)
Requirement already satisfied: certifi>=2019.9.11 in ./.local/lib/python3.10/site-packages (from mitmproxy) (2023.5.7)
Requirement already satisfied: cryptography<41.1,>=38.0 in /usr/local/lib/python3.10/site-packages (from mitmproxy) (39.0.1)
Collecting flask<2.4,>=1.1.1 (from mitmproxy)
  Obtaining dependency information for flask<2.4,>=1.1.1 from https://files.pythonhosted.org/packages/fd/56/26f0be8adc2b4257df20c1c4260ddd0aa396cf8e75d90ab2f7ff99bc34f9/flask-2.3.3-py3-none-any.whl.metadata
  Using cached flask-2.3.3-py3-none-any.whl.metadata (3.6 kB)
Collecting h11<0.15,>=0.11 (from mitmproxy)
  Using cached h11-0.14.0-py3-none-any.whl (58 kB)
Collecting h2<5,>=4.1 (from mitmproxy)
  Using cached h2-4.1.0-py3-none-any.whl (57 kB)
Collecting hyperframe<7,>=6.0 (from mitmproxy)
  Using cached hyperframe-6.0.1-py3-none-any.whl (12 kB)
Collecting kaitaistruct<0.11,>=0.10 (from mitmproxy)
  Using cached kaitaistruct-0.10-py2.py3-none-any.whl (7.0 kB)
Collecting ldap3<2.10,>=2.8 (from mitmproxy)
  Using cached ldap3-2.9.1-py2.py3-none-any.whl (432 kB)
Collecting mitmproxy-rs<0.3,>=0.2.0b1 (from mitmproxy)
  Using cached mitmproxy_rs-0.2.2.tar.gz (854 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting msgpack<1.1.0,>=1.0.0 (from mitmproxy)
  Using cached msgpack-1.0.6-cp310-cp310-openbsd_7_3_amd64.whl
Collecting passlib<1.8,>=1.6.5 (from mitmproxy)
  Using cached passlib-1.7.4-py2.py3-none-any.whl (525 kB)
Collecting protobuf<5,>=3.14 (from mitmproxy)
  Obtaining dependency information for protobuf<5,>=3.14 from https://files.pythonhosted.org/packages/fa/8a/e9c6b48b8f4651df1b1a9d46fe94a74ed99881141b4660aa855a798c7c53/protobuf-4.24.3-py3-none-any.whl.metadata
  Using cached protobuf-4.24.3-py3-none-any.whl.metadata (540 bytes)
Requirement already satisfied: pyOpenSSL<23.3,>=22.1 in ./.local/lib/python3.10/site-packages (from mitmproxy) (23.2.0)
Collecting pyparsing<3.2,>=2.4.2 (from mitmproxy)
  Obtaining dependency information for pyparsing<3.2,>=2.4.2 from https://files.pythonhosted.org/packages/39/92/8486ede85fcc088f1b3dba4ce92dd29d126fd96b0008ea213167940a2475/pyparsing-3.1.1-py3-none-any.whl.metadata
  Using cached pyparsing-3.1.1-py3-none-any.whl.metadata (5.1 kB)
Collecting pyperclip<1.9,>=1.6.0 (from mitmproxy)
  Using cached pyperclip-1.8.2-py3-none-any.whl
Collecting ruamel.yaml<0.18,>=0.16 (from mitmproxy)
  Obtaining dependency information for ruamel.yaml<0.18,>=0.16 from https://files.pythonhosted.org/packages/d9/0e/2a05efa11ea33513fbdf4a2e2576fe94fd8fa5ad226dbb9c660886390974/ruamel.yaml-0.17.32-py3-none-any.whl.metadata
  Using cached ruamel.yaml-0.17.32-py3-none-any.whl.metadata (17 kB)
Collecting sortedcontainers<2.5,>=2.3 (from mitmproxy)
  Using cached sortedcontainers-2.4.0-py2.py3-none-any.whl (29 kB)
Collecting tornado<7,>=6.2 (from mitmproxy)
  Using cached tornado-6.3.3-cp38-abi3-openbsd_7_3_amd64.whl
Collecting urwid-mitmproxy<2.2,>=2.1.1 (from mitmproxy)
  Using cached urwid_mitmproxy-2.1.2.1-cp310-cp310-openbsd_7_3_amd64.whl
Collecting wsproto<1.3,>=1.0 (from mitmproxy)
  Using cached wsproto-1.2.0-py3-none-any.whl (24 kB)
Collecting publicsuffix2<3,>=2.20190812 (from mitmproxy)
  Using cached publicsuffix2-2.20191221-py2.py3-none-any.whl (89 kB)
Collecting zstandard<0.22,>=0.11 (from mitmproxy)
  Using cached zstandard-0.21.0-cp310-cp310-openbsd_7_3_amd64.whl
Collecting typing-extensions<4.6,>=4.3 (from mitmproxy)
  Using cached typing_extensions-4.5.0-py3-none-any.whl (27 kB)
Collecting pylsqpack<0.4.0,>=0.3.3 (from aioquic-mitmproxy<0.10,>=0.9.20->mitmproxy)
  Using cached pylsqpack-0.3.17-cp310-cp310-openbsd_7_3_amd64.whl
Requirement already satisfied: cffi>=1.12 in /usr/local/lib/python3.10/site-packages (from cryptography<41.1,>=38.0->mitmproxy) (1.15.1)
Collecting Werkzeug>=2.3.7 (from flask<2.4,>=1.1.1->mitmproxy)
  Obtaining dependency information for Werkzeug>=2.3.7 from https://files.pythonhosted.org/packages/9b/59/a7c32e3d8d0e546a206e0552a2c04444544f15c1da4a01df8938d20c6ffc/werkzeug-2.3.7-py3-none-any.whl.metadata
  Using cached werkzeug-2.3.7-py3-none-any.whl.metadata (4.1 kB)
Collecting Jinja2>=3.1.2 (from flask<2.4,>=1.1.1->mitmproxy)
  Using cached Jinja2-3.1.2-py3-none-any.whl (133 kB)
Collecting itsdangerous>=2.1.2 (from flask<2.4,>=1.1.1->mitmproxy)
  Using cached itsdangerous-2.1.2-py3-none-any.whl (15 kB)
Requirement already satisfied: click>=8.1.3 in ./.local/lib/python3.10/site-packages (from flask<2.4,>=1.1.1->mitmproxy) (8.1.4)
Collecting blinker>=1.6.2 (from flask<2.4,>=1.1.1->mitmproxy)
  Using cached blinker-1.6.2-py3-none-any.whl (13 kB)
Collecting hpack<5,>=4.0 (from h2<5,>=4.1->mitmproxy)
  Using cached hpack-4.0.0-py3-none-any.whl (32 kB)
Collecting pyasn1>=0.4.6 (from ldap3<2.10,>=2.8->mitmproxy)
  Using cached pyasn1-0.5.0-py2.py3-none-any.whl (83 kB)
Collecting ruamel.yaml.clib>=0.2.7 (from ruamel.yaml<0.18,>=0.16->mitmproxy)
  Using cached ruamel.yaml.clib-0.2.7-cp310-cp310-openbsd_7_3_amd64.whl
Requirement already satisfied: pycparser in /usr/local/lib/python3.10/site-packages (from cffi>=1.12->cryptography<41.1,>=38.0->mitmproxy) (2.21)
Collecting MarkupSafe>=2.0 (from Jinja2>=3.1.2->flask<2.4,>=1.1.1->mitmproxy)
  Using cached MarkupSafe-2.1.3-cp310-cp310-openbsd_7_3_amd64.whl
Using cached mitmproxy-10.0.0-py3-none-any.whl (1.6 MB)
Using cached asgiref-3.7.2-py3-none-any.whl (24 kB)
Using cached flask-2.3.3-py3-none-any.whl (96 kB)
Using cached protobuf-4.24.3-py3-none-any.whl (175 kB)
Using cached pyparsing-3.1.1-py3-none-any.whl (103 kB)
Using cached ruamel.yaml-0.17.32-py3-none-any.whl (112 kB)
Using cached werkzeug-2.3.7-py3-none-any.whl (242 kB)
Building wheels for collected packages: mitmproxy-rs
  Building wheel for mitmproxy-rs (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Building wheel for mitmproxy-rs (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [303 lines of output]
      Running `maturin pep517 build-wheel -i /usr/local/bin/python3.10 --compatibility off`
      🍹 Building a mixed python/rust project
      🔗 Found pyo3 bindings with abi3 support for Python ≥ 3.10
      🐍 Not using a specific python interpreter
         Compiling autocfg v1.1.0
         Compiling proc-macro2 v1.0.66
         Compiling unicode-ident v1.0.11
         Compiling cfg-if v1.0.0
         Compiling libc v0.2.147
         Compiling scopeguard v1.2.0
         Compiling version_check v0.9.4
         Compiling typenum v1.16.0
         Compiling getrandom v0.2.10
         Compiling generic-array v0.14.7
         Compiling quote v1.0.31
         Compiling syn v1.0.109
         Compiling syn v2.0.26
         Compiling lock_api v0.4.10
         Compiling simd-adler32 v0.3.5
         Compiling rand_core v0.6.4
         Compiling target-lexicon v0.12.10
         Compiling semver v1.0.18
         Compiling adler v1.0.2
         Compiling cc v1.0.79
         Compiling crossbeam-utils v0.8.16
         Compiling memchr v2.5.0
         Compiling miniz_oxide v0.7.1
         Compiling crypto-common v0.1.6
         Compiling memoffset v0.9.0
         Compiling futures-core v0.3.28
         Compiling rustc_version v0.4.0
         Compiling pyo3-build-config v0.18.3
         Compiling crossbeam-epoch v0.9.15
         Compiling anyhow v1.0.72
         Compiling either v1.8.1
         Compiling subtle v2.5.0
         Compiling num_cpus v1.16.0
         Compiling smallvec v1.11.0
         Compiling futures-sink v0.3.28
         Compiling once_cell v1.18.0
         Compiling itertools v0.10.5
         Compiling parking_lot_core v0.9.8
         Compiling zeroize_derive v1.4.2
         Compiling io-lifetimes v1.0.11
         Compiling rayon-core v1.11.0
         Compiling platforms v3.0.2
         Compiling pin-project-lite v0.2.10
         Compiling crossbeam-deque v0.8.3
         Compiling crossbeam-channel v0.5.8
         Compiling zeroize v1.6.0
         Compiling backtrace v0.3.68
         Compiling indexmap v1.9.3
         Compiling crc32fast v1.3.2
         Compiling gimli v0.27.3
         Compiling rustix v0.37.23
         Compiling cpufeatures v0.2.9
         Compiling prost-derive v0.11.9
         Compiling pyo3-ffi v0.18.3
         Compiling errno v0.3.1
         Compiling object v0.31.1
         Compiling addr2line v0.20.0
         Compiling spin v0.9.8
         Compiling num-traits v0.2.15
         Compiling tempfile v3.6.0
         Compiling slab v0.4.8
         Compiling bytes v1.4.0
         Compiling prettyplease v0.1.25
         Compiling rustc-demangle v0.1.23
         Compiling regex-syntax v0.7.4
         Compiling bitflags v1.3.2
         Compiling hashbrown v0.12.3
         Compiling futures-channel v0.3.28
         Compiling futures-task v0.3.28
         Compiling regex-automata v0.3.3
         Compiling prost v0.11.9
         Compiling curve25519-dalek v4.0.0-rc.3
         Compiling parking_lot v0.12.1
         Compiling pin-project-internal v1.1.2
         Compiling block-buffer v0.10.4
         Compiling inout v0.1.3
         Compiling num-integer v0.1.45
         Compiling memoffset v0.8.0
         Compiling futures-util v0.3.28
         Compiling fixedbitset v0.4.2
         Compiling byteorder v1.4.3
         Compiling fastrand v1.9.0
         Compiling petgraph v0.6.3
         Compiling pin-project v1.1.2
         Compiling rayon v1.7.0
         Compiling cipher v0.4.4
         Compiling digest v0.10.7
         Compiling flate2 v1.0.26
         Compiling prost-types v0.11.9
         Compiling regex v1.9.1
         Compiling pyo3 v0.18.3
         Compiling curve25519-dalek-derive v0.1.0
         Compiling futures-macro v0.3.28
         Compiling which v4.4.0
         Compiling universal-hash v0.5.1
         Compiling heapless v0.7.16
         Compiling pyo3-macros-backend v0.18.3
         Compiling ring v0.16.20
         Compiling nanorand v0.7.0
         Compiling num-rational v0.4.1
         Compiling tokio v1.29.1
         Compiling pin-utils v0.1.0
         Compiling opaque-debug v0.3.0
         Compiling lazy_static v1.4.0
         Compiling protoc-bin-vendored-linux-ppcle_64 v3.0.0
         Compiling protoc-bin-vendored-win32 v3.0.0
         Compiling heck v0.4.1
         Compiling protoc-bin-vendored-linux-aarch_64 v3.0.0
         Compiling protoc-bin-vendored-linux-x86_32 v3.0.0
         Compiling multimap v0.8.3
         Compiling log v0.4.19
         Compiling weezl v0.1.7
         Compiling futures-io v0.3.28
         Compiling protoc-bin-vendored-linux-x86_64 v3.0.0
         Compiling protoc-bin-vendored-macos-x86_64 v3.0.0
         Compiling protoc-bin-vendored v3.0.0
         Compiling prost-build v0.11.9
         Compiling poly1305 v0.8.0
         Compiling flume v0.10.14
         Compiling pyo3-macros v0.18.3
         Compiling jpeg-decoder v0.3.0
         Compiling chacha20 v0.9.1
         Compiling hash32 v0.2.1
         Compiling tracing-core v0.1.31
         Compiling tokio-macros v2.1.0
         Compiling tracing-attributes v0.1.26
         Compiling aead v0.5.2
         Compiling fdeflate v0.3.0
         Compiling zune-inflate v0.2.54
         Compiling socket2 v0.4.9
         Compiling mio v0.8.8
         Compiling ip_network v0.4.1
         Compiling unindent v0.1.11
         Compiling bytemuck v1.13.1
         Compiling smoltcp v0.10.0
         Compiling half v2.2.1
         Compiling async-trait v0.1.71
         Compiling lebe v0.5.2
         Compiling untrusted v0.7.1
         Compiling stable_deref_trait v1.2.0
         Compiling spin v0.5.2
         Compiling ip_network_table-deps-treebitmap v0.5.0
         Compiling color_quant v1.1.0
         Compiling indoc v1.0.9
         Compiling bit_field v0.10.2
         Compiling exr v1.7.0
         Compiling ip_network_table v0.2.0
         Compiling gif v0.12.0
         Compiling qoi v0.4.1
         Compiling tracing v0.1.37
         Compiling png v0.17.9
         Compiling chacha20poly1305 v0.10.1
         Compiling tiff v0.8.1
         Compiling futures-executor v0.3.28
         Compiling x25519-dalek v2.0.0-rc.3
         Compiling mitmproxy v0.2.2 (/tmp/pip-install-3hsunsob/mitmproxy-rs_617044cbb859458a82eceb856b9c3982/local_dependencies/mitmproxy)
         Compiling hmac v0.12.1
         Compiling blake2 v0.10.6
         Compiling untrusted v0.9.0
         Compiling hex v0.4.3
         Compiling base64 v0.13.1
         Compiling managed v0.8.0
         Compiling boringtun v0.5.3
         Compiling futures v0.3.28
         Compiling image v0.24.6
      error: could not compile `boringtun` due to 14 previous errors
      warning: build failed, waiting for other jobs to finish...
      💥 maturin failed
        Caused by: Failed to build a native library through cargo
        Caused by: Cargo build finished with "exit status: 101": `PYTHON_SYS_EXECUTABLE="/usr/local/bin/python3.10" "cargo" "rustc" "--release" "--manifest-path" "/tmp/pip-install-3hsunsob/mitmproxy-rs_617044cbb859458a82eceb856b9c3982/Cargo.toml" "--message-format" "json" "--lib"`
      error[E0432]: unresolved import `poll`
        --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/mod.rs:47:5
         |
      47 | use poll::{EventPoll, EventRef, WaitResult};
         |     ^^^^ use of undeclared crate or module `poll`

      error[E0432]: unresolved imports `tun`, `crate::device::errno_str`, `super::errno`, `super::errno_str`
        --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/mod.rs:48:5
         |
      48 | use tun::{errno, errno_str, TunSocket};
         |     ^^^ use of undeclared crate or module `tun`
         |
        ::: /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/drop_privileges.rs:4:5
         |
      4  | use crate::device::errno_str;
         |     ^^^^^^^^^^^^^^^^^^^^^^^^
         |
        ::: /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/udp_unix.rs:4:13
         |
      4  | use super::{errno, errno_str, Error};
         |             ^^^^^  ^^^^^^^^^

      error[E0308]: mismatched types
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/api.rs:67:57
          |
      67  |                         "set=1" => api_set(&mut reader, d),
          |                                    -------              ^ types differ in mutability
          |                                    |
          |                                    arguments to this function are incorrect
          |
          = note: expected mutable reference `&mut LockReadGuard<'_, Device>`
                             found reference `&Device`
      note: function defined here
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/api.rs:202:4
          |
      202 | fn api_set(reader: &mut BufReader<&UnixStream>, d: &mut LockReadGuard<Device>) -> i32 {
          |    ^^^^^^^                                      -----------------------------

      error[E0308]: mismatched types
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/api.rs:97:57
          |
      97  |                         "set=1" => api_set(&mut reader, d),
          |                                    -------              ^ types differ in mutability
          |                                    |
          |                                    arguments to this function are incorrect
          |
          = note: expected mutable reference `&mut LockReadGuard<'_, Device>`
                             found reference `&Device`
      note: function defined here
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/api.rs:202:4
          |
      202 | fn api_set(reader: &mut BufReader<&UnixStream>, d: &mut LockReadGuard<Device>) -> i32 {
          |    ^^^^^^^                                      -----------------------------

      error[E0599]: no method named `set_fwmark` found for struct `Arc<UDPSocket>` in the current scope
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/peer.rs:130:22
          |
      130 |             udp_conn.set_fwmark(fwmark)?;
          |                      ^^^^^^^^^^ method not found in `Arc<UDPSocket>`

      error[E0063]: missing field `sin_len` in initializer of `libc::sockaddr_in`
        --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/udp_unix.rs:18:20
         |
      18 |         let addr = sockaddr_in {
         |                    ^^^^^^^^^^^ missing `sin_len`

      error[E0063]: missing field `sin_len` in initializer of `libc::sockaddr_in`
        --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/udp_unix.rs:58:20
         |
      58 |         let addr = sockaddr_in {
         |                    ^^^^^^^^^^^ missing `sin_len`

      error[E0063]: missing field `sin_len` in initializer of `libc::sockaddr_in`
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/udp_unix.rs:102:20
          |
      102 |         let addr = sockaddr_in {
          |                    ^^^^^^^^^^^ missing `sin_len`

      error[E0063]: missing field `sin_len` in initializer of `libc::sockaddr_in`
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/udp_unix.rs:181:24
          |
      181 |         let mut addr = sockaddr_in {
          |                        ^^^^^^^^^^^ missing `sin_len`

      error[E0599]: no method named `wait` found for struct `Arc<_>` in the current scope
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/mod.rs:234:29
          |
      234 |                 match queue.wait() {
          |                             ^^^^ method not found in `Arc<_>`

      error[E0599]: no method named `set_fwmark` found for reference `&Arc<UDPSocket>` in the current scope
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/mod.rs:491:18
          |
      491 |             sock.set_fwmark(mark)?;
          |                  ^^^^^^^^^^ method not found in `&Arc<UDPSocket>`

      error[E0599]: no method named `set_fwmark` found for reference `&Arc<UDPSocket>` in the current scope
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/mod.rs:495:18
          |
      495 |             sock.set_fwmark(mark)?;
          |                  ^^^^^^^^^^ method not found in `&Arc<UDPSocket>`

      error[E0599]: no method named `set_fwmark` found for reference `&Arc<UDPSocket>` in the current scope
         --> /home/floort/.cargo/registry/src/github.com-1ecc6299db9ec823/boringtun-0.5.3/src/device/mod.rs:501:22
          |
      501 |                 sock.set_fwmark(mark)?
          |                      ^^^^^^^^^^ method not found in `&Arc<UDPSocket>`

      error: aborting due to 13 previous errors

      Some errors have detailed explanations: E0063, E0308, E0432, E0599.

      For more information about an error, try `rustc --explain E0063`.

      Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/usr/local/bin/python3.10', '--compatibility', 'off'] returned non-zero exit status 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for mitmproxy-rs
Failed to build mitmproxy-rs
ERROR: Could not build wheels for mitmproxy-rs, which is required to install pyproject.toml-based projects

Thanks for the quick turnaround. I'm afraid you're running into https://github.com/cloudflare/boringtun/issues/82 here. That's a bit of a tricky problem for us unfortunately.

We could make mitmproxy run without mitmproxy_rs, and then mark our dependency on mitmproxy_rs with a != openbsd platform marker (assuming such a thing exists). I'm happy to accept a patch for that, but it's nothing I'm actively pursuing.
Alternatively, the obvious solution would be to fix up boringtun. To be frank I have no idea how much work that would take. We don't use their I/O parts, which seem to be failing here. 🤷

I see an aditional option:
Mark mitmproxy and/or mitmproxy_rs as only supporting win32, Linux and macOS and removing any reference to operating systems like OpenBSD from the docs. I'll submit a pull request for this option.

Looking a bit closer: boringtun does actually have device as a separate module (https://github.com/cloudflare/boringtun/blob/e1d6360d6ab4529fc942a078e4c54df107abe2ba/boringtun/src/lib.rs#L8-L9), so this should actually work again with the next mitmproxy release. Would you mind testing whether pip install mitmproxy-rs==0.3.5 works for you?

That might fix it when rust 1.72.0  is available in the next OpenBSD release. I will test and report back.

What Rust version is OpenBSD on right now? :)

That's version 1.68.0 for OpenBSD 7.3.

Thanks. I just shipped mitmproxy 10.1 with a MSRV of 1.70, looking forward to the next OpenBSD update! :)

Thanks. At least that build issue seems to be resolved. Tested on OpenBSD pre-release snapshots there is still an issue with the clock type in https://github.com/cloudflare/boringtun/blob/master/boringtun/src/sleepyinstant/unix.rs that I will report upstream.

Thanks! 🍰 If we can get a PR for boringtun that makes it work with OpenBSD, I'd be happy to point mitmproxy-rs to use that. That kind of patching is super easy with Rust fortunately.

@floort what kind of issue? Is that due possibly use/reference of CLOCK_BOOTTIME?
I think something like https://github.com/cloudflare/boringtun/pull/386 should do the trick if that's the case!

authors: floort iamleot mhils


text:
Query array fix

Fix for #3072 and #3254
Added format_pair function and changed the implementation of format_dict.
Did relevant changes in urlencoded.py

This is ready for review.

It was a learning experience.Thanks!
I will make all the changes.


text:
Remove duplicate answers in DNS queries

Description
Fixes #6647 by assuming all DNS queries are made over UDP, will need to be reworked when TCP support is added.
Checklist

[x] I have updated tests where applicable.
[x] I have added an entry to the CHANGELOG.

I tried adding this:
resp = dns.Message.unpack(resp_bytes := await s.read(65535))
assert resp_bytes = tdnsresp().packed

here:
https://github.com/mitmproxy/mitmproxy/blob/1a02ebb89f6765d827f2fe0086dfe5960eb6e093/test/mitmproxy/addons/test_proxyserver.py#L294-L299
because that test would've checked for duplicates (among other things) I guess, but it seems like s.read is only getting one answer instead of two (8.8.8.8 and 8.8.4.4), and I tried comparing it with dig +noedns dns.google in wireshark and they seem to match up exactly except for id of course and the answer count (1 in s.read and 2 in dig's request).
Will send another PR if I figure it out.

Good catch and thanks for the PR.
LGTM, but it shouldn't matter what value we use in the type param (as long as it's DGRAM or STREAM). If anything, we need to query/reflect the type of the upstream connection, not whether DNS answers via UDP or TCP.
Perhaps we should therefore just specify SOCK_STREAM, since it's usage for upstream endpoints is more likely as of today in mitmproxy. (But again, I don't know of any kconfig, sysctl, gai.conf or resolv.conf flags, that would allow only one of UDP and TCP but not the other.)

@meitinger: approver merges :)

authors: meitinger mhils sujaldev


text:
Updating menu doesn't not change published status

Steps to Reproduce

Create a menu.
Publish the course. Not that the "You have unpublished changes" message is cleared.
Make a change to the menu, such as adding another item.
Click on the publish button to open the drawer.

Expected Behavior

There should be a message "You have unpublished changes"

Actual Behavior

No message
Clicking publish button has no effect

Did you click the Save button after adding the menu? The "Save" button in the panel doesn't actually save to the server. The user needs to click the "Save" in the menu page to POST changes to the server

Closing, I will address the menu closing UX quirk in #793

authors: noisecapella pdpinch

repo: mitodl/ocw-studio


text:
🛑 INS-PC is down

In b996540, INS-PC (https://rdp.nipponschoolnepal.com) was down:

HTTP code: 530
Response time: 90 ms

Resolved: INS-PC is back up in 8fa67c9 after 15 hours, 35 minutes.

repo: mitraNBIT/Uptime


text:
cargo-insta: fix --manifest-path

Prior to this change --manifest-path only worked properly if it pointed to the root of a non-virtual workspace.
Rewrite all the cargo interaction to use cargo-metadata which crucially provides Metadata::resolve::root which is used to determine which package --manifest-path was pointing to.
https://doc.rust-lang.org/cargo/reference/workspaces.html#virtual-workspace

This seems like a good change. A bit of my worry is that we cargo-insta has abysmal test coverage, so I think I would need to do some manual testing on this.

Makes sense to me. I did test this locally.

I did find a buglet here in handling a virtual workspace where a manifest path is not specified - it should be fixed now.

@mitsuhiko could you cut a new release please?

authors: mitsuhiko tamird

repo: mitsuhiko/insta


text:
.mdlrc not being processed unless full path provided

Relates to #133 and #121
From what I'm reading it appears that this was supposed to have been working.
I created a .mdlrc file with the following contents to disable the indent rule because I want to use 4 space indent, not 2 space (i think i actually want a style, but didnt get that far yet and not sure the rule supports it)
rules "~MD007"

When I run mdl -c .mdlrc -l | grep MD007 I should get nothing
# This is with ./.mdlrc in place
$ mdl -l | grep MD007
MD007 - Unordered list indentation
# Referencing the file
$ mdl -l -c .mdlrc | grep MD007
MD007 - Unordered list indentation
# Specifically referencing with pathing
$ mdl -l -c ./.mdlrc | grep MD007
$
# Letting it be my 'default'
$ mv .mdlrc ~/
$ mdl -l | grep MD007

It appears that maybe this is fixed but a release needs to be cut

Markdownlint 0.4.0 has just been release with fixes for loading .mdlrc, so this should be fixed for you. Let me know if you still have problems.

authors: gregswift mivok

repo: mivok/markdownlint


text:
Add delegate for DidSetIdentify

The JoinExperiement has Async call to SetIdentify.
And If we want to use experiment on the startup, we might check the tweak before the setIdentify Completed.
I added a delegate  "mixpanelDidSetIdentify" , which called when the SetIdentify method completed.

Upon giving this a second look, I don't think we want to call joinExperimentsWithCallback: inside of identify: as this has a huge potential to break with A/B tests that are using an alias.

@samgreen,  Do you have another idea / solution for getting the user experiments right after we call to SetIdentify?
Looks to me like a mandatory feature for signout-> sign in (with another user) flow.

authors: elihayc samgreen

repo: mixpanel/mixpanel-iphone


text:
unkpg.com is intermittently displaying 502/520 errors when serving packages

Not sure where to put this but your site is returning 502 errors and any assets that I have served form you are now not working.  All my sites are now broken.

We're also seeing this intermittently.
Example failing url: https://unpkg.com/@zywave/zui-bundle@latest/dist/bundle.js
Error page:

This issue, unfortunately, still happens.
Example: https://unpkg.com/axios/dist/axios.min.js

Ray ID was 7613f3c39940502a

authors: azherebtsov p-ob ste6412

repo: mjackson/unpkg


text:
Some containers don't respect the size on mobile Huawei Android Email clients

Sorry if this has been posted before. I've searched through and haven't found anything related.
I also understand the Huawei Android Email client is not a tested email client. However, this is a real problem that will become more pronounced as the market share increases.
The Bug
On some Huawei Android mobile email clients, containers seem to have some extra space. Most of the times the 'spill' seems to be on the right (also saw some to the left, although usually half the size of the right ones).
The bottom also appears affected, mainly by mj-body.
This is happening, so far, in sections, columns and images. Because images live inside columns that live inside sections, the result is more pronounced in images.
Even if you can minizime the problem by selecting a background color similar to the image in the mj-section, the size of it is never really correct. Even mj-text displays some extra space to the right.
To Reproduce
Steps to reproduce the behavior:

Create a file with this MJML code:

<mjml>
  <mj-body background-color="red">
    <mj-section
         padding="0"
         background-color="pink">
      <mj-column background-color="orange">
        <mj-image
           fluid-on-mobile="true"
           padding="0"
           src="http://5vph.mj.am/img/5vph/b/1g86w/0696u.jpeg"
           />
      </mj-column>
    </mj-section>
    <mj-section background-color="#f0f0f0">
      <mj-column>
        <mj-text>
           This is some sample text. This is some sample text.
           This is some sample text. This is some sample text.
           This is some sample text. This is some sample text.
        </mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Render it to HTML by doing mjml -r test.mjml -o test.html
Send the HTML to an email address with any system
See error

Expected behavior
'Spills' from parent containers should not be present. Container sizes should be correctly maintained.
MJML environment (please complete the following information):

OS: Android
MJML Version 4.2.0
MJML tool used [MJML cli, MJML vscode extension]

Email sending environment(for rendering issues):

Platform used to send the email [Guestfolio] (doesn't change the html output)

Affected email clients (for rendering issues):

Email Client: Huawei Android Email client
OS: Android
Note: Could not test on other Android devices so far.
Gmail, Outlook and Apple products are ok (to the best of their own capabilities; example: Outlook has some flaws with padding).

Screenshots
Actual device display:

The desired result shoud be (photoshoped):

Additional context

Sorry about the generic answer here, but it will be the same as previous issue on this client.
As it's not a major client and not available in litmus/eoa we have no real way to try identify what's happening.
We would be happy to merge any PR, but it looks like the engine behind this email client is doing a lot of non-standard things with the HTML.

I understand completely.
But at least these issues become identified. So if someone searches for them they'll find some details.
Meanwhile I'll be trying to figure what underlying code is making the unexpected issues.

Feel free to re-open if someone willing to work on this

authors: iRyusa urbgimtam

repo: mjmlio/mjml


text:
mj-body naming looks wrong in docs

As I see from all examples there is no mjml-body, correct it is mj-body.
But when navigating the docs you can see, that is named mjml-body
https://mjml.io/documentation/#mjml-body

The title refers to the package name instead of the tag name (#1480), this will be changed in the next release of the doc as it seems to confuse people.

authors: iRyusa iamandrewluca


text:
Score Display Background Issue

Hey Guys,
We should take a look at the score_display handling.  I added a background animation in my YAML that works great with one player, but as soon as you add another, the background animation disappears.  Just wanted to get this into the tracking system before I forget about it.  :)

This has been resolved

repo: mjocean/PyProcGameHD-SkeletonGame


text:
Hashicorp providers appear to have moved to a different repo breaking codegen

It appears that several hashicorp maintained providers have moved from https://github.com/terraform-providers into https://github.com/hashicorp .
This breaks the codegen for adding new providers, and the makecode.py script does not currently provide useful information when it fails to pull these repos.
I added some temporary logging to demonstrate the situation:
aus-tmay1:python-terrascript taylor.may$ make code
rm -f tests/*.pyc
rm -f terrascript/*.pyc
rm -f terrascript/*/*.pyc
rm -f .coverage
rm -f .noseid*
( cd tools && ./makecode.py )
INFO:root:alicloud
INFO:root:archive
INFO:root:arukas
INFO:root:aws
INFO:root:bitbucket
INFO:root:clc
INFO:root:chef
INFO:root:circonus
INFO:root:cloudflare
INFO:root:cloudscale
INFO:root:cloudstack
INFO:root:cobbler
INFO:root:datadog
ERROR:root:Missing 'provider.go' for repo 'archive' in '/var/folders/wr/4_8vkc1d7_x52gzplzw6bvc9l0j93f/T/tmpuq_v396t' resultcode [0]
archive
b"Cloning into '.'...\n"
INFO:root:digitalocean
INFO:root:dns
INFO:root:dme
INFO:root:dnsimple
INFO:root:docker
INFO:root:dyn
INFO:root:external
INFO:root:fastly
ERROR:root:Missing 'provider.go' for repo 'dns' in '/var/folders/wr/4_8vkc1d7_x52gzplzw6bvc9l0j93f/T/tmpjcrsxafq' resultcode [0]
dns
b"Cloning into '.'...\n"
INFO:root:github
INFO:root:gitlab
INFO:root:google
INFO:root:google-beta
ERROR:root:Missing 'provider.go' for repo 'external' in '/var/folders/wr/4_8vkc1d7_x52gzplzw6bvc9l0j93f/T/tmpwtqbe9f6' resultcode [0]
external
b"Cloning into '.'...\n"
INFO:root:grafana

It looks like github is doing a redirect for several of these repos, however the provider.go is at a different path for the ones that are falling through. For example, instead of being in the root of the repo, the tls provider has it at internal/provider/provider.go

Hi @starhawking, thanks for reporting this. The logic in makecode.py really needs a lot of work. Have a look at #issue145 for another problem with makecode.py. I hope to find some time this weekend to look into these problems.

Hi @starhawking, thanks for reporting this. The logic in makecode.py really needs a lot of work. Have a look at
#issue145 for another problem with makecode.py. I hope to find some time this weekend to look into these problems.

Thanks for the super quick response!
I was starting to put together a PR for this if you'd like it. I found a lot of places where things had moved in the repos, and the clone depth of 0 was no longer catching the provider.go file, and some had moved the provider.go to another name entirely. I don't quite have all the edge cases captured yet tho.

FYI: I started a separate discussion (#149) on the issue of making makecode.py more robust.

I think some of the issues with moved directories (and moved providers.go) should be solved by https://github.com/mjuenema/python-terrascript/pull/150 (which I made while @mjuenema was investigating better alternatives)

@starhawking Feel free to add your name to CONTRIBUTORS.md and create a Pull Request for it. You deserve it.

Also, if you pull develop now, you'll be able to run make providers and it would actually handle some (all) of those cases, but the increased logging would be good non-the-less.

authors: ilons mjuenema starhawking

repo: mjuenema/python-terrascript


text:
Fix zxing-core 3.4.0 crashes on Android < 7.0

Downgrade zxing to 3.3.3 can fix the crash.
https://github.com/zxing/zxing/issues/1170#issuecomment-494806839

Actually I think it would be better to fork this repo and make these changes to support a lower version.

authors: magicismight mkdesilva

repo: mkdesilva/react-native-qr-image-reader


text:
Consider switching dependency logic to 'withDependencies' introduced in Gradle 4.4

https://docs.gradle.org/4.4/javadoc/org/gradle/api/artifacts/Configuration.html#withDependencies(org.gradle.api.Action)
This is some more backward incompatibility though as the API was just introduced.

Initial migration shows lots of tests failing for 4.4 and 4.5, but not with 4.6 when using withDependencies


text:
Upgrade HESK 2.5.5 > HESK 2.5.5 / Mods for HESK 1.7

Hi, When I try to upgrade a ticket system HESK 2.5.5 to HESK 2.5.5 including Mods for HESK 1.7.
I get a sql error. I just won't install.
So I tried to upgrade to 1.6 and from there to 1.7 and that worked. Unfortenately all tickets are over the place again ;-)

I just ran a clean install of HESK 2.5.5, followed by a Mods for HESK 1.7 install. I did not get any errors. Can you provide the SQL error you got?

It said ... cannot connect to sql

It sounds like a database connection issue then. What process are you using to update this helpdesk?

At first I have chosen the install as from a normal HESK installation. After that I tried every other option. I checked the database settings e few times. But it was correct, since I was also able to install with MFH1.6. After that I had upgraded to 1.7. My ticket system was actually modified very much. Maybe that is the reason?
I have one more ticket system that should be upgraded. Maybe you want to do the install, so you can see?

If you can send me an email with the following, I'll see what happens when I run the install:

Any credentials needed to access filesystem
Any credentials needed to access database
URL of HESK installation to be updated

Please give me some time to prepare :-)
Thanks for helping :-)
Van:  Mike Koch notifications@github.com
Beantwoorden - Aan:  mkoch227/Mods-for-HESK
<reply+008cacdf06e5c8edf6b54cf6bdfeb924930b351d9076c38d92cf0000000110c28f799
2a169ce032ed661@reply.github.com>
Datum:  maandag 5 januari 2015 18:44
Aan:  mkoch227/Mods-for-HESK Mods-for-HESK@noreply.github.com
CC:  Bas Cuppen bas@cuppen.de
Onderwerp:  Re: [Mods-for-HESK] Upgrade HESK 2.5.5 > HESK 2.5.5 / Mods for
HESK 1.7 (#104)
If you can send me an email with the following, I'll see what happens when I
run the install:

Any credentials needed to access filesystem
Any credentials needed to access database
URL of HESK installation to be updated
‹
Reply to this email directly or view it on GitHub
https://github.com/mkoch227/Mods-for-HESK/issues/104#issuecomment-68745304
.

Actually, would you be able to send me a backup of the database that hasn't been updated yet? That way I can play around with the data without ruining any production data.

Closed due to inactivity. If you still need assistance, reopen this same issue.


text:
Threads are not calculated correctly for multi processing

The number of threads for multiprocessing is undercalculated. For example when the threads passed are 2 the partitioning of the data is defensive and always assigns a single thread. As a workaround for now is to pass threads: 3 or more.
This affects the following:
SalmonEncryptor
SalmonDecryptor
SalmonFileImporter
SalmonFileExporter

fixed 1dbcb5f60aeecc33a488636e06980bb6f635c211


text:
is a mlx_lm.train command feasible?

Hi,
Given ~64/128/192GB or ram, would it be worthwhile/feasible to have a mlx_lm.train command to do full model fine-tuning (so not LoRa)? I could obviously try and implement in mlx directly but maybe a higher level command is feasible?

It's feasible for the right model size. There are two places you could look as starting points:

The Transformer LM example. That does training for a Transformer model
The LoRA example. In this example you could remove the call to model.freeze and the lora layers and that should give you full model training.

Watch out for lower precision though. Without other changes you'd likely want to use float32 for full model training.

authors: MichelNivard awni

repo: ml-explore/mlx-examples


text:
[Bug] Loading Model and cold start prompting freezes application

🐛 Bug
I'm noticing this both with using the default LLama-2-7b and TinyLlama-1.1b. When loading the model for the first time or when prompting the model for the first time. It halts the process and the UI freezes. It takes a couple seconds before the UI thread becomes responsive again.
If you have multiple workers in your application outside of the model loading, it will result in the Android OS killing the application with an ANR (Android Not Responding) message. These type of ANR happen when you try performing too much work on the main thread so I'm assuming we are missing some asynchronous loading of the model weights into memory or when we try prompting the model.
To Reproduce
Steps to reproduce the behavior:

try loading llama-2 based model on a device

Expected behavior
The model weights are loading asynchronously into memory and interacting with the model is also being executed on a background thread.
Environment

Platform (e.g. WebGPU/Vulkan/IOS/Android/CUDA): Android
Operating system (e.g. Ubuntu/Windows/MacOS/...): Android 13
Device (e.g. iPhone 12 Pro, PC+RTX 3090, ...): Samsung Tab 7 Ultra (16GB RAM)
How you installed MLC-LLM (conda, source): source
How you installed TVM-Unity (pip, source): source
Python version (e.g. 3.10): 3.11.x
GPU driver version (if applicable): NA
CUDA/cuDNN version (if applicable): NA
TVM Unity Hash Tag (python -c "import tvm; print('\n'.join(f'{k}: {v}' for k, v in tvm.support.libinfo().items()))", applicable if you compile models): NA
Any other relevant information: this behavior has always been around

This is interesting. I think one take away is that we should place the initialization of the chat module (aka chat.reload) also in the separate thread(just like the thread we use for decode).
Note that in iOS this is achieved with a threadworker, would be great to check what is the case in android

See https://github.com/mlc-ai/mlc-llm/blob/main/ios/MLCChat/States/ChatState.swift#L325 how we wrap things in a threadWorker.push

I'm planning to debug this more while looking into https://github.com/mlc-ai/mlc-llm/issues/1295, the issue is that atm I'm unable to debug because there is no native build system integration with gradle which makes it unable to debug c++ code directly from Android Studio.

llm_chat.cc / Reload function:
Step 1: Process config json string executed in 0.307916 ms
Step 2: Set tokenizer executed in 99.319792 ms
Step 3: Initialize vm executed in 14.728854 ms
Step 4: Initialize sample functions executed in 0.003854 ms
Step 5: Load params in nd-array cache executed in 783.505261 ms
Step 6: KV cache creation executed in 10.713750 ms
Step 7: Pre-allocate fixed size ndarray executed in 1.455156 ms
Step 8: Reset chat executed in 0.012032 ms

authors: tobrun tqchen

repo: mlc-ai/mlc-llm


text:
Cannot auto detect device-name on linux cpu platform [Bug]

🐛 Bug

when i build project in linux without cpu , and use mlc_chat_cli to infer llama2 model, something goes wrong.
terminate called after throwing an instance of 'tvm::runtime::InternalError'
  what():  [14:35:58] /root/autodl-tmp/Projects/mlc-llm/cpp/cli_main.cc:67: Cannot auto detect device-name
Stack trace:
  [bt] (0) /root/autodl-tmp/Projects/mlc-llm/build/tvm/libtvm_runtime.so(tvm::runtime::Backtrace[abi:cxx11]()+0x2c) [0x7fbca818e69c]
  [bt] (1) ./mlc_chat_cli(tvm::runtime::detail::LogFatal::Entry::Finalize()+0x3d) [0x55642a3e6acd]
  [bt] (2) ./mlc_chat_cli(+0xab3f) [0x55642a3dcb3f]
  [bt] (3) ./mlc_chat_cli(+0x9975) [0x55642a3db975]
  [bt] (4) /usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7fbca7c76083]
  [bt] (5) ./mlc_chat_cli(+0xa10e) [0x55642a3dc10e]

Aborted (core dumped)

To Reproduce
Steps to reproduce the behavior:

mkdir -p build && cd build
python3 ../cmake/gen_cmake_config.py  # only cpu!
cmake .. && cmake --build . --parallel $(nproc) && cd ..
./mlc_chat_cli --model ./dist/models/Llama-2-7b-chat-hf-q4f16_1-MLC

mlc-llm does not support cpu?

MLC-LLM only supports GPU (including i-GPU), no CPU backend for now

Thanks!


text:
[Op][Gradient] More gradients and polishment

This PR introduces more gradients for operators and polishes the structure and tests. To be specific,

Overload __neg__ for relax expr.
Complete the gradients from unary, binary operators.
Use overloaded operators instead of function in the implementation to make the calculation more clear. (E.g. use a + b instead of add(a, b))
Add the annotation of the return value. (List[Expr])
Refactor tests.

Could you send the __neg__ to tlc with a test? Thanks!

repo: mlc-ai/relax


text:
Fix duration

Remove support for Python 3.6 as it reached its end of life in December 2021.
Fix duration measurement : The last_duration was computed before making measurement, and the _last_measured_time was set after, so we "lost" some time. Measurement on Windows Intel Power Gadget could take up to 1.6 seconds. For GPU on Linux up to 0.07 second.

Which version can I install to test the solution ?
I'm really willing to test this solution.
Thanks again for all your work