nixos-unstable channel hasn't updated in over 2 weeks

nixos-unstable appears to be stuck at 2d8cfe76a9e4f05e391d30f1654d45dee5993b8a from April 13th. nixos-unstable-small is a little more up-to-date, but also lags 7 days by now.

That's because all installer tests are failing: http://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents

For some reason installer tests are building glibc, which shouldn't happen. @wkennington @lethalman @vcunat  thoughts?

@domenkozar why not?

Because installer doesn't have access to networking as we want to support offline installs.

It definitely shouldnt be building glib
On Apr 27, 2015 9:21 AM, "Domen Kožar"<EMAIL_ADDRESS>wrote:

Because installer doesn't have access to networking as we want to support
offline installs.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/7589#issuecomment-96730102.

It isn't building glibc but glibc-locales.

It isn't building glibc but glibc-locales.

Then maybe it's related to 650492c5c87b4a7d4ab2afc3502e3656a4ac4e0a? @edolstra?

Yes, looks likely, although the glib leak must be due to something else.

Oh right yeah, definitely that change
On Apr 27, 2015 10:08 AM, "Vladimír Čunát"<EMAIL_ADDRESS>wrote:

Yes, looks likely, although the glib leak must be due to something else.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/7589#issuecomment-96742589.

It seems like it would make the most sense for the installer tests not to
install them as well so as not to waste time and temporary space. It does
raise the question about putting them in the iso though, I think that's
probably a good idea for the graphical one. Maybe even the minimal.
On Apr 27, 2015 10:10 AM, "William Kennington"<EMAIL_ADDRESS>wrote:

Oh right yeah, definitely that change
On Apr 27, 2015 10:08 AM, "Vladimír Čunát"<EMAIL_ADDRESS>wrote:

Yes, looks likely, although the glib leak must be due to something else.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/7589#issuecomment-96742589.

It's not entirely obvious why this happens, given that both the installation CD and the target configuration include modules/profiles/minimal.nix (and thus should get the same Glibc locales).

nixpkgs-unstable is stuck at march 22.
should I just switch to nixos-unstable for nixpkgs?

Ah, that seems caused by de0f122b016c, as Hydra claims to miss lib.tests, but I don't yet see what's the problem in there.

nixos-unstable is still stuck at the same commit, despite the fixes done so far... so reopening.

The jobset hasn't even evaluated since the fix was pushed ;-)

What do you mean?
This evaluation: https://hydra.nixos.org/build/21847931
.. contains this fix: 19366a10fcfa33acc1d150e6815cc49bd1a59988
... yet, the installer tests are still failing, right?

Yes it has, recent nixos-install changes broke the tests:
machine# setting root password...
machine# Enter new UNIX password: Retype new UNIX password: passwd: Authentication information cannot be recovered
machine# passwd: password unchanged
machine: exit status 10
machine: output:
error: command `nixos-install < /dev/null >&2' did not succeed (exit code 10)
command `nixos-install < /dev/null >&2' did not succeed (exit code 10)

Could it be caused by 7b37a5f168706db5efa33599354f5c1967ac4c51? @Jookia?

Hopefully fixed in ff88f4bcda606d9a47f807b773749280998e64ac

Ah, I got confused by bluescreen303, thinking this issue is about nixpkgs-unstable and not nixos-unstable. In nixpkgs the lag is much worse, but it doesn't depend on nixos tests...

On 04/30/2015 02:48 AM, Domen Kožar wrote:

Hopefully fixed in ff88f4b
https://github.com/NixOS/nixpkgs/commit/ff88f4bcda606d9a47f807b773749280998e64ac

I actually have no recollection of changing that given I wasn't sure
exactly why it was there. I must've gone over that patch at least a
dozen times too but only checked the part I intended to change.
Sorry everyone!
Jookia.

The very bad consequence of all this is the fact that most of development has now shifted to the staging branch. We must kick staging I believe. @edolstra ideas?

@lethalman I don't understand. Why would development shift to the staging branch? And what does that have to do with the unstable channel?

@edolstra nothing with the unstable channel but with delayed hydra builds in general. The staging branch is not merged into master since 6 weeks. I've just had a PR against a staging branch because of GNOME instead of master, and that's only a recent contribution.
No wonder there are many other updates in staging that should have gone to master instead but forced by the fact that a dependency has been updated only in staging.

The nixpkgs-unstable channel should update once the last ~4k jobs finish in the evaluation, as the critical ones succeeded http://hydra.nixos.org/build/21861946#tabs-constituents

Done


Typo in replicalimit-param.yaml fixed.

Issue fixed: The word 'namspace' had a typo and its fixed now.

/assign @SataQiu for approval.

/kind bug

/remove-language ar

/remove-kind bug

Hi @rohan-kapse , thanks for your contribution, but the content of this PR is duplicated with the previous #44188, maybe you can help to review that PR?

That PR is for en content and this one for zh-cn

Fixes: #44192

Hi @rohan-kapse , thanks for your contribution, but the content of this PR is duplicated with the previous #44188, maybe you can help to review that PR?

That PR is for en content and this one for zh-cn

Hi @rohan-kapse , thanks for your contribution, but the content of this PR is duplicated with the previous #44188, maybe you can help to review that PR?

That PR is for en content and this one for zh-cn

Yes, my mistake. I saw 3 PR with same content.

Thank you for your contribution. However, it seems that this pull request is a duplicate of #44193. In such cases, the earlier raised PR has a precedence. Thanks for your understanding.
So this will be closed.
/close


TypeError: '<' not supported between instances of 'list' and 'int'

how to fix?

Can't reproduce the error. It works great on colab.
Have you used the code from the readme page?
from be_great import GReaT
from sklearn.datasets import fetch_california_housing

data = fetch_california_housing(as_frame=True).frame

model = GReaT(llm='distilgpt2', batch_size=32, epochs=50)
model.fit(data)
synthetic_data = model.sample(n_samples=100)

If yes, please try to reinstall the be_great and restart your jupyter notebook. Plus, I suggest deleting files checkpoints.
Hope it helps.

also: https://github.com/kathrinse/be_great/issues/12

oh, training started, thank you a lot(honestly, I've tried a couple of reinstallations)

happy to read it, if you have more questions, do not hesitate to ask :)


Missing stake pool

