text:
[sw] Build software with different compiler flag combinations (e.g. inlining disabled) in CI

It would be useful to have the software build be more resilient to compiler flag changes. To acheive this we could pick some combinations to test in CI.
#9216 would not have been needed if there was a build done in CI with -O0 or -fno-inline enabled. At a minimum it may make sense to have a 'no optimizations' build. We could also consider doing builds with sanitizers enabled and/or different optimization levels (e.g. -O3,-Os and -Oz).

#9216 would not have been needed if there was a build done in CI with -O0 or -fno-inline enabled. At a minimum it may make sense to have a 'no optimizations' build. We could also consider doing builds with sanitizers enabled and/or different optimization levels (e.g. -O3,-Os and -Oz).

One problem with -O0 is that you need to change the mask ROM size to ensure the unoptimized code still fits. In my testing for PR #9216 I doubled the size and that worked. Unfortunately there currently isn't a single place (DRY) to make that change, nor a configuration switch to make the change without patching the source.
In case it's useful, this was my hacky patch:
diff --git a/hw/ip/rom_ctrl/util/scramble_image.py b/hw/ip/rom_ctrl/util/scramble_image.py
index 22b433c88..e6b5135e7 100755
--- a/hw/ip/rom_ctrl/util/scramble_image.py
+++ b/hw/ip/rom_ctrl/util/scramble_image.py
@@ -15,7 +15,7 @@ from Crypto.Hash import cSHAKE256
 from mem import MemChunk, MemFile

 ROM_BASE_WORD = 0x8000 // 4
-ROM_SIZE_WORDS = 8192
+ROM_SIZE_WORDS = 8192*2

 PRINCE_SBOX4 = [
     0xb, 0xf, 0x3, 0x2,
diff --git a/hw/top_earlgrey/sw/autogen/top_earlgrey_memory.ld b/hw/top_earlgrey/sw/autogen/top_earlgrey_memory.ld
index 9c67b6a0c..b93024ce3 100644
--- a/hw/top_earlgrey/sw/autogen/top_earlgrey_memory.ld
+++ b/hw/top_earlgrey/sw/autogen/top_earlgrey_memory.ld
@@ -11,6 +11,6 @@ MEMORY {
   ram_ret_aon(rwx) : ORIGIN = 0x40600000, LENGTH = 0x1000
   eflash(rx) : ORIGIN = 0x20000000, LENGTH = 0x100000
   ram_main(rwx) : ORIGIN = 0x10000000, LENGTH = 0x20000
-  rom(rx) : ORIGIN = 0x00008000, LENGTH = 0x8000
+  rom(rx) : ORIGIN = 0x00008000, LENGTH = 0x8000*2
   eflash_virtual(rx) : ORIGIN = 0x80000000, LENGTH = 0x100000
 }

I was already planning on adding the -fno-inline variant to the CI builds, as a follow-up to PR #9216.

I just remembered another scenario that ideally we would add: build OT with a version of LLVM built with debug assertions. This would be even more important if we ever use any downstream feature patches, as those features don't get exercised by the wider community and thus it's easier for any bugs not to be exposed.

Moving to backlog as this is a nice-to-have feature.

authors: luismarques mundaym


text:
[flash_ctrl] address the d2s documentation items

see https://github.com/lowRISC/opentitan/issues/11675

@alphan @cdgori could you guys have a look?

source: gharchive/pull-request

repo: lowRISC/opentitan

license_type: permissive

license_source: github-api


text:
[ci] Cut down apt-requirements

These system dependencies don't seem to be required any more.

I see that we have a cmake rule here.
I am not sure if this uses the system's cmake or not.
Our documentation recommends autoconf to build verilator here.
We also seem to depend on ninja in airgapped builds and in tool requirement checks and in some weird files.
I would first double-check if those files are outdated or not. If we remove the tools for apt, then we should update the doc/files.

Hmm, you're right. I was hoping CI would catch any problems but there are two reasons why it might not:

GitHub / Azure hosted runners come with some tools pre-installed (like cmake and autoconf)
Our self-hosted runners come with packages pre-installed in the container, but that container isn't updated automatically for this PR

I'm going to drop this, don't think it's worth the work.

authors: jwnrt pamaury


text:
[lc_ctrl/otp_ctrl] Precompute hashed versions of global tokens

This precomputes hashed versions of the all-zero and RAW unlock token using the PRINCE primitive.
This solution relies on constant propagation to fold the logic into constants at elab time.

this LGTM. Hopefully this simplifies out to just constants like we hope.. hehe

Yeah... But I think it should. After all, the module just has outputs, so by construction it should be able to resolve these values using constant prop (unless there is a synthesis tool bug ;)).

authors: msfschaffner tjaychen


text:
WIP: [sram_ctrl] Transition into D2

Draft PR to prepare moving the SRAM controller into D2.
Signed-off-by: Michael Schaffner msf@opentitan.org

let's discuss this one with Don / Faisal a bit.
Because D2 implies feature freeze and only bug fixes from here on.
I feel like we would need some software feedback to ensure this is okay.

let's discuss this one with Don / Faisal a bit.
Because D2 implies feature freeze and only bug fixes from here on.
I feel like we would need some software feedback to ensure this is okay.

Yeah we can hold off on this one until at least the DIF header has been written (implying that the regfile and functionality has been reviewed by SW).
@mateenfaisal, @gkelly, @lenary: who owns the SRAM controller DIF?

Yeah we can hold off on this one until at least the DIF header has been written (implying that the regfile and functionality has been reviewed by SW).
@mateenfaisal, @gkelly, @lenary: who owns the SRAM controller DIF?

Yeah we can hold off on this one until at least the DIF header has been written (implying that the regfile and functionality has been reviewed by SW).
@mateenfaisal, @gkelly, @lenary: who owns the SRAM controller DIF?

yes, but i was actually hoping @mateenfaisal and Don can come up with a process they think works best for the project.

Yeah we can hold off on this one until at least the DIF header has been written (implying that the regfile and functionality has been reviewed by SW).
@mateenfaisal, @gkelly, @lenary: who owns the SRAM controller DIF?

yes, but i was actually hoping @mateenfaisal and Don can come up with a process they think works best for the project.

@dsandrs

@dsandrs

Ack on Sram DIF, process request for new features. Will read this thread.

Ack on Sram DIF, process request for new features. Will read this thread.

The SRAM DIF is owned by @gkelly - there's no header/implementation for it yet.

The SRAM DIF is owned by @gkelly - there's no header/implementation for it yet.

Will talk to @gkelly, on when he can get started on SRAM header. For now, I have entered SRAM header as predecessor for SRAM D2 in the plan.

Will talk to @gkelly, on when he can get started on SRAM header. For now, I have entered SRAM header as predecessor for SRAM D2 in the plan.

I've taken a look at the docs for this. There are really only two things we really care about from the SW side: calling for a new key and checking the status. We're even going to end up doing those in assembly pre-CRT. This interface looks good to me, I'm comfortable with this going to D2 before we've written the DIF header proper.

I've taken a look at the docs for this. There are really only two things we really care about from the SW side: calling for a new key and checking the status. We're even going to end up doing those in assembly pre-CRT. This interface looks good to me, I'm comfortable with this going to D2 before we've written the DIF header proper.

Thanks for giving this a look @gkelly.
I have waived the CDC lint setup and am putting this up for review.

Thanks for giving this a look @gkelly.
I have waived the CDC lint setup and am putting this up for review.

Moving this back to draft due to the missing execute from SRAM scheme.

Moving this back to draft due to the missing execute from SRAM scheme.

@tjaychen do you think we can move this into D2 now that the execute from SRAM scheme is in place?

authors: gkelly lenary mateenfaisal msfschaffner tjaychen


text:
[util] clocking enhancements

This commit is necessary to address #8405 and #8037

Modules are now allowed to delcare a different clock group per clock.
This allows for some flexibility in how things are hooked-up.
Further the idea of "internal" clocks are introduced for clocks that
are generated entirely inside a module but still used with the regfile.
This is especially useful for creating CDC structures for blocks like
clkmgr that has locally generated clocks.

sounds good, i can come back and remove it.
Because to be honest... i've never looked at that field for debug...
On Fri, Oct 1, 2021 at 2:46 AM Rupert Swarbrick @.***>
wrote:

@.**** commented on this pull request.
In util/topgen/clocks.py
https://github.com/lowRISC/opentitan/pull/8410#discussion_r720105885:

   for clk_name, src_name in raw_clocks.items():

       src = sources.get(src_name)

       if src is None:

           raise ValueError(f'The {clk_name} entry of clocks for {what} '

                            f'has source {src_name}, which is not a '

                            f'known clock source.')

       self.add_clock(clk_name, src)

Eh, I tend to think that debugging is best done by adding random print
statements when we come to investigate something :-) But I don't feel very
strongly: happy either way.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/8410#discussion_r720105885,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSV3QWWMDFXPXOGGALTUEV7QRANCNFSM5E6JQTFA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


text:
keygen (!!!不要修改这里!!!)

机器码

用户名

激活码

免责声明

[X] 我已阅读并同意遵守免责声明

eyJ2Ijoid2lufDEuNC43IiwiaSI6IlE0R3A3ZHFzaTMiLCJsIjoiTEFQVE9QLUpBVlJHUU00IHwgYWRtaW4gfCBXaW5kb3dzIn0=

source: gharchive/issue

authors: Moon-Sun-S axinke

repo: lqinyli/typroaction

license: MIT


text:
migrate SonarCloud to JDK11 (+)

See https://sonarcloud.io/documentation/upcoming/

Should we install oraclejdk8 + (?) jdk11, and force Travis CI run the sonar analyzing itself under jdk11?
See a long discussion
https://community.sonarsource.com/t/re-move-to-java-11-java-8-deprecated/25275/18

repo: lrozenblyum/chess


text:
[Feature] Grading System Server Side

Checklist

[x] Server: I followed the coding and design guidelines.
[x] Server: I added multiple integration tests (Spring) related to the features (with a high test coverage)
[x] Server: I added @PreAuthorize and check the course groups for all new REST Calls (security)
[x] Server: I implemented the changes with a good performance and prevented too many database calls
[x] Server: I documented the Java code using JavaDoc style.

Motivation and Context

Artemis is currently lacking a more generic grading system. This PR contains the initial database implementation for it, which would allow for separate grading scales on different courses and/or exams.
Description

The grading system consists of a new GradingScale class which contains a set of GradeSteps - each having its own lower and upper bound for the point percentages to which it applies and a string to represent the name of the grade. Each course would contain an instance of GradingScale which would also be the default for that course. The exams of that course could choose to use the same grading system as the course or have a separate one.
Steps for Testing

Review code

Test Coverage

GradeStepResource.java: 100%
GradingScaleService.java: 96%
GradingScaleResource: 100%
Screenshots

There still seem to be 4 tests that fail for some reason in Bamboo but run perfectly fine locally, after I've rerun them multiple times. I'm open to suggestions @ls1intum/artemis

