Question: Undelete account?

I don't understand if the account was deleted or suspended? Does the account still show up in the admin interface?
Note that suspending an account also bans their email address.

It seems you're using a *different* username than that of the account which is to be re-used. If you want to re-use the email address but with a different name, you can delete the old account with `tootctl accounts delete USERNAME`.

Undelete account
Hey,

I was experimenting with a hachyderm account as I wasn’t sure whether to move my mastodon.social account to it. As I wasn’t sure I ended up deleting my account.

I’ve since seen a lot of similar minded folk move over and so have decided I’d like to do the same, but am I able to reinstate the deleted account?

I didn’t make any posts so it’s just bringing back the account/username I’m trying to do. Is this possible?

The username was @mattbrailsford

Anyone know if this is possible. From what I read it says deletion is permanent, but I’ve also seen user initiated deletions appear as suspensions to the admin.

👋 Hello! We actually were investigating this for another user with a similar issue. It looks like deleted accounts cannot be reactivated, not exactly. The issues that it causes with federation results in a "zombie" like state as other Mastodon servers will have stored the information that this account is deleted.

There is information about it on the mastodon/mastodon repo here:

 URL

We know this isn't ideal and have also submitted an issue to their tracker to see if there's anything in the 4.x releases that would allow us to do this. (We haven't had success thus far.)

I know this isn't an ideal answer :(

Thanks @quintessence

I thought this might be the case but I was reading mixed information so I really appreciated you clarifying.

I’ll hold tight for a little while and keep track of the other issue to see if it’s something that can be resolved in a future update, otherwise I’ll go with a different username 👍🏻

thanks again for your insight

i'm going to close this as there's nothing more i think we can do. feel free to reopen it if you learn something about undeletions.

Reactivate account
### Pitch

A user of my instance for trying / wrong ..etc, gave him to delete his account, I get in the admission, as a suspended account.

I try later to register again and cannot. because your email is "supposedly in use".

Is there any way to release that email?

### Motivation

Reactivate account

Read the official documentation: URL as mentioned from the *account* section:

RAILS_ENV=production bin/tootctl accounts create USERNAME --email EMAIL@MAIL.LOL --reattach

@mthld Thanks for your answer, I was seeing the link, but it can't solve the problem

mastodon@mastodon:~/live$ RAILS_ENV=production bin/tootctl accounts create USERNAME --email whoami@azeroth.website --reattach --force
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:66: warning: already initialized constant Net::ProtocRetryError
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:66: warning: previous definition of ProtocRetryError was here
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:206: warning: already initialized constant Net::BufferedIO::BUFSIZE
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:206: warning: previous definition of BUFSIZE was here
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:503: warning: already initialized constant Net::NetPrivate::Socket
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:503: warning: previous definition of Socket was here
Failure/Error: email
 has already been taken

### User data
Username: Skeep
mail: whoami@azeroth.website

### Deleting user

mastodon@mastodon:~/live$ RAILS_ENV=production bin/tootctl accounts delete Skeep
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:66: warning: already initialized constant Net::ProtocRetryError
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:66: warning: previous definition of ProtocRetryError was here
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:206: warning: already initialized constant Net::BufferedIO::BUFSIZE
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:206: warning: previous definition of BUFSIZE was here
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:503: warning: already initialized constant Net::NetPrivate::Socket
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:503: warning: previous definition of Socket was here
Deleting user with 0 statuses, this might take a while...
OK

Supposedly it was erased and everything ok. When I check the moderation, it keeps coming out, it never goes away.
I even try to register with his email and it goes out of use.
Captura de pantalla de 2021-08-22 15-11-42
Captura de pantalla de 2021-08-22 15-11-15
Captura de pantalla de 2021-08-22 15-10-51

Run, `User.where(email: 'whoami@azeroth.website')` in `RAILS_ENV=production bundle exec rails c`

@ClearlyClaire

mastodon@mastodon:~/live$ RAILS_ENV=production bundle exec rails c
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:66: warning: already initialized constant Net::ProtocRetryError
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:66: warning: previous definition of ProtocRetryError was here
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:206: warning: already initialized constant Net::BufferedIO::BUFSIZE
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:206: warning: previous definition of BUFSIZE was here
/home/mastodon/.rbenv/versions/2.7.2/lib/ruby/2.7.0/net/protocol.rb:503: warning: already initialized constant Net::NetPrivate::Socket
/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/net-protocol-0.1.0/lib/net/protocol.rb:503: warning: previous definition of Socket was here
UserChewy console strategy is `urgent`
Loading production environment (Rails 6.1.3.2)
irb(main):001:0> User.where(email: 'whoami@azeroth.website')
=> #

The promt was left waiting as another command, I close it with exit, did not work

Hm… alright, the email address has been blocked when you suspended it, then. Removing the block will be a bit annoying… open the Rails console (`RAILS_ENV=production bundle exec rails c`) and type the following:

ruby
class EmailBlockFinder
 include EmailHelper
 def find(email)
 CanonicalEmailBlock.where(canonical_email_hash: email_to_canonical_email_hash(email))
 end
end
EmailBlockFinder.new.find('whoami@azeroth.website').map(&:reference_account)
EmailBlockFinder.new.find('whoami@azeroth.website').destroy_all

(please copy the output, it will help me debug things)

This should be enough, but I'm surprised at a few things here:
- I would have expected the error not to be “has already been taken” (but that is what the code does, it's a bit confusing)
- I would have expected `tootctl accounts delete Skeep` to also remove the email block, but it does not… maybe it'd need an extra option
- I would have expected an easy way to remove the email block… but there is none

Oh, the root issue is #16498. I thought this would have been fixed in a release by now :grimacing:

Please note that reactivating a user account in this fashion will cause issues when federating with some other ActivityPub implementations.

I reactivated an account on my Mastodon instance using `accounts create` with the `--reattach` flag as described above. The user was unable to interact with users on Pleroma instances that were aware of their account before the deletion. I had to contact the admins of those instances and ask them to manually re-enable the account in their instances, because Pleroma doesn't seem to allow for reactivation of deleted remote accounts.

Unfortunately I'm not ActivityPub-savvy enough to discern whether this kind of user reactivation violates the spec and shouldn't be done, or whether this is a bug in implementations that behave this way.

Another note: the follower/followed counts for the reactivated user were wrong and wouldn't update until I ran `tootctl cache recount accounts`.

It's not a spec violation nor a "bug" per se, but it is an unhandled case. Likely what implementations would need to do is detect somehow that the user has been recreated and invalidate their old cache.


Question: New release before end of 2023?

@Drakonas @fernandofig @Xmetalfanx @elmuz @ms178 @pixelpicnic No it is NOT dead. Im going to be completely honest, I was in inpatient rehab for alcohol, something I have struggled with since 15 years old.

I also happen to have covid right now too (i caught it at the facility, as did 10 others), but I will get a release out as soon as I can (because I want a new version too for tha security fixes)

I will be making a note on the previous release and upcoming release to explain why I was "dead" for a month.

New release before end of 2023?
Last one was from start of october 2023. Can we carve out a final release for this year before the end of the year?

@Alex313031 Keep this browser alive, It doesn't matter what people think. It doesn't matter the chromium version is not latest. Other browsers using latest can never beat this browser. Waiting for update sooner. Thanks.

At this point we should just have LTS builds if there's such variant of Chromium, would be better to focus just on it.

@Alex313031 This browser, was the best browser I ever used. It would be a real shame if it falls apart due to you leaving. I wish you a Mary Christmas and the best of luck. I genuinely don't care about "images in the files" if I don't got to mess with it. It did not effect me. Mary Christmas or whatever holiday you wish to celibate, or even none and all. And take your time. Be in a good head space before returning. Please and thank you.

LOL, bro just abandoned the project due to one stupid Chris Titus video, FINE XD

@ilyabumblebee And we are here using it until it works. Almost 2 months without an update for a browser, still rocks.

The owner/main dev said in this issue, that he unforatunately has health problems and for that reasons, he currently can't update the browser. But the project is **not dead**, he wants to take care of an update when he feels better again. We shouldn't rush him and give him time to recover.

@DMW007 @rubyFeedback @pazza2234 @NewsonUpreti @ilyabumblebee Project is NOT dead. Just rebased for M119! Building releases now.

I am so happy to hear this even If I am late. I will be switching back soon.

Is this project dead?
There haven't been any updates in any repo in weeks, 2 months for Windows. If the dev is dealing with life stuff, I understand, but an update would be nice while certain things are starting to break like site data being lost randomly and RAM leak issues popping up.

If it is abandoned, it'd be nice to state if you have no plans to develop it further so I can move to something else.

Hope Alex is ok, regardless.

I sure hope not - I'm late to the party, and I love this browser.
I hope all is well!

@Drakonas This project is notorious for late updates to new releases or skipping several releases alltogether, sadly. Hence the period of time without committs is nothing new. While this doesn't mean that the project is dead, it also speaks for itself that the current team might not be up to the task of maintaining such a big project.

As Youtubers recently made quite a splash to push Thorium and that Google increased its release cadence, I fear that it collapses under the burden. No timely releases are a major security concern. And as I love Thorium, and its current state saddens me just as well as you.

What this project is in dire need of:

1) automated builds and releases
2) timely updates

From the answers I've seen before, it comes down to costs and time issues. The builds are made manually at the moment.

If you look at the author page you can see almost zero activity recently, not just about this project. Let's hope he'll come back.

If you look into his activity back in 2022, it seems that, much like this year, he was mostly inactive from november. Activity picked up again by January. Maybe he's on vacation?

Honestly I don't care at this point. I've been watching this project and feeling pretty much the same as @ms178 , and now from what is transpiring from #463 , I think I'll jump ship altogether.

I hope somebody remakes a similar project so it's under a significantly less concerning developer.

yeah ... i am going to have to go back to FIrefox ... the "furry porn" stuff i think should be removed and has no place in a project like this (not even "offended" or "think of the children!" about it) ... the other stuff i saw just now ... figuring some people were going overboard BUT THEN seeing proof ... I cant have anything by this dev on my PC ... i am done .... and this was the first non-bloated (looking at Brave and Vivaldi) Chromium based browser i liked ... ever ... but yeah ... forget all the good stuff .... now maybe if another dev does the same sort of work, removes all that crap and takes OVER the project ... I may come back

this dev may do great coding work but this content i have seen on his/her repos is not acceptable to me ... and yes i admit again i thought some users were going overboard ... just seeing one "furry porn" pic at first.

Yeah, honestly the furry porn shit was bad on its own, and that in it of itself got me to start pulling it from computers i installed it on. Even still, at that point i would have been willing to give it another shot in the future.

When somebody archives a site titled the way that repo was titled, and has those types of images for _any_ reason, I no longer trust the main dev of this project, and so far i don't really trust any of the other devs I've seen so far, while i don't recall that they have done much to lose trust, they haven't done much to regain trust from a currently tainted project.

