2,818,117 events, 1,402,342 push events, 2,220,842 commit messages, 180,362,274 characters
Don't add versions of resource already present in the database
Problem: (copied from the commit with the title: "Don't add inactive versions of resources as new resources" (I cannot say the git hash because it's only local here for now, so it would be incorrect anyway)
KisResourceCacheDb, noticing the resource already exists, checks for timestamp and adds a new version if needed. However at this point it shouldn't be needed, ever, no matter what timestamps say.
If a filepath is in the database, then it means Krita knows about it and already has this filepath remembered. Adding a new version with the same filepath doesn't sound reasonable. If the user replaced one resource with the same, called the same way, it means we might need to update the thumbnail and/or the name, but adding anything to the database - no, because there is no more resources, they were replaced.
With proper versioning and the feature "revert to previous version", it will lead to even more trouble, with the newest-by-timestamp version replacing the user-selected current version on every restart.
This resulted in multiple versions with -1 number and generally duplication of versions.
Instead, we should just update the timestamp. (Also why would we use timestamp now, anyway?) Note: this commit doesn't do that yet.
fixes ninja shoes for humans
im gonna lose my fucking shit with you people
[MIRROR] Removes the gen_turfs from icebox arrivals (#204)
-
Removes the gen_turfs from icebox arrivals, they don't god damn do anything because they are literally just placeholders for areas, and they aren't in the right fucking area. Also gets rid of some dumb plating that makes the area looks worse imo (#56107)
-
Removes the gen_turfs from icebox arrivals
Co-authored-by: LemonInTheDark [email protected]
mido: Change path naming for cert
- Added legacy-um to devicetree itself so fuck you
Signed-off-by: Gagan Malvi [email protected] Change-Id: Ie808b6b7bb7f90ba798604530c3f0e85a0534626
New data: 2021-01-12. See data notes for important messages.
NT testing decreased today for an unknown reason.
Vaccine datasets:
- 2021-01-11: Our Ontario vaccine dataset has changed. Previously, we used two datasets: the MoH Daily Situation Report (https://www.oha.com/news/updates-on-the-novel-coronavirus), which is released weekdays in the evenings, and the “COVID-19 Vaccine Data in Ontario” dataset (https://data.ontario.ca/dataset/covid-19-vaccine-data-in-ontario), which is released every day in the mornings. Because the Daily Situation Report is released later in the day, it has more up-to-date numbers. However, since it is not available on weekends, this leads to an artificial “dip” in numbers on Saturday and “jump” on Monday due to the transition betwen data sources. We will now exclusively use the daily “COVID-19 Vaccine Data in Ontario” dataset. Although our numbers will be slightly less timely, the daily values will be consistent. We have replaced our historical dataset with “COVID-19 Vaccine Data in Ontario” as far back as they are available.
- 2020-12-17: Vaccination data have been added as time series in timeseries_prov and timeseries_hr.
- 2020-12-15: We have added two vaccine datasets to the repository, vaccine_administration_cumulative.csv and vaccine_distribution_cumulative.csv. These data should be considered preliminary and are subject to change and revision. The format of these new datasets may also change at any time as the data situation evolves.
Upcoming changes (specific dates to be announced soon):
- The data structure of time series data will change in response to user feedback. This will only consist of adding additional columns to make the data easier to work with. The core columns will remain the same, for now. More details to follow. Initially, the updated dataset will be provided alongside the new dataset. After a time, the new data format will completely replace the old format.
Recent changes:
- 2021-01-08: The directories cases_extra and mortality_extra have been moved to other/cases_extra and other/mortality_extra.
Revise historical data: cases (AB, BC, MB, ON); mortality (MB, ON, QC); testing (NT).
Note regarding deaths added in QC today: “The data also report 47 new deaths, but the total of deaths amounts to 8,782 due to the withdrawal of 2 deaths that the investigation has shown not to be attributable to COVID-19. Among these 47 deaths, 13 have occurred in the last 24 hours, 27 have occurred between January 5 and January 10, 4 have occurred before January 5 and 3 have occurred at an unknown date.” We report deaths such that our cumulative regional totals match today’s values. This sometimes results in extra deaths with today’s date when older deaths are removed.
Note about SK data: As of 2020-12-14, we are providing a daily version of the official SK dataset that is compatible with the rest of our dataset in the folder official_datasets/sk. See below for information about our regular updates.
SK transitioned to reporting according to a new, expanded set of health regions on 2020-09-14. Unfortunately, the new health regions do not correspond exactly to the old health regions. Additionally, the provided case time series using the new boundaries do not exist for dates earlier than August 4, making providing a time series using the new boundaries impossible.
For now, we are adding new cases according to the list of new cases given in the “highlights” section of the SK government website (https://dashboard.saskatchewan.ca/health-wellness/covid-19/cases). These new cases are roughly grouped according to the old boundaries. However, health region totals were redistributed when the new boundaries were instituted on 2020-09-14, so while our daily case numbers match the numbers given in this section, our cumulative totals do not. We have reached out to the SK government to determine how this issue can be resolved. We will rectify our SK health region time series as soon it becomes possible to do so.
somewhat finished the scrollbar
fuck you python and fuck your average bullshit
Created Text For URL [thenationonlineng.net/18-year-old-girl-set-boyfriend-ablaze-in-benue/]
test: Fake EOL date of Fedora 28
We write the year 2020. Forgotten by the masses, and shadowed by the turmoils of the COVID-19 pandemic, a little gray Linux distribution took its last breath and withered away. The big Lib Virt forgot about its once loved child, and refused to ever look at it again.
But a small group of intrepid developers put on their red helmets^Whats, mounted their cockpit, and went out to salvage it. Never shall the world forget "Fedora 28" again, and it will still stand strong long after every other penguin in the world ate their last fish.
Boring technical epilogue: libvirt only allows installing a distribution up to a year after its EOL. Make sure that we don't run into that trap anytime soon again.
Closes #14177
"11am. I went to bed far too late yesterday.
11:05am. Let me read the OPM dump and then I'll do some work on the docs.
11:20am. Let me work on the docs for an hour. I need to get into this for a bit. It is time to start wrapping things up.
///
The previous segment is not all there is to serialization. I could have picked other subjects to demonstrate the language's prowess at abstraction, but serialization is a common task that other languages rarely do without flaw. It will only get more important as time goes on. When I picked F# as main target in the old version of Spiral it was mistake because I had no automatic way to manage GPU memory. Yet, the future hardware will not have unified memory and it won't be necessary to deal with unmanaged pointers like in the past. Instead it will all be about message passing between isolated cores, and being able to succinctly and efficiently serialize data in various formats and having it cross various kinds of boundaries is Spiral's greatest strength.
Back in 2016, I ran into a fairly extreme serialization challenge when trying to pass data to a NN agent. At that time, I had no idea how to do pickler combinators so my situation was that much worse - I fervently wished for some way to map a regular type to a sequence of one-hot vectors.
An one-hot vector is an array whose elements are all 0, apart from a single element which is 1. I needed an efficient way to do this task - I tried doing it by hand in C style, but the problem with doing that quickly becomes aparent. It is extemely unsafe and very hard to do. It is a killer combination that slowly set me on the path of being a language designer.
Imagine you are doing a NN-based poker agent, and the you are trying to pass an input to its model. The is a simple HU poker variant with two cards. Here is how the game state could be modeled.
type rank = i32
type suit = i32
type card = rank * suit
type player = {
stack : i32
hand : card * card
}
type pot = i32
type game = player * player * pot
We'll assume that the opponent's previous action could be inferred from the size of the pot. But the player should receive his previous action during this betting round. So the actual player input would be something like this.
union action =
| Raise: i32
| Call
| NoAction
type player_view = {
stack_self : i32
stack_opp : i32
pot : i32
hand : card * card
prev_action : action
}
This player_view is what needs to be serialized. Compared to the previous scheme, things are more difficult this time. There are two main challenges.
-
Serializing arbirary ints is far too wasteful. An int converted to a one hot-vector would take 2Gb. Instead one has to account for maximum and minimum stack sizes which might be between 0 to a few 100 chips. Suits are only 4, and the number of different cards is 13. In other words, the problem is that unlike in the previous section, the type no longer corresponds to the representation being used. It would be great if Spiral had dependent types so that bounded ints could be used, but that is not the case here. There is no problem with using ints for stack sizes and such inside the game itself, but they are huge problem to serialize in the one-hot format.
-
Dealing with sizes. As in the previous section, the union types are tricky here because one case is prefixed by the rest.
Because of the added difficulties, unlike when it comes to vanilla serialization, the introspective approach is no longer so obviously superior to the introspective one. If all the bounds are known at compile time, an introspective approach would involve using nominals with symbolic bounds which would require hackery like converting symbols to ints to serve as bounds. I previously had the idea of specifying the size using a prototype function, but something like prototype size a : i32 is not allowed in Spiral because a is an unused forall variable.
In the old version of Spiral, I did not use pickler combinators, but I still had to specify a schema even there, so the advantages of the introspective approach is minimal over the combinator one.
///
Let me back this up here. I'll redo this from the start.
11:40am. I see that I got a reply from somebody trying out Spiral on Linux. Forget the docs for the time being.
///
However, when I try to use it, I see a notification: "Spiral: The server has aborted with an error."
This happens when the VS Code plugin runs the server process, but the process aborts for some reason.
///
12:35pm. Let me have breakfast here. I opened an issue on the Spiral repo and put down my thoughs. For the rest of the day, I'll focus on dealing with the last segment. After that I'll clear up some space on my hard drive and get Linux to install."
DROP ME adjust toml s
playing around: make red output
wip: start DynamicDirectionRed
move to my lpc8xx-hal clone
start using Dynamic pin
impl toggle_direction_should_turn_off_red_led, adjust code to demonstrate https://github.com/Lotterleben/lpc8xx-hal/commit/d2c88e1f233a494a45c63c5d12a59419919e76bc works
add and use set_pin_direction_input msg o/
hacky: make set_pin_direction_output() work. blinkenlights!
add incomplete red_led_should_be_toggleable_by_level() (toggling works but level reading does not)
weip: refactor towards DynamicPin
more moves towards DynamicPin: red_led_should_be_toggleable_by_level() works again
wip: added set_output_pin_high/low, either broke Dynamic.set_high or demonstrated that it is broken
guck an, wenn man's richtig macht funktioniert's auch
fix copypasta err
make dyn pin change functions more generic -> allow user to spec which pin to use
whoops. rm OutputPin::Dynamic
add Green placeholders, rm unnecessary assistant::dynamic_pin (-> all tests green)
ReadDynamicPin command arrives at t-a
🎉 config green as input on t-a, adjust it_should_set_pin_level() (green), add some docs and more debug output
add generic-ish functions for input pin reading
use assistants pin-genmeric-ish set_output_pin*() in other tests too
first steps away from red/green pin names
refactor: split SetDirection handling into 2 match arms
first step toiwards less led-dependent pinint names
talk to myself in the comments about where I'm blocked
polishing: resolve some todos
polishing: add more (failing) tests
forgot one in 67d5ef4
convert DynamicPin::GPIO to ardunio-style pin numbers (no generic handling yet)
make t-a pin numbers generic, arduino-style o/
assistant: resolve a bunch of docs todos
t-a: minor cleanup
cargo fmt
fix dynamic_interrupt_handlers_should_be_ignored_after_direction_switch
cleanup + n more mentions of green
give blue a less helpful name too :P
ta-a: cleanup, impl SetDynamicPin() for all current pins
Revert "give blue a less helpful name too :P"
This reverts commit 246f8264da646d5a3a1ea016b0c1bbdd1363d0e3.
give blue a more useful name: it's the target timer interrupt signal!
rename red to pinint3_pin, make it trigger interupts
api smell: ensure that pin is output before reading
Revert "rename red to pinint3_pin, make it trigger interupts"
This reverts commit fd4dbd6c768d9ecf1e36c3d779ba16c2167e9e6f.
baby steps: rename red
NOW make red be interruptable
UX rtefactoring: impl in_out_changes_should_be_consuming() and pin_should_not_be_creatable_twice()
wip: save my changes before I make one last attempt at my play doh interface
ux refactor #3: start play doh api, in_pin_should_not_be_creatable_twice() green
ux refactor #3: got until lifetime snafu on in/out conversion
ux refactor #3: gdefeat lifetime elision (compiles)
ux refactor #3: impl out_pin_should_not_be_creatable_twice()
ux refactor #3: houston we have a 🚨 🎉
ux refactor #3: convert assistant_red_led_should_be_toggleable_by_pin_direction (a little bit hacky)
ux refactor #3: convert assistant_red_led_should_be_toggleable_by_level, rm unnecessary test
ux refactor #3: cleanup o/
ux refactor #3: fix one small cleanup todo
cleanup: In/OutputPin2 -> In/OutputPin, simplify tests
tip: default output pink level works, but buggy
clean up wonky_in_out_conversion_should_work(), now green (bug was in hal, see #fb749a5 there)
adjust assistant_red_led_should_be_toggleable_by_pin_direction() to new default pin level setting
aaand rm SetDirectionOutput again, we don't want the extra deserialization overhead I think
we have option types and cargo fmt. use them.
assistant.rs: rm done TODOs, add doc TODOs
rename: to_...pin to into..._pin
bugfix for https://app.asana.com/0/1198886832406477/1199154134266615/f: shrink the right queue! -.-
resolve TODOs, remove dead code
assistant: use systick
fix move whoops in loop in test
wip: systick loops over input pins
merge dynamic_input_pin_levels and dynamic_pins, modify level info (untested)
DELETEME a bunchz of debugging changes
add blinky simple-unit-under-test
finish simple-unit-under-test firmware
make inverse dut test go green
DELETEME undo debug changes for extra dyn pins
add rudmentary dut_pin_1_should_toggle_periodically(), last mile missing (can'+t read pin bc of resource constraints
dut test finished: blue as out
add wiring instructions
cleanup: slience warnings
make all tests compile by exposing all Assistant fns again(running untested bc wiring)
tests/(assistant.rs: silence warning
wip: dyn_noint_pins_producer
wip: init_queue
rm xoxo debug test
add flip-link?
some renaming; add CONFLICT notes
sketch: use dyn_noint_measurements_in
whoops. also add timer_interrupt.rs
rm outdated RTODO
wip: make use of rtic resources (unfortunaetly + lots of reformating)
durchstich: communication between noint producer and consumer
whoop whoop! dyn pin reading finally works! next up: clean up copypasta
read multiple noint dyn pin levels
impl setDirection for dyn noint pins
fmt and update deps
cleanup: we only need one timerinterrupt queue
Add files via upload
Here we go again. More James. Look if you read through this, James's words are in here. He doesn't bring her up unless she out right attacks his home and life. Most cases, we do not hear from him unless she sends the cops at him, or other people. Which she has done, she screams she doesn't but, she has. And no one in the Dibney Cru believes her lies. Because again, it has changed. Her story has changed again. It always does. She is back to screaming James knew her at 9. Lisa nixed that quickly and said no James didn't come into their lives till she was into her later years like 19teen 20 years old. So no one is believing her BS.
Hacked. Lord help us, we know she was not hacked. We have a lot of the proof that WillowtheWay or whatever the Willow name is, was not hacked. Because we found all of it. So again, its a load of BS. She does this, as one of the girls said in the discord, that she screams hacked when she is caught being abusive. Which is every day.
We all know she is crazy but I want to bring up something I find hysterical. So she keeps bringing up her IQ. She has admitted that she had it done in her late teens and it was a Mensa score of 77... Yeah. At the height of when those tests are often taken, she scored a 77. Which makes her a moron. An idiot. Average is 85 to 95-120 depending on who you take the test through. So again she is a moron. We are not calling her an Idiot because its an opinion, we are calling her an idiot because it is fact. Comparatively against many of us in the discord we run IQ scores from 95 to 162. Mine is 132 which to give you an idea this is what that means
"A score of 116 or more is considered above average. A score of 130 or higher signals a high IQ. Membership in Mensa, the High IQ society, includes people who score in the top 2 percent, which is usually 132 or higher." Jan 28, 2020
Her score of 77 puts her here "70 to 84: Borderline mental disability." which we know. Also "Borderline intellectual functioning, also called borderline mental retardation (in the ICD-8), is a categorization of intelligence wherein a person has below average cognitive ability (generally an IQ of 70–85), but the deficit is not as severe as intellectual disability (below 70)." So not retarded, but not smart either.
We know for a fact, she googles everything, and often does not comprehend all she reads, twisting it to fit her narrative. We have seen it time and time again. I have seen it when she attacked me before the Dibney Cru was formed. It is like a synapse is not firing right to allow her to comprehend what she is reading does not always apply to her or can be used by her. Take law for instance.
But I am rattling. Anyways. That is the past 24 hours.
Updating: 1/13/2021 3:00:00 PM
- Added: Abusing C# For Loops For Job Security (https://eddieabbondanz.io/post/c-sharp/abusing-for-loops-for-job-security/)
- Added: What is Social Cooling? (https://reasonandmeaning.com/2017/10/31/what-is-social-cooling/)
- Added: The process, thought and technology behind building a friendly .NET SDK for JetBrains Space (https://blog.maartenballiauw.be/post/2021/01/13/the-process-thought-and-technology-behind-building-a-friendly-net-sdk-for-jetbrains-space.html)
- Added: How do you know when you’re an EXPERT at a #programming language?!? (https://www.tiktok.com/@shanselman/video/6917114209398426886?_d=secCgYIASAHKAESMgowhr43G7CpaKhKOpxsNdpWyGhTPi1WrVjm%2BgFEdqieXUihOmFHguXIkXJr95wItlw8GgA%3D&language=en&preview_pb=0&sec_user_id=MS4wLjABAAAAFt5MIdypn_f0WZh40awWRF89Zw9Amdawzs3Uv8kCYseoyWirUnzj1bZawGbeNpw4&share_item_id=6917114209398426886&share_link_id=C7AB8CCD-301E-442E-8687-95FD2181EADA×tamp=1610516229&u_code=de1hm7ac6mg7id&user_id=6860974717076014086)
Generation took: 00:07:35.2669416 Maintenance update - cleaning up homepage and feed
Merge #602
602: +Debug for CoordinateType r=frewsxcv a=michaelkirk
- I agree to follow the project's code of conduct.
- [TODO] I added an entry to
CHANGES.mdif knowledge of this change could be valuable to users.
This is intended to address georust/geo#597
I took a broader approach, and wonder if people are interested in it. The tldr is:
- deprecate
CoordinateType; (now includesstd::fmt::Debug) - Add
trait CoordNum: CoordinateType; - Add
trait CoordFloat: CoordNum + num_traits::Float
Add trait GeoNum: CoordNum + HasKernel
Add trait GeoFloat: CoordFloat + HasKernel
downstream adoption
If your crate interops with geo-types, you may need to make changes like this:
pub fn foo<T>(line_string: &geo_types::LineString<T>)
where
- T: num_traits::Float,
+ T: geo_types::CoordFloat,
{
or this (this one is actually only a deprecation, so you could leave it as is for now, but eventually you'll need to make the change):
pub fn foo<T>(line_string: &geo_types::LineString<T>)
where
- T: geo_types::CoordinateType
+ T: geo_types::CoordNum
{
alternative considered
If I went with the minimal approach to adding Debug trait, changes would instead need to look like this:
This one, for non-floats, could remain untouched:
pub fn foo<T>(line_string: &geo_types::LineString<T>)
where
T: geo_types::CoordinateType
{
But anything restricted to floats would need to explicitly include Debug
pub fn foo<T>(line_string: &geo_types::LineString<T>)
where
- T: num_traits::Float,
+ T: num_traits::Float + std::fmt::Debug,
{
motivation:
I initially completed #597 with the most conservative approach, achieved in the first two commits. The first simply adds Debug to CoordinateType and the second fixes the resulting compiler errors.
This is a breaking change for anyone constraining generic implementations to just num_traits::Float, e.g. like geojson crate does (fix here: https://github.com/georust/geojson/compare/mkirk/geo-types-0.7?expand=1), and polylabel (fix here: https://github.com/urschrei/polylabel-rs/compare/master...michaelkirk:mkirk/geo-types-0.7?expand=1)
Compare this to a crate like geo-booleanop, for which things "just work" because they targeted CoordinateType.
This got me thinking that, similar to #577 (yet unreleased), if we want people to write code targeting geo-types in a generic way, it might be helpful to make it clearer and easier how to do so.
So, I've added a CoordFloat and a CoordNum which is basically just a rename of CoordinateType, and applied them liberally within our own code base. I'm hoping this would drive others to reach for these traits rather than specific num_traits when implementing code intended for generic geo-types interop.
For crates like geo-booleanop, which targeted CoordinateType, things "just work" after the update, but they'll see a deprecation notice like:
$ cargo build
warning: use of deprecated trait `geo_types::CoordinateType`: use `CoordFloat` or `CoordNum` instead
--> lib/src/boolean/helper.rs:2:29
|
2 | use geo_types::{Coordinate, CoordinateType};
| ^^^^^^^^^^^^^^
|
= note: `#[warn(deprecated)]` on by default
Which I think is acceptably clear.
It's a large number of lines changed change overall, I know! But it's mostly mechanical, and I thought, since we're breaking geo-types, maybe this is a good time to bite the bullet and avoid some future pain.
If it's too controversial, as I said, the minimal amount of change we need to enable Debug for CoordinateType is the first three commits (through and including "address fallout of "Add Debug to CoordinateType"). It's still a pretty big change with just that, and note that this will still break the crates I mentioned. I intend to fix the ones I know about, but there's a long tail of crates, which is why I hate breaking geo-types.
In the few that I've checked it's been quick to adapt to the change, but it might be worth announcing and letting sit open for a while in case downstream geo-types users want to weigh in.
Co-authored-by: Michael Kirk [email protected]
Wrote basic test cases for year map; this map is the root of all evil in the world of software design but it works. Shit, I want to change it but it works... and never change a running system if you don't have time to spare...
Initial Overclock GPU Andreno-308 650MhZ for Xiaomi Redmi 4a.
Credits and Thanks to XolosKernel / @Genom48
Cherry-pick always keep Authorship, Fuck you Kangers.
Signed-off-by: Ahmad Thoriq Najahi [email protected] Signed-off-by: Thagoo [email protected]
Update chat/matrix-synapse to 1.25
With this release, the Synapse team is announcing a formal deprecation policy for our platform dependencies, like Python and PostgreSQL:
All future releases of Synapse will follow the upstream end-of-life schedules.
Which means:
- This is the last release which guarantees support for Python 3.5.
- We will end support for PostgreSQL 9.5 early next month.
- We will end support for Python 3.6 and PostgreSQL 9.6 near the end of the year.
Crucially, this means we will not produce .deb packages for Debian 9 (Stretch) or Ubuntu 16.04 (Xenial) beyond the transition period described below.
The website https://endoflife.date/ has convenient summaries of the support schedules for projects like Python and PostgreSQL.
If you are unable to upgrade your environment to a supported version of Python or Postgres, we encourage you to consider using the Synapse Docker images instead.
We will make a good faith attempt to avoid breaking compatibility in all releases through the end of March 2021. However, critical security vulnerabilities in dependencies or other unanticipated circumstances may arise which necessitate breaking compatibility earlier.
We intend to continue producing .deb packages for Debian 9 (Stretch) and Ubuntu 16.04 (Xenial) through the transition period.
The old Purge Room API and Shutdown Room API are deprecated and will be removed in a future release. They will be replaced by the Delete Room API.
POST /_synapse/admin/v1/rooms/<room_id>/delete replaces POST /_synapse/admin/v1/purge_room and
POST /_synapse/admin/v1/shutdown_room/<room_id>.
- Fix HTTP proxy support when using a proxy that is on a blacklisted IP. Introduced in v1.25.0rc1. Contributed by @Bubu. (#9084)
- Add an admin API that lets server admins get power in rooms in which local users have power. (#8756)
- Add optional HTTP authentication to replication endpoints. (#8853)
- Improve the error messages printed as a result of configuration problems for extension modules. (#8874)
- Add the number of local devices to Room Details Admin API. Contributed by @dklimpel. (#8886)
- Add
X-Robots-Tagheader to stop web crawlers from indexing media. Contributed by Aaron Raimist. (#8887) - Spam-checkers may now define their methods as
async. (#8890) - Add support for allowing users to pick their own user ID during a single-sign-on login. (#8897, #8900, #8911, #8938, #8941, #8942, #8951)
- Add an
email.invite_client_locationconfiguration option to send a web client location to the invite endpoint on the identity server which allows customisation of the email template. (#8930) - The search term in the list room and list user Admin APIs is now treated as case-insensitive. (#8931)
- Apply an IP range blacklist to push and key revocation requests. (#8821, #8870, #8954)
- Add an option to allow re-use of user-interactive authentication sessions for a period of time. (#8970)
- Allow running the redact endpoint on workers. (#8994)
- Fix bug where we might not correctly calculate the current state for rooms with multiple extremities. (#8827)
- Fix a long-standing bug in the register admin endpoint (
/_synapse/admin/v1/register) when themacfield was not provided. The endpoint now properly returns a 400 error. Contributed by @edwargix. (#8837) - Fix a long-standing bug on Synapse instances supporting Single-Sign-On, where users would be prompted to enter their password to confirm certain actions, even though they have not set a password. (#8858)
- Fix a longstanding bug where a 500 error would be returned if the
Content-Lengthheader was not provided to the upload media resource. (#8862) - Add additional validation to pusher URLs to be compliant with the specification. (#8865)
- Fix the error code that is returned when a user tries to register on a homeserver on which new-user registration has been disabled. (#8867)
- Fix a bug where
PUT /_synapse/admin/v2/users/<user_id>failed to create a new user whenavatar_urlis specified. Bug introduced in Synapse v1.9.0. (#8872) - Fix a 500 error when attempting to preview an empty HTML file. (#8883)
- Fix occasional deadlock when handling SIGHUP. (#8918)
- Fix login API to not ratelimit application services that have ratelimiting disabled. (#8920)
- Fix bug where we ratelimited auto joining of rooms on registration (using
auto_join_roomsconfig). (#8921) - Fix a bug where deactivated users appeared in the user directory when their profile information was updated. (#8933, #8964)
- Fix bug introduced in Synapse v1.24.0 which would cause an exception on startup if both
enabledandlocaldb_enabledwere set toFalsein thepassword_configsetting of the configuration file. (#8937) - Fix a bug where 500 errors would be returned if the
m.room_history_visibilityevent had invalid content. (#8945) - Fix a bug causing common English words to not be considered for a user directory search. (#8959)
- Fix bug where application services couldn't register new ghost users if the server had reached its MAU limit. (#8962)
- Fix a long-standing bug where a
m.imageevent without aurlwould cause errors on push. (#8965) - Fix a small bug in v2 state resolution algorithm, which could also cause performance issues for rooms with large numbers of power levels. (#8971)
- Add validation to the
sendToDeviceAPI to raise a missing parameters error instead of a 500 error. (#8975) - Add validation of group IDs to raise a 400 error instead of a 500 eror. (#8977)
- Fix the "Event persist rate" section of the included grafana dashboard by adding missing prometheus rules. (#8802)
- Combine related media admin API docs. (#8839)
- Fix an error in the documentation for the SAML username mapping provider. (#8873)
- Clarify comments around template directories in
sample_config.yaml. (#8891) - Move instructions for database setup, adjusted heading levels and improved syntax highlighting in INSTALL.md. Contributed by @fossterer. (#8987)
- Update the example value of
group_creation_prefixin the sample configuration. (#8992) - Link the Synapse developer room to the development section in the docs. (#9002)
- Deprecate Shutdown Room and Purge Room Admin APIs. (#8829)
- Properly store the mapping of external ID to Matrix ID for CAS users. (#8856, #8958)
- Remove some unnecessary stubbing from unit tests. (#8861)
- Remove unused
FakeResponseclass from unit tests. (#8864) - Pass
room_idtoget_auth_chain_difference. (#8879) - Add type hints to push module. (#8880, #8882, #8901, #8940, #8943, #9020)
- Simplify logic for handling user-interactive-auth via single-sign-on servers. (#8881)
- Skip the SAML tests if the requirements (
pysaml2andxmlsec1) aren't available. (#8905) - Fix multiarch docker image builds. (#8906)
- Don't publish
latestdocker image until all archs are built. (#8909) - Various clean-ups to the structured logging and logging context code. (#8916, #8935)
- Automatically drop stale forward-extremities under some specific conditions. (#8929)
- Refactor test utilities for injecting HTTP requests. (#8946)
- Add a maximum size of 50 kilobytes to .well-known lookups. (#8950)
- Fix bug in
generate_log_configscript which made it write empty files. (#8952) - Clean up tox.ini file; disable coverage checking for non-test runs. (#8963)
- Add type hints to the admin and room list handlers. (#8973)
- Add type hints to the receipts and user directory handlers. (#8976)
- Drop the unused
local_invitestable. (#8979) - Add type hints to the base storage code. (#8980)
- Support using PyJWT v2.0.0 in the test suite. (#8986)
- Fix
tests.federation.transport.RoomDirectoryFederationTestsand ensure it runs in CI. (#8998) - Add type hints to the crypto module. (#8999)
Jingle all the way with opera tab completion
It's time to fulfil our quest that was desired to be done from times of yore (#56). And since Christmas is about giving back and caring about others, we decided to bring merry to all our users and enable tab completion for opera CLI arguments.
One can almost get enchanted when looking at a CLI that has a nice-working tab completion. Shell completion can be hard to comprehend sometimes because there's many ways to support it. Since opera uses argparse we had to find a tab completion package that's compatible with it. The love on first sight would be argcomplete Python package which was designed for completing argparse commands and their arguments. However, when we tried it, it didn't turn out so well. Most of the time we were unable to get it working with our subparsers and on the other hand we didn't want to activate completion globally. So we almost gave up with that. But then we remembered that failure only happens when you give up. Hoper and determination fuel the true champions. So we found shtab as a possible solution. The package is still very young and some features will probably be worked on in the future.
We were able to use shtab in our code to generate a shell completion
script. And we don't even need a separate command to do that since
shtab supports defining a global optional argument that will print
out the completion script for the main parser. We used that and
defined --shell-completion/-s flag which receives a shell type to
generate completion for. Shtab currently supports bash and zsh so those
are the options. So, after running opera -s bash|zsh the generated
tab completion script will be printed out. To activate it you must
source the contents which can be done with eval "$(opera -s bash)"
or you can save it to a file and then source it. The procedure will
be fully explained in the opera documentation.
First thoughts about tab completion also included a possibility to pre-install it for the user. For that we would need to do the sourcing within the installation. There was also a suggestion to have a separate opera shell-completion command that would have a --install switch to install tab completion on user's system. We didn't want to upset the users by installing something into their environment that they might not want. We also didn't want to modify their ~/.bashrc file and add our completion as that could bring a lot of problems. At the end, we decided to just print out the generated completion script and then the user can decide how to continue for himself.
The new completion feature will give aid to those opera users who seek it. Since opera CLI is evolving and growing, new and new commands and CLI options are being introduced. So it's easy to make a mistake while you're using the CLI. And that's when tab completion comes in handy.
Jingle all the way with opera tab completion
It's time to fulfil our quest that was desired to be done from times of yore (#56). And since Christmas is about giving back and caring about others, we decided to bring merry to all our users and enable tab completion for opera CLI arguments.
One can almost get enchanted when looking at a CLI that has a nice-working tab completion. Shell completion can be hard to comprehend sometimes because there's many ways to support it. Since opera uses argparse we had to find a tab completion package that's compatible with it. The love on first sight would be argcomplete Python package which was designed for completing argparse commands and their arguments. However, when we tried it, it didn't turn out so well. Most of the time we were unable to get it working with our subparsers and on the other hand we didn't want to activate completion globally. So we almost gave up with that. But then we remembered that failure only happens when you give up. Hope and determination fuel the true champions. So we found shtab as a possible solution. The package is still very young and some features will probably be worked on in the future.
We were able to use shtab in our code to generate a shell completion
script. And we don't even need a separate command to do that since
shtab supports defining a global optional argument that will print
out the completion script for the main parser. We used that and
defined --shell-completion/-s flag which receives a shell type to
generate completion for. Shtab currently supports bash and zsh so those
are the options. So, after running opera -s bash|zsh the generated
tab completion script will be printed out. To activate it you must
source the contents which can be done with eval "$(opera -s bash)"
or you can save it to a file and then source it. The procedure will
be fully explained in the opera documentation.
First thoughts about tab completion also included a possibility to pre-install it for the user. For that we would need to do the sourcing within the installation. There was also a suggestion to have a separate opera shell-completion command that would have a --install switch to install tab completion on user's system. We didn't want to upset the users by installing something into their environment that they might not want. We also didn't want to modify their ~/.bashrc file and add our completion as that could bring a lot of problems. At the end, we decided to just print out the generated completion script and then the user can decide how to continue for himself.
The new completion feature will give aid to those opera users who seek it. Since opera CLI is evolving and growing, new and new commands and CLI options are being introduced. So it's easy to make a mistake while you're using the CLI. And that's when tab completion comes in handy.
Does't work at all. Still trying to figure out why the requests are not working. I hate my life. Without the champId == 0 seemed to work (at least the ban pick selection).
modpost: file2alias: go back to simple devtable lookup
[ Upstream commit ec91e78d378cc5d4b43805a1227d8e04e5dfa17d ]
Commit e49ce14150c6 ("modpost: use linker section to generate table.") was not so cool as we had expected first; it ended up with ugly section hacks when commit dd2a3acaecd7 ("mod/file2alias: make modpost compile on darwin again") came in.
Given a certain degree of unknowledge about the link stage of host programs, I really want to see simple, stupid table lookup so that this works in the same way regardless of the underlying executable format.
Signed-off-by: Masahiro Yamada [email protected] Acked-by: Mathieu Malaterre [email protected] Signed-off-by: Sasha Levin [email protected] Change-Id: If4290e58a2c34a7f69e2aa8e9ec0b07f15792d21
Fix mounts being usable after a disk is ejected
This probably fails "responsible disclosure", but it's not an RCE and frankly the whole bug is utterly hilarious so here we are...
It's possible to open a file on a disk drive and continue to read/write to them after the disk has been removed:
local disk = peripheral.find("drive")
local input = fs.open(fs.combine(disk.getMountPath(), "stream"), "rb")
local output = fs.open(fs.combine(disk.getMountPath(), "stream"), "wb")
disk.ejectDisk()
-- input/output can still be interacted with.
This is pretty amusing, as now it allows us to move the disk somewhere else and repeat - we've now got a private tunnel which two computers can use to communicate.
Fixing this is intuitively quite simple - just close any open files belonging to this mount. However, this is where things get messy thanks to the wonderful joy of how CC's streams are handled.
As things stand, the filesystem effectively does the following flow::
-
There is a function `open : String -> Channel' (file modes are irrelevant here).
-
Once a file is opened, we transform it into some . This is, for instance, a BufferedReader.
-
We generate a "token" (i.e. FileSystemWrapper), which we generate a week reference to and map it to a tuple of our Channel and T. If this token is ever garbage collected (someone forgot to call close() on a file), then we close our T and Channel.
-
This token and T are returned to the calling function, which then constructs a Lua object.
The problem here is that if we close the underlying Channel+T before the Lua object calls .close(), then it won't know the underlying channel is closed, and you get some pretty ugly errors (e.g. "Stream Closed"). So we've moved the "is open" state into the FileSystemWrapper.
The whole system is incredibly complex at this point, and I'd really like to clean it up. Ideally we could treat the HandleGeneric as the token instead - this way we could potentially also clean up FileSystemWrapperMount.
BBut something to play with in the future, and not when it's 10:30pm.
All this wall of text, and this isn't the only bug I've found with disks today :/.