There still seem to be 4 tests that fail for some reason in Bamboo but run perfectly fine locally, after I've rerun them multiple times. I'm open to suggestions @ls1intum/artemis

@stefanwaldhauser you know something about adding new entities to the database. Maybe this is related and the liquibase-master is wrong?

Here's the bamboo test report page with the 4 failing test cases in the GradingScaleIntegrationTest class. 3 of them return 400 (Bad Request) when they shouldn't and the last one is related to a deserialization loop. All of them run without a problem locally

authors: derLalla ivohashamov


text:
Quiz exercises: Fix reset question button of dnd question in reevaluation page

Checklist
General

[ ] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[ ] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[ ] I chose a title conforming to the naming conventions for pull requests.

Client

[x] I documented the TypeScript code using JSDoc style.
[ ] I added multiple screenshots/screencasts of my UI changes.

Motivation and Context

The question reset button of the DnD question on the quiz reevaluation page does not work. This caused the instructor not to be able to revert the changes made during quiz reevaluation.
Description

The questionEditorText attribute of DragAndDropQuestionEditComponent needs to be updated with the new value of the markdown editor, otherwise, questionEditorText will always contain the same value (the first value when the component is loaded) which causes the reset functionality to be not working.
Steps for Testing

Prerequisites:

1 Instructor
1 Quiz Exercise that is ended

Log in to Artemis
Navigate to Course Administration
Select the Course
Navigate to Exercises
Click Reevaluation of the quiz exercise
Update the question of DnD question
Click the undo button
Verify that the undo button works

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

Class/File
Branch
Line

drag-and-drop-question-edit.component.ts
77.27%
88.85%

Screenshots

Codecov Report

Merging #6080 (3270315) into develop (2cd54c2) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files
@@            Coverage Diff             @@
##             develop    #6080   +/-   ##
==========================================
  Coverage      80.07%   80.08%
- Complexity     12693    12694    +1
==========================================
  Files           2192     2192
  Lines          86883    86884    +1
  Branches       12980    12980
==========================================
+ Hits           69575    69579    +4
+ Misses          9610     9608    -2
+ Partials        7698     7697    -1

Impacted Files
Coverage Δ

...-question/drag-and-drop-question-edit.component.ts
79.75% <100.00%> (+0.06%)
:arrow_up:

...e/scheduled/WeeklyEmailSummaryScheduleService.java
65.51% <0.00%> (-3.45%)
:arrow_down:

...ce/scheduled/ParticipantScoreSchedulerService.java
86.74% <0.00%> (+2.40%)
:arrow_up:

Flag
Coverage Δ

client
76.06% <100.00%> (+<0.01%)
:arrow_up:

server
84.56% <ø> (+<0.01%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2cd54c2...3270315. Read the comment docs.

authors: codecov-commenter rriyaldhi


text:
[DM-23547] Upgrade to cert-manager 0.13.1

Import new CRDs from the upstream Git repository and update the
cert-manager-crd app to deploy them.  Add some operational docs for
why this is a separate app and how it is updated.
Update all issuers to use the new API group and the new syntax for
specifying the solver.
Update all annotations to use the new annotation label for specifying
the issuer.
Remove the Argo CD ignoreDifferences configuration to see if this
problem is fixed with the latest cert-manager.
Remove the disable-validation annotation for the cert-manager
namespace since that upstream documentation page no longer exists
and upstream no longer appears to recommend this change.

Awesome work. I guess there isn't an immediate risk of failure if this change goes sideways because we already have certs in place, right? So we can watch the logs and generally see that cert-manager is healthy to know it's working.

Ah, I see the notes about deployment on the Jira ticket.

authors: jonathansick rra

repo: lsst-sqre/roundtable


text:
🛑 lsy223622.com is down

In d61a5e3, lsy223622.com (http://lsy223622.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: lsy223622.com is back up in af2ef99 after 659 days, 1 hour, 36 minutes.


text:
🛑 SoHard Cloud is down

In 6315eae, SoHard Cloud (http://cloud.lsy223622.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SoHard Cloud is back up in 84de339 after 10 minutes.


text:
🛑 SoHard Cloud is down

In afa2dbc, SoHard Cloud (http://cloud.lsy223622.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SoHard Cloud is back up in fca0d7b after 8 minutes.


text:
🛑 Mirror-木生 is down

In 95e3896, Mirror-木生 (https://t.lsy223622.com/ncov-xidian-times) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-爬 is back up in 824f60d.


text:
🛑 Mirror-爬 is down

In 1cd17c4, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 916 ms

Resolved: Mirror-鱼露 is back up in f06f80d.


text:
🛑 Mirror-爬 is down

In b3217a7, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1120 ms

Resolved: Mirror-鱼露 is back up in b7f3a7c.


text:
🛑 Mirror-爬 is down

In 0944bb0, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1001 ms

Resolved: Mirror-鱼露 is back up in 249abfc.


text:
🛑 Mirror-没有女朋友跨年的群傻逼 is down

In a98fc8b, Mirror-没有女朋友跨年的群傻逼 (https://x.ksfu.top/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-木生 is back up in 893306b.


text:
🛑 Mirror-爬 is down

In 8c63763, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1197 ms

Resolved: Mirror-鱼露 is back up in 6a09113.


text:
🛑 Mirror-爬 is down

In f2a40f7, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1027 ms

Resolved: Mirror-鱼露 is back up in 6abc8e9.


text:
🛑 Mirror-木生 is down

In a475eeb, Mirror-木生 (https://t.lsy223622.com/ncov-xidian-times) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-爬 is back up in 642707a.


text:
🛑 Mirror-爬 is down

In c381489, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1173 ms

Resolved: Mirror-鱼露 is back up in 5cd5f2b.


text:
🛑 Mirror-爬 is down

In 376110a, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 737 ms

Resolved: Mirror-鱼露 is back up in baac590.


text:
🛑 Mirror-爬 is down

In f447070, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1982 ms

Resolved: Mirror-鱼露 is back up in 14c6138.


text:
🛑 Mirror-爬 is down

In 2347dff, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 652 ms

Resolved: Mirror-鱼露 is back up in ce48ed0.


text:
🛑 Mirror-爬 is down

In d210128, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1092 ms

Resolved: Mirror-鱼露 is back up in b42e14a.


text:
🛑 Mirror-爬 is down

In e4e6375, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1132 ms

Resolved: Mirror-鱼露 is back up in 5290839.


text:
🛑 Mirror-爬 is down

In 0c45621, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 732 ms

Resolved: Mirror-鱼露 is back up in 4f49336.


text:
Hilfetext Eingabe Callsign

Kommentar Dani Lutz: Bei Eintragung des Kennzeichens: „Tippen Sie die ersten Buchstagen (ohne Bindestrich) der Immatrikulation......

Eingabe von Bindestrichen künftig ignoriert, dann Anpassung des Hilfetexts hinfällig

authors: philhug rzueger

repo: lszt/flights-react


text:
Move bot code to it's own repo

Also add a clear license
The goal is to make it easy to find and clone and improve together. 😃

@egils-consulting great suggestions. I'm doing it now.

@egils-consulting great suggestions. I'm doing it now.

@egils-consulting it is now on https://github.com/lubianat/covidbot

@egils-consulting it is now on https://github.com/lubianat/covidbot

authors: egils-consulting lubianat


text:
🛑 DGC prod is down

In 3d3de3e, DGC prod (https://digichanges.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: DGC prod is back up in 859c340.

repo: lucalop/monitoring


text:
Tag v0.12.0 was moved and became unusable with Go 1.13

I left a comment in the original issue #2129 but will also open a new one, so that it would get noticed.
Briefly: tag v0.12.0 was most likely moved from one commit to another, and official Go proxy has cached the old version, which now fails all checksum verifications.

Thanks for researching this. I re-tagged the v0.12.0 release as v0.12.1.

authors: marten-seemann zserge

repo: lucas-clemente/quic-go


text:
🛑 Punto de Fuga is down

In 90b3912, Punto de Fuga (http://puntodefugapodcast.com) was down:

HTTP code: 500
Response time: 533 ms

Resolved: Punto de Fuga is back up in bf34104.

repo: lucasboh/upptime


text:
Feature map size calculation problem

When use resnet18-culane, the feature map size calculated by: self.fmap_h = img_h // self.stride get wrong result;
The out feature size: 12x20, calculated size: 11x20

Looks like a bug to me, but I have to look deeper into it to confirm.

authors: lhcalibur lucastabelini

repo: lucastabelini/LaneATT


text:
Il programma è ok

Ciao Luca,
il tuo codice sorgente è corretto.
Ti chiederei solamente di rinominarlo come primo.c.
A presto,
Andrea

perfetto, dovrei aver fatto, grazie


text:
Metric label instance conflict with prometheus

The metric with label instance will conflict with prometheus when it be pulled into.
The original metric the exporter exposed is like:
zk_znode_count{instance="localhost:2181"}

But when it be pulled into promethes it will re-labeled by prometheus like:
zk_znode_count{exported_instance="localhost:2181",instance="localhost:9120",job="zk_export"}

I think the instance label is only owned for exporter itself,
So I suggest that we should rename zk metric label instead of instance.

Hi, sorry for the late response. I've been on holiday for a couple weeks. Do you have something in your prometheus config to rename the instance label to something else? We've been using that label across a few different services and haven't run into prometheus renaming it yet

The Prometheus server will attach an instance label to each scraped metric that does not already have one. The automatically attached instance label contains the host and port of the target scraped. If a metric already has an instance label, an exporter_instance label is attached instead.

This is the official advise here: prometheus/prometheus#490

Ah right, we've always gone with the default honor_labels config which is why we've never seen this. I've updated the label here to be zk_instance. Let me know if you have any other issues

authors: Keleir lucianjon

repo: lucianjon/zk-exporter

license: mit

license_source: bigquery


text:
How to Use Lucide with Vanilla JS?

Package

[X] lucide
[ ] lucide-angular
[ ] lucide-flutter
[ ] lucide-preact
[ ] lucide-react
[ ] lucide-react-native
[ ] lucide-solid
[ ] lucide-svelte
[ ] lucide-vue
[ ] lucide-vue-next
[ ] Figma plugin
[ ] source/main
[ ] other/not relevant

Version
0.291.0
Browser

[ ] Chrome/Chromium
[X] Firefox
[ ] Safari
[ ] Edge
[ ] iOS Safari
[ ] Opera
[ ] Other/not relevant

Operating system

[X] Windows
[ ] Linux
[ ] macOS
[ ] Other/not relevant

Description
After installing lucide according to Web(Vanilla) documentation using npm and use it in my script, console says:
Uncaught TypeError: The specifier “lucide” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../”, or “/”.

Steps to reproduce
Code like those on the documentation didn't work in mine as expected
Checklist

[X] I have searched if someone has submitted a similar issue before and there weren't any. (Please make sure to also search closed issues, as this issue might already have been resolved.)

Can you provide the actual steps to reproduce this error or a minimal reproduction in a sandbox?
(i.e. how you're actually trying to use it in your script)

Here's the minimal src code:
Sandbox.zip

Unfortunately, I still cannot reproduce the exact error message given, for that I would need further context as to how you're even trying to build this code, as the package.json provided includes no such information.
My first guess, however, is that you simply cannot use lucide as a devDependency, please install as npm i lucide as stated in the documentation, not npm i -D lucide.
Here's a working reproduction of your code, I hope this helps:
https://codesandbox.io/s/silly-raman-chrywt?file=/package.json

Wow, I though it must be a dependency. Thank you! ❤

Oh, as I searching more: it is because I use Live Server, and also I am in local development.
This article may help:
How to handle ES6 bare module imports for local Development

authors: chessurisme karsa-mistmere

repo: lucide-icons/lucide

license: ISC


text:
toy-block icon

Icon name: toy-block
Use case: Used for plugins, add-ons
Contributes to #651
similar icons:

Design proposal:

100%

Looks nice, but I think we can easily go with square's full height as well as the full 2px rounding and still have it completely legible.

authors: ericfennis karsa-mistmere


text:
SSL issue

I keep getting this issue spammed.
[02:18:39 WARN]: Fri Dec 28 02:18:39 GMT 2018 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.
LuckPerms Version: 4.3.62 Bukkit/Spigot
Server Version: 1.12.2 (with viaversion, backwards, and rewind) (1.7-1.13.2)

The solution has been linked in issue #1235. It tells you precisely what you need to do. (What you need to add where).

authors: BrainStone JustProGit

repo: lucko/LuckPerms


text:
stop server error

[03:35:43 WARN]: Exception in thread "ForkJoinPool.commonPool-worker-18" java.util.concurrent.CompletionException: java.sql.SQLException: HikariDataSo
urce HikariDataSource (luckperms-hikari) has been closed.
[03:35:43 WARN]:        at me.lucko.luckperms.common.storage.Storage.lambda$makeFuture$0(Storage.java:91)
[03:35:43 WARN]:        at java.util.concurrent.CompletableFuture$AsyncSupply.run(Unknown Source)
[03:35:43 WARN]:        at java.util.concurrent.CompletableFuture$AsyncSupply.exec(Unknown Source)
[03:35:43 WARN]:        at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
[03:35:43 WARN]:        at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
[03:35:43 WARN]:        at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
[03:35:43 WARN]:        at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
[03:35:43 WARN]: Caused by: java.sql.SQLException: HikariDataSource HikariDataSource (luckperms-hikari) has been closed.
[03:35:43 WARN]:        at me.lucko.luckperms.lib.hikari.HikariDataSource.getConnection(HikariDataSource.java:96)
[03:35:43 WARN]:        at me.lucko.luckperms.common.storage.implementation.sql.connection.hikari.HikariConnectionFactory.getConnection(HikariConnecti
onFactory.java:151)
[03:35:43 WARN]:        at me.lucko.luckperms.common.storage.implementation.sql.SqlStorage.loadUser(SqlStorage.java:276)
[03:35:43 WARN]:        at me.lucko.luckperms.common.storage.Storage.lambda$loadUser$4(Storage.java:149)
[03:35:43 WARN]:        at me.lucko.luckperms.common.storage.Storage.lambda$makeFuture$0(Storage.java:86)
[03:35:43 WARN]:        ... 6 more

Looks like the connection to the database is closed just before the rest of the plugin. Doesn't seem to be anything to worry about!


text:
Show Results of Old Events

For whatever reason LD38 isn't showing its results. Fix it.

Could it be that LD38 didn't have a state when it was done? Now that states are there, it might be only that

No it had the state, but the state that meant closed changed (was 6 now 8).

authors: local-minimum povrazor

repo: ludumdare/ludumdare


text:
Stream isn't writeable and enableOfflineQueue options is false

ioredis version: ^4.14.0
error message: Stream isn't writeable and enableOfflineQueue options is false;
here is my code:
const Ioredis = require('ioredis')
let redis = new Ioredis({
  'port': 6379,
  'host': 'testcc',
  'family': 4,
  'db': 0,
  'enableOfflineQueue': false
})
async function getActivity () {
  try {
    const activityList = await redis.get('tkey')
    if (activityList) return activityList
    return {
      succ: true,
      code: 404,
      msg: 'no activity'
    }
  } catch (error) {
    console.error(error.message)
    return {
      succ: false,
      code: 500,
      msg: error.message
    }
  }
}
getActivity()

if i set a timer to the function . it work fine.
setTimeout(getActivity,1000)

can you help me to solve the problem? thx

Use redis.connect(function () { /* Do your stuff */ });
https://stackoverflow.com/questions/35696219/find-out-when-ioredis-connection-has-been-established

thank you @knoxcard . Is there any Promise implement to run my code without using callback ?

Yup, appears that connect() returns a promise.
https://github.com/luin/ioredis/issues/30

repo: luin/ioredis


text:
Remove remaining dependencies on MATLAB toolboxes

In order for the DOE to be usable with the core MATLAB product without any additional (purchaseable) toolbox the following dependencies must be eliminated::

Optimization toolbox - need to find good open-source alternatives to the fmincon, lsqnonlin, ...

Statistics and Machine Learning toolbox - the sensitivity analysis function now requires the pdist map, this must be changed by an open-source alternative

The functionality does not need to be removed, and toolbox-dependent functions can be used optionally.

All reamining dependencies have been removed in the following commits:
Optimization Toolbox

https://github.com/luisfabib/DeerAnalysis2/commit/640c2498a9fdd89a9c823a31c1bfca7d1953b087 & https://github.com/luisfabib/DeerAnalysis2/commit/56370d7853e4c9500df270d0df13ccce7be75612 : The fmincon and lsqnonlin solvers used for the fitparamodel function now have open-source alternatives fminsearchbnd and nlsqbnd, respectively.  If the toolbox is available, the MATLAB solvers will be used by default, otherwise the open-source solvers will be set as default.

Statistics and Machine Learning toolbox

https://github.com/luisfabib/DeerAnalysis2/commit/0d0cb80fa8a002a985992b4dc57f97bc53fba97e  &  https://github.com/luisfabib/DeerAnalysis2/commit/48e00eac3f2b7ad02cb79c3d56cc8f1dac7312dd  : The prctile and pdist functions from the toolbox have been locally implemented.


text:
Colorizing of indent line is not working

Is there anything wrong with?
I've tried to load it before and after my colorscheme plugin.
~/.config/nvim/lua/user/plugins.lua:
-- Show vertical indent lines for blocks:
use({
  'lukas-reineke/indent-blankline.nvim',
  require = function()
    require('user.plugins.indent-blankline')
  end,
})

~/.config/nvim/lua/user/plugins/indent-blankline.lua:
------------------------------------------------------------------------------
-- Indent Blankline Plugin
------------------------------------------------------------------------------

-- Import Indent Blankline with a protected call:
local indent_blankline_status_ok, indent_blankline = pcall(require, 'indent_blankline')
if not indent_blankline_status_ok then
  return
end

------------------------------------------------------------
-- Appearance

-- Set color of indent-blankline plugin for vertical lines:
vim.cmd([[highlight IndentBlanklineChar guifg='#252525' gui=nocombine]])

indent_blankline.setup({
  char_highlight_list = {
    -- Call color variable:
    'IndentBlanklineChar',
  },
    filetype_exclude = {
    'help',
    'terminal',
    'dashboard',
    'packer',
    'lspinfo',
    'TelescopePrompt',
    'TelescopeResults',
  },
  buftype_exclude = {
    'terminal',
    'NvimTree',
  },
  show_trailing_blankline_indent = false,
  show_first_indent_level = true,
})

...termguicolors is already activated.
If I manually source indent-blankline.lua, my color works. But not if I start Neovim regularly.

I was having the same problem and setting the highlight groups in after/plugin works for me.  For example, I have the following file: after/plugin/colors.lua
vim.api.nvim_set_hl(0, "IndentBlanklineIndent1", {fg = "#E06C75"})
vim.api.nvim_set_hl(0, "IndentBlanklineIndent2", {fg = "#E5C07B"})

etc, etc
This enables the colors on start of opening the buffer rather than re-sourcing indent-blankline (I'm using lazy plugin manager but not sure if that matters)

Hi @bradfordleak :)
Thanks for your reply!!
I've tried that (I'm using Packer). It doesn't work for me :/
I've created ~/.config/nvim/after/colors.lua which schould work properly too.
Then I've tried:
vim.api.nvim_set_hl(0, 'IndentBlanklineIndent', { fg = '#252525 })
and
vim.cmd([[highlight IndentBlanklineChar guifg=#252525]])
Both doesn't work, so I've put it in my own color scheme on line 17.
Now it works. I don't understand why. I've switched the order of loading the color scheme and indent-blankline in my plugins.lua in all circumstances without any success. ..crazy behavior?!

This is not really related to indent-blankline. Whatever highlight group is set last takes priority. If you get a wrong color, it means there is an issue with the order you set the highlight groups.
When you load indent-blankline doesn't matter.
You can check where a highlight group was last set with :verbose highlight IndentBlanklineChar
I'll close this ticket, this is nothing I can fix. It's a problem with your config.

Thanks for the hint and the command, @lukas-reineke :)
No I'm able to go fishing :)

@MannyFay Did you figure this out?
I am having the same issue. I tried defining the highlight groups I want before and after sourcing the plugins with no success.
I can get it to stay only by setting it in a callback passed to vim.schedule().

I tried defining the highlight groups I want before and after sourcing the plugin with no success.

When you source indent-blankline does not make a difference.
It is probably your color scheme that overwrites the highlight groups, you want to define them after you load that.

authors: MannyFay bradfordleak lukas-reineke v3s1e


text:
List of ABC instance, use a table or something with border to make the list more clear

especially for cases where the list has one entry

Since I think they need to be in a TOC, so that they show up in the sidebar, I don't think this is gonna work

repo: lukasturcani/stk


text:
How do I get started?

Hi @lukegehron!
First of all, this is a really nice work, congrats!
Secondly, I just wanted to know how could I get started by running your project locally on my computer and if there was the possibility to integrate the HTML code into interfaces such as the ones provided by Gradio, which are able to render HTMLs.

As a disclaimer, I am not a JS/TS developer, thus sorry in advance for any basics/beginners' question I may ask :)

Thanks and have a nice day🥰
Cheers,
Astra

Hi Astra,
I just updated the code and the readme. I also have made a github pages at https://lukegehron.github.io/speckle-ai/

Many thanks!
Another quick question: is there any general way I can query your fal.ai ComfyUI API endpoint (like with curl or with requests in python)?
Cheers,
Astra :)

Hi @lukegehron,
I found a way to query your space with python, would you like the code of the minimal interface I built to do it? :)
I can PR it directly here on GitHub!

sure - feel free to make a PR and I will review

authors: AstraBert lukegehron

repo: lukegehron/speckle-ai


text:
fsviewer: Fix persistence

Fix #1918 (Placeholder files were created in persist directory by mistake.)

Duplicate of #1918

That is not problem. Persist will still work. There is no difference if you create new file in $dir or $persist_dir

It seems $persist_dir has not been created when pre_install script is running, so placeholders won't be created also.

repo: lukesampson/scoop-extras

license: Unlicense


text:
Create freecad-pre.json

Please check that it is correct:

normal freecad release is .exe installer
pre-release is .7z archive

First contribution ever. Not sure about actual installation commands.

https://github.com/ScoopInstaller/Versions


text:
Updated package-lock.json & npm package release

As per discussion with @CJ42

I think npm 7 is causing problems here.


text:
Fix/LUM-8316: split to unique and multiple

General summary
Split the Select component in 2 main components

Select -> string value
SelectMultiple -> array as value

In order to avoid too many code duplication, an higher-order component "WithSelectContext" was created.
We can continue to split select if needed and create ChipSelect and ChipSelectMultiple.
Important change
All unhandled props are now passed to the field instead of the wrapper.
The reason is, when we use a Select we expect to use a field. So if "disabled" is passed, it should go to the input and not the wrapper.
Screenshots

Check list

[ ] (if has style) Add need: review-integration label
[ ] (if has textual documentation) Add need: review-doc label
[ ] (if has code) Add need: review-frontend label
[ ] (if has react) Check through the react dev check list
[ ] (if fix or feature) Add need: test label

Check out the contribution guide for general guidelines for submissions to the design system.

Just demo issue I guess (the PR on left, master on right)

authors: FlorentDinet radiuso

repo: lumapps/design-system


text:
fix scrollbar: firefox support

The mousewheel event is no longer supported in firefox.
I replaced the deprecated mousewheel event with the new wheel event and added support for multiple delta modes to make the experience uniform across different browsers.
Now the scrollbar works almost the same on both chrome and firefox.

LumX scrollbar is removed in LumX v1.0.0rc1. I close your PR, sorry.

authors: l-catallo matmkian

repo: lumapps/lumX


text:
next release?

Hey I am working on a port of MUI for react-basic, and I'd like to use the generated types that are in master now. I'm ow far off from the next release you are. If it's a while, I'll use the types in the released version, but otherwise I'll wait.
Thanks!

It's probably better to work off of master. I'll try to get that pending PR in and released in the next few days.

thanks!
On Thu, Jul 18, 2019 at 2:39 PM Madeline Trotter notifications@github.com
wrote:

It's probably better to work off of master. I'll try to get that pending
PR in and released in the next few days.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lumihq/purescript-react-basic/issues/100?email_source=notifications&email_token=AAAIFIPOC6ASFCBBQZBGJD3QAC2GFA5CNFSM4IE6DIF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2JM3DA#issuecomment-512937356,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAIFIKD4VTSDMASQZ2JUHDQAC2GFANCNFSM4IE6DIFQ
.

authors: dwhitney spicydonuts

repo: lumihq/purescript-react-basic


text:
LuMongo Stats

Would like to be able to get the following easily:
Instance Info:
lumongoAllocatedMemory
lumongoCurrentMemoryUsage
Index info:
name
size (on disk)
docsCount
allFieldNames
facetableFieldNames
terms

@mdavis95 what else? I can also add as I think about the UI some more.

sortableFieldNames

Also needed is total disk size available.

Also queries per index / per second stats

repo: lumongo/lumongo


text:
Typo within login-form.blade.php

Correcting a TailwindCSS typo
Please describe your Pull Request as best as possible, explaining what it provides and why it is of value, referencing any related Issues.
Try to include the following in your Pull Request, where applicable...

Documentation updates
Automated tests

Thanks @ItsJustPW

authors: ItsJustPW glennjacobs

repo: lunarphp/lunar


text:
请教Huawei Mate Book 14 2020 触屏版安装问题？无线网卡和屏幕点不亮

您好，我的笔记本是Huawei Mate Book 14 2020 触屏版，CUP：i7-10510U，我安装完Ventura之后，出现安装过程中、以及安装好之后，引导后屏幕点不亮的情况，键盘鼠标都有相应，就是屏幕黑的，请问这是什么原因呢？
另外，我尝试用此EFI安装了Monterey，默认搭配的无线网卡驱动可能有问题，链接WIFI就崩溃重启，是不是需要替换Monterey版本的网卡驱动？

wifi的问题，需要降级一下驱动版本。屏幕点不亮的问题，可以在原作者或者pcbeta论坛发帖问下。

好的，感谢支持！WiFi问题解决了，降了下版本就Ok了。> wifi的问题，需要降级一下驱动版本。屏幕点不亮的问题，可以在原作者或者pcbeta论坛发帖问下。

@luoei 您好，我的笔记本是Huawei Mate Book 14 2020 i5-10210U+MX250，安装了Ventura。开机或者唤醒后wifi需要大概两三分钟才能连接成功。请问你是怎么解决这个问题的呀？

自带的这个切换和开机第一次连都比较慢。我现在用的是usb适配器连接的网络。

感谢大佬，不过usb适配器好像是用于Realtek系列网卡，我的笔记本网卡是英特尔wireless-AC 9560 160MHz。好像用不了哎。

感谢大佬，不过usb适配器好像是用于Realtek系列网卡，我的笔记本网卡是英特尔wireless-AC 9560 160MHz。好像用不了哎。

usb适配器里面也带有一个网卡和自带的网卡是2个独立的，wifi选择和切换也是另外一个程序。

好的，感谢大佬，我试一下

authors: Jintao-Xie dev-shoko luoei


text:
适配android5 api22出现的问题

dpt-android5.zip
环境：
Nexus5
android5.1.1
api22

执行出错，日志上看着是CodeItem已经回填成功，但是出现了NullPointerException

dpt-android5.zip:
1、android5.patch 我适配android5 修改的代码，包括添加了LoadMethod_L函数
2、error.log错误日志。

希望大神有空帮忙看下

应该是没填完，代码就执行了

我有试过在填充后，把begin指针对应的size大小的dex文件保存到私有目录，使用jadx打开dex，发现抽取后的方法是有被填充回去的。

那把base.odex文件删掉试试

删除了/data/dalvik-cache/arm目录下的odex文件，确实可以正常运行，请问有什么措施可以不让他走odex呢？

试试hook execv，看有没有执行dex2oat

使用以下代码进行hook execv未发现他走dex2oat的过程
static void* (*oriexecve_addr)(const char *__file, char *const *__argv, char *const *__envp);

static void* (*oriexecv_addr)(const char *__path, char *const *__argv);

void* execve_addr22(const char *__file, char *const *__argv, char *const *__envp) {
    DLOGD("process:%d,enter execve:%s", getpid(), __file);
    if (strstr(__file, "dex2oat")) {
        return NULL;
    } else {
        return oriexecve_addr(__file, __argv, __envp);
    }
}

void* execv_addr22(const char *__path, char *const *__argv) {
    DLOGD("process:%d,enter execv:%s", getpid(), __path);
    if (strstr(__path, "dex2oat")) {
        return NULL;
    } else {
        return oriexecv_addr(__path, __argv);
    }
}

void hook_exec(){
    void *execv_addr = DobbySymbolResolver(GetLibcPath(), "execv");

    DobbyHook(execv_addr, (void *) execv_addr22,
              (void **) &oriexecv_addr);

    void *execve_addr = DobbySymbolResolver(GetLibcPath(), "execve");

    DobbyHook(execve_addr, (void *) execve_addr22,
              (void **) &oriexecve_addr);
}

这个问题后来有解决吗？

当前方式自己解决

authors: AdenTk blueb0ne luoyesiqiu

repo: luoyesiqiu/dpt-shell


text:
Configure and enable watchdog just before jumping to the application firmware

This PR enables the watchdog just before jumping to the application bootloader. In case of issue with the new firmware, and if this firmware does not refresh it, the watchdog will reset the CPU, allowing MCUBoot to rollback to the previous version of the firmware.
This PR will help prevent the user from bricking their device by uploading a non-working firmware via the OTA.
Note that if this PR is merged, the application firmware will have to refresh the watchdog register periodically (max delay is ~7 seconds).
Here is the code to refresh the watchdog:
NRF_WDT->RR[0] = WDT_RR_RR_Reload;

Yep merged thanks!
How would we test this hmmm....

I did test it by building a custom bootloader that does not refresh the watchdog :)
This is how I found this issue : generate the DFU file with the standalone firmware (built to start @0x0 instead of 0x8000). The bootloader jumps, but the vector table is incorrect and ... cpu does nothing. In this case, the watchdog will reset and mcuboot will rollback.

Here is a test scenario. It uses 2 new files (I had to compress them into ZIP files for Github...):

bootloader_with_watchdog.zip : the bootloader built from this PR
dfu-BAD.zip : A DFU file generated from the standalone version of InfiniTime (https://github.com/JF002/Pinetime/releases/download/0.7.1/pinetime-app.bin). This firmware is built to run from offset 0x0 and won't run correctly when flashed at offset 0x8000 by OTA.

Using the current version of the bootloader (https://github.com/JF002/Pinetime/releases/download/0.7.1/bootloader.hex)

Flash the bootloader and the image of InfiniTime 0.7.1 (https://github.com/JF002/Pinetime/releases/download/0.7.1/pinetime-mcuboot-app-image.hex)
Reset and notice that it's working fine
OTA the dfu-BAD.img firmware
Reset
Notice that the screen displays the boot logo, and that the firmware does not run, the system is locked and there is no way to reset the CPU.

Using the new version of the bootloader (bootloader_with_watchdog.img)

Flash the new bootloader and the image of InfiniTime 0.7.1 (https://github.com/JF002/Pinetime/releases/download/0.7.1/pinetime-mcuboot-app-image.hex)
OTA the dfu-BAD.img firmware
Reset
Notice that the bootloader displays the boot logo, take some time, then the screen blinks (it's the reset from the watchdog) and finally, the original firmware runs again, meaning that MCUboot reverted to the old firmware. Victory :+1:

Great Job! :-) Wonder if we should use the Logo Loader as a simple test case, since it's a really simple firmware.
And we should recruit some beta testers to help with Regression Testing whenever we update the bootloader (since it's so mission critical).

Hypnos is now compatible with this watchdog.

Awesome! :-)

authors: JF002 endian-albin lupyuen

repo: lupyuen/pinetime-rust-mynewt


text:
Failed to resolve module 'ops.roi_ops' (in a custom TorchScript model)

A custom op can be visualized in Netron if model is exported to ONNX but not with TorchScript.

Netron app and version: Windows Desktop app 4.9.3
OS and browser version: Windows 10; OS build 19042.867
PyTorch version: 1.8.1
Ninja: 1.10.0.post2

Steps to Reproduce:

Ninja is required to run the code as well as torch. Run the following code and verify that the TorchScript model is unable to be visualized correctly by Netron:

import torch
from torch import nn

import torch.utils.cpp_extension

op_source = """
// Copyright (c) Facebook, Inc. and its affiliates. All Rights Reserved.
#include <torch/script.h>

template <typename scalar_t>
at::Tensor nms_cpu_kernel(const at::Tensor& dets,
                          const at::Tensor& scores,
                          const float threshold) {
  AT_ASSERTM(!dets.type().is_cuda(), "dets must be a CPU tensor");
  AT_ASSERTM(!scores.type().is_cuda(), "scores must be a CPU tensor");
  AT_ASSERTM(dets.type() == scores.type(), "dets should have the same type as scores");

  if (dets.numel() == 0) {
    return at::empty({0}, dets.options().dtype(at::kLong).device(at::kCPU));
  }

  auto x1_t = dets.select(1, 0).contiguous();
  auto y1_t = dets.select(1, 1).contiguous();
  auto x2_t = dets.select(1, 2).contiguous();
  auto y2_t = dets.select(1, 3).contiguous();

  at::Tensor areas_t = (x2_t - x1_t) * (y2_t - y1_t);

  auto order_t = std::get<1>(scores.sort(0, /* descending=*/true));

  auto ndets = dets.size(0);
  at::Tensor suppressed_t = at::zeros({ndets}, dets.options().dtype(at::kByte).device(at::kCPU));

  auto suppressed = suppressed_t.data<uint8_t>();
  auto order = order_t.data<int64_t>();
  auto x1 = x1_t.data<scalar_t>();
  auto y1 = y1_t.data<scalar_t>();
  auto x2 = x2_t.data<scalar_t>();
  auto y2 = y2_t.data<scalar_t>();
  auto areas = areas_t.data<scalar_t>();

  for (int64_t _i = 0; _i < ndets; _i++) {
    auto i = order[_i];
    if (suppressed[i] == 1)
      continue;
    auto ix1 = x1[i];
    auto iy1 = y1[i];
    auto ix2 = x2[i];
    auto iy2 = y2[i];
    auto iarea = areas[i];

    for (int64_t _j = _i + 1; _j < ndets; _j++) {
      auto j = order[_j];
      if (suppressed[j] == 1)
        continue;
      auto xx1 = std::max(ix1, x1[j]);
      auto yy1 = std::max(iy1, y1[j]);
      auto xx2 = std::min(ix2, x2[j]);
      auto yy2 = std::min(iy2, y2[j]);

      auto w = std::max(static_cast<scalar_t>(0), xx2 - xx1);
      auto h = std::max(static_cast<scalar_t>(0), yy2 - yy1);
      auto inter = w * h;
      auto ovr = inter / (iarea + areas[j] - inter);
      if (ovr >= threshold)
        suppressed[j] = 1;
   }
  }
  return at::nonzero(suppressed_t == 0).squeeze(1);
}

at::Tensor nms(const at::Tensor& dets,
               const at::Tensor& scores,
               const double threshold) {
  at::Tensor result;
  AT_DISPATCH_FLOATING_TYPES(dets.scalar_type(), "nms", [&] {
    result = nms_cpu_kernel<scalar_t>(dets, scores, threshold);
  });
  return result;
}

TORCH_LIBRARY(roi_ops, m) {
  m.def("nms", &nms);
}
"""

torch.utils.cpp_extension.load_inline(
    name="nms",
    cpp_sources=op_source,
    is_python_module=False,
    verbose=True,
)

class NonMaximumSuppression(torch.nn.Module):
    def __init__(self):
        super(NonMaximumSuppression, self).__init__()
        self.iou_threshold = 0.45

    def forward(self, x):
        bboxes = x[0,:,:4]
        probs = x[0,:,4]
        out_idx = torch.ops.roi_ops.nms(bboxes, probs, self.iou_threshold)
        return bboxes[out_idx], probs[out_idx]

class NMSWrapper(torch.nn.Module):
    def __init__(self):
        super(NMSWrapper, self).__init__()
        self.conv = nn.Conv2d(3, 16, 3, 1, 1, bias=True)
        self.relu = nn.ReLU()
        self.nms = NonMaximumSuppression()

    def forward(self, x):
        x = self.conv(x)
        x = self.relu(x)

        x = x.reshape(1,512,5)

        bboxes_masked, scores_masked = self.nms(x)

        return bboxes_masked, scores_masked

def register_custom_op():
    def symbolic_nms(g, boxes, scores, threshold):
        return g.op('NonMaxSuppression', boxes, scores, threshold)

    from torch.onnx import register_custom_op_symbolic
    register_custom_op_symbolic('roi_ops::nms', symbolic_nms, 13)
register_custom_op()

if __name__ == '__main__':
    nms_module = NMSWrapper()
    x = torch.zeros(1,3,16,10)
    outputs = nms_module(x)
    traced_model = torch.jit.trace(nms_module, x)
    with open('nms_wrapper.model', 'wb') as f:
        torch.jit.save(traced_model, f)
    # verify reloading
    with open('nms_wrapper.model', 'rb') as f:
        reloaded_model = torch.jit.load(f)
        reloaded_model_outputs = reloaded_model(x)
        print(all((outputs[0] == reloaded_model_outputs[0]).flatten()))
        print(all((outputs[1] == reloaded_model_outputs[1]).flatten()))

    with open('nms_wrappper.onnx', 'wb') as f:
        torch.onnx.export(nms_module, x, f, opset_version=13)

You can also verify that for the ONNX export, Netron is able to visualize the custom op correctly.

This is a TorchScript issue. The model file does not contain metadata or a definition for roi_ops.nms.

nms_wrapper.zip

authors: amr-martini lutzroeder

repo: lutzroeder/netron


text:
Sítio omie não está a fornecer as tarifas

O sítio omie não está a fornecer as tarifas para amanhã?

O sensor de integração sensor.omie_spot_price_pt tem os preços de amanhã.  Deve haver algo de errado no meu modelo de tarifário.

o meu sensor não tem os preços de amanhã. E por conseguinte, também não tenho os valores para o template LuzBoa que uso... deve haver algum problema com a API do site OMIE?

Parece que o problema está no MAJ.  O modelo testa se é igual a "unknown", e, se for, é utilizado um valor de zero, mas parece que o teste falha, mas MAJ é não-numérico.
Alterei a linha no cálculo da tarifa de amanhã de:
{%- set price = ((PM + CGS + k)*(1.0 + FP) + MAJ + TAR) | round(2) %}

para
{%- set price = ((PM + CGS + k)*(1.0 + FP) + 0 + TAR) | round(2) %}

Agora está a funcionar para mim.

Talvez seja melhor efetuar esta alteração tanto no cálculo da tarifa de hoje como no de amanhã.  Penso que o MAJ já não está a ser fornecido.

entretanto forcei um reboot do HA e já foi fazer fetch...

However, I forced a reboot of the HA and it was already fetching...

Por isso, talvez tenha sido apenas o facto de ter recarregado o yaml depois de ter feito a alteração ao modelo e não a alteração do código.  É estranho que ambos tenhamos visto o problema ao mesmo tempo e que só tenhamos feito os cálculos da tarifa de amanhã.

entretanto forcei um reboot do HA e já foi fazer fetch...

Por isso, talvez tenha sido apenas o facto de ter recarregado o yaml depois de ter feito a alteração ao modelo e não a alteração do código.  É estranho que ambos tenhamos visto o problema ao mesmo tempo e que só tenhamos feito os cálculos da tarifa de amanhã.

Agora está a funcionar devido à definição de MAJ para 0 ou ao reinício do yaml.

Futuramente seria bom capturar os logs correspondentes a estes eventos para poder corrigir um eventual problema na integração.

Os registos mostram estes dois erros:
This error originated from a custom integration.
Logger: custom_components.omie.coordinator
Source: helpers/update_coordinator.py:306
Integration: OMIE - electricity market operator for the Iberian Peninsula (documentation, issues)
First occurred: 2:00:12 PM (4 occurrences)
Last logged: 4:00:12 PM
Timeout fetching omie.adjustment_next data
Timeout fetching omie.spot_next data
Timeout fetching omie.adjustment data
Logger: homeassistant.components.template.template_entity
Source: components/template/template_entity.py:194
Integration: Template (documentation, issues)
First occurred: February 2, 2024 at 4:30:17 PM (27 occurrences)
Last logged: 4:31:23 PM
TemplateError('UndefinedError: None has no element datetime.datetime(2024, 2, 4, 0, 0, tzinfo=<DstTzInfo 'Europe/Lisbon' WET0:00:00 STD>)') while processing template 'Template<template=({% set CGS = 4 -%} {% set k = 10 -%} {% set FP = 0.15 -%} {% set TAR = -12.1 -%} {% set ns = namespace(hourly_data=[]) %} {% for h, PM in state_attr('sensor.omie_spot_price_pt', 'today_hours').items() -%} {% set MAJ = state_attr('sensor.omie_adjustment_price_pt', 'today_hours')[h] -%} {% if PM == None or MAJ == None %} {% set price=PM %} {% else %} {% set price=((PM + CGS + k)(1 + FP) + MAJ + TAR) | round(2) %} {% endif %} {% set ns.hourly_data=ns.hourly_data + [(h.isoformat(), price)] %} {% endfor -%} {{ dict(ns.hourly_data) }}) renders=4>' for attribute 'today_hours' in entity 'sensor.coopernico_base_tarifario_simples'
TemplateError('UndefinedError: None has no element datetime.datetime(2024, 2, 5, 0, 0, tzinfo=<DstTzInfo 'Europe/Lisbon' WET0:00:00 STD>)') while processing template 'Template<template=({% set CGS = 4 -%} {% set k = 10 -%} {% set FP = 0.15 -%} {% set TAR = 36.5 -%} {% set ns = namespace(hourly_data=[]) %} {% for h, PM in state_attr('sensor.omie_spot_price_pt', 'tomorrow_hours').items() -%} {% set MAJ = state_attr('sensor.omie_adjustment_price_pt', 'tomorrow_hours')[h] -%} {% if PM == None or MAJ == None %} {% set price=PM %} {% else %} {% set price=((PM + CGS + k)(1 + FP) + MAJ + TAR) | round(2) %} {% endif %} {% set ns.hourly_data=ns.hourly_data + [(h.isoformat(), price)] %} {% endfor -%} {{ dict(ns.hourly_data) }}) renders=4>' for attribute 'tomorrow_hours' in entity 'sensor.coopernico_base_tarifario_simples'
TemplateError('UndefinedError: 'TAR' is undefined') while processing template 'Template<template=({{ TAR | float(0) }}) renders=4>' for attribute 'TAR' in entity 'sensor.coopernico_bihorario_spot_consumption_price'
TemplateError('UndefinedError: None has no element datetime.datetime(2024, 2, 5, 0, 0, tzinfo=<DstTzInfo 'Europe/Lisbon' WET0:00:00 STD>)') while processing template 'Template<template=({% set CGS = 4 -%} {% set k = 10 -%} {% set FP = 0.15 -%} {% set TAR_vazio = 9.2 -%} {% set TAR_fora_vazio = 50.2 -%} {% set ns = namespace(hourly_data=[]) %} {% for h, PM in state_attr('sensor.omie_spot_price_pt', 'tomorrow_hours').items() -%} {% set MAJ = state_attr('sensor.omie_adjustment_price_pt', 'tomorrow_hours')[h] -%} {% set TAR = TAR_vazio if h.hour < 8 or h.hour > 21 else TAR_fora_vazio -%} {% if PM == None or MAJ == None %} {% set price=PM %} {% else %} {% set price=((PM + CGS + k)*(1 + FP) + MAJ + TAR) | round(2) %} {% endif %} {% set ns.hourly_data=ns.hourly_data + [(h.isoformat(), price)] %} {% endfor -%} {{ dict(ns.hourly_data) }}) renders=4>' for attribute 'tomorrow_hours' in entity 'sensor.coopernico_bihorario_spot_consumption_price'
TemplateError('UndefinedError: 'TAR' is undefined') while processing template 'Template<template=({{ TAR | float }}) renders=4>' for attribute 'TAR' in entity 'sensor.coopernico_base_tarifario_tri_horario'

Só esta parte diz respeito à integração, o resto é nos templates.
Logger: custom_components.omie.coordinator
Source: helpers/update_coordinator.py:306
Integration: OMIE - electricity market operator for the Iberian Peninsula (documentation, issues)
First occurred: 2:00:12 PM (4 occurrences)
Last logged: 4:00:12 PM

Timeout fetching omie.adjustment_next data
Timeout fetching omie.spot_next data
Timeout fetching omie.adjustment data

Um erro qualquer transiente no OMIE. Tenho de pôr isto a tentar de novo quando falha à primeira...

authors: JeffersM1 joaocbatista luuuis


text:
Why not pass client handle in callbacks?

Evening.
I'm interested, why we don't pass client handle in read_start callbacks?
It will be very convenient when you using external functions:

local function callback(client, err, chunk)
print(type(client) == 'userdata') -- true
return
end

client:read_start(callback) -- if we need to access client handle in callback by some reason, for now we need to define «one-liners»:
-- client:read_start(function(...) callback(client, ...) end)

So, why such behaviour isn't default?

I've just made simple patch to enable that behaviour for read_start, but I don't think it is correct solution btw.
--- stream.orig	2020-06-11 22:52:30.748014861 +0300
+++ stream.c	2020-06-11 22:52:35.524068945 +0300
@@ -93,21 +93,28 @@
   lua_State* L = data->ctx->L;
   int nargs;

+  // stream handle 1st arg
+  lua_newuserdata(L, sizeof(*handle));
+  lua_getfield(L, LUA_REGISTRYINDEX, "uv_stream");
+  lua_setmetatable(L, -2);
+  ++nargs;
+
   if (nread > 0) {
     lua_pushnil(L);
     lua_pushlstring(L, buf->base, nread);
-    nargs = 2;
+    nargs = nargs+2;
   }

   free(buf->base);
-  if (nread == 0) return;
+  if (nread == 0)
+    return;

   if (nread == UV_EOF) {
-    nargs = 0;
+    // EOF
   }
   else if (nread < 0) {
     luv_status(L, nread);
-    nargs = 1;
+    ++nargs;
   }

   luv_call_callback(L, (luv_handle_t*)handle->data, LUV_READ, nargs);

Note that this is true for the bindings to all similar functions as well (e.g. udp_recv_start). Changing these functions to pass the stream/handle as the first parameter to the callbacks would be breaking changes, though, which we are trying to avoid. The way to do this in a non-breaking way would be to pass it as the last argument to the callbacks (not quite ideal, but don't have many options if we're trying to keep backwards compatibility).
In terms of the status quo, I think luv mostly expects the stream/handle to be able to be an upvalue of the callback function.

Maybe there is a better way to deal with it? ☺
3rd argument sounds much worse, because in different callbacks there are different (and sometimes variable) number of arguments.
So.
Maybe better variant is to plan that changes for next major release?

We don't have any precedent for making breaking changes and we don't do arbitrary version bumps because the luv version is pegged to the libuv version.

This is likely not going to change since it would change the API. A different approach is use a bind like API like this.
ie:
bind(kls.someFunc, instance, client)

authors: SinisterRectus rphillips snoopcatt squeek502

repo: luvit/luv


text:
Fast Detect

Project Link
https://github.com/ValveSoftware/source-sdk-2013
Project License
Source SDK Copyright(c) Valve Corp.
Steam App Ids
https://steamdb.info/app/353220/
Additional Context
That is a free HL2 mod that works fine with Source SDK 2013 natively. Steps:

Install Fast Detect
Switch upcoming branch of Source SDK Base 2013 Singleplayer and install it
Copy ~/.local/share/Steam/steamapps/common/Fast Detect/FastDetect into ~/.local/share/Steam/steamapps/sourcemods ; rename the folder as fastdetect
Apply LANG=en_US.UTF-8 bash within  ~/.local/share/Steam/steamapps/sourcemods/fastdetect
Run find ./ | sort -r | sed 's/\(.*\/\)\(.*\)/mv "\1\2" "\1\L\2"/' |sh within  ~/.local/share/Steam/steamapps/sourcemods/fastdetect
Edit ~/.local/share/Steam/steamapps/sourcemods/fastdetect/gameinfo.txt > replace 353220 with 243730
Copy client.so and server.so from ~/.local/share/Steam/steamapps/common/Source SDK Base 2013 Singleplayer/sourcetest/bin into ~/.local/share/Steam/steamapps/sourcemods/fastdetect/bin
Restart Steam and run Fast Detect mod.

Added in https://github.com/luxtorpeda-dev/packages/commit/fe61bf5e7e6673c4c61c1819d0574a1ffeed713e
Thanks for the suggestion.

repo: luxtorpeda-dev/packages

license: Zlib


text:
Error when I run the command

Run respectively:

Check your nodejs version and upgrade to v14.+

Thank you!


text:
Added important notes about iOS 10 privacy rules

about needing to define strings for NSCameraUsageDescription and NSMicrophoneUsageDescription

Thanks for your contribution!

authors: abcd-ca ptomasroos

repo: lwansbrough/react-native-camera


text:
Added option for serverless.yml to source log level from environment …

…variable LOG_LEVEL.
CHP-224
Issue #, if available:
Description of changes:
Checklist:

[ ] Have you successfully deployed to an AWS account with your changes?
[ ] Have you written new tests for your core changes, as applicable?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

thanks for cleaning up my mistake here. feel free to push.

authors: Zambonilli jmrah


text:
Support specifying list of SSL/TLS ciphers for lxd, or just add additional ciphers

Currently it does not seem possible to specify a custom list of ciphers.  This is OK if the lxc command line tool is used, but it breaks some front-ends.
This is a useful request because of projects like:

https://github.com/dobin/lxd-webgui
https://github.com/aarnaud/lxd-webui

which aim to provide a web GUI front-end to the lxd service. (they are the only LXD front-ends i've found so far).  They are client-side code only; the server is just serving static content.  The client web browser directly connects to the lxd REST API.
However the problem is that lxd only supports TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher, which is not supported by Internet Explorer 11 on Windows 7, for example (reference: https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win 8.1).  So it is not possible to use these user agents with a web GUI as listed above.  It seems like it would be reasonable to allow a few other cipher suites to be specified, which have better web browser support.

Hmm, this doesn't make sense to me. According to the code, we allow two ciphers:

tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

According to the document you linked to, IE doesn't support the first, but it supports the second, so there should be no problem.

I assume you refer to https://github.com/lxc/lxd/blob/57bfe90f4d4e79696d678e74b95676731d652830/shared/network.go#L41 and https://github.com/lxc/lxd/blob/256460d6c45596ad0d27f771d559432341c5bdab/lxd/daemon.go#L806 ?
I see what you mean.  But something is wrong because:
$ dpkg -s lxd
Version: 2.0.2-0ubuntu1~16.04.1

(I confirmed that this version does declare both ciphers in above linked locations).
Scanning the endpoint with Digicert's tool:

I also tested in Wireshark and confirmed the findings:

IE11 indeed offers to use TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 but not TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
The server replies with TLS alert 21: handshake failure. (Alert 21 record, message level == 2 == fatal, description == 40 == Handshake Failure).

Ah, the problem is that ECDHE_ECDSA can only be selected if the server certificate is using ECDSA... so we need to find another reasonable RSA one instead.

authors: JohnstonJ stgraber

repo: lxc/lxd


text:
How do we lxd import? Instructions are extremely unclear

I use Ubuntu 16.04, and all i got for importing instructions was the help screen when I type just: lxd import
To test this feature, I had already done a backup of a container from the containers directory, with zfs send | zfs receive.
Then I targz-ed the directory I sent, as root user in order to preserve file ownerships. I took it to a different machine, with a fresh install of the newest lxd (2.15) just like the source machine's lxd.
I didn't know where to untar it, because the instructions were so unclear. So I created a zfs filesystem called test-container under default/containers in the destination machine zfs pool. I untarred (as root again), and did a "mv" of the contents of the untarred directory inside the default/containers/test-container (that was the original name of the container, as well).
Then I did: lxd import test-container
and got:
root@test-vm:/# lxd import test-container
error: The container "test-container" does not seem to exist on any storage pool.
What should I do? The instructions ought to be a lot clearer than this...

We have https://github.com/lxc/lxd/blob/master/doc/backup.md for that. Suggestions on how to extend that documentation would be welcome.

I had read that also, and still couldn't figure out what to do.
I wish this page mentioned that all I need to backup is the container I want (and nothing else is necessary) from zfs (with zfs send, for example).
Also instructions how to restore (with zfs receive -d default).
Before that, I had my backed-up files, and I was placing them in /var/lib/lxd/containers, which was wrong... but how could I know?
After zfs receiving, I must create a link from /var/lib/lxd/containers/my-test-container to the other directory which I don't remember right now. And only then can I lxd import my container.
Also I would like to know whether the above instructions seem enough to you, or whether I will have restored only part of my container if I follow them.
Thanks for a great product!

@brauner can you clarify and then update the documentation?
IIRC we only need the container to be restored in /var/lib/lxd/storage-pools/... with LXD re-creating the symlink in /var/lib/lxd/containers, but maybe I'm wrong and we have a bug :)

lxd import doesn't recreate the bug. Also mention fuidshift of lxd-tools (ubuntu package), as it might be needed after a backup restore operation.

fuidshift shouldn't be needed when using "lxd import" as the container's id map is part of backup.yaml, letting LXD do the remapping on container start.

So assuming that you're using ZFS and have backed up the container with send/receive. You should:

Ensure that there are no containers with the same name in your LXD
Cleanup any manual restore attempt you may have done such as a direct restore in /var/lib/lxd/containers or leftover files for your container in /var/lib/lxd/storage-pools/
Do your "zfs receive" to recreate the ZFS filesystem for the container
Ensure that the mountpoint property for that filesystem is /var/lib/lxd/storage-pools/POOL/containers/NAME where POOL is the storage pool name as reported by "lxc storage list" and NAME is the name of your container (and must match the ZFS filesystem)
Mount the ZFS filesystem "zfs mount "
Run "lxd import NAME" where NAME is the container's name

If that all works and the container fails to start, then please post the error as well as "lxc config show --expanded NAME". It could well be that LXD doesn't recalculate the map on "lxd import", if that's the case, there is a very simple trick to force LXD to do so, which should unstick things.

I followed your steps (all of them as root). Here's the result: When I typed lxd import test-container, I got:
error: open /var/lib/lxd/containers/test-container/backup.yaml: no such file or directory

which I believe means I need to do ln -s from there to there.
I did that, and ran import again. It ran. Now I'm doing start and exec bash. Oops, problem!
root@test-vm:~# lxc exec test-container bash
bash: /root/.bashrc: Permission denied
root@test-container:/# ls -al
total 34
drwxr-xr-x  22 nobody nogroup  22 Jun 19 23:52 .
drwxr-xr-x  22 nobody nogroup  22 Jun 19 23:52 ..
drwxr-xr-x   2 nobody nogroup 173 Jul  2 04:41 bin
drwxr-xr-x   3 nobody nogroup   3 Jun 19 23:52 boot
drwxr-xr-x   9 root   root    500 Jul  2 19:41 dev
drwxr-xr-x  92 nobody nogroup 182 Jul  2 04:44 etc
drwxr-xr-x   3 nobody nogroup   3 Jul  2 04:37 home
drwxr-xr-x  20 nobody nogroup  24 Jul  2 04:44 lib
drwxr-xr-x   2 nobody nogroup   3 Jun 19 23:49 lib64
drwxr-xr-x   2 nobody nogroup   2 Jun 19 23:49 media
drwxr-xr-x   2 nobody nogroup   2 Jun 19 23:49 mnt
drwxr-xr-x   2 nobody nogroup   2 Jun 19 23:49 opt
dr-xr-xr-x 875 nobody nogroup   0 Jul  2 19:41 proc
drwx------   3 nobody nogroup   8 Jul  2 04:43 root
drwxr-xr-x  18 root   root    680 Jul  2 19:42 run
drwxr-xr-x   2 nobody nogroup 236 Jul  2 04:44 sbin
drwxr-xr-x   2 nobody nogroup   2 Apr 29 08:38 snap
drwxr-xr-x   2 nobody nogroup   2 Jun 19 23:49 srv
dr-xr-xr-x  13 nobody nogroup   0 Jul  2 19:14 sys
drwxrwxrwt   7 nobody nogroup   7 Jul  2 19:27 tmp
drwxr-xr-x  10 nobody nogroup  10 Jun 19 23:49 usr
drwxr-xr-x  13 nobody nogroup  15 Jun 19 23:52 var

What trick do you have to suggest to me? Couldn't you have it do it automatically, without trick?

You didn't provide the "lxc config show" I asked above.

As for the need to make the symlink, yes, that shouldn't be needed as LXD should be able to locate the container in /var/lib/lxd/storage-pools. @brauner I thought you fixed that one?

Can you also provide the following from your ZFS backup filesystem, before running a "lxd import":

ls -lh /var/lib/lxd/storage-pools/default/containers/test-container/rootfs/
cat /var/lib/lxd/storage-pools/default/containers/test-container/backup.yaml

@stgraber, symlinks are not needed for import to work.

@brauner Any idea what cause the error above?
error: open /var/lib/lxd/containers/test-container/backup.yaml: no such file or directory

I want to see the output of lxc info.

I see one potential problem in the code.

karjala@test-vm:~$ lxc config show --expanded test-container
architecture: x86_64
config:
  image.architecture: amd64
  image.description: ubuntu 16.04 LTS amd64 (release) (20170619.1)
  image.label: release
  image.os: ubuntu
  image.release: xenial
  image.serial: "20170619.1"
  image.version: "16.04"
  volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
  volatile.eth0.hwaddr: 00:16:3e:67:10:f9
  volatile.eth0.name: eth0
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""
karjala@test-vm:~$

More answers coming soon...

root@alex-latitude:~# zfs receive -d -n -v backup-white-cyprus/stephan-demo <~karjala/test.stream
would receive full stream of default/containers/test-container@snapshot-snap0 into backup-white-cyprus/stephan-demo/containers/test-container@snapshot-snap0
root@alex-latitude:~# zfs receive -d backup-white-cyprus/stephan-demo <~karjala/test.stream
root@alex-latitude:~# zfs set mountpoint=/here-the-good-containers backup-white-cyprus/stephan-demo/containers/test-container

...

root@alex-latitude:/here-the-good-containers# cat backup.yaml
container:
  architecture: x86_64
  config:
    image.architecture: amd64
    image.description: ubuntu 16.04 LTS amd64 (release) (20170619.1)
    image.label: release
    image.os: ubuntu
    image.release: xenial
    image.serial: "20170619.1"
    image.version: "16.04"
    volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
    volatile.eth0.hwaddr: 00:16:3e:3e:10:0f
    volatile.eth0.name: eth0
    volatile.idmap.base: "0"
    volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.power: STOPPED
  devices: {}
  ephemeral: false
  profiles:
  - default
  stateful: false
  description: ""
  created_at: 2017-07-02T04:36:58Z
  expanded_config:
    image.architecture: amd64
    image.description: ubuntu 16.04 LTS amd64 (release) (20170619.1)
    image.label: release
    image.os: ubuntu
    image.release: xenial
    image.serial: "20170619.1"
    image.version: "16.04"
    volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
    volatile.eth0.hwaddr: 00:16:3e:3e:10:0f
    volatile.eth0.name: eth0
    volatile.idmap.base: "0"
    volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.power: STOPPED
  expanded_devices:
    eth0:
      nictype: bridged
      parent: lxdbr0
      type: nic
    root:
      path: /
      pool: default
      type: disk
  name: test-container
  status: Stopped
  status_code: 102
  last_used_at: 2017-07-02T16:11:10.271550129Z
snapshots: []
pool:
  config:
    size: 50GB
    source: /var/lib/lxd/disks/default.img
    zfs.pool_name: default
  description: ""
  name: default
  driver: zfs
  used_by: []
volume:
  config: {}
  description: ""
  name: test-container
  type: container
  used_by: []

root@alex-latitude:/here-the-good-containers# ls -al
total 14
drwxr-xr-x  4 165536 165536    6 Ιούλ  2 07:37 .
drwxr-xr-x 26 root   root   4096 Ιούλ  2 23:32 ..
-r--------  1 root   root   2336 Ιούλ  2 22:27 backup.yaml
-rw-r--r--  1 root   root   1568 Ιούν 20 04:03 metadata.yaml
drwxr-xr-x 22 165536 165536   22 Ιούν 20 02:52 rootfs
drwxr-xr-x  2 root   root      8 Ιούν 20 04:03 templates
root@alex-latitude:/here-the-good-containers# ls -alh rootfs/
total 39K
drwxr-xr-x 22 165536 165536  22 Ιούν 20 02:52 .
drwxr-xr-x  4 165536 165536   6 Ιούλ  2 07:37 ..
drwxr-xr-x  2 165536 165536 173 Ιούλ  2 07:41 bin
drwxr-xr-x  3 165536 165536   3 Ιούν 20 02:52 boot
drwxr-xr-x  5 165536 165536  91 Ιούν 20 02:51 dev
drwxr-xr-x 92 165536 165536 182 Ιούλ  2 07:44 etc
drwxr-xr-x  3 165536 165536   3 Ιούλ  2 07:37 home
drwxr-xr-x 20 165536 165536  24 Ιούλ  2 07:44 lib
drwxr-xr-x  2 165536 165536   3 Ιούν 20 02:49 lib64
drwxr-xr-x  2 165536 165536   2 Ιούν 20 02:49 media
drwxr-xr-x  2 165536 165536   2 Ιούν 20 02:49 mnt
drwxr-xr-x  2 165536 165536   2 Ιούν 20 02:49 opt
drwxr-xr-x  2 165536 165536   2 Απρ  12  2016 proc
drwx------  3 165536 165536   8 Ιούλ  2 07:43 root
drwxr-xr-x  3 165536 165536   3 Ιούν 20 02:51 run
drwxr-xr-x  2 165536 165536 236 Ιούλ  2 07:44 sbin
drwxr-xr-x  2 165536 165536   2 Απρ  29 11:38 snap
drwxr-xr-x  2 165536 165536   2 Ιούν 20 02:49 srv
drwxr-xr-x  2 165536 165536   2 Φεβ   5  2016 sys
drwxrwxrwt  7 165536 165536   7 Ιούλ  2 22:27 tmp
drwxr-xr-x 10 165536 165536  10 Ιούν 20 02:49 usr
drwxr-xr-x 13 165536 165536  15 Ιούν 20 02:52 var

This is my ZFS backup filesystem, as you asked. It's not attached to a LXD system at all.

Since I'm not sure that's you wanted (the directories were different in your question), I'm repeating these steps in the RESTORE lxd machine, just before the lxd import command.

root@test-vm:/var/lib/lxd/storage-pools/default/containers/test-container# ls -al
total 11
drwxr-xr-x  4 165536 165536    6 Jul  2 07:37 .
drwxr-xr-x  3 root   root   4096 Jul  2 23:41 ..
-r--------  1 root   root   2336 Jul  2 22:27 backup.yaml
-rw-r--r--  1 root   root   1568 Jun 20 04:03 metadata.yaml
drwxr-xr-x 22 165536 165536   22 Jun 20 02:52 rootfs
drwxr-xr-x  2 root   root      8 Jun 20 04:03 templates

root@test-vm:/var/lib/lxd/storage-pools/default/containers/test-container# ls -al rootfs/
total 39
drwxr-xr-x 22 165536 165536  22 Jun 20 02:52 .
drwxr-xr-x  4 165536 165536   6 Jul  2 07:37 ..
drwxr-xr-x  2 165536 165536 173 Jul  2 07:41 bin
drwxr-xr-x  3 165536 165536   3 Jun 20 02:52 boot
drwxr-xr-x  5 165536 165536  91 Jun 20 02:51 dev
drwxr-xr-x 92 165536 165536 182 Jul  2 07:44 etc
drwxr-xr-x  3 165536 165536   3 Jul  2 07:37 home
drwxr-xr-x 20 165536 165536  24 Jul  2 07:44 lib
drwxr-xr-x  2 165536 165536   3 Jun 20 02:49 lib64
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 media
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 mnt
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 opt
drwxr-xr-x  2 165536 165536   2 Apr 12  2016 proc
drwx------  3 165536 165536   8 Jul  2 07:43 root
drwxr-xr-x  3 165536 165536   3 Jun 20 02:51 run
drwxr-xr-x  2 165536 165536 236 Jul  2 07:44 sbin
drwxr-xr-x  2 165536 165536   2 Apr 29 11:38 snap
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 srv
drwxr-xr-x  2 165536 165536   2 Feb  5  2016 sys
drwxrwxrwt  7 165536 165536   7 Jul  2 22:27 tmp
drwxr-xr-x 10 165536 165536  10 Jun 20 02:49 usr
drwxr-xr-x 13 165536 165536  15 Jun 20 02:52 var

root@test-vm:/var/lib/lxd/storage-pools/default/containers/test-container# cat backup.yaml
container:
  architecture: x86_64
  config:
    image.architecture: amd64
    image.description: ubuntu 16.04 LTS amd64 (release) (20170619.1)
    image.label: release
    image.os: ubuntu
    image.release: xenial
    image.serial: "20170619.1"
    image.version: "16.04"
    volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
    volatile.eth0.hwaddr: 00:16:3e:3e:10:0f
    volatile.eth0.name: eth0
    volatile.idmap.base: "0"
    volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.power: STOPPED
  devices: {}
  ephemeral: false
  profiles:
  - default
  stateful: false
  description: ""
  created_at: 2017-07-02T04:36:58Z
  expanded_config:
    image.architecture: amd64
    image.description: ubuntu 16.04 LTS amd64 (release) (20170619.1)
    image.label: release
    image.os: ubuntu
    image.release: xenial
    image.serial: "20170619.1"
    image.version: "16.04"
    volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
    volatile.eth0.hwaddr: 00:16:3e:3e:10:0f
    volatile.eth0.name: eth0
    volatile.idmap.base: "0"
    volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.power: STOPPED
  expanded_devices:
    eth0:
      nictype: bridged
      parent: lxdbr0
      type: nic
    root:
      path: /
      pool: default
      type: disk
  name: test-container
  status: Stopped
  status_code: 102
  last_used_at: 2017-07-02T16:11:10.271550129Z
snapshots: []
pool:
  config:
    size: 50GB
    source: /var/lib/lxd/disks/default.img
    zfs.pool_name: default
  description: ""
  name: default
  driver: zfs
  used_by: []
volume:
  config: {}
  description: ""
  name: test-container
  type: container
  used_by: []

root@test-vm:~# lxc info
config: {}
api_extensions:

storage_zfs_remove_snapshots
container_host_shutdown_timeout
container_syscall_filtering
auth_pki
container_last_used_at
etag
patch
usb_devices
https_allowed_credentials
image_compression_algorithm
directory_manipulation
container_cpu_time
storage_zfs_use_refquota
storage_lvm_mount_options
network
profile_usedby
container_push
container_exec_recording
certificate_update
container_exec_signal_handling
gpu_devices
container_image_properties
migration_progress
id_map
network_firewall_filtering
network_routes
storage
file_delete
file_append
network_dhcp_expiry
storage_lvm_vg_rename
storage_lvm_thinpool_rename
network_vlan
image_create_aliases
container_stateless_copy
container_only_migration
storage_zfs_clone_copy
unix_device_rename
storage_lvm_use_thinpool
storage_rsync_bwlimit
network_vxlan_interface
storage_btrfs_mount_options
entity_description
image_force_refresh
storage_lvm_lv_resizing
api_status: stable
api_version: "1.0"
auth: trusted
public: false
environment:
addresses: []
architectures:

x86_64
i686
certificate: |
-----BEGIN CERTIFICATE-----
secret
-----END CERTIFICATE-----
certificate_fingerprint: .........................secret.............
driver: lxc
driver_version: 2.0.8
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.4.0-83-generic
server: lxd
server_pid: 3707
server_version: "2.15"
storage: zfs
storage_version: 0.6.5.6-0ubuntu16

Thanks, so the backup looks good with the right ownership on files which matches what's in backup.yaml.
Can you now create the symlink in /var/lib/lxd/containers/ and then run "lxd import test-container" but don't start the container after that. Instead, post:

ls -lh /var/lib/lxd/storage-pools/default/containers/test-container/rootfs/
lxc config show --expanded test-container

That should let me figure out exactly what LXD is going to do when you do start the container and see why you'd then end up with broken uid/gid.

root@test-vm:/var/lib/lxd/containers# ls -lh /var/lib/lxd/storage-pools/default/containers/test-container/rootfs/
total 36K
drwxr-xr-x  2 165536 165536 173 Jul  2 07:41 bin
drwxr-xr-x  3 165536 165536   3 Jun 20 02:52 boot
drwxr-xr-x  5 165536 165536  91 Jun 20 02:51 dev
drwxr-xr-x 92 165536 165536 182 Jul  2 07:44 etc
drwxr-xr-x  3 165536 165536   3 Jul  2 07:37 home
drwxr-xr-x 20 165536 165536  24 Jul  2 07:44 lib
drwxr-xr-x  2 165536 165536   3 Jun 20 02:49 lib64
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 media
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 mnt
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 opt
drwxr-xr-x  2 165536 165536   2 Apr 12  2016 proc
drwx------  3 165536 165536   8 Jul  2 07:43 root
drwxr-xr-x  3 165536 165536   3 Jun 20 02:51 run
drwxr-xr-x  2 165536 165536 236 Jul  2 07:44 sbin
drwxr-xr-x  2 165536 165536   2 Apr 29 11:38 snap
drwxr-xr-x  2 165536 165536   2 Jun 20 02:49 srv
drwxr-xr-x  2 165536 165536   2 Feb  5  2016 sys
drwxrwxrwt  7 165536 165536   7 Jul  2 22:27 tmp
drwxr-xr-x 10 165536 165536  10 Jun 20 02:49 usr
drwxr-xr-x 13 165536 165536  15 Jun 20 02:52 var

root@test-vm:/var/lib/lxd/containers# lxc config show --expanded test-container
architecture: x86_64
config:
  image.architecture: amd64
  image.description: ubuntu 16.04 LTS amd64 (release) (20170619.1)
  image.label: release
  image.os: ubuntu
  image.release: xenial
  image.serial: "20170619.1"
  image.version: "16.04"
  volatile.base_image: 7a7ff654cbd8f5f09bec03aa19d8d7d92649127d18659036a963b1ea63f90d25
  volatile.eth0.hwaddr: 00:16:3e:e7:3f:1e
  volatile.eth0.name: eth0
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

I haven't started the container yet.

Ok, perfect, that does show a bug in the import code then.
It shows the following changing from:
    volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'

To:
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'

Instead of the expected:
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":100000,"Nsid":0,"Maprange":65536}]'
    volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'

Run:
lxc config set test-container volatile.last_state.idmap '[{"Isuid":true,"Isgid":false,"Hostid":165536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":165536,"Nsid":0,"Maprange":65536}]'
lxc start
That should fix the issue.

@brauner any idea what's going on here? Looks like we're replacing the existing idmap with the current system one, which is reasonable, but we do so without keeping the previous value for volatile.last_state.idmap so the container doesn't remap the filesystem on startup.

Indeed, that command you gave me just now fixed the problem (for this one time).

@stgraber, sounds like the backup.yaml file couldn't not be updated and hence is missing the updated volatile key.

Oh, ok the original backup.yaml contains the correct entry.

The container directory itself was owned by 165536 (if that's of any use to anyone):
root@alex-latitude:/here-the-good-containers# ls -al
total 14
drwxr-xr-x  4 165536 165536    6 Ιούλ  2 07:37 .
drwxr-xr-x 26 root   root   4096 Ιούλ  2 23:32 ..
-r--------  1 root   root   2336 Ιούλ  2 22:27 backup.yaml
-rw-r--r--  1 root   root   1568 Ιούν 20 04:03 metadata.yaml
drwxr-xr-x 22 165536 165536   22 Ιούν 20 02:52 rootfs
drwxr-xr-x  2 root   root      8 Ιούν 20 04:03 templates

@stgraber, why should this be a bug in the import code? All the import code does with backup.yaml is to unmarshal it into a go struct. It doesn't alter the values.

Hm, wait.

We're currently wiping all volatile.* keys on import except for volatile.base_image. I'll take a look at the volatile keys now and see which ones would make sense to keep.

Question: Shouldn't the developers of lxc have tested their product before claiming that lxd import does not need the link to exist before tunning the command? Whenever you fix a bug, you should test the product to see that the bug has been fixed. I think that's the proper way...

We have automated testing for this feature which wasn't cleaning everything up, @brauner's fix is now fixing that particular issue so that this doesn't regress.
Not requiring the symlink was one of the very many details we discussed back when the feature was implemented and was forgotten when the test code was written. https://github.com/lxc/lxd/blob/master/test/suites/backup.sh
Bugs happen, when we find them, we fix them and add tests, apparently even on Sundays.

Ok ok!

Did you also fix the uids problem? Is it planned to be fixed? Do you need reminders? Should I open a new ticket for that?

The uid problem is also addressed in the branch I sent.

@brauner May I reiterate the request to update backup.md?
The instructions there are quite vague, and I can't quite make what I read here and on 3481 into a complete backup-and-restore sequence.

@yoniy0, without wanting to relay the question back to you what exactly are you looking for? I just want to make sure that I'm not putting anything useless in there. What exactly are you looking for? Implementation details or an example command line like lxd import <container-name>?

@brauner TL;DR: a complete man page for lxd import.
Longer:

One has the data (including backup.yaml) of an old container <container-name> on some media, and a new LXD instance. We can also assume no container in the new instance is currently named <container-name>.
What steps should one take to import the old container into the new instance?

authors: akarelas brauner stgraber yoniy0


text:
LXD 2.18 Broken on Ubuntu 16.04.3 LTS

Required information

Distribution: Ubuntu 16.04.3 LTS
The output of "lxc info" or if that fails:

Kernel version: GNU/Linux 4.4.0-92-generic x86_64
LXC version: 2.0.10
LXD version: 2.18-0ubuntu3~16.04.1
Storage backend in use: lvm

Issue description
Cannot install lxd on ubuntu 16.04.3 LTS with following error:
The following packages have unmet dependencies:
lxd : Depends: liblxc1 (>= 2.1.0~) but 2.0.8-0ubuntu1~16.04.2 is to be installed
Steps to reproduce

sudo apt-get install --yes --quiet --target-release=xenial-backports lxd

Oh crap, fixing.

Fix uploaded to the Ubuntu archive for 16.04 and 17.04, package is building now and should get published to the archive within the hour.

Sorry about that, my text system happened to have the more recent liblxc so I didn't catch the issue...

thx!

authors: stgraber tpouyer