It would be nice if somebody else remakes a similar project, but with everything that has come out, it cannot be under the current main dev.

@Xmetalfanx @SethbotStar You guys do know it was an archive of an anti circumcision website that was around for over a decade until the hosters shut down > URL

@Alex313031
Appreciate you and hope you're doing better. Thanks for sharing - that's big of you.
fortify!

Truly.. I had no intention of sharing ill contempt.. I was honestly more worried something has happened to you.

I hope you recover well... Sounds like such an awful thing to have to deal with during the holiday season.

Wishing you well mate. Rooting for you.


Question: All databases are empty, possibly due to unintentional OrbStack reset?

Thank you for the feedback @MattWilcox.

It can be disabled completely:

bash
ddev config --disable-settings-management

All databases are empty, possibly due to unintentional OrbStack reset
### Preliminary checklist

- [x] I am using the latest stable version of DDEV (see upgrade guide)
- [x] I have searched existing issues
- [x] I have checked the troubleshooting guide
- [x] I have run `ddev debug test` to include output below

### Output of `ddev debug test`

Since the upgrade to 1.24.5, all my databases are empty.

Upgrade to 1.24.6 did not help.

I run ddev debug test in one of my projects, here is th output.

 URL

### Expected Behavior

I expect that after upgrade all projects are still running with no problem (as it did all the uzpgrades before)

### Actual Behavior

All databases are running and I can connect but are empty

### Steps To Reproduce

_No response_

### Anything else?

_No response_

Hi @idleog,

I see that you are using Craft CMS, in a recent release there were changes (requested by the Craft CMS team) in the arrangement of environment variables URL

You are most likely connected to a database defined in `.ddev/.env.web` instead of `.env`.

See the issue for more details:

- #7233

---

DDEV didn't delete your databases, the volumes are here:

======== docker system df ========
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 23 0 4.042GB 4.042GB (100%)
Containers 0 0 0B 0B
Local Volumes 17 0 3.259GB 3.259GB (100%)
Build Cache 158 0 22.23MB 22.23MB

Hi @stasadev

Thanks a lot for your answer.

I was aware of the new .env file in .ddev, and it is setup correctly (the db settings in .ddev/.env.web are identical to the ones in web/.env)
And I have two projects running with CakePHP, no CraftCMS, and I have the same problem there.

When I open sequelace with 'ddev sequelace', I see the db called db, but there are no tables in it.

If you say DDEV didn't delete my databases, the volumes are here, is there another way to see all databases, including the ones CraftCMS used to use, and to dump them?

Cheers
Peter

First, make sure it's not an issue with Sequel Ace.

Check for tables with:

bash
ddev mysql -udb -pdb -e 'SHOW TABLES;'

Then check your volumes (or use the OrbStack GUI):

bash
docker volume ls

There’s a chance a Docker factory reset was done, and the 17 volumes (3.259 GB) I see could be just Mutagen volumes, not actual database data.

There’s also a chance a different Docker provider was used earlier, and databases are still there, but `docker context ls` shows only OrbStack, so that’s unlikely.

---

P.S. Always make backups: URL

And one more unrelated issue:

======== OS Information ========
Darwin MacBookPro.fritz.box

======== ping attempt on ddev.site ========
ping: cannot resolve dkdkd.ddev.site: Unknown host

DDEV is about to issue the command:
 sudo --preserve-env=HOME /opt/homebrew/bin/ddev hostname tryddevproject-31553.ddev.site 127.0.0.1

You're using Fritzbox, and `*.ddev.site` is not resolved by default, see URL

Thanks for your reply.

It is not an sequealace issue, ddev mysql -udb -pdb -e 'SHOW TABLES;' shows no result, and CraftCMS shows 503 whent starting the frontend, and wants to install CraftCMS when launching the backend.

'docker volume ls' shows all current volumes, including the formation21-mariadb volume.

when I import a backup, everything is up and running again, so it seems that the db is initially around and connected as it should, but it is empty (that's also the reason that CraftCMS trys to reinstall, becuase it sees an empty db).

I did compare the db volumes of a project with empty db, and a project with re-imported backup, they looks quite different, but I do not understand what all the files are for at all, so maybe an expert can say sth. looking at the screenshots.

project, db-volume with reimported backup

project, db-volume with empty db

Cheers, -Peter

By the dates, were the new "empty" volumes data created recently?

You started using DDEV quite a while ago:

======== mkcert information ========
/opt/homebrew/bin/mkcert
CAROOT= WSLENV= JAVA_HOME=
/Users/goeldi/Library/Application Support/mkcert
total 16
-r-------- 1 goeldi staff 2484 24 Feb 2023 rootCA-key.pem
-rw-r--r-- 1 goeldi staff 1777 24 Feb 2023 rootCA.pem

But the total number of images is small:

======== docker system df ========
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 23 0 4.042GB 4.042GB (100%)
Containers 0 0 0B 0B
Local Volumes 17 0 3.259GB 3.259GB (100%)
Build Cache 158 0 22.23MB 22.23MB

In most cases, users don’t manually clean up Docker resources, and images tend to accumulate.

I assume a Docker factory reset may have occurred. DDEV itself can't do that.

All existing volumes are created recently, and only the ddev projects I started after the update to 1.24.5 are around at all. All other project volumes are gone.

so this means that all docker files/volumes have been cleaned? So that must be happened in Orbstack? I for sure did not clean up any resources on purpose.

Correct, something happened with OrbStack.
I can't say what exactly. Hope you have all needed backups.
Here's the link again for anyone reading this: URL

Improve Craft CMS "settings management" (writing to project `.env`)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem?

The Craft CMS project type writes a number of `CRAFT_*` vars to the project's `.env` file, which is not ideal for a few reasons:
- Craft itself doesn't natively enforce .env usage, so it relys on someone using `vlucas/phpdotenv`
- We've found it not uncommon for people to upload their local .env file to a server and use as a base for editing. Usually they are aware enough to change the `CRAFT_DB_` vars, but often times don't realize `CRAFT_WEB_ROOT` was added by DDEV, leave it in place, and break their remote app.

### Describe your solution

The way things are implemented now seems to be somewhat by chance and a fundamental misunderstanding of how the "settings management" feature is intended to be used.

Ideally, DDEV wouldn't touch the project's `.env` file, and instead inject the environment variables directly into the containers.

### Describe alternatives

 It appears that writing `.ddev/.env` is one option for that, but writing to YAML may also be an option.

### Additional context

- URL
- URL

I would really like to see us use .ddev/.env.

Note that environment variables defined in `.ddev/.env` are populated for all containers for the project.

It seems like just creating/managing `.ddev/.env` would solve the Craft problems ?

@timkelty we'll need at least your reaction and followup on
* URL
to move this forward.

While it's not required, it's used by the template URL

---

I opened the issue below for this:

- #7309

---

From Discord URL

Using `.ddev/.env.web` may not be an obvious change for existing applications.

It might make sense to revert #7236 in favor of implementing #7309, especially while Craft CMS setup is still broken (see #7286) in DDEV v1.24.5, so the impact remains minimal for now.

We're not reverting anything in v1.24.6.

We'll gather more feedback from the Craft CMS community on this.

The idea in #7309 is good and will improve things for all project types.

Just adding in here as general feedback so it's not lost in Discord.

This change is something I just don't want in our projects, and all it's done in introduce a new thing I've had to add into the project's root level .gitignore file, and a level of confusion about what's actually happening.

Context: I was working on our long-standing starter project, from which other web projects are built, and the new behaviour added the `.ddev/.env.web` file into that base project's Git repo - but that file has variable values specific to the instance (PRIMARY_SITE_URL).

I appreciate this may be a little niche, but as a general thought - I was under the impression that .env anything should not be in GIT, because the purpose is that these are environmental data that changes, and shouldn't be in Git because those values differ based on where you're actually running the project.

Frankly, for us, we don't want any of the stuff DDEV adds into `.env` as we just do not use those values in our projects. It's already set up and running. Likewise, we don't want or need the new `.ddev/.env.web` either - and now it's there, I don't actually understand _which .env files' values_ will be being used! The one in .ddev, or our standard one at the standard location.

As you see @MattWilcox this was requested by @timkelty of Pixel & Tonic. We generally only do explicit CMS integrations in collaboration with the communities involved, and this one was done over time with collaboration from the Craft CMS folks.

We just tagged new `craftcms/craft` releases for v4 and v5, which no longer include default `CRAFT_DB_*` env var values in `.env.example.dev` file (which the default `.env` file is copied from on `composer install`).

Tested installing Craft 4 and 5 on an older version of DDEV as well as v1.24.6, and all works as expected. Older versions will append the `CRAFT_DB_*` vars to `.env`, and v1.24.6 will add them to `.ddev/.env.web`. Either way, Craft is configured correctly and able to connect to the DB immediately after running `ddev create-project`.

@MattWilcox That’s true for the root `.env` file, but this is a special case. DDEV isn’t adding any sensitive to `.ddev/.env.web`, or anything that would change from one dev environment to the next; it’s all just a replication of info that’s already being stored elsewhere in `.ddev/`.

It's also worth noting that `.ddev/.env.web` and `.env` are fundamentally different: Vars in `.ddev/.env.web` are actually injected into the DDEV containers by docker, where `.env` is loaded by the `vlucas/phpdotenv` and the project itself.

@timkelty @brandonkelly I'm figuring out how to address those changes in our existing projects and our Craft boilerplate. Removing the `CRAFT_DB_*` variables from the `.env` doesn't work for me because we only have a single `.env.example`, not three different examples files for dev/staging/production. So we're always copying `.env.example` to `.env` during `composer install`. That means we would have to manually add those variables to the `.env` in any staging or production system, which is awkward.

I found a much better solution, in my opinion, is to switch from `Dotenv\Dotenv::createUnsafeMutable` to `Dotenv\Dotenv::createUnsafeImmutable` in our `bootstrap.php`. This means that existing environment variables can never be overridden. This is a saner default anyway. And it means I can still have the `CRAFT_DB_*` variables in my env, but they won't take effect if ddev has already set those variables, so the ddev-injected variables always have precedence and will always work, even if another colleague hasn't updated their `.env` yet.

This might be a good default for `craftcms/craft` as well?

Correct me if I'm missing something …

---

@MattWilcox I agree with you that even the env files in `.ddev` shouldn't be tracked in git, I've added this in my top-level `.gitignore` when we started using ddev:

gitignore
/.ddev/.env
/.ddev/.env.*

@MoritzLost We used to use `createUnsafeImmutable()`, but changed it in response to URL

We just discussed whether it would make sense to switch back in light of this DDEV change, but decided to keep it as-is, as the (now) current behavior is more in line with expected behavior at first glance. (We expect it would confuse people to have environment variables defined in `.env` which aren’t getting picked up.)

That said, if you’d prefer to stick with a single `.env.example` and understand the effects of going with `createUnsafeImmutable()`, you are definitely free to go with that in your own projects!

@brandonkelly Good to know the history, thanks! Yeah, it might be confusing for new devs if their `.env` doesn't take effect.

We'll stick with using `createUnsafeImmutable()` for now. ddev only sets the variables that are absolutely required for the web container to work correctly, so having those take precedence makes sense for us. But I can see that using the mutable approach is a more reasonable default for the starter project.

I've added a note at the top of our `.env.example` to avoid future confusion:

# Environment variables are loaded in `bootstrap.php` by vlucas/phpdotenv
# Existing environment variables (e.g. provided by DDEV) always take precedence
# and are not overridden by .env values. If a variable is already set in the
# environment, the .env value is ignored.


Question: Mes compteurs d'énergie ne fonctionnent pas - There is no state available for this entity?

Bon j'ai réessayé avec la version officielle 2022.5 qui sortait aujourd'hui et ca marche toujours pas.. j'ai l'impression que c'est vraiment un détail que @valleedelisle pourrait régler... as-tu des idées rapides? Merci

Setup failed for custom integration hilo: Requirements for hilo not found: ['python-hilo>=2022.5.1'].
14:55:43 – (ERROR) setup.py

Logger: homeassistant.util.package
Source: util/package.py:99
First occurred: 14:52:30 (3 occurrences)
Last logged: 14:55:43

Unable to install package python-hilo>=2022.5.1: ERROR: Cannot install python-hilo==2022.5.1 because these package versions have conflicting dependencies. ERROR: ResolutionImpossible: for help visit URL WARNING: You are using pip version 22.0.3; however, version 22.0.4 is available. You should consider upgrading via the '/usr/local/bin/python3 -m pip install --upgrade pip' command.

Mes compteurs d'énergie ne fonctionnent pas - There is no state available for this entity
Est-ce que ca vous dit qqch?

On dirait que Home assistant force la définition de tyypes pour ces variables... mais j'y connais pas grand chose!

J'ai récemment dû réinstaller l'intégration après plusieurs problèmes bizarres. Tout semble enfin se connecter et je suis capable de contrôler mes thermostats à partir de Home Asssistant. Par contre, aucune donnée statistiques au niveau Énergie.

image

Quand je regarde les stats dans Developers tools, je vois ceci:

image

image

Je n'ai pas essayé de cliquer sur "remove", car je ne veux justement pas les enlever... mais peut-etre vont-ils se recréer ensuite?

C'est réglé dans la plus récente version, sinon voir mes explications pour faire le ménage dans le dashboard energy: URL

Y'a eu un gros remaniement du code chez HA pour tout ce qui est énergy dashboard et utility meters. Je vais devoir deepdive à nouveau ce code pour bien intégrer.

Est-ce que dans l'intervalle, il est possible de désactiver l'ajout automatique des sensors dans l'onglet Energie pour que seulement nos entrées manuelles (qui fonctionnent) restent?

J'ai le même problème. J'avais tout cleané hier, mis les bons sensors, puis ce matin plus rien ne marchait et les sensors non fonctionnels étaient revenus.

Juste pour info, je viens tout juste de faire un fresh install de hass, la version avec URL

J'ai aucune données dans mes energy meters. L'hivers commence et j'aurais bien aimé suivre la consommation de mes 10 thermostats
image

image

Je suis content de voir que c'est pas moi qui est fou... j'ai passé ma soirée a force-delete les donnees d'ergenie, re-installer le plugin Hilo, delete tous mes devices a la main... Puis au final, y'a rien qui marche :)