I recently registered a stake pool under the TREES ticker, but it does not show up in Daedalus.
It works in Yoroi, ADAPools (https://adapools.org/pool/010135d6c273b169481091d1b1486ec8e21b978de354c1572f3c4429) and other sites.
I recently discovered that this ticker was used already and retired
https://adapools.org/pool/b98514bb7c8fe8efaa6762d6ae811ad2fbb783653f7af1aba12ba201
I'm guessing that Daedalus may be filtering out my stake pool because it shares a ticker with a retired one?

Thank you for contacting us @AJFunk  . We will check this and get back to you.

@AJFunk did you make sure your stake pool is listed on SMASH?
You can call the Smash-Server like:
https://smash.cardano-mainnet.iohk.io/api/v1/metadata/<poolid>/<metahash>

Replace the with your Pool-ID in hex or bech format and with your Meta-Hash in hex.

If it isn't then Daedalus won't show it.

After doing some more digging, I think the issue is on my end. I updated to pool metadata.json, but I did not create a new metadata hash and resubmit my registration certificate with the updated hash.
Thank you for taking a look!


Problem search with "date type of field"?

I have Date field.
Ex: ISODate("2015-08-22T00:00:00.000+0000").
But I can't search with this.
Please help m.

Closing as duplicate of #121. Not yet possible.


add parsers for tsv and other delimited text

I believe it would be useful to abstract out the parsing and formatting of d3.csv to allow for tab separated texts and perhaps other *sv's.
I've created a quick hack of d3.tsv here:
https://github.com/vlandham/d3.tsv
It uses almost the same code as d3.csv, but instead of hardcoding the separation character, you pass it into the format and parse functions.
Would it be useful to attempt to bring this into the main code base? If so, d3.csv could be modified slightly to use the same code and just pass in a comma.
Any suggestions on what the general parsing code should be called and where it should live so that d3.csv and d3.tsv could share it effectively?

Supporting TSV would be nice, yes. But isn't the behavior slightly different depending on the separator? For example, with CSV, you have to quote commas but you don't have to quote tabs, while with TSV, it's the opposite? I suppose that doesn't matter for parsing, but it would require different d3_formatValue implementations depending on the separator.


SQLite - To create NOT NULL column without DEFAULT value

There is an error in SQLiteAdapter that creates the columns as NULL despite having indicated the field as NOT NULL. Currently, the only way to create a NOT NULL field is to specify a DEFAULT value for that column.
With this change, it is allowed to create a NOT NULL column without indicating its DEFAULT value.
In order to allow for backward compatibility, this change will cause SQLiteAdapter continue to create a column as NULL by default when it is not specified whether it is null or not.

The SQL statements generated when creating the columns are correct when phinx migrate is executed.
The test is not successful because the MockAdapter returns NULL when requesting getAdapter()->getAdapterType.
The condition in Table.php does not run because getAdapterType is not equal to sqlite.
What to do to successfully pass the tests?

tests failing indicate that there is some bc issue here maybe.


disable config aggregation in ap-northeast-3

what

Disable AWS Config aggregation in ap-northeast-3

why

Config aggregation is not supported in this region

references

AWS Docs

/test all

/test all


Blank screen till MathView render content

I am using 5 MathViews on single screen. Screen remains blanks till these MathViews render content.
Is there any way that I can get callback when MathView rendered content, so that loader can be seen until MathView render content ?

I think you can treat the MathViews as regular webViews in this scenario, and set WebViewClients on them.


[Bug]: 500 No authorization token was found during PUT requests

Relevant scope
Deployed demo
Description
Currently if you try to do a PUT requests, API will answer you "No authorization token was found" with code 500.
At first, the authorization header in token is specified (see screenshot: https://ibb.co/x36vs2z)
At second, even if token not specified, I expect form API one of those errors:

400 Bad Request (if we consider missing Authorization as malformed request)
401 Unauthorized (if we do not care of token was not specified or not but sure that system cannot authorize user)

Can you, please, check the API and clarify what is wrong in my request and UI get this error.
Request params:
method: PUT
url: https://conduit.productionready.io/api/user
headers:   Authorization: Token {token}
body<EMAIL_ADDRESS>

Hey @concise-studio,
Thanks for pointing out this bug! I can reproduce it.
It's due to server redirection: the new API is hosted on https://api.realworld.io but there is a redirection to it from https://conduit.productionready.io to support existing implementations.
I don't have direct access to https://conduit.productionready.io, so I can't guarantee when I'll fix it.
I encourage you to use https://api.realworld.io/api (being used under the hood). I'll open an issue to update the documentation accordingly.
Please change the URL of the image to https://conduit.productionready.io/images\smiley-cyrus.jpeg as https://realworld-temp-api.herokuapp.com has been shut down a few days ago.
I'll open another issue to fix such a link in the new API as well.

Thank you, I switched the API Url and it works now


Is it possible to make msgraph.Group a hashable type?

I see many fields on the Group struct are pointers to slices. Is this to ensure the value can be used as a key in a map?
The Group value is something that would be fit for caching. There are a few fields whose types do not allow values of type Group to be hashable for some implementations of an LRU cache. For example, []GroupType and []GroupResourceBehaviorOption.
Since many slice fields are already pointers to a slice, is it possible to convert those remaining fields' types to pointer to a slice, so that Group may be used as a key in a map?
Also, the GroupsClient returns not a slice of group pointers []*Group, but a pointer to a slice of groups *[]Group? Is this intentional as well?

Hi @maxsokolovsky, thanks for the questions.
The use of pointers in the model structs is generally to play nice with Go's json marshaler. Behavioral differences between json null, zero values and omitting a field vary wildy between APIs and even between fields on the same object.
Some fields that are not pointer references are likely holdovers and can probably be updated. You're welcome to open a PR for these 👍
Clients that return pointers are intentional, since these could be nil in the event of an API error. However, if a client method returns a nil error, then the result can be reasonably expected to be non-nil.

@manicminer, thanks for your response! I will open a PR with those holdovers fields updated to be pointer types!
About the last part - since clients return collections of things (slices), the first returned value doesn't have to be a pointer type, and can be nil in case of an error, since the default empty value for a slice of anything is nil. Would it also be more memory-efficient to copy a []*Group rather than *[]Group across functions?


Merge with existing manifest.json?

Any ideas on how to merge with an existing manifest.json generated by other processes?

Would doing:
{
  cache: JSON.parse(fs.readFileSync(...))
}

be enough or should we add an options to handle that?
cc @gmac

This is actually a fairly well-defined use case in multi-compiler architectures where we want a single manifest that documents output from all compilers. This can be achieved by passing a shared cache object to all plugin instances, such as:
var manifest = {};
var compiler1 = { ..., plugins: [ new WebpackManifestPlugin({ cache: manifest }) ] };
var compiler2 = { ..., plugins: [ new WebpackManifestPlugin({ cache: manifest }) ] };

Note that this pattern requires a single object instance to be shared; the system won't work as expected if you pass unique object clones to each plugin instance.

@gmac Yeah I got that, but do you think the code I posted above is alright to handle merging with an existing manifest.json in the case of a single compiler?

@mastilver yep, looks right to me!

module.exports = {
    // ...
    plugins: [
      new ManifestPlugin({
        cache: JSON.parse(fs.readFileSync(path.join(__dirname, 'manifest.json'))
      })
    ]
};


Try to shorten

https://github.com/sindresorhus/awesome/pull/1794#issuecomment-674479215

Does not seem to run upon a PR which kinda defeats the purpose?

I could be wrong but you may want to try:
on:
  pull_request:
    branches: [main]

or
on: [push, pull_request]

https://docs.github.com/en/actions/reference/events-that-trigger-workflows#example-using-a-list-of-events


Bar plots with negative values.

Support bar plots with negative values.

Hi @v0dro,
I want to work on this issue, but would need some guidance, if you can help.

Sure. What do you want to know?

Sorry @v0dro for replying late. Can you please give an insight of the code which is creating the problem.
Thanks.


Add the ability to update memory, cpu, and priority of job types via the UI

Once we move to Seed, the job type resources will not be able to be updated through the Scale REST API.
The following job type fields will be editable through the REST API: is_active, is_paused, configuration, priority, max_scheduled, max_tries, icon_code

Given that this won't be possible in v6, is it still necessary for the legacy UI then?

I would vote no, but I don't know what Chris would say.

Verdict is we need to update memory, cpu, and max_tries via the UI


Remove splitDocs

See https://github.com/elm-lang/package.elm-lang.org/issues/98. It seems that redundancy is now removed, but the docs/*.json files are still being produced (but never used). This PR gets rid of them for the future.
After accepting this PR here, the FromJSON instance for Type over in https://github.com/elm-lang/elm-compiler should be dead code. Removing it then, would also fix this issue: https://github.com/elm-lang/elm-compiler/issues/1076.

Cool, thanks!

Can you do the elm-compiler part tomorrow or later? Don't want to clutter up 0.16 things.


Fix for issue #1972: Fixed typecasting, and added more debug logging.

I'm not sure if this is adequately tested...   Feel free to just use it as a POC if its wrong.
Fixes: #1972

So my environment had had an error with an extra ` after my email address, which I fixed, but DCO seems to be remaining confused.   Sorry about that...  LMK if I'm doing something wrong.

After playing around with some other code so I could POC java deps, I think I fixed this issue at the wrong end...   I'm still investigating, but it seems like I maybe should have fixed this at the APK end instead of the cyclonedx end.

Seems like I was right the first time based on: syft/pkg/cataloger/kernel/cataloger.go line 117: // note: relationships should have Package objects, not pointers

To fix DCO I usually git reset HEAD~1 and re-commit with -s, then force push

Hmmmm.   So...  the itest was failing because the decode is lossy, as far as I can tell.   Looking at: syft/formats/common/cyclonedxhelpers/decoder.go  it looks like the /FIXME in line 230 is a red herring, I don't think there's anything to fix there (cyclonedx relationships imply a type, probably, though there might be a broader discussion of what sort they imply)
I fixed this piece, but now we're getting to the fact that package_ids are changed in the encode/decode process...  The current test redacts the ids for individual packages, so I could go in and redact the ids in the dependencies section as well, although it feels a bit gross?  I'm a bit curious why in the decoder we're not trying to preserve IDs?  is it because you can't rely on them being present and/or syft formatted?  Is there a better way?
Still getting the weird DCO behavior on commit a4...  is it because I used amend instead of rebase?  (I did amend because otherwise it was trying to sign off twice with the mistake I made)

@kzantow this seems to be an issue related to PR #1872   after my fix to decoder, your thoughts on if I should just proceed with redacting from the itest given the decision not to proceed with that?

@markgalpin are you able to rebase/squash this to fix the DCO issue?
One way: if you have an upstream remote of this repo (e.g. git remote add upstream https://github.com/anchore/syft.git):
git fetch upstream
git reset upstream/main

re-commit your changes with --signoff and then force-push the new single commit to this branch.
If you could do this, I'd love to help adding a few tests (or you're welcome to)

@kzantow Sorry for the delay, got busy with other work -- I really appreciate the advice you've given.  This commit does most things discussed above, but I need some help figuring out how to suppress the regex in the encode/decode cycle for the dependsOn block.   I haven't been able to figure out a REGEX for it that works quite (admittedly I haven't had a whole lot of time to spend on the project, and next time I get a chance I'll take another stab at it)
And then, yes, any help you have on other ways to test this, I'll gladly take, though it looks like mostly the test cycle is relying on encode/decode itest to catch things.


Confirm alert does not work well with long body

I am trying to use a confirm alert for a disclaimer that a user has to accept or decline. As it is the nature of these things, they are quiet long. This displaces the alert's title and the buttons are not visible anymore.

Here is my code, where lorem is a really long disclaimer string:
            let confirm = Alert.create({
                title: "Disclaimer",
                message: lorem,
                buttons: [
                    {
                        text: "Decline",
                        handler: () => {
                            console.log('Disagree clicked');
                        }
                    },
                    {
                        text: "Accept",
                        handler: () => {
                            localStorage.setItem("isFirstLogin", "false");
                            this.performLogin();
                        }
                    }
                ]
            });

This will be fixed when beta.2 is released. Thanks for the issue!


use sync.waitgroup and mutex for building response

fixes #15

quick benchmark.  LGTM 🔥
first three iterations with fix and next three iterations without fix. ( each iteration have 5 queries in same panel pulling 100K records )


Feature: Add Hook for Web Application Panic

@stevvooe
This PR is for issue email after registry webapp panic #41, improving my previous design (closed).
It use self setting up hooks, to catch panic in web application.
And, send email in hooks handle directly, to no use new http server and handler.
Please help to take a view.
Thanks a lot!

Re-Implementation:

Simplify the writing in config.yml about handlers parameters;
Clear Log Hook functionality, and make hook interface smart in hooks.go. Allow user add hook handling easily in future;
Clear mail interface, via define Mail structure, which only includes necessary mail parameters;
Configure log hook as app method of configureLogHook;

@xiekeyang This is looking a lot better. We may want to review the configuration again, since we won't be able to change that in the future.
Thank you for working to get this in!

@stevvooe Thanks a lot!
Any proposal on configuration or other points, please put up freely.
I'd pay high attention to your viewpoint and improve it.

latest change:

change name from handlers to hooks , in config.yml, configuration.go, and configuration_test.go
change name from email to mail , in config.yml and configuration.go

cc @avinson @RichardScothern @dmcgowan

Would you like the below,
  hooks:
    enable: false
    levels:
      - panic
    type: mail
    mail:
     smtp_host: mail.example.com
     smtp_port: 25
     smtp_login: mailuser
     smtp_password: password
     smtp_insecure: true
     from_addr<EMAIL_ADDRESS>
     to_addr:
       -<EMAIL_ADDRESS>

Let's do the following:
  hooks:
    - type: mail
      levels:
        - panic
      disabled: true
      options:
        smtp:
          addr: mail.example.com:25
          login: mailuser
          password: password
          insecure: true
        from<EMAIL_ADDRESS>
        to:
          -<EMAIL_ADDRESS>
Changes:

hooks must be a list so that multiple hooks can be supported
Note that I changed enabled to disabled, so the default is to have the hook active and it is consistent with other configuration options.
made smtp options a sub-struct
shortened to and from
removed explicit port argument (we use addr everywhere else)
changed to use generic "options" to match other configuration sections (see middleware).

@xiekeyang Also, let's call "login" "username", to match the internal Go functions.

Got it, In progress

Hi @stevvooe
Done.

optimize names and struct in config;
make hook slice type;
make hook and mail design clear;

This looks pretty good @xiekeyang.  Just a few small points.

@RichardScothern @stevvooe
Done in config.yml, 'configuration.go', app.go and mail.go
Thanks for your review.

@xiekeyang This is getting really close. Thanks for working through the feedback.

@stevvooe , is it like following?
mail.go
// mailer provides fields of email configuration for sending.
type mailer struct {
        Addr, Username, Password, From string
        Insecure                       bool
        To                             []string
}

func (mail *mailer) sendMail(subject, message string) error

hooks.go
// LogHook is for hooking Panic in web application
type LogHook struct {
        LevelsParam []string
        Mail        *mailer
}

@stevvooe, @RichardScothern ,
Done. hooks.go, mail.go and app.go
Please help to review it. thanks a lot!

@stevvooe @RichardScothern @noxiouz ,
Any proposal?

@xiekeyang Again, we are close. The actual email format needs to be tweaked. We may also want some documentation for this feature. In particular, we need some documentation around configuration. For this PR, adding TODOs in the docs/configuration.md file would be sufficient, along with an example configuration.

Dear @stevvooe ,
Done. Please Review, thanks.

@moxiegirl PTAL docs.

@moxiegirl  Please help review my docs in this patch, and put up your proposal. I'd improve it if necessary. Thanks a lot!

Fixed. Including,

Set Hooks title H2;
Put the sample first;
Correct description as "The hooks subsection configures the logging hooks' behavior, including a sequence handler such as for sending mail. Refer to loglevel to configure the level of messages printed."

PTAL. Thanks so much.

@stevvooe @moxiegirl
Fixed. Including,

Set Hooks title H2;
Put the sample first;
Correct description as "The hooks subsection configures the logging hooks' behavior, including a sequence handler such as for sending mail. Refer to loglevel to configure the level of messages printed."

PTAL. Thanks so much.

@stevvooe @moxiegirl
It is OK?

@xiekeyang Yes, this PR is ready to go. However, to close out #41, we need to intercept the panic in the web application and emit a panic-level message. I am not sure exactly how to do this with logrus, so I filed https://github.com/Sirupsen/logrus/issues/181.
Either way, I think we are ready to merge this PR, as its useful either way.

@stevvooe
Thanks so much!
I tried via logrus.Panic("xxx"), and found it works correctly.

@xiekeyang It looks like we may need a handler that does a panic-recover:
func panicHandler(handler http.Handler) http.Handler {
    return func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                 // report via logrus (maybe missing functionality from logrus)
                 // Calling logrus.Panic might be sufficient, confirm stack trace
            }
        }
        handler.ServeHTTP(w, r)
    }
}

The above change might be separate PR. This PR already provides email reporting for errors and high log levels.
Let me know how you'd like to proceed.

LGTM

@stevvooe
I use logrus.Panic("Testing Hook message") after configureLogHook, needn't recovery. And it fires hook and mail to work correctly.
Any way, I'd put up best way on another new PR or issue to discuss with you.
About this PR, do you have more proposal, please let me know.
Thanks so much.

@xiekeyang I think I failed to make my point clear. Yes, calling logrus.Panic("Testing Hook message") directly works fine. The original feature request was to catch and report web application panics, which this PR does not yet do.

@stevvooe  Understand.

@stevvooe
Thanks for your great idea!
I set up panicHandle func, wrap it to http handler. And it works correctly.
After app server run, it can capture any panic in code.
in main.go:
app := handlers.NewApp(ctx, *config)
handler := configureReporting(app)
handler = panicHandler(handler)
handler = gorhandlers.CombinedLoggingHandler(os.Stdout, handler)

func panicHandler(handler http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
                defer func() {
                        if err := recover(); err != nil {
                                log.Panic(fmt.Sprintf("%v", err))
                        }
                }()
                handler.ServeHTTP(w, r)
        })
}

@xiekeyang Could you add an example panic trace?

Test Panic Code (ping /v2/)
app.go
func apiBase(w http.ResponseWriter, r *http.Request) {
	...........
    panic("This is test panic")
    fmt.Fprint(w, emptyJSON)
}

hooks.go
func (hook *logHook) Fire(entry *logrus.Entry) error {
	logrus.Info("Capture Hook MSG:", entry.Message)
	..................
}

ping /v2/
@:~/work/src/github.com/docker/distribution$ curl -X GET http://localhost:5050/v2/
curl: (52) Empty reply from server
distribution log
@:~/work/src/github.com/docker/distribution$ sudo docker logs distribution
time="2015-05-23T01:38:24.814652725Z" level=info msg="endpoint local-8082 disabled, skipping" environment=development instance.id=e2de58ef-30c7-4723-b812-cc020e968bf3 service=registry version=v2.0.0-148-g646f4f3.m
time="2015-05-23T01:38:24.814878512Z" level=info msg="endpoint local-8083 disabled, skipping" environment=development instance.id=e2de58ef-30c7-4723-b812-cc020e968bf3 service=registry version=v2.0.0-148-g646f4f3.m
time="2015-05-23T01:38:24.815056702Z" level=info msg="using redis blob descriptor cache"
time="2015-05-23T01:38:24.815199387Z" level=info msg="listening on [::]:5000"
time="2015-05-23T01:38:24.815285002Z" level=info msg="debug server listening localhost:5001"
time="2015-05-23T01:39:42.755201355Z" level=debug msg="authorizing request" http.request.host="localhost:5050" http.request.id=79358f67-3307-45bb-b6eb-d92572ecbd76 http.request.method=GET http.request.remoteaddr="<IP_ADDRESS>:50063" http.request.uri="/v2/" http.request.useragent="curl/7.35.0"
time="2015-05-23T01:39:42.755323184Z" level=info msg="response completed" http.request.host="localhost:5050" http.request.id=79358f67-3307-45bb-b6eb-d92572ecbd76 http.request.method=GET http.request.remoteaddr="<IP_ADDRESS>:50063" http.request.uri="/v2/" http.request.useragent="curl/7.35.0" http.response.contenttype="application/json; charset=utf-8" http.response.duration=2.355878ms http.response.status=0 http.response.written=0
time="2015-05-23T01:39:42.755476974Z" level=info msg="Capture Hook MSG:This is test panic"
time="2015-05-23T01:39:42.755474764Z" level=panic msg="This is test panic"
2015/05/23 01:39:49 http: panic serving <IP_ADDRESS>:50063: &{0xc20803a1c0 map[] 2015-05-23 01:39:42.755474764 +0000 UTC panic This is test panic}
goroutine 10 [running]:
net/http.func·011()
	/usr/src/go/src/net/http/server.go:1130 +0xbb
github.com/Sirupsen/logrus.(*Entry).log(0xc20810aac0, 0x0, 0xc20800bb80, 0x12)
	/go/src/github.com/docker/distribution/Godeps/_workspace/src/github.com/Sirupsen/logrus/entry.go:103 +0x634
github.com/Sirupsen/logrus.(*Entry).Panic(0xc20810aac0, 0xc20816f500, 0x1, 0x1)
	/go/src/github.com/docker/distribution/Godeps/_workspace/src/github.com/Sirupsen/logrus/entry.go:148 +0x7f
github.com/Sirupsen/logrus.(*Logger).Panic(0xc20803a1c0, 0xc20816f500, 0x1, 0x1)
	/go/src/github.com/docker/distribution/Godeps/_workspace/src/github.com/Sirupsen/logrus/logger.go:155 +0xec
github.com/Sirupsen/logrus.Panic(0xc20816f500, 0x1, 0x1)
	/go/src/github.com/docker/distribution/Godeps/_workspace/src/github.com/Sirupsen/logrus/exported.go:102 +0x48
main.func·001()
	/go/src/github.com/docker/distribution/cmd/registry/main.go:281 +0x1c2
github.com/docker/distribution/registry/handlers.apiBase(0x7f19560e1a20, 0xc2080d0ac0, 0xc20801e820)
	/go/src/github.com/docker/distribution/registry/handlers/app.go:536 +0x1ec
net/http.HandlerFunc.ServeHTTP(0xbb45e8, 0x7f19560e1a20, 0xc2080d0ac0, 0xc20801e820)
	/usr/src/go/src/net/http/server.go:1265 +0x41
github.com/docker/distribution/registry/handlers.func·007(0x7f19560e1a20, 0xc2080d0ac0, 0xc20801e820)
	/go/src/github.com/docker/distribution/registry/handlers/app.go:399 +0x114a
net/http.HandlerFunc.ServeHTTP(0xc20811e380, 0x7f19560e1a20, 0xc2080d0ac0, 0xc20801e820)
	/usr/src/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/mux.(*Router).ServeHTTP(0xc20802ee60, 0x7f19560e1a20, 0xc2080d0ac0, 0xc20801e820)
	/go/src/github.com/docker/distribution/Godeps/_workspace/src/github.com/gorilla/mux/mux.go:98 +0x297
github.com/docker/distribution/registry/handlers.(*App).ServeHTTP(0xc20811a280, 0x7f19560e1a20, 0xc2080d0ac0, 0xc20801e820)
	/go/src/github.com/docker/distribution/registry/handlers/app.go:340 +0x337
main.func·002(0x7f19560e1928, 0xc20811eac0, 0xc20801e820)
	/go/src/github.com/docker/distribution/cmd/registry/main.go:284 +0x77
net/http.HandlerFunc.ServeHTTP(0xc2080fcc30, 0x7f19560e1928, 0xc20811eac0, 0xc20801e820)
	/usr/src/go/src/net/http/server.go:1265 +0x41
github.com/gorilla/handlers.combinedLoggingHandler.ServeHTTP(0x7f19560de1f0, 0xc20802c008, 0x7f19560de7e8, 0xc2080fcc30, 0x7f19560e1880, 0xc208055680, 0xc20801e820)
	/go/src/github.com/docker/distribution/Godeps/_workspace/src/github.com/gorilla/handlers/handlers.go:88 +0x1be
github.com/gorilla/handlers.(*combinedLoggingHandler).ServeHTTP(0xc20811e800, 0x7f19560e1880, 0xc208055680, 0xc20801e820)
	<autogenerated>:15 +0xbe
net/http.serverHandler.ServeHTTP(0xc208108480, 0x7f19560e1880, 0xc208055680, 0xc20801e820)
	/usr/src/go/src/net/http/server.go:1703 +0x19a
net/http.(*conn).serve(0xc2080555e0)
	/usr/src/go/src/net/http/server.go:1204 +0xb57
created by net/http.(*Server).Serve
	/usr/src/go/src/net/http/server.go:1751 +0x35e

And mail sends successfully.

@stevvooe
It is OK?

@xiekeyang Looks good. Seems to be doing the right thing.

LGTM!
@dmcgowan @RichardScothern PTAL

@moxiegirl Thanks. Done.

Thanks @xiekeyang. LGTM

LGTM.  Excellent effort @xiekeyang


Build from source code on Cavium Thunder X

I am trying to build ROCK-Kernel-Driver from branch roc-1.6.3 on my ubunu16.04-arm64 server which is running on Cavium Thunder X. The kernel version in Makefile of this repo is 4.11.  Here is my environment :
uname -a
Linux ubuntu 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:06:30 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
Here are my steps：
1.make rock-dbg_defconfig
2.make
3.sudo make modules_install
4.sudo make install
there is no error during making. While when I restart the operating system and select the new kernel, it gets stuck, and the system can't be started. Output of the terminal is as follows:
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
I also want to know that, if I can build other source code successfully  including ROCT-Thunk-Interface, ROCR-Runtime, ROCm-Device-Libs, HCC, HIP, etc, with failure on building ROCK-Kernel-Driver ?
@gstoner

Ps: which branch/tag should I choose when I try to build other source code on my  ubunu16.04-arm64 server including ROCT-Thunk-Interface, ROCR-Runtime, ROCm-Device-Libs, HCC, HIP, etc. thanks
@gstoner

One thing we found you had force Atomic Completer on ( PCIe atomics) one you do this it will boot.

We now have been testing ROCm 1.6.4 with HCC,  working on HIP support now.


Resize images

The output has been changed to 1080p, so the following images need to be created at the appropriate sizes:

logo - 172 x 150
sponsors - 960 x 288

fixed by #2


Test Request: Kong Gateway EE version <IP_ADDRESS>-rc1

What component needs testing with KIC?
Kong Gateway EE
Container image
kong/kong-gateway-dev:<IP_ADDRESS>-rc1
Additional information
No response

As discussed elsewhere and covered in #4657 the validation workflow currently fails for 2.8.x.
Closing until #4657 is resolved.


Got dpkg: warning: downgrading chef from 12.1.0-1 to 12.0.3-1 at knife solo prepare user@host

Before executing knife solo prepare user@host I had installed chef on the host as described in First steps with Chef, i.e by running curl -L https://www.opscode.com/chef/install.sh | bash as root on the host.
However, running knife solo prepare user@host warned that chef had been downgraded.
Should I worry about that?
The only thing I found to be changed on the host was, besides the downgrade, was the file /home/user/install.sh, which I believe is the script that made the install of chef.
Am I right?

What version of chef to you have on your workstation?  Knife-solo should try to
install the same version on the server as you have on your workstation.
<EMAIL_ADDRESS>
Before executing knife solo prepare user@host I had installed chef on the
host as described in First steps with Chef
http://gettingstartedwithchef.com/first-steps-with-chef.html, i.e by
running curl -L https://www.opscode.com/chef/install.sh | bash as root on
the host.
Should I worry about that?
The only thing I found to be changed on the host was, besides the
downgrade, was the file /home/user/install.sh, which I believe is the
script that made the install of chef.
Am I right?
—
Reply to this email directly or view it on GitHub
https://github.com/matschaffer/knife-solo/issues/425.

--
-Mat
about.me/matschaffer

I have:
$ dpkg -l | grep chef
ii  chefdk                                                      0.4.0-1                                             amd64        The full stack of chefdk
$ chef -v
Chef Development Kit Version: 0.4.0
$ chef-solo -v
Chef: 12.1.0.rc.0
$ chef-apply -v
Chef: 12.1.0.rc.0
$ chef-zero -v
4.0
$ chef-client -v
Chef: 12.1.0.rc.0

Maybe my problem is that I did not configured to use the ruby embedded in chefdk, as I already had ruby installed before trying out chefdk. Had a look around:
$ ls -d /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef*
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.0.3
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-dk-0.4.0
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/cheffish-0.9.2
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-provisioning-0.18
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-provisioning-aws-0.2.1
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-provisioning-azure-0.1
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-provisioning-fog-0.12
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-provisioning-vagrant-0.8.1
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chefspec-4.2.0
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-vault-2.4.0
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-zero-1.5.6
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-zero-3.2.1
$ ls -d /usr/local/lib/ruby/gems/2.1.0/gems/chef*
/usr/local/lib/ruby/gems/2.1.0/gems/chef-12.1.0.rc.0
/usr/local/lib/ruby/gems/2.1.0/gems/chef-zero-4.0
$ cat ~/.bash_profile
#eval "$(chef shell-init bash)"

I installed knife-solo with chef gem install knife-solo.
I don't know how chef and chef-zero ended up in /usr/local/lib/ruby/gems/2.1.0/gems/.

Me neither but I suspect that's where knife solo is picking it up. I may even be calling out to 'gem' to get that info which might be why I'm not getting the chefdk version. I'll leave this open to try to ensure that knife always gets the version in the same gem space.


LazyLoaded event never fired

This is my Slick config:
var carouselConfig = {
    infinite: true,
    draggable: false,
    slidesToShow: 1,
    slidesToScroll: 1,
    initialSlide: 0,
    lazyLoad: 'ondemand',
    event: {
        afterChange: function (event, slick, currentSlide, nextSlide) {
            console.log(event, slick, currentSlide, nextSlide);
        },
        beforeChange: function (event, slick, currentSlide, nextSlide) {
            console.log(event, slick, currentSlide, nextSlide);
        },
        lazyLoaded: function (e, slick, img, src) {
            console.log(e, slick, img, src);
        }
    }
};

afterChange and beforeChange events are fired, lazyLoaded event never fired.

@devmark looks like there is just no method for that, do you have a plan to implement that? :)

should be work on version 3.1.6

Yeap, thank you!
On Fri, Jul 22, 2016 at 4:49 PM Mark<EMAIL_ADDRESS>wrote:

should be work on version 3.1.6
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/devmark/angular-slick-carousel/issues/81#issuecomment-234548611,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADlRzjGGNoz5rqC_N2I3nTJyREi4mJ2mks5qYMpQgaJpZM4JA8Yq
.

Hi Devamrk!
In last version from bower there is console output in file*
angular-slick.js:266

*console.log('=lazyLoadedlazyLoadedlazyLoaded');
Is it possible to delete it?)

On Fri, Jul 22, 2016 at 4:57 PM Константин Ваничкин <
<EMAIL_ADDRESS>wrote:

Yeap, thank you!
On Fri, Jul 22, 2016 at 4:49 PM Mark<EMAIL_ADDRESS>wrote:

should be work on version 3.1.6
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/devmark/angular-slick-carousel/issues/81#issuecomment-234548611,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADlRzjGGNoz5rqC_N2I3nTJyREi4mJ2mks5qYMpQgaJpZM4JA8Yq
.

Thanks for report . will del soon


Add Storybook for component design/testing

https://github.com/nismod/irv-jamaica/pull/98 installs the Storybook packages and sets up a default config, with some basic component stories for sidebar components.
https://github.com/nismod/irv-jamaica/pull/120 sets up the docs plugin so that docgen comments can serve as documentation.
https://github.com/nismod/irv-jamaica/pull/121 builds the storybook in GitHub Actions, then tests each story with Playwright. Tests are functions attached to each story, using Jest and Testing Library under the hood. If you're familiar with writing Testing Library queries and user interactions, this should be straightforward to set up. You can see a simple story with tests here: https://nismod.github.io/irv-jamaica/?path=/story/details-featuresidebar--default
https://github.com/nismod/irv-jamaica/pull/102 installs Mock Service Worker, and shows how to mock HTTP requests for components that use the API.
https://github.com/nismod/irv-jamaica/pull/125 and https://github.com/nismod/irv-jamaica/commit/da8eef40df200eb8f46019c77fddc5a8f259c63d publish to GItHub Pages (https://nismod.github.io/irv-jamaica.)

For the initial install, I think I just followed the instructions at https://storybook.js.org/docs/get-started/install.
npx storybook@latest install

I haven't added the data map to the storybook yet (see https://github.com/nismod/irv-jamaica/issues/167.)


Particle export from PhoenixFD for 3ds max

If not Thinking Particles, there is no need to check for both the ext particle interface and ipfSystem - in PhoenixFD we had to create a dummy PFSystem in order to workaround this limitation. The actual ipfSystem is checked before actually being used about 20 lines further.
Also, the built-in 3ds max Alembic export forces us to provide a dummy node as a result of GetParticleGroup() in order for the export to proceed correctly. This is why the returned node does not have to necessarily implement the IParticleGroup interface and should better be checked against NULL.

Thank you, this is a good change!


Add to kubectl plugin kc

Hi sunny0826,
This is an awesome tool! Thanks for your open source contribution :)
It helps us to manage kubeconfig more efficiently.
I submitted a PR https://github.com/kubernetes-sigs/krew-index/pull/2545 to add this tool to krew.
To make this tool to broader users.

As far as I know, the file .krew.yaml is supposed to be a template file, like this https://github.com/rajatjindal/kubectl-evict-pod/blob/main/.krew.yaml
You can refer to https://github.com/rajatjindal/krew-release-bot

Got it, updated.
Please help to add the krew-release-bot action.
PTAL thanks.

Thanks for your contribution


Adding support for elementary OS distro in install script.

Adding support for elementary OS in the installer script.
The script will query the upstream release from the command $ lsb_release -a -u, so, it's now very easy to add support for more forked distros.
I don't know what are the side effects of checking the upstream release for all distros. For that reason, I've restricted this check to elementary OS, which I've been able to test.
I've tested this in elementary OS 0.3 (freya) and it's working just fine.
Credits to Daniel Foré and Cody Garver from elementary OS for helping me out to achieve this.
TL;DR:
We've tested the command in some distros (based and non-based in Debian/Ubuntu) and have achieved a solution that should work across all distros. It'll check for the existince and success of the command lsb_release -a -u to then retrieve the upstream release info.

What do you think of this @jfrazelle ?

sweet this is neat!, ping @tianon

LGTM, thanks for finding this out, its seriously going to make things so much cleaner

No problem! :smiley:
I've edited the first message to give credits to the folks from elementary OS for helping me out. :+1:

@jfrazelle @benmccann
Surely it'd be better if it works across all distros. Let's test in all platforms we can.

How to test your platform
Run the following commands and post their respective outputs here:
$ lsb_release -a
$ lsb_release -a -u

For elementary OS 0.3:
fmoliveira:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	elementary OS
Description:	elementary OS Freya
Release:	0.3
Codename:	freya

fmoliveira:~ $ lsb_release -a -u
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04 LTS
Release:	14.04
Codename:	trusty

Sorry I've accidentaly closed the pull request. Already reopened.

For Ubuntu 14.04:
filipe:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.2 LTS
Release:	14.04
Codename:	trusty

filipe:~ $ lsb_release -a -u
Usage: lsb_release [options]

lsb_release: error: no such option: -u

filipe:~ $ echo $?
2

filipe:~ $ ls /etc/upstream-release/
ls: cannot access /etc/upstream-release/: No such file or directory

filipe:~ $ cat /etc/upstream-release/*
cat: /etc/upstream-release/*: No such file or directory

Please note as the -u argument is unsupported in Ubuntu, the command will put an error number to exit code. This might be a safe way to determine whether the user is running a forked distro or not.

For Linux Mint:
$ lsb_release -a
LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID:	LinuxMint
Description:	Linux Mint 17.2 Rafaela
Release:	17.2
Codename:	rafaela

$ lsb_release -a -u
LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04 LTS
Release:	14.04
Codename:	trusty

$ ls /etc/upstream-release/
lsb-release

$ cat /etc/upstream-release/*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"

Thanks @benmccann ! The upstream release info will make the script work perfectly in Linux Mint.
I'll create some virtual machines with other distros to test them.

For Debian Jessie:
user@debian:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.1 (jessie)
Release:        8.1
Codename:       jessie

user@debian:~ $ lsb_release -a -u
Usage: lsb_release [options]

lsb_release: error: no such option: -u

user@debian:~ $ echo $?
2

user@debian:~ $ ls /etc/upstream-release/
ls: cannot access /etc/upstream-release/: No such file or directory

user@debian:~ $ cat /etc/upstream-release/*
cat: /etc/upstream-release/*: No such file or directory

For Kubuntu 14.04:
kubuntu@kubuntu:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty

kubuntu@kubuntu:~ $ lsb_release -a -u
Usage: lsb_release [options]

lsb_release: error: no such option: -u

kubuntu@kubuntu:~ $ echo $?
2

kubuntu@kubuntu:~ $ ls /etc/upstream-release/
ls: cannot access /etc/upstream-release/: No such file or directory

kubuntu@kubuntu:~ $ cat /etc/upstream-release/*
cat: /etc/upstream-release/*: No such file or directory

For openSUSE:
linux@linux:~> lsb_release -a
LSB Version:	n/a
Distributor ID:	openSUSE project
Description:	openSUSE 13.2 (Harlequin) (x86_64)
Release:	    13.2
Codename:	    Harlequin

linux@linux:~> lsb_release -a -u
lsb_release: invalid option -- 'u'

linux@linux:~> echo $?
2

linux@linux:~> ls /etc/upstream-release/
ls: cannot access /etc/upstream-release/: No such file or directory
linux@linux:~> cat /etc/upstream-release/*

cat: /etc/upstream-release/*: No such file or directory

RedHat based distros don't usually have the lsb_release command installed by default, though it's possible to install it.
I haven't tested the command in any RH based distro, but I'm considering the output will be similar to openSUSE's, which isn't Debian based too.

Conclusion
Well, I think we've had enough tests for a good conclusion.
Some distros don't have the lsb_release installed by default. But everything based on Debian seems to have it. The base Debian, Ubuntu and Kubuntu distros don't have the -u argument to print the upstream release, and an error is raised in the exit code of the command. It seems we can trust the command in all distros when it returns zero (no error).
We can do this then:

Check if command lsb_release exists.
Try to set a variable with the output of the command lsb_release -a -u.
If zero is returned, it's safe to assume we've got the Distribution ID and Codename from the upstream distro and we can replace that info in the script variables.
If non-zero is returned, we'll do not touch the variables and let the script run as it would do it today.

I'll change the script and amend this pull request.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:fmoliveira/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

I've amended the changes to the script, following the logic from the "conclusion" comment.
I've also improved the scripting sequence a little bit.
It's working fine in elementary OS and so should too in any other distros. Tests from people using other distros are always welcome anyway. :smiley:

I've amended the changes to the script, following the logic from the "conclusion" comment.
I've also improved the scripting sequence a little bit.
It's working fine in elementary OS and so should too in any other distros. Tests from people using other distros are always welcome anyway. :smiley:

very awesome. this looks good to me

:-1: This will break on Red Hat and derivatives. The -u parameter is invalid:
$ lsb_release -a -u
lsb_release: invalid option -- 'u'

Someone posted a comment here with the following message, but it's already been deleted:
This will break on Red Hat and derivatives. The -u parameter is invalid:

Whoever it was, I'm aware that major distros don't have the -u option and the script is prepared to handle that scenario. Please note we were discussing this in the previous comments to avoid breaking the script in any distro.
Note the following line of code:
if [ "$?" = "0" ]; then

It'll check if the previous command exited with no error before setting new values to lsb_dist and dist_version.
Anyway, we'd be glad if you could test the modified script from my repo and tell us if an error really ocurred in your distribution. Please try either of the following commands:
wget -qO- https://raw.githubusercontent.com/fmoliveira/docker/master/hack/install.sh | sh

or:
curl -o- https://raw.githubusercontent.com/fmoliveira/docker/master/hack/install.sh | sh

If you've any further questions please do not hesitate posting here. We're to help. :+1:

One point for improvement: We could do all the string manipulation stuff after this validation for better readability, instead of doing both the check and the string manipulation in one line. I'll do that and amend this commit.

Someone posted a comment here with the following message, but it's already been deleted:
This will break on Red Hat and derivatives. The -u parameter is invalid:

Surely we're concerned about major distros. We're aware that major distros don't have the -u option and the script is prepared to handle that scenario.
Please note the following line of code:
if [ "$?" = "0" ]; then

It'll check if the previous command exited with no error before setting new values to lsb_dist and dist_version.
Anyway, we'd be glad if you could test the modified script from my repo and tell us if an error really ocurred in your distribution. Please try either of the following commands:
wget -qO- https://raw.githubusercontent.com/fmoliveira/docker/master/hack/install.sh | sh

or:
curl -o- https://raw.githubusercontent.com/fmoliveira/docker/master/hack/install.sh | sh

If you've any further questions please do not hesitate posting here. We're to help. :+1:

One point for improvement: We could do all the string manipulation stuff after this validation for better readability, instead of doing both the check and the string manipulation in one line. I'll do that and amend this commit.

Based in the last comment, I've seen a point for improvement.
Instead of doing the -u check and string manipulation all in one line, we should split them in separate lines to avoid piping the error to the next commands. This will automatically improve readability.
I'll do that and amend this pull request.

I've amended this pull request with changes suggested in the previous comment.
The lsb_release -a -u command will be ran once to verify if the options exists, before proceeding to format the output.
Also, the script is not setting a variable with the command output anymore because it'd remove newlines and break grep usage. In the previous commit it relied in replacing newlines with separators and cutting them by indexes, but it'll break if the order of Distribution ID and Codename in the command output changes someday.

I've amended this pull request with changes suggested in the previous comment.
The lsb_release -a -u command will be ran once to verify if the options exists, before proceeding to format the output. This will avoid piping the error to the next commands.
Also, the script is not setting a variable with the command output anymore because it'd remove newlines and break grep usage. In the previous commit it relied in replacing newlines with separators and cutting them by indexes, but it'll break if the order of Distribution ID and Codename in the command output changes someday.

@fmoliveira Yes, I commented, but deleted it as soon as I realised you'd already dealt with the issue. My bad for commenting without properly reviewing the code. :+1:

Oh, I see @Djelibeybi ! No problem! Extra caution is always good, especially when dealing with an important script such as the installer itself!
Thanks for pointing your concerns anyway, you've made me think in the latter improvement that I've amended. :wink:  :+1:

Worked great on my eOS Freya, thanks. I was getting the "not easily detectable" error message.
:shipit:

Also working on my Linux Mint 17.2 Rafaela. Thanks!

@fmoliveira looks like this needs a rebase

Ok @thaJeztah I'll do that!

Seems like Linux Mint 16 Petra doesn't have the -u option. Does this mean, it won't be install-able?
$ lsb_release -a -u
Usage: lsb_release [options]

lsb_release: error: no such option: -u

Thanks for warning @sudohippie , I'll create a VM to test what we can do for Petra.

@fmoliveira sorry, needs a rebase!

Ok @tiborvass , I'll do that very soon and amend this pull request. Thanks!

@sudohippie @thaJeztah @tiborvass
I've created a Mint 16 VM and the -u option really doesn't exist. I'm trying to find an alternative solution for this case.
I'll analyse this before rebasing my pull request.

@fmoliveira can you fall back to the solution in https://github.com/docker/docker/pull/14991 on Linux Mint 16? I would test, but only have Mint 17.2 installed currently.

@fmoliveira, @benmccann  - Looking at the download-able versions on Linux Mint website, it seems like Petra 16 has been discontinued. Not sure if this should be supported. I am planning to move to 17.2 now.

I'll analyse this issue before rebasing my pull request

Alright. Maybe should consider merging this PR at some point, and improve further in a follow-up.

it seems like Petra 16 has been discontinued. Not sure if this should be supported

Good point; we should definitely be careful not to try and fix every version out there, especially if it's deprecated. Users can still add the repo manually.
ping @tianon for thoughts (perhaps ideas for better handling of the -u) :smile: (would love to see this move forward :+1:)

@benmccann Unfortunately the file /etc/upstream-release/lsb-release or directory /etc/upstream-release as mentioned in #14991 doesn't exist in Mint 16.

@thaJeztah I get your point. You're absolutely right, we'll already improve support for several distros.
In Mint 16 the script result just won't change, but surely we could improve further if needed. Good point at Mint 16 being discontinued.
I'll rebase this today and amend the PR.

@fmoliveira :+1: great! Fwiw, @tianon is "leading" in this area, but I just wanted to avoid having this PR open for weeks, only to 'tweak' things (while it is already a good improvement)

this is awesome :) so nice to see everyone working together ;)
i think we just need a rebase then we can get this in and add support for other things in seperate PRs so this can be in for the release ;)

wdyt?

Oh nice, scraping this information directly from the LSB data is an excellent touch! :+1:

Sure @jfrazelle . I'll rebase this tonight (BRT, just a few hours from now) and amend it so we're able to merge. :)
Thanks for your thoughts @tianon !

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:fmoliveira/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~10
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

Thanks a million everyone for helping us to test this script. I've just rebased it.
The script is fail-proof for distros which doesn't have the -u option. If this still won't work for your distro, please open a new issue.
ping @jfrazelle @benmccann @Djelibeybi @fabioxgn @arner @thaJeztah @sudohippie @tiborvass @tianon

:+1:

:+1:

:+1:

LGTM great work all!
ping @jfrazelle @tianon for review

LGTM

ping @tianon for any last minute words/approval :)

:tada: great work!
@calavera think you want this?

Thanks everybody for the support in testing and merging this! :tada: :tada:

thank you for making something super exstensible!!!
On Wed, Aug 5, 2015 at 4:35 PM, Filipe Oliveira<EMAIL_ADDRESS>wrote:

Thanks everybody for the support in testing and merging this! [image:
:tada:] [image: :tada:]
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/15001#issuecomment-128183735.

 ;)

You're welcome @jfrazelle ! ;)

You're welcome @jfrazelle ! ;)
It rocks working with all of you!

Sorry for the delayed response, but it looks like Cumulus Linux doesn't work as the '-u' option isn't supported for lsb_release (same as what was reported with an older version of Mint).  That sucks as I liked this fix a bit more than dragging out the debian line to include more and more forks.

cherry picked into #15091

@gospo I see. It's a pity the LSB check won't work for Cumulus. I suggest you to open a new issue to discuss with more people about ideas to solve this. There are some stuff I'd ask to try to help but this isn't the ideal place.

Closes #14999.


Update continuous-verification-faqs.md

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: \

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://672285c2790ff13af585086a--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://673526a0d49d516e15db1cd7--harness-developer.netlify.app


Mapping HealthcareProvider::DepartmentSpecialty

[30-Jun 16:05] Jorn Duwel
Is het wel logisch dat AfdelingSpecialisme op de HealthcareProvider Organization.type staat en niet op de Location.type?
[30-Jun 16:10] Jorn Duwel
Hoe ik er op kom: als je de Example op zibs.nl omzet naar FHIR, maakt hij zowel een Location en een Organization.  Nou nee niet per se, maar óók niet van een Organisatie lijkt me. Dus de vraag is waar past hij het best denk ik

Agreed that DepartmentSpecialty does not map neatly on Organization.type as well as Location.type.
One, maybe important, difference is that Location.type has an extensible binding to ServiceDeliveryLocationRoleType while Organization.type has an example binding. Therefore, our COD016-VEKT codes are easier mapped to Organization.type. No need for a very big ConceptMap to map codes.
So I think I am in favor of keeping the mapping of DepartmentSpecialty on Organization.type.

I actually think that COD016-VEKT (https://www.vektis.nl/standaardisatie/codelijsten/COD016-VEKT#inhoud) has lots of overlap with http://hl7.org/fhir/v3/ServiceDeliveryLocationRoleType/vs.html
So I would actually consider that an argument FOR mapping DepartmentSpecialty on Location.type.
Is that easy? No not at all, but is 'easiest' a good reason?
However, COD016-VEKT is actually a 'zorgverleners'-codelist and not a 'zorgaanbieders'-codelist, it talks about persons, not either organizations or locations. So maybe that would be a zib-ticket?

I think it's hard to say something in general about this. Organization is a hierarchical concept; it's perfectly possible that a large organization has a specialized branch with multiple locations. In this case you would get an Organization with a specialty with multiple Location resources. In other cases, it is the location that represents a specialty of an Organization. And in other situations, an organization has multiple locations but a specialty is found at some of them.
The zib just doesn't care; every physical location is a zib HealhtcareProvider instance. In our mapping, we split it over two resources. From this viewpoint, both the Location and the Organization are guaranteed to offer the specialty, but it's not guaranteed that either the Location or the Organization offers the specialty. However, I think it makes sense that a zib instance will be as close to the specialism as possible, thus that the zib represents one location of an organization or division that offers the specialty. In this case Organization will be the correct place and not Location (because there might be other locations). In other words: when the zib represents a location that is the only place that offers that specialty, the rest of the elements will probably represent that specialty as well. For this reason, I think Organization is the best (or least bad) mapping and not Location.

@jduwel ,

However, COD016-VEKT is actually a 'zorgverleners'-codelist and not a 'zorgaanbieders'-codelist, it talks about persons, not either organizations or locations. So maybe that would be a zib-ticket?

That feels worthy of a zib ticket/question to see if there is a more appropriate list of DepartmentSpecialty. Although I believe the Vektiz list contains some relevant codes. Also supported by this ticket: https://bits.nictiz.nl/browse/ZIB-464 that states: "De Vektislijst is een combinatie van specialismen, typen zorgverleners, maar ook instellingen als verpleeghuizen staan erin."
Moreover, I can follow the reasoning of Pieter.

Re: the ValueSet, thanks for the ticket. So that has probably already been discussed.
I think Location.type is the least bad mapping. From a zib perspective I can follow Pieter's logic, so in a 'zib-only' world, we could get away with Organization.type. However, isn't it the point of FHIR to allow for a more broad data exchange? The granularity of DepartmentSpecialty matches Location.type better then Organization.type, so in a more broader context I would expect the data to be there.

Likely, I will now be swearing in the church: what of mapping them to both elements?

Meeting conclusion. least bad option: only map in Organization.type. Location only goes about the physical location. Also noteworthy comment in the Location spec: "Note: Wards/departments are not part of this structure - these would form part of the Organizational Hierarchy." The Vektiz valueset is too broad to purely map on Location.type.
For now, we will close this issue and live with the status quo.


Replace tensorflow-cpu usage with tensorflow

The tensorflow-cpu package does not support MacOS or non-x86 hardware. Replacing the tensorflow-cpu python package requirement with the tensorflow meta package should enable the bazel build and the dependent python scripts to be used on those platforms.
BUG=#2367, #1781

bazel build tensorflow/lite/micro/examples/micro_speech:audio_preprocessor not working on macos with the patch

Thanks @kismeter. Could you provide output log?

Thanks @kismeter. Could you provide output log?
here's the logs
`
tflite-micro % bazel build tensorflow/lite/micro/examples/micro_speech:audio_preprocessor

Extracting Bazel installation...
Starting local Bazel server and connecting to it...
ERROR: Traceback (most recent call last):
File "/private/var/tmp/_bazel_alpha/bfbcf8515a0c85a3ab85982eec0435fb/external/tensorflow_cc_deps/BUILD", line 7, column 16, in
hdrs = glob(["_site/tensorflow/include/"], allow_empty=False, exclude_directories=1),
Error in glob: glob pattern '_site/tensorflow/include/' didn't match anything, but allow_empty is set to False (the default value of allow_empty can be set with --incompatible_disallow_empty_glob).
ERROR: /private/var/tmp/_bazel_alpha/bfbcf8515a0c85a3ab85982eec0435fb/external/tensorflow_cc_deps/BUILD: no such target '@@tensorflow_cc_deps//:cc_library': target 'cc_library' not declared in package '' defined by /private/var/tmp/_bazel_alpha/bfbcf8515a0c85a3ab85982eec0435fb/external/tensorflow_cc_deps/BUILD (Tip: use query "@tensorflow_cc_deps//:*" to see all the targets in that package)
ERROR: /Users/alpha/tflite-micro/python/tflite_micro/signal/BUILD:283:23: no such target '@@tensorflow_cc_deps//:cc_library': target 'cc_library' not declared in package '' defined by /private/var/tmp/_bazel_alpha/bfbcf8515a0c85a3ab85982eec0435fb/external/tensorflow_cc_deps/BUILD (Tip: use query "@tensorflow_cc_deps//:*" to see all the targets in that package) and referenced by '//python/tflite_micro/signal:ops/_window_op.so'
ERROR: Analysis of target '//tensorflow/lite/micro/examples/micro_speech:audio_preprocessor' failed; build aborted: Analysis failed
INFO: Elapsed time: 27.010s, Critical Path: 0.10s
INFO: 1 process: 1 internal.

Fetching repository @@tflm_pip_deps_tensorflow_macos; starting
`

Hi @kismeter, Is it working on Mac OS now?

Hi @kismeter, Is it working on Mac OS now?

@mansnils build passed.
Running audio_preprocessor crash on apple silicon macOS due to other issue.


[chip-test] chip_sw_entropy_src_cs_aes_halt

Test point name
chip_sw_entropy_src_cs_aes_halt
Host side component
No response
OpenTitanTool infrastructure implemented
No response
Contact person
martin-lueker
Checklist
Please fill out this checklist as items are completed. Link to PRs and issues as appropriate.

[ ] Check if existing test covers most or all of this testpoint (if so, either extend said test to cover all points, or skip the next 3 checkboxes)
[ ] Device-side (C) component developed
[ ] Bazel build rules developed
[ ] Host-side component developed
[ ] HJSON test plan updated with test name (so it shows up in the dashboard)
[ ] Test added to dvsim nightly regression (and passing at time of checking)

estimate 8
remaining 2023-04-04 4

i'll take this for now.
The plan is to just add a top level assertion to check for this behavior.
Most of the edn req test can be re-used, but we want to update that to do reseeds more frequently so we can create a conflict situation between sha3 and aes.

unassigning to work on other high priority tests.

AES tests misconfigure transaction #15642

The only way I can see here to do reseeds is to call it in the dif: dif_csrng_reseed

Is anyone actively working on this test (in case assignees field is not up to date)?

@sriyerg discussed updating the testplan, but I haven't heard any discussion of writing the sv assertion and seeing if we hit it.

Hi Fatih,
I see that @drewmacrae has updated definition very recently.  I think this can be incorporated into chip_sw_entropy_src_csrng, with the addition of an assertion which insists that when in FIPS mode every output between the entropy_src and the csrng get a four-phase handshake on the cs_aes_halt if before outputting any thing to CSRNG.   There are two tricky parts to consider:

The assertion should not be enabled when the entropy_src is not in FIPS mode.

There may be delays between the AES handshake and the seed output as there is a queue internal to the entropy_src so you could get as many as 4 handshakes before you see your first seed transferred between the two IPs.
Aside from this additional assertion requirement here, there is nothing in the SW setup that is special.

As an alternative approach I posit that this could be moved to the Unit entropy_src testbench:  Given that the entropy_src should never output FIPS mode seeds without this handshake, the mere passing of chip_sw_entropy_src_csrng, would signify that the handshake is working.   The proof then remains to guarantee that the entropy_src always respects this requirement. In the unit testbench one can either:

Disable the cs_aes_halt handshake and confirm that no seeds come out (not very satisfying as it is really just a null test) OR
Add functionality to the scoreboard to track that every FIPS processing event is preceded by a handshake event (which can be captured from the agent generating the handshake).  On can keep a counter of the unclaimed handshakes and trigger a failure if that count goes below zero.

Perhaps It's because I'm no expert at writing elegant assertions, but given the complexities of writing this particular assertion, I think the scoreboarding option 2, is probably the easiest (assuming unit level verification is satisfactory).

The check that every FIPS seed is preceded by a CS_AES_HALT handshake will be added with https://github.com/lowRISC/opentitan/pull/16200
With this we can probably at least simplify the need for the assertion, (or perhaps even no longer need it?).  With chip_sw_entropy_src_csrng the generation of the seeds will imply that something is giving the entropy_src a handshake.  The one check might be to just do a continuity check to make sure that the handshake is actually coming from AES.  What do people think?

Thanks for the detailed description @martin-lueker, and thanks @sriyerg for the recent update on the test plan #16186. I will need some time to digest this (given my unfamiliarity with these IPs). Meanwhile, I am self-assigning the test.

Removing myself from the assignment, as I don't think I will be working on this soon.

I think we definitely want to cover this for M2.5. Whether this should be done as a TLT or block-level tests for entropy_src and csrng, we shall see. It's definitely not related to the aes block. Instead, csrng features an internal aes engine and this TLT is about the synchronization of this engine with entropy_src.

Triaged for csrng, https://github.com/lowRISC/opentitan/labels/Priority%3AP2 for M2.5 SGTM.

Effort estimate for M2.5 captured in entropy source:

estimate 8

This feature involves entropy_src and csrng. It can be tested at the block level with assertions (which can be active in block- and top-level tests):

entropy_src may run its SHA3 module (mostly the Keccak round) only while cs_aes_halt request (which entropy_src controls) and acknowledge (which csrng controls) are high.
csrng may run its AES module only while cs_aes_halt request or acknowledge are low.

(There are a few other assertions, such as that acknowledge may not drop before request drops, but those can be covered by generic push/pull interface assertions.)
I've added an assertion for (1) to entropy_src and have to report that entropy_src violates this condition. The condition essentially is only guaranteed when entropy_src triggers the final SHA3 absorbing process through sha3's process_i. There are other scenarios in which a Keccak round is run (triggered through keccak_round's run_i input) and for which entropy_src does not request cs_aes_halt. These scenarios can be identified based on the states of entropy_src's main FSM:

continuous health tests (state ContHTRunning);
firmware override mode (states FWInsertMsg, Sha3Prep (after FWInsertMsg));
startup (states StartupPhase1, StartupPass1, StartupFail1).

(I've also seen the assertion fail in the states Idle -- as a consequence of getting disabled during an operation -- and AlertHang, but I suspect those are the effect of one of the aforementioned scenarios.)
I've tried to fix these scenarios in entropy_src's main FSM. However, this led to:

cs_aes_halt request being high much more often/longer than it has to be, during firmware override mode, therefore adding a risk to delay or even stall CSRNG operation;
entropy bits from the AST noise source getting dropped, while waiting for cs_aes_halt to get acknowledged.

I think entropy_src could be changed to always perform a cs_aes_halt handshake before it runs its Keccak round. However, I think properly implementing this would require intricate RTL changes, a reorganization of how entropy_src's SHA3 instance is controlled in concert with the disabling mechanism, the firmware override interface, and the cs_aes_halt handshake, and a careful evaluation of what this means for dropping raw entropy bits (and therefore manipulating entropy sampling) or how that could be prevented with appropriately sized buffers and an upper bound on cs_aes_halt acknowledge after request.
I think such changes are out of scope for this release. This means Earlgrey's power distribution has to be dimensioned such that entropy_src's SHA3 and csrng's AES can run at the same time. This should not be difficult as csrng's AES has only around 10 kGE that can draw power (which is many factors smaller than, e.g., OTBN). We should make sure the maximum power test covers this scenario.
I'll create a draft PR (to be closed immediately) with the assertions I wrote and the RTL changes I tried and link the PR here.
I suggest we close this issue with a PR that removes the chip_sw_entropy_src_cs_aes_halt testpoint from Earlgrey's testplan and create a new https://github.com/lowRISC/opentitan/labels/Type%3AFutureRelease issue that tracks the full implementation of cs_aes_halt in entropy_src.

Many thanks @andreaskurth for investigating this and reporting back!
I fully agree with you that changing the design to always halt AES before running the SHA3 is out of scope for this release.
What I am wondering is whether running a single SHA3 round here and there while CSRNG is busy might be okay. Do you have an idea how often this happens and how far away the individual run_i pulses are spaced?

What I am wondering is whether running a single SHA3 round here and there while CSRNG is busy might be okay. Do you have an idea how often this happens and how far away the individual run_i pulses are spaced?

How often this happens: I got the impression* that there's a cs_aes_halt handshake before a Keccak round run about 90% of the time, maybe even more. So I'd say in the majority of cases it works as intended but I wouldn't rely on that to always be the case.
How far the individual run_i pulses (and thus Keccak round runs) are spaced in time: About* 1000 clock cycles.

Estimates from checking a few waves, not a full statistical analysis over a representative sample set.

Thanks @andreaskurth for getting back. It's good to have a rough idea on how frequently this happens. I think anything beyond 100 clock cycles should be fine. Because a full SHA3 would run for 24 clock cycles and the AES-256 inside CSRNG takes 16 clock cycles. IIRC a generate command will take 3 or 4 AES runs. Even if it would happen once every 100 cycles it wouldn't create a huge overlap.

Yes, I'll add some assertions to ensure that this does not happen too often.


Moving boxes to another device

Question
We have the same app running on multiple devices entering data into forms.
We would like to synchronize changes in forms on the remote devices to a master tablet.
My team has been doing a conversion to Box -> SON, transport JSON, JSON->BOX, merge.
I wonder why can't we just move the boxes, open them up on the receiving end, merge differences.
We are basically writing stuff to boxes and writing equivalent code to write / read into JSON, and I wonder why not just do it once?
Version
Android/ioS
Latest version of flutter and hive.
Thanks,
Ken Nelson

You can also transfer box file, read & parse on other end then copy data to the box on endpoint.

@TheMisir I'm currently trying to move the full boxes to a backup location and restore/overwrite the full boxes on request.
Converting box.values or box.toMap() to JSON currently seems a lot of unnecessary work (since I'm storing custom data models), if there would be any way to just get a hold of the full box-files or box-file-contents as a single string (being on iOS/Android). Do you have any hints for me?

You can copy database file itself. The .hive files is stored in getApplicationDocumentsDirectory() directory.

Just in case anyone looking for way to do it in a "string"-way when copying isn't the best option:
https://github.com/hivedb/hive/issues/173#issuecomment-776052867


Arabic doesn't render correctly

Hi, I use vim inside the terminal and it renders Arabic correctly. But I'm missing MacVim features. I was wondering if MacVim is using CoreText, then why Arabic is rendered incorrectly?
Take the following words for example, if you check the vim 8 in terminal it should display it as you can see it in your browser (if you have already executed set noarabic).
عربی فارسی
But in MacVim, the Arabic text is rendered from left to right. I saw there is an issue already posted here #696, but was it fixed?

I hope I can show how to make it work. I don't use MacVim in the terminal, I use the MacVim.app (Custom Version 8.1.280 (151)). This is the screenshot from the Vim 8 in the terminal. Which is the expected behavior:

Text which I used to make the screenshot:
فارسی English
The same text in MacVim:

Also, I needed to change the font in the MacVim to the New Courier because, in the terminal, the fallback font for Arabic is New Courier, but in MacVim it doesn't happen and goes to a font I don't recognzie. As you can see the order of characters for Arabic has become reversed in the MacVim. Arabic is right to left, and in MacVim it's being displayed as left to right.
I have to add that previously if I build the Vim 8 with the +arabic and +farsi feature in the terminal, the Arabic also was displayed incorrectly. But if I build it without the -arabic feature, the arabic in the terminal Vim displayed correctly. So finally I realized I could make the vim in terminal work with +arabic only if the vim recognized the terminal is bidi. So even by having the +arabic feature in the vim inside the terminal, I added the set termbidi in my vimrc and Arabic started to show correctly. I think MacVim also reads the same vimrc file because settings show up the same. I hope this helps to find a solution?
My Vim version (not the MacVim):
~$ vim --version
VIM - Vi IMproved 8.1 (2018 May 18, compiled Dec  2 2018 03:52:24)
macOS version
Included patches: 1-556
Compiled by<EMAIL_ADDRESS>Huge version without GUI.  Features included (+) or not (-):
+acl               +extra_search      +mouse_netterm     +tag_old_static
+arabic            +farsi             +mouse_sgr         -tag_any_white
+autocmd           +file_in_path      -mouse_sysmouse    -tcl
+autochdir         +find_in_path      +mouse_urxvt       +termguicolors
-autoservername    +float             +mouse_xterm       +terminal
-balloon_eval      +folding           +multi_byte        +terminfo
+balloon_eval_term -footer            +multi_lang        +termresponse
-browse            +fork()            -mzscheme          +textobjects
++builtin_terms    -gettext           +netbeans_intg     +timers
+byte_offset       -hangul_input      +num64             +title
+channel           +iconv             +packages          -toolbar
+cindent           +insert_expand     +path_extra        +user_commands
-clientserver      +job               -perl              +vartabs
+clipboard         +jumplist          +persistent_undo   +vertsplit
+cmdline_compl     +keymap            +postscript        +virtualedit
+cmdline_hist      +lambda            +printer           +visual
+cmdline_info      +langmap           +profile           +visualextra
+comments          +libcall           -python            +viminfo
+conceal           +linebreak         +python3           +vreplace
+cryptv            +lispindent        +quickfix          +wildignore
-cscope            +listcmds          +reltime           +wildmenu
+cursorbind        +localmap          +rightleft         +windows
+cursorshape       -lua               -ruby              +writebackup
+dialog_con        +menu              +scrollbind        -X11
+diff              +mksession         +signs             -xfontset
+digraphs          +modify_fname      +smartindent       -xim
-dnd               +mouse             +startuptime       -xpm
-ebcdic            -mouseshape        +statusline        -xsmp
+emacs_tags        +mouse_dec         -sun_workshop      -xterm_clipboard
+eval              -mouse_gpm         +syntax            -xterm_save
+ex_extra          -mouse_jsbterm     +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L/usr/local/lib -o vim        -lm -lncurses  -liconv -framework AppKit     -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin -lpython3.7m -ldl -framework CoreFoundation

I'm very interested to make this work. Could anyone please direct me where should I look in the source and what is the main part that takes care of glyph generation and layout?

All MacVim's code are in here: https://github.com/macvim-dev/macvim/tree/master/src/MacVim
There are two text views: MMCoreTextView (used when Core Text renderer is on, which is default), and MMTextView which uses the OS native text view (used when Core Text renderer is off). There's also MMTypeSetter which may be part of what triggers this but I'm not sure. I did try to reproduce this and noticed that this bug happens in both Core Text renderer and non-Core Text one.

Hi @typoman I want to circle back to this since there are some discussions on this topic in upstream Vim. Is this still an issue for you and did you get around it? Are you just calling set arabic for now? Or just use Apple Terminal to handle it?


User logging in must have OtherPassword privilege

In order to login to Jadeite/Rowan, a user must have CodeModification (reasonably) and also OtherPassword.  The error is a little confusing and only mentions CodeModificiation.
Since this is a one-person-per repository scenario it may not be critical... but generally you don't want just anyone to have OtherPassword since with that, they can change any other user's password, disable their commits, etc.
I imagine this is done to allow SymbolDictionary/SymbolList monkeying about with... maybe we have overworked the privilege.

@LisaAlmarode Do you have a specific example of what happens when the user doesn't have OtherPassword --- I did not have a goal to require OtherPassword privileges for using Rowan:). You mention an error ... do you have a stack or the exact wording of the error message?

@LisaAlmarode, Thanks.
Now, if you could extract the stack that matches this error from the Jadeite ERRORS File we'd know what operation was involved ...
Presumably you are testing with a non-DataCurator/SystemUser user? Is OtherPassword privilege a privilege that we recommend for use by normal developers or is it reserved for folks with special privileges?

No Jadeite.ERRORs file is to be found.
Yes, that was the point of the exercise - I created a new user to verify behavior.  To merely log in, you must have CodeModication and OtherPassword, but no other permissions are required (to log in... more may be needed for other operations).
OtherPassword very much not recommended for normal developers, since normal developers should not be able to change one another's passwords nor disable one another from committing.
As noted, however, it may not really matter in a single-user stone.

I think we do want to track this one down ... @ericwinger I'm bouncing this to you to reproduce under a Dolphin debugger so we can understand a) what code is being executed to trigger this and b) to perhaps fix #173 ...
Not getting a stack from errors like this will make it difficult fir us to help users who run issues ...

... once we get the stack, we can decide what needs to be done ...
@LisaAlmarode, did you happen to check if there was anything recorded in the gem log?

In order to create a user with different privileges, I need to know how to make Rowan visible to a non-DataCurator and non-SystemUser user. What is the easiest way to do that @dalehenrich?
My guess is that I need to modify their symbol list.

In topaz, logged in as the user execute the following:
run
GsPackagePolicy current enable.
UserGlobals at: #rowanCompile put: true.
System commit
%

This is all we do for DataCurator ... Rowan is installed in Globals so it is visible to everyone with Globals in their symbol list --- the default symbol list I assume ...

@dalehenrich  - I'm a little confused.  I created a new user with all the privileges (in GBS in my rowan-enabled repository). However, when I try to login through Jadeite, it tells me that ROWAN_PROJECTS_HOME is nil.
Oddly, I can login as SystemUser and the env var is true.
Suggestions?

what do you mean by env var is true ... ROWAN_PROJECTS_HOME should be a string not a boolean ...
What does "all the privileges" mean ... I thought you were going to test a user with minimal privileges, not all of the privileges ...
First off, you probably need to verify logins by using an RPC login with topaz and check the env var ... the netldi shouldn't discriminate based upon which user is logging and the netldi is controlling the env vars for the gem process...
Secondly I would be suspicious that Jadeite is taking different paths depending upon the privileges of the user ...

Nothing in the gem log.
It is, incidentally, trivially easy to produce.
Create the user as DataCurator:
run
AllUsers addNewUserWithId: 'Lisa' password: 'swordfish'.
(AllUsers userWithId: 'Lisa') privileges: { 'CodeModification'    } .
System commitTransaction.
%
Then try to login as Lisa with the password swordfish.

@dalehenrich - Problem fixed. I checked "No Perform on Server" by mistake when setting up my user.

@dalehenrich @LisaAlmarode First clue. The first error is from the compile of JadeServer code on the server. That code is called in GciSession>>initializeServer. The error handler wraps any error and throws up the first dialog Lisa saw.
I'll attach big ugly string that's being passed to server.
JadeCodeCompileString.txt

Do you have details on what the error is ... CodeModification should allow us to compile methods, so I'm curious where the error is coming from ... can you post a stack?

Still working on getting a stack with more information. Next best thing so far is a dialog saying:

a SecurityError occurred (error 2151), reason: rtErrNoPriv, An attempt was made to do a privileged operation for which no privilege has been granted.

I verified I gave the user CodeModification privilege, and only that.

You should be able to try executing the compile string in topaz and get a good stack ... I would think

No luck getting the string to run in topaz.  Trying to get a stack by setting GEM_HALT_ON_ERROR to 2151 but can't get the gem to halt yet.
Maybe @LisaAlmarode or @dalehenrich  can get a gem stack off GEM_HALT_ON_ERROR?
(Maybe that's not possible for security errors)

When you say "no luck ,,, with topaz" what do you mean ... the string compiles correctly or ???

Remember that Jadeite sets up a funky environment to do the compile (DataCurator UserGlobals among other things) ...

Looks like otherPassword was required in versions prior to GemStone 3.3 to compile code.
http://kermit.gemtalksystems.com/bug?bug=44433
Therefore, I surmise (without stacks) that it's the code compilation done when initializing Jade on the server that's the problem.

When you say "no luck ,,, with topaz" what do you mean ... the string compiles correctly or ???

I massaged the string and put it in a file. Then I tried to input it into topaz. I changed the file to say run at the top but the delimiter for stopping the run % killed the input.
Effectively, I'm not yet topaz-savvy enough to get topaz to input a file built on smalltalk code to run.

what does "killed the input" mean?

okay ... here's the SymbolList>>validatePrivilege method, and the comment seems to explain what's going on:
_validatePrivilege

"
To modify your own SymbolList, you need #CodeModification.
To modify another's SymbolList, you need #OtherPassword.

Returns true if successful, otherwise signals an error and
if execution continued returns false.
"

| upro |
upro := System myUserProfile .
self == upro symbolList ifTrue:[
  ^ upro _validateCodeModificationPrivilege
] ifFalse:[
  self == GsSession currentSession symbolList ifTrue:[
    ^ upro _validateCodeModificationPrivilege
  ] ifFalse:[
    ^ upro _validatePrivilegeName: #OtherPassword
  ].
].

If I read this correctly (if I saw a stack it would be confirmed --- i.e. error coming from within SymbolList>>_validatePrivilege), the security error is being raised because Jade is creating a new symbol list  and it  is not the current user's symbol list nor is it the current session's symbol list...
I'm not exactly sure why it is necessary to fabricate a symbol list that includes DataCurator's UserGlobals ...
@LisaAlmarode do you know offhand if this is still the case in 3.4/3.5?

@LisaAlmarode by the way when you include code or arbitrary text, you can avoid having html formatting rules invoked by putting the code between two lines of backticks ``` ... I'll edit the comment for readability ...

@dalehenrich - This may be the offending code.  I wonder if it's a residue of when the JadeServer was compiled under it's own private symbol dictionary?
I removed the two >>>'d lines and I was able to login.
             nextPutAll: 'symbolList := System myUserProfile symbolList.'; lf;
       >>>>  nextPutAll: 'symbolList := (AllUsers userWithId: ''DataCurator'') symbolList.'; lf;
        >>>> nextPutAll: 'symbolList := symbolList class new add: (symbolList detect: [:each | each name == #UserGlobals]); add: (symbolList detect: [:each | each name == #Globals]); yourself.'; lf;

If you are curious about why those two lines were added I suggest you look at the BLAME view  for the file where that contains that code:

It will tell you which commit those lines were added for and you can look at the commit comment and even changes for that commit ... I recall that there was a bugfix or two in that area and when I read the bug reports in the area, the changes had to do with "being allowed to create classes that were the same as those in the symbol list being viewed" or something like that .... I didn't dig too deep ... it seems that the changes were made a year or two ago which is pretty recent as things go, but the bug may be totally unrelated to what our needs are and if you can login, then that means the the JadeServer code compile without issue which is the goal --- Rowan itself does adds to symbol lists, but they are always the ones owned by the current user and those are allowed ...

@ericwinger let's go ahead and include this two line change in the current candidate and see if we hit any other issues ...

I've pushed this change to the Jadeite master branch, along with the tag Alpha2.0.1.
I did not cut a new Jadeite.exe. Can do so when needed.

we can wait until we have a request for a new drop ...