Meme genre de setup, Proxmox + HAOS dans sa propre VM. Fresh install de HA (ma premiere motivation est d'utiliser le le plugin d'hilo!)

Laisse-moi savoir si tu trouves une solution

Je viens d'avoir le même problème. Je me suis aperçu que ma config s'était vidée.

As-tu vérifié que tu avais de l'info dans le plan name et la case pour générer les sensors à ON?
image

J'ai finalement réussi a faire marcher les compteurs d'énergie. J'ai repris la doc dans ReadMe.md et ca s'est mis a marcher. CODE 18!

Normalement, je fermerais cette issue. Je pense que c'est resolved.

As tu essayé ca? Ca pourrait confirmer que c'est resolved.

image

Je regarde les screenshot de @caublet et c’est partielle réglé avec #230

Les sensors qui sont dans ton dashboard sont non fonctionnels. Il faut les enlever et suivre la méthode donnée par @skimaniac dans #160

je vais essayer d’ajouter ça dans le wiki

As tu réglé ton problème? Voir ma réponse à @caublet

Faites un update à la dernière version de Hilo ça va aider!

Fix possible mergé. Je sais que c’est plate à faire mais clean install redonnes-moi des nouvelles?

Ca a l'air d'être OK mais je t'avoue que je check pu ca depuis un méchant bout, car je n'utilise plus les compteurs d'énergies fournis par l'intégration depuis que j'ai connecté mes thermostats hilo directement par zigbee. Mais bon, les compteurs ont l'air OK dans las section "statistics" présentement.

Je vais fermer et suivre ça dans #319 comme c'est un duplicate plus récent. Merci de ta réponse!

Incompatibilité Home Assistant 2022.5
Ne marche pas bien avec 2022.5 présentement… updatez à vos risques et périls.. pour ma part j’ai rollbacké et j’ai encore des trucs qui ne marchent plus avec Hilo depuis…

@FrancoLoco as-tu résolu tes problèmes avec 2022.5? La version officielle vient de sortir, peux-être qu'ils ont changé des choses depuis la beta?

Non j'étais revenu à 2022.4 et j'ai pas réessayé 2022.5 depuis..

@skimaniac as-tu essayé toi? est-ce que ca marche maintenant?

Je viens d'upgrader mon container ce matin et je n'ai pas eu ce probleme. Par contre, j'ai une erreur similaire avec une autre de mes integration [1] et j'ai une autre erreur [2] plus loin qui semble liée à un changement dans l'integration sensor de home assistant

[1]

2022-05-05 08:38:21 ERROR (SyncWorker_2) [homeassistant.util.package] Unable to install package paho-mqtt==1.5.1: ERROR: Cannot install paho-mqtt==1.5.1 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit URL
WARNING: You are using pip version 22.0.3; however, version 22.0.4 is available.
You should consider upgrading via the '/usr/local/bin/python3 -m pip install --upgrade pip' command.
2022-05-05 08:38:21 INFO (SyncWorker_3) [homeassistant.util.package] Attempting install of paho-mqtt==1.5.1
2022-05-05 08:38:28 ERROR (SyncWorker_3) [homeassistant.util.package] Unable to install package paho-mqtt==1.5.1: ERROR: Cannot install paho-mqtt==1.5.1 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit URL
WARNING: You are using pip version 22.0.3; however, version 22.0.4 is available.
You should consider upgrading via the '/usr/local/bin/python3 -m pip install --upgrade pip' command.
2022-05-05 08:38:28 INFO (SyncWorker_1) [homeassistant.util.package] Attempting install of paho-mqtt==1.5.1
2022-05-05 08:38:31 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281472852626640] Received invalid command: mobile_app/push_notification_channel
2022-05-05 08:38:35 ERROR (SyncWorker_1) [homeassistant.util.package] Unable to install package paho-mqtt==1.5.1: ERROR: Cannot install paho-mqtt==1.5.1 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit URL
WARNING: You are using pip version 22.0.3; however, version 22.0.4 is available.
You should consider upgrading via the '/usr/local/bin/python3 -m pip install --upgrade pip' command.
2022-05-05 08:38:35 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration jq300: Requirements for jq300 not found: ['paho-mqtt==1.5.1'].

[2]

2022-05-05 08:39:02 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up hilo platform for sensor
Traceback (most recent call last):
 File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
 await asyncio.shield(task)
 File "/config/custom_components/hilo/sensor.py", line 171, in async_setup_entry
 create_energy_entity(d)
 File "/config/custom_components/hilo/sensor.py", line 148, in create_energy_entity
 device._energy_entity = EnergySensor(device)
 File "/config/custom_components/hilo/sensor.py", line 264, in __init__
 super().__init__(
TypeError: __init__() got an unexpected keyword argument 'unit_of_measurement'

@valleedelisle as tu vu ma pull request dans python-Hilo? J’ai l’impression que lousser les requirements aiderait..?

Non j'ai pas toucher à 2022.5 un peu à cause de ça, mais j'ai un home assistant (test) sur un docker lui je l'ai updater et j'ai tester Hilo sur lui ce matin et ça fonctionne pas (les mêmes erreurs que vous avez rapporter)

Donc je toucherai pas à mon HA principal pour tout de suite ;)

Moi qui d'habitude upgrade 2 fois par année, j'me suis fait mettre de la pression en écrivant ça 🤣 J'ai pu d'environment de test alors j'viens de mettre ma 'prod' à terre pour faire marcher ça.

@valleedelisle c'est quoi ton autre intégration qui ne fonctionne plus? Si c'est un intégrationnistes assez populaire ça se peux que les dévelopeur de HA corrige le problème de python ou je sais pas trop... ;)

Un autre developpeur qui fix son integration sans pousser une release 🙄 (ca m'est arrived quelques fois)

All right je confirme que ca marche avec le nouveau release v2022.5.2, party d'update d'Home Assistant! 🎉 Merci!!

Moi c'est ok ça se met à jour. Mais si tu as 0 dans l'app Hilo ta passerelle est probablement déconnecté du côté de l'antenne zigbee vers le compteur d'Hydro.

Les thermostats répondent?

Si oui reboot la paserelle.

Si ça se règle pas dans Hilo : j'ai du le ouvrir un case pour la mienne qui parlait plus au compteur. 3-4,jours.

Obtenir Outlook pour Android
Sent: Thursday, May 5, 2022 12:25:08 PM
To: dvd-dev/hilo ***@***.***>
Cc: Fox350 ***@***.***>; Comment ***@***.***>
Subject: Re: [dvd-dev/hilo] Incompatibilité Home Assistant 2022.5 (Issue #112)

y a tu juste moi qui a ce bug là: dans HA SmartEnergyMeter Power 0w, dans l'app Hilo 0w, mais le total par heur dans l'app continu à monter. 🤨

—
Reply to this email directly, view it on GitHub

J'avais aussi ce problème, je croyais à un problème Hilo, mais effectivement en rebootant la passerelle ca a fonctionné.

C'est la faute à Jean Charest 😁

Obtenir Outlook pour Android
Sent: Thursday, May 5, 2022 3:09:59 PM
To: dvd-dev/hilo ***@***.***>
Cc: Fox350 ***@***.***>; Comment ***@***.***>
Subject: Re: [dvd-dev/hilo] Incompatibilité Home Assistant 2022.5 (Issue #112)

J'ai rien touché et c'est revenu. Mais la passerelle était verte et les données montaient quand même, donc elle devait être branché sur le compteur. Bizarre quand même 🤷🏻♂

—
Reply to this email directly, view it on GitHub

J'ai un autre bug depuis que je suis à 2022.5, mes compteurs d'énergie ne se remplissent plus et je vois constamment cette erreur dans les logs:
2022-05-05 16:11:02 WARNING (MainThread) [custom_components.hilo] check_tarif: Unable to find state for sensor.hilo_energy_total_daily_low

C'est un peu poche ça que les update de HA brise des intégrations qui fonctionnaient :(

Bah c'est un peu de ma faute, faudrait que je suive les updates de près mais j'ai pas le temps.

Ensuite, c'est pas une intégration officielle, donc elle n'est pas testée. De plus, je n'ai pas écrit de functional et unit test. Par contre, je suis ouvert aux PR, si ça tente à quelqu'un.

Moi j'ai dû changer tous mes energy sensors, mais je ne sais si j'ai remis me bon. Mes valeurs sont négatives.

Screenshot_2022-05-05-21-27-54-26_c3a231c25ed346e59462e84656a70e50

Bon finalement de mon côté j'ai réassocié manuellement mes energy meters dans les settings du dashboard energy car ca semblait lié à des trucs orphelins ou brisés (autant pour le compteur total que pour les devices individuels).. et avec le bout de code de la pull request ci-dessus, ca a réglé mon erreur (_check_tarif: Unable to find state for sensor.hilo_energy_total_daily_low_) et ca s'est remis à fonctionner correctement semblerait pour moi pour le moment.

Les nouveaux compteurs non brisés sont ceux avec une petite icone à côté:
image

@skimaniac moi aussi elles reviennent, pour le moment je les laisse là et les ignore...

Pour moi ça a arrêté de réapparaître après le 3e fois que je les ai enlevés.

@FrancoLoco je viens de voir dans la page des statistiques qu'elles apparaissent avec des erreurs, je vais les supprimer là aussi pour voir si ça corrige.

<img width="1261" alt="Capture d’écran, le 2022-05-09 à 10 26 18" src=" URL

J'ai le même problème que toi ! Je viens tout juste d'installer cette intégration Hilo. Comment ça fonctionne pour réassocier manuellement mes energy meters ? Merci !


Question: IDE0251 error in error list has no title?

@DanTravison Apparently this was forgotten to be moved. I opened URL and will close this.

IDE0251 error in error list has no title
_This issue has been moved from a ticket on Developer Community._

[severity:It bothers me. A fix would be nice] I just opened my project and noticed in the Error List window I have two IDE0251 errors with no descriptions. If I click to go to the location of the error, I see code is fine. Also, the link to the documentation around that error seems to be broken, I get a 404 on it ( URL

### Original Comments
#### Feedback Bot on 3/16/2023, 05:46 PM:
(private comment, text removed)

#### Feedback Bot on 3/17/2023, 06:31 AM:
(private comment, text removed)

### Original Solutions
(no solutions)

The original ticket was incorrectly moved to roslyn-analyzers repo URL

I saw a number of these with no description in my build and all were reporting for struct Properties with public get accessors . In all cases, the suggested fix is to make the member read-only.

I tried refactoring to make the structure read-only which eliminated the warnings but implementation and usage becomes rather convoluted since the methods that normally updated the current instance in place now need to create a copy with the updated values.

Is this an analyzer issue or am I missing something?

The project is configured with the following:
 true
 latest

I'm building with Microsoft Visual Studio Community - Version 17.6.0 Preview 4.0

I don't see these when I build with Microsoft Visual Studio Community - Version 17.5.4

Here are a few examples:

public float X
{
 get => _x; <--
}

get <--
{
 return new PointF(_x, _y);
}

public Color ToColor() <--
{
 double chroma = Brightness * Saturation;
 double hue = Hue / 60;
 double x = chroma * (1 - Math.Abs((hue % 2) - 1));
 double m = Brightness - chroma;

 return HSLColor.ToColor(chroma, hue, x, m, Alpha);
}

@DanTravison can you update your code sample with
`

` markdown flags?

Yes. Making the property readonly will help when calling it on a readonly instance of your struct. The compiler will now no longer have to copy the instance in that case as it can be sure that calling the property directly is safe (as it can't mutate the instance).

I have few issues with the warning:
1: The properties only have a get accessory. Isn't that, by definition, a readonly property?
2: The underlying fields are explicitly declared as private.
I don't see the reasoning behind adding readonly declaration to a read-only property.
3: In one case, it is flagging a method that returns a value based on a calculation of a private field. I can't declare that read-only and the field cannot be declared readonly because it is used as an accumulator.

Nope. Consider the following:

c#
int Prop { get { this.x++; return this.x; }

There's no cross symbol understanding. At the user site it has to assume the worst.

To ensure the compiler doesn't copy your structs when you access properties off of them if the instance is in a readonly location.

Why not? :) Looks fine to be made a readonly prop or method.

That's a bug.

Also a bug. This issue tracks fixing those issues. I'm just trying to answer your personal questions about your scenario. :)

I must have missed that language change. Thanks for pointing that out.

This is what led to my confusion. When I see IDE0044 reported for class fields, I don't hesitate to use the guidance since the page clearly states why and I've confirmed it enough to trust the recommendation. With IDE0251, there is no explanation and I'm reluctant to make changes I don't understand.

With your explanation, it's obvious there's a case I didn't consider.

Thanks.

cs
record struct SomeRecord(int X)
{
 // IDE0251:
 public bool Equals(CacheKey? other) => false;

 // IDE0251:
 public override int GetHashCode() => 0;
}

I am affected by the same issue.

Unity project
Visual Studio Code 1.78.2
C# for Visual Studio Code (powered by OmniSharp) 1.25.7
Microsoft.Unity.Analyzers 1.15.0

Empty text for IDE0251 in "PROBLEMS" window, see attached screenshot, caused by the following code:

public struct DummyStruct
{
 public int DummyValue;

 // the "get" in the following line causes an IDE0251 notification
 public int GetDummyValue { get => DummyValue; set => DummyValue = value; }
}

IDE0251-empty-text

**REPRO:** I'm also getting the IDE0251 with no message, but no suggested fix after VS2022 upgrade to Version 17.6.2. This is the code fragment that's frowned upon (^^ mark the dotted underscores):

c#
record struct VoiceMarker(uint Start, uint Length) : IComparable {
 public uint End => Start + Length;
// ^^
 public int CompareTo(VoiceMarker v) =>
// ^^
 Comparer .Default.Compare(Start, v.Start); // Length is irrelevant.
}

The project file is unremarkable:

xml

 Exe
 net7.0
 disable
 enable
 True
 False

To suppress the message, add to `.editorconfig`:

ini
[*.cs]
# URL
dotnet_diagnostic.IDE0251.severity = none

Plus is emits the "make it readonly" for a property that **has a setter**. Making that one actually `readonly` surely makes IDE0251 go away, but gives "CS1604 cannot set write protected field" instead.

To me it looks pretty much as if the emitted IDE0251 is also incorrect in some cases ...

I think this was fixed by #67664, so it should be fixed in VS 17.7
The missing documentation page is tracked in dotnet/docs#30361

Closing this out as the original issue reported here has been fixed with #67664. If there are any additional functional issues with this rule, kindly file separate issues. Thanks!

IDE0251 error in error list has no description
_This issue has been moved from a ticket on Developer Community._

---
[severity:It bothers me. A fix would be nice]
I just opened my project and noticed in the Error List window I have two IDE0251 errors with no descriptions. If I click to go to the location of the error, I see code is fine. Also, the link to the documentation around that error seems to be broken, I get a 404 on it ( URL

---
### Original Comments

#### Feedback Bot on 3/16/2023, 05:46 PM:

(private comment, text removed)
#### Feedback Bot on 3/17/2023, 06:31 AM:

(private comment, text removed)

---
### Original Solutions
(no solutions)

@CyrusNajmabadi I think this was unintentionally moved to this repo. It belongs to dotnet/roslyn.

Is there a link to the issue in dotnet/Roslyn? I can't find it.


Question: [Migrated] #167: Add Dockerfiles, plain Docker deployment instructions and minor fixes?

**Original comment by @proppy**
**Posted:** 2014-06-14 17:11:39 UTC

---

Note of you just want to have a container to build the projects and get
binaries out.

You can also set the ENTRYPOINT to the build command.

docker build ; docker run # to build
docker cp # to get the file out of the container
On Jun 14, 2014 10:00 AM, "Johan Euphrosine" proppy@google.com wrote:

[Migrated] #167: Add Dockerfiles, plain Docker deployment instructions and minor fixes
**Original Pull Request #167**
**Original Author:** @discordianfish
**Created:** 2014-06-19 12:52:56 UTC
**Updated:** 2014-08-12 20:25:13 UTC
**Closed:** 2014-08-12 20:25:13 UTC
**PR State:** closed
**Merged:** No
**Base Branch:** master
**Head Branch:** various-fixes
**Commits:** 4
**Changed Files:** 10
**Additions:** +106
**Deletions:** -18

**Note:** This was originally a Pull Request. The code changes are preserved in the forked repository's branches.

---

Hi,

I've put all this in one PR, hope that's okay. It's basically what I had to change to get it working in my everything-is-dockerized environment.
I've tried to come up with "good commits". Let me know if you prefer single PRs for each of them.

So the idea here is to run kubernetes itself in Docker containers, therefor I created three Dockerfiles. The documentation assumes that this will be added as automated builds in the Google account. Guess that's up for discussion so let me know if I should change that.
The Dockerfile in / will create a kubernetes 'base image' which just includes the code/binaries and is used by kubernetes-node and kubernetes-server. This might not fit all all deployments but it's a good start and easy to understand.
To make this possible I added a `-docker` flag to point to the docker address (since with the bind-mount we can't use /var/run/docker.sock in the container). Beside that I made kubelet use the client lib for pulling the image instead of the binary (which isn't installed in the container).

**Original comment by @brendanburns**
**Posted:** 2014-06-19 15:48:14 UTC

---

Awesome! Thanks for doing this. I'll take a detailed look today. In the
meantime, can you sign our CLA?

Instructions are in CONTRIB.md. It's basically identical to the Apache CLA

Thanks again.
Brendan

On Thu, Jun 19, 2014, 5:53 AM, discordianfish notifications@github.com
wrote:

**Original comment by @proppy**
**Posted:** 2014-06-19 15:54:29 UTC

---

Related: #19 and #141

**Original comment by @discordianfish**
**Posted:** 2014-06-19 17:24:53 UTC

---

(I've just moved cdd6b3c back in here so this branch can be built/used)

**Original comment by @brendandburns**
**Posted:** 2014-06-30 19:10:04 UTC

---

We got your CLA today.

Any chance you can extract the Docker API calls for Image Pulling (rather than shelling out) into a separate PR?

Many thanks!
--brendan

**Original comment by @discordianfish**
**Posted:** 2014-07-03 12:05:21 UTC

---

OK, I've created #351

**Original comment by @discordianfish**
**Posted:** 2014-07-08 17:24:34 UTC

---

Do you guys have interest in anything else from this PR? I still would like to see a easy way to deploy kubernetes as docker images itself. Happy to help if you have concrete suggestions.

**Original comment by @brendandburns**
**Posted:** 2014-07-14 14:42:48 UTC

---

Kelsey,
Have a look at the contents of the './build' directory, that does exactly
what you suggest.

It would be great to centralize on on version of this stuff.

Brendan
On Jul 14, 2014 7:29 AM, "Kelsey Hightower" notifications@github.com
wrote:

**Original comment by @brendandburns**
**Posted:** 2014-08-12 20:25:13 UTC

---

closing this now, since its a little out of date at this point, and the docker pull stuff was integrated in a different PR.

[Migrated] #19: Use Docker to host most server components
**Original Issue #19**
**Original Author:** @jbeda
**Created:** 2014-06-08 05:36:00 UTC
**Updated:** 2019-03-24 07:15:34 UTC
**Closed:** 2016-03-19 19:37:36 UTC

---

Right now we use salt to distribute and start most of the server components for the cluster.

Instead, we should do the following:
- [x] Only support building on a linux machine with docker installed. Perhaps support local development on a mac with a local linux VM
- [ ] Package each server component up as a Docker image, built with a Dockerfile
 - [ ] Support uploading these Docker images to either the public index or a GCS backed index with google/docker-registry. Or GCR?
 - [ ] Minimize docker image size by switching to single layer static golang binary docker images.
 - [ ] Support `docker save` to generate tars of the docker image(s) for dev/private development.
- [ ] Use the kubelet to run/health check the components. This means the kubelet will manage a set of static tasks on each machine (including the master) and a set of dynamic tasks.
- [ ] The only task that shouldn't run under the docker should be the kubelet itself. We may have to hack in something for (network mode = host) for the proxy.

**Original comment by @proppy**
**Posted:** 2014-06-08 06:04:40 UTC

---

On Sat, Jun 7, 2014 at 10:35 PM, Joe Beda notifications@github.com wrote:

##

Johan Euphrosine (proppy)
Developer Programs Engineer
Google Developer Relations

**Original comment by @monnand**
**Posted:** 2014-06-11 06:07:14 UTC

---

I have some questions just out of curious:
- Does it mean that salt will not be used in the future?
- About kubenetes docker containers, does it only contain compiled binary files, or contain source code? More precisely, are you going to put build process into the Dockerfile?

Thank you!

**Original comment by @jbeda**
**Posted:** 2014-06-11 17:24:17 UTC

---

@monnand I imagine that we will continue to use salt to bootstrap stuff. But we'll be able to reduce some of the more complex salt config.

For example, we currently ship and compile the source everywhere where it is run. If we start building docker images, we can precompile the binaries before they are run.

I'm thinking that we'll follow the example of Docker itself and do the build process in docker containers. This, with boot2docker, could lead to a good dev flow for Mac OS X.

**Original comment by @monnand**
**Posted:** 2014-06-11 23:03:35 UTC

---

@jbeda Correct me if I'm wrong. (I'm not saying that kubelet should run inside a docker container. I'm just trying to see what are the technical difficulties here.)

As far as I know, kubelet only needs to communicate with docker through docker remote api, which is either trhough a unix socket or a remote IP/port pair. Does it need to read/write cgroup's filesystem? In either case, it seems that we could mount the /var/run onto the container and run kubelet inside that containers.

We are currently doing this in cadvisor, which runs inside a docker container but can communicate with docker daemon and read information from the cgroup filesystem. The container could still run inside its own namespace, but communicate with docker daemon through the mounted volume. We use the following command to run cadvisor inside a docker container:

sudo docker run \
 --volume=/var/run:/var/run:rw \
 --volume=/sys/fs/cgroup/:/sys/fs/cgroup:ro \
 --volume=/var/lib/docker/:/var/lib/docker:ro \
 --publish=8080:8080 \
 --detach=true \
 google/cadvisor

**Original comment by @brendanburns**
**Posted:** 2014-06-11 23:49:19 UTC

---

There was just a discussion of this in the plumbers meeting. The union bay
networks folks want the ability to muck with the network from a container
too.

Brendan
On Jun 11, 2014 4:33 PM, "Joe Beda" notifications@github.com wrote:

**Original comment by @jbeda**
**Posted:** 2014-06-14 15:48:42 UTC

---

Notes of work in progress:
- I'm starting out by moving our build process into Docker. A snapshot of a Dockerfile and a Makefile to automate some common stuff is here: URL
- If we say everyone has to build on Linux, this is much easier. With the boot2docker on a Mac, you essentially have a remote machine that you are talking to through a local TCP pipe. That means with any `-v local-path:container-path` the `local-path` is really local to the boot2docker VM and not the local workstation.

This leaves us with 2 choices:
1. Build in the boot2docker VM and copy results back out, either through stdout from the docker run or via `boot2docker ssh`
2. Build the final docker images inside the boot2docker VM inside of a docker container. Yup, this means running docker in docker. This is supported with `dind` but it gets complicated. There is a repo ( URL with support but...
 - There is no license in that repo. Issue: URL
 - The Docker build process itself uses dind but has a forked script checked in to the Docker repo. These have diverged and I worry about continued support for the separate dind repo. Issue to harmonize these: URL

Right now I'm leaning toward copying stuff in and out (option 1).

**Original comment by @proppy**
**Posted:** 2014-06-14 17:00:57 UTC

---

You could have Dockerfile for individual binaries and have the resulting
container image launch it has its ENTRYPOINT.

That way you could leverage the fact sources are sent from your workstation
to the VM as the /build payload (context) over the remote API (no need to
copy to the host) and the docker image is your artefact.
On Jun 14, 2014 8:48 AM, "Joe Beda" notifications@github.com wrote:

**Original comment by @proppy**
**Posted:** 2014-06-15 01:47:44 UTC

---

FYI, I have a pending patch to docker that could provide an hacky
alternative.
 URL

This would allow something like

docker build -t builder ; (docker run builder | docker build -t runner -)

On Jun 14, 2014 2:52 PM, "Joe Beda" notifications@github.com wrote:

**Original comment by @saad-ali**
**Posted:** 2015-01-17 00:07:16 UTC

---

CC: @saad-ali

**Original comment by @bgrant0607**
**Posted:** 2015-03-10 19:18:03 UTC

---

See also #5011.

**Original comment by @errordeveloper**
**Posted:** 2016-03-16 09:41:48 UTC

---

Isn't this mostly done already?

**Original comment by @maicohjf**
**Posted:** 2019-03-24 07:15:34 UTC

---

15.
Check to see how many nodes are ready (not including nodes tainted NoSchedule) and write the
number to /opt/......

首先用kubectl get node 查看总共node 数量，然后kubectl describe node 查看
不包含污点值为NoSchedule 的node 数量

16.
From the Pod label name=cpu-utilizer, find pods running high CPU workloads and write the name
of the Pod consuming most CPU to the file /opt/...... (which already exists)

方法一：
通过kubectl get pod -l name=cpu-utilizer -o wide 查看pod 所在的node
之后kubectl describe node 查看哪个pod 请求的cpu 最多
三个都是0，我就都写进去了
方法二：
kubectl top pod -l name=cpu-utilizer


Question: curl exited with code '6'?

Maybe you have some privileges issues with this docker host? Maybe try the `--privileged` flag ? URL

curl exited with code '6'
Hi antlafarge,

I have tried to run your jdownloader container on a Raspi 4 with Bookworm arm64. Unfortunately the container does not come up. The Logfile says:

2023-11-08T20:51:15+00:00| ________________________________________ CONTAINER STARTED _________________________________________
2023-11-08T20:51:15+00:00| OS = "Ubuntu 22.04.3 LTS"
2023-11-08T20:51:15+00:00| JAVA version = "openjdk-17-jre-headless:arm64 17.0.8.1+1~us1-0ubuntu1~22.04"
2023-11-08T20:51:15+00:00| JAVA options = ""
2023-11-08T20:51:15+00:00| Delete any existing JDownloader installation files
2023-11-08T20:51:15+00:00| Download URL
2023-11-08T20:51:31+00:00| JDownloader.jar download failed: curl exited with code '6'
2023-11-08T20:51:31+00:00| Download URL
2023-11-08T20:51:47+00:00| FATAL ERROR JDownloader.jar download failed: curl exited with code '6'
2023-11-08T20:51:47+00:00| Get more informations here : URL
2023-11-08T20:51:47+00:00| ________________________________________ CONTAINER EXITED __________________________________________

I tried manually downloading JDownloader.jar on my network using the browser. It is working. Do you have any idea how to solve the problem?

Hello,
Many users reported me this problem for a long time, and most of the time there is a problem for the container to access to the DNS servers, and it's related to a misconfiguration or a bug in their docker installation.
Look at this : URL

Hello,
thank you very much for your help and information. I have now solved the problem by including the IP of a name server in the docker-compose.yml:

 jdownloader:
 image: antlafarge/jdownloader:latest
 container_name: jdownloader
 restart: on-failure:10
 hostname: jdownloader_dock
 dns: 8.8.8.8

It is working. :-)

Fatal Error during Download
After the Update to the latest version from 18.09.2023 i got the following error:

2023-09-20T16:18:42+00:00| ________________________________________ CONTAINER STARTED _________________________________________
2023-09-20T16:18:42+00:00| OS = "Ubuntu 22.04.3 LTS"
./docker-entrypoint.sh: line 37: ii: command not found
./docker-entrypoint.sh: line 37: ii: command not found
2023-09-20T16:18:42+00:00| JAVA version = " "
2023-09-20T16:18:42+00:00| JAVA options = ""
2023-09-20T16:18:42+00:00| Delete any existing JDownloader installation files
2023-09-20T16:18:42+00:00| Download URL
2023-09-20T16:18:58+00:00| JDownloader.jar download failed: curl exited with code '6'
2023-09-20T16:18:58+00:00| Download URL
2023-09-20T16:19:14+00:00| FATAL ERROR JDownloader.jar download failed: curl exited with code '6'
2023-09-20T16:19:14+00:00| Get more informations here : URL
2023-09-20T16:19:14+00:00| ________________________________________ CONTAINER EXITED __________________________________________

Partial. I tried it on another Docker host, no problems here. Where the problems occur, I was able to remedy the situation by setting the network mode to host. In bridge mode it can not download the jdownloader.jar. I don't understand why. Other containers on the same host can access the internet in bridge mode without problems.
I have completely removed the container and rebuilt it, always without success. only the network host mode works.

its not an arm, its an i5 proxmox host with vm ubuntu 22.xx -> docker -> jdown

the privileged mode doesnt work. only the network host mode works for the moment

Or maybe a bug with m'y new release i will do some checks this night

I just want to notice I just fixed the logs with a new release

i try, but the same result, i pull the new releases, same error with latest and alpine.
what i say, it works on this docker host until 1 wekk. my watchtower pull an update last week after this i have to use the netwprk host mode to run

I didn't change anything in network.
Maybe a bug in this docker host or in the lastest alpine and ubuntu images I use to build this new releases?

first again many thanks to your support. i can't understand it yet, but i have redone the whole configuration of the docker with regard to ip and dns. now it works. what i don't understand is why the network host mode worked. i have in another docker pihole with unbound running, that also works great. only as soon as container wanted to access "internally" i.e. jdown -> pihole it came to problems. a reconfiguration helped. although in the end the settings are the same. it's currently inexplicable to me. have in any case many thanks


Question: The 1k context limit in Open-WebUI request is causing low-quality responses.

It should be noted that changing the context size of a model via the Modelfile is mentioned, but in the OpenAI doc , not the FAQ.

The 1k context limit in Open-WebUI request is causing low-quality responses.
### What is the issue?

When using open-webui, I've noticed that long contextual messages sent to ollama consistently result in poor responses. After investigating the issue, it appears that the `/api/chat` and `/v1/chat/completions` endpoints are defaulting to a 1k context limit. This means that when the content exceeds this length, the system automatically discards the earlier portions, leading to subpar answers. What follows is the captured network request data for open-webui version 0.3.8.

curl ' URL \
-X POST \
-H 'Host: localhost:11434' \
-H 'Accept: */*' \
-H 'User-Agent: Python/3.11 aiohttp/3.9.5' \
-H 'Content-Type: text/plain; charset=utf-8' \
--data-raw '{"model": "qwen1_5-4b-chat-q4_k_m", "messages": [{"role": "user", "content": " "}], "options": {}, "stream": true}'

Based on the final response, we can observe that the prompt_eval_count is 1026, which indicates that only approximately 1,000 tokens of context were processed.

{"role":"assistant","content":""},"done_reason":"stop","done":true,"total_duration":9987503333,"load_duration":28999667,"prompt_eval_count":1026,"prompt_eval_duration":1896469000,"eval_count":238,"eval_duration":8059779000}

I'm uncertain whether I should submit an issue about this bug to the open-webui repository.

### OS

macOS

### GPU

Apple

### CPU

Apple

### Ollama version

0.3.0

You also set a context length for a model in open-webui. Go to Workspace > Models > Create a model, choose the base model, scroll down to Model Params and under Advanced Params, set the context length.

Thank you for your response! I've also discovered another bug. When I add "options": {"num_ctx": 32000} to the `/v1/chat/completions` endpoint, it doesn't take effect and the context length remains at 1k. This option works correctly on the `/api/chat` and `/api/generate endpoints`.

Probably because the OpenAI API doesn't support specifying the context window, just `max_tokens`. So yes, that would be an appropriate feature request for ollama.

A bit more information is needed. If you supply a server log (`docker logs `) it can be checked for truncation messages. It would also be useful to see the actual HTTP request that open-webui is sending. Unfortunately that's not logged, so a tool needs to be installed to capture that:

$ docker exec -it apt install -y tcpflow
$ docker exec -it tcpflow -c 'src port 11434 or dst port 11434' > ollama-open-webui.log

Run this, use open-webui for a long context conversation, ^C tcpflow, remove any PII from the log, and add it here.

@chris-31337 , "prompt_eval_count" refers to the actual length of the processed prompt, which is 934 in your ollama-open-webui.log, meaning only the last 934 tokens were used as the prompt. Didn't you modify the modelfile as suggested? It worked for me after I made the changes. Also, is this screenshot from openwebui? I haven't seen this option before.

From ollama-docker.log:

INFO [update_slots] input truncated | n_ctx=2048 n_erase=19335 n_keep=4 n_left=2044 n_shift=1022 tid="133210613727232" timestamp=1722942601

From ollama-open-webui.log:

have ever known."}],"options":{},"keep_alive":"15m","sess

There's no `num_ctx` in the `options` field, so the input text of ~21k tokens is being whittled down to 2048 by throwing away 19335 of them. What version of open-webui are you using? I'll fire up a docker container with it and see if I can replicate.

I just discovered this setting in open-webui. My version is v0.3.11, and it's actually working. I had no idea about it before... @chris-31337
1723208848023

@anrgct interesting issue. As it is solved. Could you please close it to reduce the number of open issues?

Thank you for your patient replies! @igorschlum @rick-github

Bug Report: Context Loss
### What is the issue?

## Bug Report: Context Loss in `mistral-nemo` Model

### Description

I am using the `mistral-nemo` model in Ollama, which is supposed to have a 128k context window. However, I am observing issues with context loss with this model and the `llama3` model as well.

### Steps to Reproduce

1. Run the command `ollama run mistral-nemo`.
2. Use the following prompt:

plaintext
'{id: 0, name: "Alexander City"}'
'{id: 1, name: "Andalusia"}'
'{id: 2, name: "Anniston"}'
'{id: 3, name: "Athens"}'
'{id: 4, name: "Atmore"}'
'{id: 5, name: "Auburn"}'
'{id: 6, name: "Bessemer"}'
'{id: 7, name: "Birmingham"}'
'{id: 8, name: "Chickasaw"}'
'{id: 9, name: "Clanton"}'
'{id: 10, name: "Cullman"}'
'{id: 11, name: "Decatur"}'
'{id: 12, name: "Demopolis"}'
'{id: 13, name: "Dothan"}'
'{id: 14, name: "Enterprise"}'
'{id: 15, name: "Eufaula"}'
'{id: 16, name: "Florence"}'
'{id: 17, name: "Fort Payne"}'
'{id: 18, name: "Gadsden"}'
'{id: 19, name: "Greenville"}'
'{id: 20, name: "Guntersville"}'
'{id: 21, name: "Huntsville"}'
'{id: 22, name: "Jasper"}'
'{id: 23, name: "Marion"}'
'{id: 24, name: "Mobile"}'
'{id: 25, name: "Montgomery"}'
'{id: 26, name: "Opelika"}'
'{id: 27, name: "Ozark"}'
'{id: 28, name: "Phenix City"}'
'{id: 29, name: "Prichard"}'
'{id: 30, name: "Scottsboro"}'
'{id: 31, name: "Selma"}'
'{id: 32, name: "Sheffield"}'
'{id: 33, name: "Sylacauga"}'
'{id: 34, name: "Talladega"}'
'{id: 35, name: "Troy"}'
'{id: 36, name: "Tuscaloosa"}'
'{id: 37, name: "Tuscumbia"}'
'{id: 38, name: "Tuskegee"}'
'{id: 39, name: "Alaska"}'
'{id: 40, name: "Anchorage"}'
'{id: 41, name: "Cordova"}'
'{id: 42, name: "Fairbanks"}'
'{id: 43, name: "Haines"}'
'{id: 44, name: "Homer"}'
'{id: 45, name: "Juneau"}'
'{id: 46, name: "Ketchikan"}'
'{id: 47, name: "Kodiak"}'
'{id: 48, name: "Kotzebue"}'
'{id: 49, name: "Nome"}'
'{id: 50, name: "Palmer"}'
'{id: 51, name: "Seward"}'
'{id: 52, name: "Sitka"}'
'{id: 53, name: "Skagway"}'
'{id: 54, name: "Valdez"}'
'{id: 55, name: "Arizona"}'
'{id: 56, name: "Ajo"}'
'{id: 57, name: "Avondale"}'
'{id: 58, name: "Bisbee"}'
'{id: 59, name: "Casa Grande"}'
'{id: 60, name: "Chandler"}'
'{id: 61, name: "Clifton"}'
'{id: 62, name: "Douglas"}'
'{id: 63, name: "Flagstaff"}'
'{id: 64, name: "Florence"}'
'{id: 65, name: "Gila Bend"}'
'{id: 66, name: "Glendale"}'
'{id: 67, name: "Globe"}'
'{id: 68, name: "Kingman"}'
'{id: 69, name: "Lake Havasu City"}'
'{id: 70, name: "Mesa"}'
'{id: 71, name: "Nogales"}'
'{id: 72, name: "Oraibi"}'
'{id: 73, name: "Phoenix"}'
'{id: 74, name: "Prescott"}'
'{id: 75, name: "Scottsdale"}'
'{id: 76, name: "Sierra Vista"}'
'{id: 77, name: "Tempe"}'
'{id: 78, name: "Tombstone"}'
'{id: 79, name: "Tucson"}'
'{id: 80, name: "Walpi"}'
'{id: 81, name: "Window Rock"}'
'{id: 82, name: "Winslow"}'
'{id: 83, name: "Yuma"}'
'{id: 84, name: "Arkansas"}'
'{id: 85, name: "Arkadelphia"}'
'{id: 86, name: "Arkansas Post"}'
'{id: 87, name: "Batesville"}'
'{id: 88, name: "Benton"}'
'{id: 89, name: "Blytheville"}'
'{id: 90, name: "Camden"}'
'{id: 91, name: "Conway"}'
'{id: 92, name: "Crossett"}'
'{id: 93, name: "El Dorado"}'
'{id: 94, name: "Fayetteville"}'
'{id: 95, name: "Forrest City"}'
'{id: 96, name: "Fort Smith"}'
'{id: 97, name: "Harrison"}'
'{id: 98, name: "Helena"}'
'{id: 99, name: "Hope"}'
'{id: 100, name: "Hot Springs"}'
'{id: 101, name: "Jacksonville"}'
'{id: 102, name: "Jonesboro"}'
'{id: 103, name: "Little Rock"}'
'{id: 104, name: "Magnolia"}'
'{id: 105, name: "Morrilton"}'
'{id: 106, name: "Newport"}'
'{id: 107, name: "North Little Rock"}'
'{id: 108, name: "Osceola"}'
'{id: 109, name: "Pine Bluff"}'
'{id: 110, name: "Rogers"}'
'{id: 111, name: "Searcy"}'
'{id: 112, name: "Stuttgart"}'
'{id: 113, name: "Van Buren"}'
'{id: 114, name: "West Memphis"}'
'{id: 115, name: "California"}'
'{id: 116, name: "Alameda"}'
'{id: 117, name: "Alhambra"}'
'{id: 118, name: "Anaheim"}'
'{id: 119, name: "Antioch"}'
'{id: 120, name: "Arcadia"}'
'{id: 121, name: "Bakersfield"}'
'{id: 122, name: "Barstow"}'
'{id: 123, name: "Belmont"}'
'{id: 124, name: "Berkeley"}'
'{id: 125, name: "Beverly Hills"}'
'{id: 126, name: "Brea"}'
'{id: 127, name: "Buena Park"}'
'{id: 128, name: "Burbank"}'
'{id: 129, name: "Calexico"}'
'{id: 130, name: "Calistoga"}'
'{id: 131, name: "Carlsbad"}'
'{id: 132, name: "Carmel"}'
'{id: 133, name: "Chico"}'
'{id: 134, name: "Chula Vista"}'
'{id: 135, name: "Claremont"}'
'{id: 136, name: "Compton"}'
'{id: 137, name: "Concord"}'
'{id: 138, name: "Corona"}'
'{id: 139, name: "Coronado"}'
'{id: 140, name: "Costa Mesa"}'
'{id: 141, name: "Culver City"}'
'{id: 142, name: "Daly City"}'
'{id: 143, name: "Davis"}'
'{id: 144, name: "Downey"}'
'{id: 145, name: "El Centro"}'
'{id: 146, name: "El Cerrito"}'
'{id: 147, name: "El Monte"}'
'{id: 148, name: "Escondido"}'
'{id: 149, name: "Eureka"}'
'{id: 150, name: "Fairfield"}

3. Ask: "What's the city with id 1?"

The response is:

plaintext
The city with id 1 is not included in the provided list. The smallest id number present is for Arkadelphia, which has an id of 85.

This indicates that the model is losing context since `Andalusia` should be the correct answer.

### Temporary Solution

I found that setting the `num_ctx` parameter to 120000 before the prompt resolves the issue. For example:

plaintext
/set parameter num_ctx 120000

Then, when repeating the experiment, I receive the correct response:

plaintext
The city with id 1 is "Andalusia".

### Additional Information

Running `ollama show mistral-nemo` provides the following details:

plaintext
Model
 arch llama
 parameters 12.2B
 quantization Q4_0
 context length 1.024e+06
 embedding length 5120

Parameters
 stop "[INST]"
 stop "[/INST]"

License
 "Apache License"

### API Usage

When using the API directly with `curl`, the problem persists even if I use:

json
options = {"num_ctx": 120000}

To resolve this, I need to pass:

json
{"role": "user", "content": "/set parameter num_ctx 120000"}

within `messages` during the request.

### Conclusion

There is a bug in Ollama where the `mistral-nemo` (and `llama3`) model loses context unless the `num_ctx` parameter is explicitly set within the prompts.

### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.2.8

As background, ollama API calls (and CLI prompts via `ollama run`) that don't specify a context length, use a context length of 2048 tokens. If you need more context, you either need to specify that in the API call or change the default. `options = {"num_ctx": 120000}` is the canonical way to do that, if it's not working that's a bug and it would be great if you could send server logs demontrating this issue. Adding `{"role": "user", "content": "/set parameter num_ctx 120000"}` to an API call will not change the context window because `/set parameter` is interpreted by the CLI (`ollama run`), which is not involved in inference during an API call.

To change the default context window of a model and so do away with having to add `options` to an API call, you need to create a new model. This is easy to do and if you follow the instructions, does not require more disk.

First, get a copy of the current modelfile:

ollama show --modelfile mistral-nemo > Modelfile

Now edit the file and do two things:
1. Where it says `FROM` and a long file path, change the file path to the name of the model.
 eg, `FROM /root/.ollama/models/blobs/sha256-b559938ab7a0392fc9ea9675b82280f2a15669ec3e0e0fc491c9cb0a7681cf94`
 becomes `FROM mistral-nemo`
2. Create a new line in the file and add `PARAMETER num_ctx 120000`

Create the new model:

ollama create -f Modelfile mistral-nemo-120k

Verify the change in default context length, check num_ctx under paramaters:

 $ ollama show mistral-nemo-120k
 Model
 arch llama
 parameters 12.2B
 quantization Q4_0
 context length 1.024e+06
 embedding length 5120

 Parameters
 num_ctx 120000
 stop "[INST]"
 stop "[/INST]"

This should solve your context problem, if it persists please follow up with server logs.

this should be mentioned somewhere in the documentation, if not already.

@rick-github thanks for the awesome explanation! Will close this for now. @rodolfo-nobrega @anubhav-agrawal-mu-sigma feel free to follow up if things still aren't working..

the faq needs to be updated with your example as it took a lot of time to understand and configure the solution as it is NOT mentioned in faq - URL

I agree, I have a WIP to update various bits of documentation but haven't pushed a PR yet.


Question: [BUG] Compositor crash when using KVM and switching inputs with 2 monitors?

I am pretty confident the last variant of this issue has now been resolved with URL

Thanks @hayandev for debugging this. The missing piece was, that this only happens, when the last output is disconnected (even if just temporarily), which is why I wasn't able to reproduce this earlier.

I bunch of this code was refactored when focus-follows-cursor was introduced, which caused some subtle regressions, which only surfaced after some other fixes to output hotplug. At last that logic should be sound now.

[BUG] Compositor crash when using KVM and switching inputs with 2 monitors
Hey all,

I finally got around to running the debug version of the compiler (really don't suggest running it like this all the time it's so slow :sob: ) and I was able to reproduce the crash I was seeing in URL Here's my logs for today after reproducing the issue:

cosmic-comp-journal.log

Display info:

$ xrandr
Screen 0: minimum 16 x 16, current 5120 x 1440, maximum 32767 x 32767
DP-2 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
 2560x1440 143.91*+
 1920x1440 143.90
 1600x1200 143.89
 1440x1080 143.80
 1400x1050 143.89
 1280x1024 143.79
 1280x960 143.86
 1152x864 143.92
 1024x768 143.87
 800x600 143.83
 640x480 143.85
 320x240 142.05
 1920x1200 143.89
 1680x1050 143.88
 1440x900 143.86
 1280x800 143.84
 1152x720 143.77
 960x600 143.72
 928x580 143.50
 800x500 143.68
 768x480 143.69
 720x480 143.85
 640x400 143.37
 320x200 141.40
 2048x1152 143.88
 1920x1080 143.88
 1600x900 143.93
 1368x768 143.77
 1280x720 143.85
 1024x576 143.91
 864x486 143.63
 720x400 143.88
 640x350 143.57
DP-1 connected 2560x1440+2560+0 (normal left inverted right x axis y axis) 600mm x 340mm
 2560x1440 59.91*+
 1920x1440 59.90
 1600x1200 59.87
 1440x1080 59.87
 1400x1050 59.86
 1280x1024 59.89
 1280x960 59.94
 1152x864 59.78
 1024x768 59.68
 800x600 59.86
 640x480 59.38
 320x240 59.52
 1920x1200 59.88
 1680x1050 59.85
 1440x900 59.89
 1280x800 59.81
 1152x720 59.75
 960x600 59.63
 928x580 59.88
 800x500 59.50
 768x480 59.38
 720x480 59.71
 640x400 59.20
 320x200 58.96
 2048x1152 59.90
 1920x1080 59.88
 1600x900 59.82
 1368x768 59.88
 1280x720 59.86
 1024x576 59.90
 864x486 59.45
 720x400 59.55
 640x350 59.77

$ sudo lshw -C display
 *-display
 description: VGA compatible controller
 product: GA102 [GeForce RTX 3080 Ti]
 vendor: NVIDIA Corporation
 physical id: 0
 bus info: pci@0000:09:00.0
 version: a1
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi pciexpress vga_controller bus_master cap_list rom
 configuration: driver=nvidia latency=0
 resources: iomemory:780-77f iomemory:7c0-7bf irq:80 memory:fb000000-fbffffff memory:7800000000-7bffffffff memory:7c00000000-7c01ffffff ioport:e000(size=128) memory:fc000000-fc07ffff

I super appreciate y'all fixing the greeter in this aspect. If this can be fixed, I'll be able to go back to daily driving Cosmic! If you need more information from me, please let me know and I'll try to get it for you.

I should probably mention that, when switching, the 60Hz monitor takes a bit longer to connect than the 144Hz. Maybe that has something to do with this?

This appears to be related to #906 (both panic at the same line in `mod.rs`).

Appears to be fixed for me on

$ rpm -q cosmic-comp
cosmic-comp-1.0.0~alpha.4^git20241216.7ac204e-1.fc41.x86_64

Crash when disconnecting/reconnecting monitor
Distro: Arch Linux
Version: cosmic-comp 1.0.0.alpha.2-1

When reconnecting the monitor (happens when turning monitor back on according to timestamp) cosmic-comp crashes, taking all open programs with it.

Logs:

Oct 05 13:45:24 cosmic cosmic-comp[1501]: thread 'main' panicked at 'called `Option::unwrap()` on a `None` value': src/shell/mod.rs:973
 0:
 1:
 2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
 18:
 19:
 20: __libc_start_main
 21:
Oct 05 13:45:24 cosmic cosmic-comp[1501]: thread 'surface-HDMI-A-1' panicked at 'called `Result::unwrap()` on an `Err` value: PoisonError { .. }': src/backend/kms/surface/mod.rs:1076
 0:
 1:
 2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
Oct 05 13:45:24 cosmic xdg-desktop-por[1752]: Error reading events from display: Broken pipe
Oct 05 13:45:24 cosmic cosmic-session[1476]: Io error: Broken pipe (os error 32)
Oct 05 13:45:24 cosmic systemd[1463]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
Oct 05 13:45:24 cosmic systemd[1463]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
Oct 05 13:45:24 cosmic cosmic-session[1476]: process ' COSMIC_SESSION_SOCK=12 cosmic-comp ' failed with code 101
Oct 05 13:45:24 cosmic cosmic-session[1476]: cosmic-comp exited with error code 101
Oct 05 13:45:24 cosmic cosmic-session[1476]: draining stdin receiver before restarting process
Oct 05 13:45:24 cosmic cosmic-session[1476]: sleeping for 0ms before restarting process cosmic-comp (restart 0)
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(11v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(10v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(9v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(8v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(7v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(6v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(5v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(4v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(3v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(2v1)' cancelled
Oct 05 13:45:24 cosmic cosmic-session[1476]: RESTARTING: session restarted by request
Oct 05 13:45:24 cosmic cosmic-session[1476]: restarted process ' COSMIC_SESSION_SOCK=12 cosmic-comp ', now at 1 restarts
Oct 05 13:45:24 cosmic cosmic-session[1476]: process 'ProcessKey(1v1)' cancelled
Oct 05 13:45:26 cosmic systemd[1463]: Stopped target Cosmic Session Target.
Oct 05 13:45:26 cosmic systemd[1463]: Stopped target Current graphical user session.
Oct 05 13:45:26 cosmic systemd[1463]: Stopped target Session services which should run early before the graphical session is brought up.
Oct 05 13:45:26 cosmic systemd[1463]: Stopped target Startup of XDG autostart applications.
Oct 05 13:45:26 cosmic dbus-broker[1823]: Dispatched 20 messages @ 3(±4)μs / message.
Oct 05 13:45:26 cosmic cosmic-session[1476]: Restarting
Oct 05 13:45:26 cosmic systemd[1463]: Stopping Accessibility services bus...
Oct 05 13:45:26 cosmic systemd[1463]: Stopping Portal service...
Oct 05 13:45:26 cosmic systemd[1463]: Stopping flatpak document portal service...
Oct 05 13:45:26 cosmic systemd[1463]: Stopping sandboxed app permission store...
Oct 05 13:45:26 cosmic systemd[1463]: Stopped sandboxed app permission store.
Oct 05 13:45:26 cosmic cosmic-session[1476]: Starting cosmic-session

Same here:

log
Nov 13 21:19:50 sisyphus .cosmic-comp-wrapped[2139]: thread 'main' panicked at 'called `Option::unwrap()` on a `None` value': src/shell/mod.rs:974
 0: ::default
 1: log_panics::Config::install_panic_hook::{{closure}}
 2: std::panicking::rust_panic_with_hook
 3: std::panicking::begin_panic_handler::{{closure}}
 4: std::sys::backtrace::__rust_end_short_backtrace
 5: rust_begin_unwind
 6: core::panicking::panic_fmt
 7: core::panicking::panic
 8: core::option::unwrap_failed
 9: cosmic_comp::shell::Workspaces::active
 10: cosmic_comp::input:: ::surface_under
 11: cosmic_comp::shell::focus:: ::refresh_focus
 12: calloop::loop_logic::EventLoop ::run
 13: cosmic_comp::main
 14: std::sys::backtrace::__rust_begin_short_backtrace
 15: main
 16: __libc_start_call_main
 17: __libc_start_main_alias_2
 18: _start
Nov 13 21:19:50 sisyphus .cosmic-comp-wrapped[2139]: thread 'surface-DP-1' panicked at 'called `Result::unwrap()` on an `Err` value: PoisonError { .. }': src/backend/kms/surface/mod.rs:1124
 0: ::default
 1: log_panics::Config::install_panic_hook::{{closure}}
 2: std::panicking::rust_panic_with_hook
 3: std::panicking::begin_panic_handler::{{closure}}
 4: std::sys::backtrace::__rust_end_short_backtrace
 5: rust_begin_unwind
 6: core::panicking::panic_fmt
 7: core::result::unwrap_failed
 8: cosmic_comp::backend::kms::surface::SurfaceThreadState::redraw
 9: > as calloop::sources::EventDispatcher >::process_events
 10: cosmic_comp::backend::kms::surface::surface_thread
 11: std::sys::backtrace::__rust_begin_short_backtrace
 12: core::ops::function::FnOnce::call_once{{vtable.shim}}
 13: std::sys::pal::unix::thread::Thread::new::thread_start
 14: start_thread
 15: __GI___clone3
Nov 13 21:19:50 sisyphus .xdg-desktop-po[2723]: Error reading events from display: Broken pipe
Nov 13 21:19:50 sisyphus cosmic-session[2122]: Io error: Broken pipe (os error 32)
Nov 13 21:19:50 sisyphus systemd[2100]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
Nov 13 21:19:50 sisyphus systemd[2100]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
Nov 13 21:19:50 sisyphus cosmic-session[2122]: process ' COSMIC_SESSION_SOCK=12 cosmic-comp ' failed with code 101
Nov 13 21:19:50 sisyphus pipewire[2382]: mod.x11-bell: X11 I/O error handler called on display :1
Nov 13 21:19:50 sisyphus pipewire[2382]: mod.x11-bell: X11 display (:1) has encountered a fatal I/O error
Nov 13 21:19:50 sisyphus systemd[2100]: cosmic-launcher.scope: Consumed 41min 35.720s CPU time, 653.5M memory peak.
Nov 13 21:19:50 sisyphus systemd[2100]: app-cosmic-google-chrome-30911.scope: Consumed 3min 23.597s CPU time, 1.4G memory peak.
Nov 13 21:19:50 sisyphus cosmic-session[2122]: cosmic-comp exited with error code 101

I think this is a duplicate of #679, which might trace back to #57. This is also being tracked in pop-os/cosmic-epoch#84.

I get a similar error when trying to "wake up" my computer after sleep.

Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: Failed to destroy old mode property blob: No such file or directory (os error 2)
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: Failed to set new config.
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: failed to create signaled syncobj
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:54 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:54 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:59 .cosmic-comp-wrapped[1514]: Failed to destroy old mode property blob: No such file or directory (os error 2)
Nov 18 16:36:59 .cosmic-comp-wrapped[1514]: thread 'surface-HDMI-A-1' panicked at 'internal error: entered unreachable code': src/backend/kms/surface/mod.rs:780
 0: ::default
 1: log_panics::Config::install_panic_hook::{{closure}}
 2: std::panicking::rust_panic_with_hook
 3: std::panicking::begin_panic_handler::{{closure}}
 4: std::sys::backtrace::__rust_end_short_backtrace
 5: rust_begin_unwind
 6: core::panicking::panic_fmt
 7: core::panicking::panic
 8: > as calloop::sources::EventDispatcher >::process_events::{{closure}}
 9: > as calloop::sources::EventDispatcher >::process_events
 10: cosmic_comp::backend::kms::surface::surface_thread
 11: std::sys::backtrace::__rust_begin_short_backtrace
 12: core::ops::function::FnOnce::call_once{{vtable.shim}}
 13: std::sys::pal::unix::thread::Thread::new::thread_start
 14: start_thread
 15: clone3

System is NixOs using the stable branch. Cosmic versions are

cosmic-applets-1.0.0-alpha.2-unstable-2024-10-21
cosmic-applibrary-1.0.0-alpha.2-unstable-2024-10-24
cosmic-bg-1.0.0-alpha.2-unstable-2024-10-09
cosmic-comp-1.0.0-alpha.2-unstable-2024-10-25
cosmic-edit-1.0.0-alpha.2-unstable-2024-10-29
cosmic-files-1.0.0-alpha.2-unstable-2024-10-29
cosmic-greeter-1.0.0-alpha.2-unstable-2024-10-14
cosmic-icons-1.0.0-alpha.2-unstable-2024-10-02
cosmic-idle-0-unstable-2024-10-30
cosmic-launcher-1.0.0-alpha.2-unstable-2024-10-29
cosmic-notifications-1.0.0-alpha.2-unstable-2024-10-24
cosmic-osd-1.0.0-alpha.2-unstable-2024-10-09
cosmic-panel-1.0.0-alpha.2-unstable-2024-10-22
cosmic-randr-1.0.0-alpha.2-unstable-2024-10-24
cosmic-screenshot-1.0.0-alpha.2-unstable-2024-07-25
cosmic-session-1.0.0-alpha.2-unstable-2024-10-30
cosmic-settings-1.0.0-alpha.2-unstable-2024-10-30
cosmic-settings-daemon-1.0.0-alpha.2-unstable-2024-09-26
cosmic-term-1.0.0-alpha.2-unstable-2024-10-30
cosmic-wallpapers-1.0.0-alpha.2-unstable-2024-09-27
cosmic-workspaces-epoch-1.0.0-alpha.2-unstable-2024-08-07
xdg-desktop-portal-cosmic-1.0.0-alpha.2-unstable-2024-10-10

@Drakulix Please note that I just updated and am still able to reproduce this issue and URL .

I've tried it maybe 5-6 times in a row, with terminal open on the laptop screen and browser on the external monitor, and I lose both every single time I unplug HDMI.

I have attached my software versions as well as the journal log from the crash (starting around timestamp 0932).

Dec 13 09:32:03 pop-os cosmic-comp[2537]: thread 'main' panicked at 'called `Option::unwrap()` on a `None` value': src/shell/mod.rs:974

journal_log.txt
sys_info_sw_2024-Dec-13- 921.txt

How have you updated your install? I am not sure that version is live anywhere, but the Pop!_OS staging repo.

These logs are unfortunately not very helpful, as they don't contain full backtraces. A debug build of cosmic-comp would produce proper ones.

@Drakulix the COSMIC alpha apt repo appears to be pushing nightly builds; today's update version has the commit hash matching #1057 merging to `master`.

I've just updated, if I continue to see the issue I'll see about getting a stacktrace from a debug build.

$ apt show cosmic-comp
Package: cosmic-comp
Version: 0.1~1734010190~24.04~9b41275
Priority: optional
Section: x11
Maintainer: Victoria Brekenfeld
Installed-Size: 24.7 MB
Depends: libc6 (>= 2.38), libgbm1 (>= 21.3.0~rc1), libgcc-s1 (>= 4.2), libinput10 (>= 1.19.1), libpixman-1-0 (>= 0.30.0), libseat1 (>= 0.5.0), libudev1 (>= 183), libxkbcommon0 (>= 0.5.0), libegl1, libwayland-server0
Recommends: cosmic-session, libgl1-mesa-dri
Homepage: URL
Download-Size: 7,859 kB
APT-Manual-Installed: no
APT-Sources: URL noble/main amd64 Packages
Description: Wayland compositor of pop-os cosmic shell

I unfortunately still get that issue with URL I've built it with debugging symbols and tried to bisect the relevant parts, maybe this cosmic-reconnect-crash-log.txt log helps (I think the relevant stacktrace is on line 9606), it looks pretty similar as the log from @zsilet.

What I find interesting, is that cosmic-panel crashes first, maybe related, maybe a similar issue as this within cosmic-panel.

I still see to see unwrap panics in `Workspaces::active()` sometimes on disconnecting on monitor, even with the latest changes.

I've found the issue in my case( URL
Here's a step-by-step breakdown of the process leading to the panic:

1. Monitor disconnected (let's call it `Output-1`).
2. In `Workspaces::remove_output`:
 1. Removed from the `sets`.
 2. The `backup_set` is set (line 772).
3. Monitor connected (let's call it `Output-2`).
4. In `Workspaces::add_output`:
 1. The `backup_set` is added to `sets` with `Output-2` as the key.
5. Main function starts handling the event loop (line 120).
6. In `Common::refresh_focus`, a loop over `seats`:
 1. In `State::surface_under`, the function `shell.workspaces.active(output)` is called.
 1. At no point in the above steps is the seat's output updated to `Output-2`.
 2. Therefore, the `output` passed as a parameter is `Output-1`.
 2. Panic occurs.

I think the call to `update_pointer_focus()` at line 347 in `Common::refresh_focus` should be moved below line 359.

Also, when setting `backup_set` in `Workspaces::remove_output`, the `focused_output` of the `seat` for the removed `output` should be set to `None`.

However, I’m not sure what exactly `update_pointer_focus()` is for, so I could be wrong.
Anyway, I found that this resolves the issue.

I’m not very good at English, so I got help from ChatGPT. I’ve read through it and made some revisions, but I apologize if the sentences sound awkward.

I can confirm I am no longer seeing the sleep/wake variant of this issue.

Closing for now. Please comment if you can still reproduce on latest master (preferably with reproducing steps and/or a stack trace). I'll re-open this issue should we find another cause.

Thank you @Drakulix , verified working with the latest update.

Working for me too on

$ rpm -q cosmic-comp
cosmic-comp-1.0.0~alpha.4^git20241216.7ac204e-1.fc41.x86_64

Can confirm my crash is also fixed. Thank you very much, this was the last blocker to me trying out Cosmic full time!