Disallow hyphens in crate names

Crate names with hyphens (e.g. rustc-serialize) are awkward to use and inconsistent with the rest of the language.
This RFC proposes a plan to deprecate and eventually remove the feature before 1.0.
Rendered

:-1: Dashes are more readable and renames aren't the end of the world.
For example. I may have a crate: syncbox-io and using it would be:
extern crate "syncbox-io" as sio

Once there are dashes or underscores in the name, it's probably easier to alias to something shorter anyway for use in code.

Big :+1: here. People should try to make libraries they author as painless to use as possible, and forcing all consumers of a crate to rename it every time it's imported is not a great way to do that.

@carllerche

Dashes are more readable

The readability/aesthetics argument is subjective, and not something everyone agrees on.
Really, the fact that all arguments for them come down to they look nice should sound at least a bit suspicious. Especially when there are objective arguments on the other side.

renames aren't the end of the world

They aren't, of course. But as @sfackler says, making this kind of renaming mandatory is not the way to go. It'll be yet another special case for newcomers to learn, and introductory tutorials to explain.
Quite a few features of Rust -- C-style syntax, lifetime elision, IntoIterator -- are geared toward reducing the number of concepts a beginner has to learn up front. Disallowing hyphens follows in this trend: beginners won't have to learn renaming syntax just to generate JSON.
Renaming crates will be optional sugar, as it should be.

Once there are dashes or underscores in the name, it's probably easier to alias to something shorter anyway for use in code.

Note that if we disallow hyphens, we'll be able to do this instead:
extern crate syncbox_io as sio;

which compares favorably to
use std::fmt::Write as WriteFormat;

In fact, hyphens are the only character we allow in crates which aren't also valid in identifiers. Without them, we wouldn't need quotes at all. I didn't include this change in the RFC, but that syntax would be possible in the future.
(And before someone brings up Go: in that language the string is a path to the library, not a crate name. Note that Go doesn't allow hyphens in crate/package names either.)

+1

I'll admit that foo-bar looks better to me, but I still prefer removing -s from crate names for less exceptional cases in the language and better consistency across the ecosystem, so +1.

let's do this... :+1:

I suppose another alternate is to allow - in idents

It's ambiguous - is a-b the ident a-b or the ident a minus the ident b?

@sfackler sure, we'd also need to change parsing rules (that would be a single ident), but it is an alternative.

To avoid ambiguity, whitespace would be needed in order to have -  as an operator. Much code would break.

Is there any language that allows - as part of identifier?

@tshepang Lisp-family languages do, but they usually require spaces between tokens for this reason. I don't know of a C or ML-style language that does.

@lfairy I forgot about Lisp, thanks.

+1, using rustc-serialize is a bit weird at first

:+1: Not only is being forced to rename certain crates very frustrating, but it’s also annoying to have to choose between - and _ when choosing a crate name, and to remember which of - and _ a particular crate uses. Removing one of them seems to be a good course of action to me, and - is the best candidate for removal in my opinion by far (removing _ would be inconsistent with identifiers, having - requires renaming, and the other points already discussed).

I agree to @P1start's rationale. Encoding currently has both encoding_index_tests and encoding-index-singlebyte (and so on), primarily because they are registered by different authors. Having one correct way would be appreciatd.

Big :+1: here.

We talked about this RFC in today's meeting. One of the points in favor of using hyphens, which I don't think has been stressed enough, is that there is a large amount of precedent for using - in "package names". For example github repositories, ruby gems (for namespacing), and npm all have a large and established convention of using a hyphen.
I am personally sympathetic with the hyphen convention, and I believe that going against the precedent-at-large to gain consistency is not worth it. I think that this RFC does a great job of laying out the alternatives (thanks!), and I would personally push for the fuzzy matching alternative to become the detailed design.
Of the two motivations, consistency and usability, fuzzy matching would solve the usability problem. There are probably still some more details to hash out precisely what happens, but overall I think it's the best direction to go in. We can continue the trend of hyphens set by other communities without sacrificing usability. In this situation we would probably continue to retain the quoting syntax for renaming if necessary, it just wouldn't be necessary if you used the canonical "extern crate" name for a crate.

I don't think fuzzy matching really solves the usability problem, it just
adds complexity.

@steveklabnik could you elaborate a little more on why you think it doesn't solve the usability problem? I'm curious what use cases you have in mind and what possible extensions could be added (not that they should be, just curious!).
The specific use-case I have in mind is what's spelled out in the RFC:
extern crate "rustc-serialize" as rustc_serialize;
// vs
extern crate rustc_serialize;

-1 for similar reasons as @carllerche.
Hyphenated names are often meant to be renamed. For instance, I usually do extern crate "rustc_serialize" as serialize, especially now that we have $crate for macros.
Another case is with distributing iron-related stuff, perhaps I want to distribute a set of crates under iron-X (right now everything is just X but that could change and there are other frameworks that will exist) that are meant to be imported extern crate "iron-x" as x.

@alexcrichton
Without hypens, crate names are just identifiers. With hypens and fuzzy matching, now I have to explain why it's not just an identifier, and what those fuzzy matchers are, when instead, we could all just use identifiers and sidestep this whole mess.
It's not like there are a zillion packages right now, but I certainly would use a non-hyphenated package over a hyphenated one, if they provided simliar functionality. It's ugly hoop-jumping for no actual benefit, imho.

:+1: while you certainly can rename to your liking, you shouldn't be forced to.

@reem, I am thinking, would it be a good alternative to state in the guide lines that - is a "namespacing"/"tagging" symbol, and _ is for separating words in a name? So if a project foo has some component named bar baz, then the correct naming would be foo-bar_baz not foo-bar-baz nor foo_bar_baz.
But then on second thought, I'd rather we permit / as the namespacing symbol, and forbid -.
@Everyone, would the above be a good alternative?

Without hypens, crate names are just identifiers. With hypens and fuzzy matching, now I have to explain why it's not just an identifier, and what those fuzzy matchers are, when instead, we could all just use identifiers and sidestep this whole mess.
I guess that's the core of it: we can pile on rules to make hypens look just like underscores, or we can just use underscores and call it a day.

I definitely agree that adding any form of fuzzy matching would be adding more complexity. This RFC classifies today's behavior as both complex and hindering usability. I'd like to tease apart these concerns in this discussion. You previously said "I don't think fuzzy matching really solves the usability problem", but it sounds like you're mostly worried about the complexity a fuzzy match would be adding?
To be clear, I'm not disagreeing that a fuzzy match adds complexity, only that a fuzzy match does not solve the usability problem. I think @sfackler put it well in that today a - in a crate name forces users to rename-on-import, but a fuzzy match does not have this restriction: the "canonical name" would be hyphens translated to underscores.

It's not like there are a zillion packages right now, but I certainly would use a non-hyphenated package over a hyphenated one, if they provided simliar functionality. It's ugly hoop-jumping for no actual benefit, imho.

I agree, and my motivation for pushing back on disallowing hyphens is that I like hyphens, not so much that I don't want to go migrate all the crates on crates.io :)

@CloudiDust

Everyone, would the above be a good alternative?

I believe that scheme is similar to what Ruby employs, although I'm less sure about Python or NPM. It does clash, however, with the *-sys convention as well as the number 1 crate on crates.io, rustc-serialize (just as some data points).

Please don't add name fuzzy matching! Better leave it as is than add a possible footgun to the language. The fuzzy matching idea is much too clever for what crate importing is supposed to be doing.
Forcing everyone to just use the underscore is a better idea IMO, but damn-nigh everything is better than fuzzy matching the name. It's way too magic.

@alexcrichton, we may fuzzy match / and - (note: both mandates renaming)  instead of fuzzy matching - and _. And we may guide the community towards using / instead of -. (Or if some package uses - to separate words in a name, it will change to use _. bloom-filter looks good, bloom/filter may not be what the author intends.)
Also, we may mimic how lein (Clojure's package manager) does things, by treating a namespace-less name foo as the same as foo/foo. This worked well for clojure, I think.
The mandatory renaming avoids name clashes nicely, without introducing the concept of package/crate namespacing into the compiler. (Besides foo = foo/foo, which can be a simple string rewrite.)

@Valloric, I can accept fuzzy matching in the transition period, but if we can complete the transition without fuzzy matching, it is better.

nice!
On Mar 11, 2015 9:08 AM, "Richard Zhang"<EMAIL_ADDRESS>wrote:

@alexcrichton https://github.com/alexcrichton, we may fuzzy match / and

(note: both mandates renaming) instead of fuzzy matching - and _. And
we may guide the community towards using / instead of -. (Or if some
package uses - to separate words in a name, it will change to use _.
bloom-filter looks good, bloom/filter may not be what the author intends.)

Also, we may mimic how lein (Clojure's package manager) does things, by
treating a namespace-less name foo as the same as foo/foo. This worked
well for clojure, I think.
The mandatory renaming avoids name clashes nicely, without introducing the
concept of package/crate namespacing into the compiler. (Besides foo =
foo/foo, which can be a simple string rewrite.)
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/940#issuecomment-78182058.

Actually the RFC itself proposes using fuzzy matching in the transition period. (If we don't allow this, there would be no "transition", I realized.)
Also, there is no point in doing foo = foo/foo. lein does this because maven mandates separated group id and artifact id. Rust/Cargo/Crates.io don't have such concepts.
So I now prefer we replace - with /. Each package with - in its name would then have to decide which to use instead, / or _, depending on the meaning of -.

In the future, Cargo and Crates.io can treat the "namespace" parts of package names specially, like for grouping. And namespace-less packages like foo will be treated as "both a namespace and the nameless/main package inside that namespace" or as "a package in the global namespace". I prefer the former interpretation, as it describes nicely the relationship between foo and foo/sys.
And rustc doesn't have to know anything about package namespaces. It only needs to know that / can be in crate names but not in identifiers.

@CloudiDust adding / as a namespacing symbol (I assume by this you mean changing the syntax of use to allow use of foo/bar without quotes) would be very much the same as allowing - as a "namespacing symbol" (both are binary operators)
And keeping - has the added benefit of allowing crate names to stay the same.
That said: I'm not keen on allowing something special that isn't an identifier after the crate name. I'm under the impression that this RFC would still exist even if we could do use foo-bar as foo (note: no quotes) today.
If people want to name things with - (or /), perhaps identifiers should just be changed to include them (causing spaces or other separating tokens to be required when doing division or subtraction)

@jmesmon, I am not proposing foo/bar to be legal, but "foo/bar" to be legal. The only change compared to today is - gets replaced by /.
Currently, - may be a namespace sigil or a word separator, so package names are inconsistently using - and _.
But it is clear that / is a namespace sigil and _ is a word separator. So people will naturally use them consistently if - gets replaced by /.
If we change all - to _, it won't be clear which parts are acting as namespaces.
Cargo/Crates.io/rustc don't have to special case / (other than allowing it in package/crate names), but when they want to (in the future), they will know which sigil to look for.

Yes please. +1.

I'm in favor of banning - in crate names. I'll note a few things:

*-sys are, in the vast majority, placeholders rather than fully-realized crates.
Perl historically did the fuzzy matching thing, with ' (single-quote) being able to stand in for ::. Nobody likes this, except the Acme namespace. It was a mistake.
Easy things should be easy, hard things should be possible. Importing code is easy; it shouldn't be made artificially hard by way of mandatory renaming - but renaming is a useful tool in the more complex cases.
Allowing _ to stand in for - silently means crates could be ambiguous on import, even without actual name collisions. This violates the principle of least surprise.
I also dislike / as namespacing: Just like -, it's not valid in identifiers, and we'd get this exact same bikeshed to paint a second time. We already have :: for namespacing, and it's not currently valid in crate-name context AIUI. Similar things should look similar.

@eternaleye, I choose / because it is a common namespacing character and it is not ::, as package namespacing has nothing to do with code namespacing inside a crate. And rustc/cargo/crates.io don't have to special case / more than they special case - now.
People will need to do package namespacing anyway. And giving dual purposes to _ can make names unclear in the future. (Which part is the namespace and which part is the "actual" name?)
For a package like rustc-serialize, it can be argued that this is actually a package "serialize" under the rustc namespace, and it is natual to rename it to serialize when importing (we want the "serialize" component of the "rustc" project). While having to rename bloom-filter to bloom_filter seems pointless.
Also I am thinking, if we later special case / (more) in rustc, we can have:
extern crate "foo/bar" as bar;
extern crate "foo/baz" as baz;

// Sugar of the above
extern crate {bar, baz} from foo;

Or something similar. And no change needs to happen to cargo/crates.io.

Well, part of what I object to is "more than they special case - now" when this discussion is about whether it's already too special :P
Also, I've never been a fan of trailing from in languages - it means I need to do lookahead in order to have any idea what's actually in play.
Also, the truth of the matter is we don't have namespacing. If we do get namespacing (which I agree is a needful thing), it should actually be thought out as such rather than being retrofitted on top of a symbol originally added for aesthetics.

@eternaleye, I think I am not fine with special casing -, because - and _ are quite similar in semantics. So choosing one or another is a very subjective matter, and leads to much inconsistency. OTOH / is clearly a namespacing character if it is paired with _. So at least it wins in the consistency department. :P
The from sugar is just one of many possiblities.
Adding namespaces to rust packages is a much discussed topic. And I am currently one in favor of "no mendatory multi-level namespacing" (or "every top level package creates a new namespace").
I think building namespacing support on top of / would be quite natural and backwards-compatiable. (The compiler doesn't have to know anything about namespacing currently, and support, if needed, can be added easily later, which is a big advantage.)

Also, we may special case / in this way:
For a crate named C, extern crate "C" would bound the crate to C's last name component, that is:
extern crate "foo"; // the crate is bound to `foo`, the same as `extern crate foo;`
extern crate "foo/bar"; // the crate is bound to `bar`
extern crate "foo/bar/baz"; // the crate is bound to `baz`

This is simply not possible if we replace all -s with _s.

One thing to think about when considering the precedent for hyphens in package names in other languages is that the difference between a hyphen and an underscore is confusing to new users, and because there is no enforcement of the scheme that hyphen means namespace and underscore means word break, not everyone follows it. As a result, you have lots of commonly used packages that go against this advice, and the result for developers is that you can't rely on the convention to remember how a package's name is spelled. An example of this in Ruby is the factory_girl gem, which has a Rails-specific extension called factory_girl_rails. If this were to have followed the conventions, it would be named factory_girl-rails, which is awkward looking and probably the reason the authors decided not to do it that way.
It's clear that there is a use case for the idea of a namespaced package, but by having no enforced scheme for it, people will just do whatever they want, which makes for a more confusing experience for people consuming packages.
I rather like @CloudiDust's suggestion of using a slash as the namespace separator and disallowing the hyphen entirely. When the only two non-alphanumeric characters are slash and underscore, I think it's much more clear which one is a namespace separator and which is a word boundary. I'm not sure it's a good idea to try to infer anything about crate structure from that namespacing though. I think it should probably just be a naming convention and nothing more.
tl;dr Other languages show there's a need for a distinction between namespace and word boundary in a package name, but we shouldn't necessarily follow their lead in how they implemented the ideas, since they cause inconsistency and confusion.

:+1: for banning - and requiring crate names to be valid identifiers
:-1: for fuzzy matching

:+1: it's invalid in code, so it shouldn't be allowed outside it. Most users don't know how to alias the crate and eventually resort to IRC to find out, this obviously sucks.
Fuzzy matching is asking for trouble but

:+1: for Disallow hyphens in crate names
:-1: for Disallow hyphens in package names

I thought more about / last night and there were some disadvantages:
When declaring dependencies in Cargo.toml, foo/bar must be quoted:
[dependencies]
foo/bar = "0.0.1" # Error
"foo/bar" = "0.0.1" # Okay

which can be a bit strange when all other keys are not quoted.
Also, if we follow the new convention, almost all foo_macros crates should be renamed to foo/macros, which means they must be renamed when imported. For macro crates, this is added labor for almost nothing.
I am now not sure whether adding / would be worth it.

:+1: for banning '-' and requiring crate names to be valid identifiers
:-1: for fuzzy matching
:-1: for having renamed be a "natural" way to use a crate

Oh wow, this blew up much more than I expected :open_mouth:

@CloudiDust There's also a bit of ambiguity on crates.io. For example, currently we can look up the versions of the package maud at https://crates.io/crates/maud/versions. But if we allow / in package names, this path will be ambiguous: does it list the versions of maud, or show the package named maud/versions?
. doesn't have the URL problem, but it still needs to be quoted in TOML:
[dependencies."maud.macros"]
git = "..."

So given these constraints, - and _ are really the best options here.
I quite like your extern crate idea though. Perhaps we can use - as the separator instead of /? So we have this:
extern crate "rustc-serialize";
// desugars to:
extern crate "rustc-serialize" as serialize;

Go does something similar, which is a good sign. It does feel a bit icky, though:

Nowhere else in the language do we introduce identifiers based on a string literal
It doesn't make sense under the *-sys convention
It's hard to see at a glance what the last component should be

So I'm hesitant about it.

@alexcrichton I wrote up a detailed argument against fuzzy matching, but now I'm not so sure...
For posterity, here are some points to consider:

The majority of platforms allow hyphens, with the exceptions being C#, Java and Go. Rust tends not to go against the grain (pun not intended) without a very good reason.

crates.io already rejects packages that differ only in capitalization (e.g. you can't upload a package called RUSTC-SERIALIZE). Identifying - and _ would be a simple extension of this behavior.

Mac and Windows are case-insensitive, so there's already a level of ambiguity involved.

We can address the ambiguity issue by normalizing output filenames to lowercase-with-underscores. For example, the crate Foo-BaR can compile down to libfoo_bar.so. That seems like a good thing to do in general, hyphens or no.

Overall I'm starting to get tired of the debate over this thing, so I hope we can reach a consensus soon.

1 File names are different from identifiers.  Always have been, always will be.
2 Organizations have internal standards for file naming that do not recognize Rust's existence.
3 It is perfectly reasonable to offer a fast track from file name to identifier when the file name conforms to identifier rules, e.g. no "", no 'as too' needed.
4 It is perfectly reasonable to require that non-conforming file names be quoted and aliased, i.e. "aa-bb.cc" as aabbcc;
5 It would be of service where names come from outside the Rust world to have relaxed restrictions, e.g. allow /-.+[]()!?#@, and even space, but only inside quotes. It looks like a string literal, why impose unnecessary non-stringy restrictions?
6 Where the name is in a string literal, there's no point in folding anything; use the text as written.  The file system might fold names, and that is its business and none of Rust's.
7 In practice, stuff purely in the Rust world will have the names that can be expressed most conveniently, without coercion.  Folding case and separators might seem like a convenience, but is hardly worth the bother to document and for users to remember.
8 This boils down to 2 rules: 1) names not quoted are identifiers, full stop, and become file names by the identity mapping. 2) names in string literals, quoted, are (parts of) file names, not identifiers, full stop, and must be aliased to an identifier explicitly to work at all.

@ncm Crate names and filenames are orthogonal. You can set them differently using the -o and --extern options in rustc:
# Build a library with a custom filename
rustc --crate-type=lib --crate-name=mylibrary -o /path/to/libsuper-duper-custom-filename.rlib src/lib.rs

# Link a library with a custom filename
rustc --extern mylibrary=/path/to/libsuper-duper-custom-filename.rlib src/main.rs

I'll reiterate the comment I made on internals: for Rust 1.0, the emphasis should be on preserving forward compatibility with desired future language evolution. Namespaces are, I think, too large a concept to design on the 1.0 schedule, but they could impact extern crate usage. Therefore, I think we should reduce extern crate to the simplest core that can possibly work for 1.0, so that we leave room to expand it later. To me, that means disallowing hyphens in crate names (since the way we have to rename crates now may not be the way we want to rename them in the future, hyphens are a forward-compatibility risk), turning off crate renaming entirely (for now), and possibly re-adding them after an explicit design process post-1.0.
In other words, I am actually OK with the current behavior post-1.0, so long as it's the result of an explicit design process. I think 1.0 itself, though, should use the simplest system that can work: no hyphens, no crate renames.

Okay -- I've rewritten the RFC to only disallow - in Rust crates, but continue to allow them in Cargo packages. Funnily enough, it ends up simpler than the original RFC as it doesn't need to migrate anything.
I also added a proposal to remove quotes from the extern crate syntax. I believe this fits with the goals of improving consistency and usability, and I don't see any drawbacks to doing it.
@alexcrichton Does this address your concerns?

@lfairy I'd be fine with this! I have a few clarifications though:

This means that with a package name of foo-bar Cargo will pass --crate-name foo_bar to the compiler, right?

In Cargo, you can name targets differently than the package itself, and I suspect we would want this to be an error, right?
[lib]
name = "foo-bar"

As a data point, I just checked and we have 0 crates currently that only differ on - vs _, so this should be an easy restriction to add to crates.io.

Rubygems uses - as a means of indicating an extension, you use _ in the names of gems.

Another thing to mention, https://github.com/rust-lang/rfcs/blob/master/text/0430-finalizing-naming-conventions.md specifically says use camel_case for crate names.

@alexcrichton

This means that with a package name of foo-bar Cargo will pass --crate-name foo_bar to the compiler, right?

In Cargo, you can name targets differently than the package itself, and I suspect we would want this to be an error, right?

Yes and yes. I've reworded the section to clarify these points, thanks!

As a data point, I just checked and we have 0 crates currently that only differ on - vs _, so this should be an easy restriction to add to crates.io.

Great!

If we are doing this (allow - in package names but not crate names), then we need a convention for -. Basically, I think we should use it for namespacing/tagging as if we are using /, so, the following are considered correct:
piston-some_component, sdl2-sys, regex-macros, bloom_filter.
(Note: macro packages are to be renamed, but I can also accept leaving them as an exception as "foo macros" flows natually, in contrast "foo sys" doesn't.)
Also when we create a new package in cargo, I hope it can warn about names that may break convention, like foo_sys, and for names containing - like foo-bar_baz, cargo can warn: "hyphens are for namespacing and tagging, does this look natual to you: foo/bar_baz?"

@CloudiDust I agree that we need an official convention on this, but I think we should propose that in a separate PR.

If there is a separate mapping between file and crate names is certainly doesn't need to be duplicated here.
Mapping "-" and "_" still seems like a wart. If it is always a suffix anyway, maybe "-" could map to "::" in identifier-land?

Or, could a "-anything" suffix be simply omitted from the identifier? "-suffixes" don't seem to disambiguate anything.

@ncm, :: is for intra-crate namespacing, so I don't think we should do the - -> ::mapping. (And we should not be ignoring "-suffixes". Too magical.) However, you've given me a new idea.
@Ifairy @alexcrichton, what about retaining - in package names and map them to /s in crate names and make extern crate foo/bar_baz valid?
(Note, there are no quotes around foo/bar_baz, and the names would be bound to bar_baz, we are not doing funny things with a string literal, but / in a particular context.)
The advantage is that it is very clear hyphens/slashes are namespacing sigils. (And hyphens have to be mapped anyway.)
The disadvantage is foo-sys have to be renamed if there are multiple low-level ffi crates being imported. But this is no worse than the status quo.

The current state of the RPC is reasonable, although I'd prefer to forbid "-" on both ends for the sake of consistency.
Does the core team expect to make a decision on this next week? I mean, the schedule is tight for the beta release.

@arthurprs, I agree forbidding - on both ends is more consistent.
@Everyone, I suppose one of the reasons to retain hyphens in package names is to avoid massive renaming on crates.io. And, hyphens are used for namespacing already.
I looked at crates.io and found that most packages I saw were (correctly) using - for namespacing and _ for word separation.
While the convention has not been officially established, I'd be very surprised if - were not going to be the official namespacing sigil.
Mapping hyphens to underscores have one important advantage: it is simple. But it has one disadvantage: the namespacing information is lost in source code. If all crates become foo_bar_bazs in source code, then it kind of defeats the purpose of using - in package names.
So hyphens -> slashes feels natural to me.
Note: extern crate foo/bar/baz binding foo/bar/baz to baz is just like use foo::bar::Baz binding foo::bar::Baz to Baz.

@CloudiDust which accepted RFC (or other documentation) specifies that - in crate names must be used for namespacing instead of as a normal seperator?
Unless there is something, I view the discussion on namespacing crates as something that probably belongs in a separate RFC.

@CloudiDust Another disadvantage would be inconsistency: this / syntax isn't used anywhere else in the language, so it would feel strange in context. I'm hesitant to push such a change for this reason.
@arthurprs The RFC is written with a tight time frame in mind (all proposed changes are really easy to implement) so it shouldn't be an issue.
@jmesmon I think you're in agreement here. He already mentions that "the convention has not been officially established".

@Ifairy, I'm afraid that mapping hyphens to underscores would tempt people to go "I import with underscores anyway, so I'll always name the packages with underscores only." But this may be a minor problem and I am worrying too much.
Let's go with this RFC as written then.

+1
On Mar 13, 2015 9:45 AM, "Aidan Cully"<EMAIL_ADDRESS>wrote:

I'll reiterate the comment I made on internals
http://internals.rust-lang.org/t/pre-rfc-resolve-support-for-hyphens-in-crate-names/1459/22?u=aidancully:
for Rust 1.0, the emphasis should be on preserving forward compatibility
with desired future language evolution. Namespaces are, I think, too large
a concept to design on the 1.0 schedule, but they could impact extern
crate usage. Therefore, I think we should reduce extern crate to the
simplest core that can possibly work for 1.0, so that we leave room to
expand it later. To me, that means disallowing hyphens in crate names
(since the way we have to rename crates now may not be the way we want to
rename them in the future, hyphens are a forward-compatibility risk),
turning off crate renaming entirely (for now), and possibly re-adding them
after an explicit design process post-1.0.
In other words, I am actually OK with the current behavior post-1.0, so
long as it's the result of an explicit design process. I think 1.0 itself,
though, should use the simplest system that can work: no hyphens, no crate
renames.
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/940#issuecomment-78740822.

We discussed this RFC today and the reception was quite favorable of the RFC as-written. I'm going to hold off on merging for a bit to allow any final comments, but otherwise I think this is good to go, thanks @lfairy!

The current version of this RFC appears to have widespread support now by striking a nice balance between consistency in the language while allowing usage of naming conventions in external functions such as Cargo and crates.io. I've now merged this RFC, and thanks again @lfairy!
Tracking issue: https://github.com/rust-lang/rust/issues/23533

@alexcrichton was the intention here to also forbid hyphens in the "crate name" of an output binary?
It seems like we need to do something with our test suite to avoid lots of annoying warnings there.

@pnkfelix currently it is invalid to manually specify --crate-name with a hyphen in it, but compiling foo-bar.rs as a binary will cause the compiler to emit foo-bar as a binary with foo_bar as the crate name (similar to what Cargo does). This means that the test suite shouldn't have any extra warnings.

@alexcrichton all I know is that when I currently compile tests by hand via the command lines I see from compiletest, I often see warnings.
e.g.:
% x86_64-apple-darwin/stage2/bin/rustc /Users/fklock/Dev/Mozilla/rust-lesser-box/src/test/compile-fail/borrowck-issue-14498.rs -L x86_64-apple-darwin/test/compile-fail/ --target=x86_64-apple-darwin -L x86_64-apple-darwin/test/compile-fail/borrowck-issue-14498.stage2-x86_64-apple-darwinlibaux -C prefer-dynamic -o x86_64-apple-darwin/test/compile-fail/borrowck-issue-14498.stage2-x86_64-apple-darwin --cfg rtopt --cfg debug -O -L x86_64-apple-darwin/rt
warning: crate names soon cannot contain hyphens: borrowck-issue-14498
...

@pnkfelix are you sure you're rebased on the current master? I believe I removed that warning very recently.

@alexcrichton yeah okay I don't see it now.

Now that quotes are removed, are crate names like static no longer valid?


Fix use of filesystem in ZTexture

Merging this in without waiting for the usual approvals-- this is preventing some from building over in MM.
@louist103 fyi because this issue was introduced by your changes, just so you know for next time. Apparently this is only an issue on some setups, which is why jenkins never complained


Potential breaking change: slash in :application

Steps to reproduce

Have an :application name like "vendor/application"
Upgrade to Capistrano 3.5 (from ~3.1, which was locked to 3.4 prior to update)
Deploy

Expected behaviour
Don't know if this is expected, or a BC breaking change which should be fixed. However it is a change and I could find documentation for it.
Actual behaviour
Prior to 3.5 names like these worked. I've gone through the change log, the only reference I found was actually fixing a bug related to application name. Currently I get the following error:
The :application value "vendor/application" is invalid!
Use only letters, numbers, hyphens, dots, and underscores. For example:
  set :application, 'vendor_application'
(Backtrace restricted to imported tasks)
cap aborted!
Capistrano::ValidationError: Capistrano::ValidationError

Tasks: TOP => production
(See full trace by running task with --trace)

Thanks for the report @sagikazarmark. What you're seeing is intentional, but I don't think we'd considered your use-case.
It looks like your app lives in a sub-directory of your Git repository, and you were relying on being able to use / in the name ? (Or, alternately that you set deploy_to on level higher than your actual servers' webroots?)
Either way we added guards to ensure that the application_name (which is used for a directory name) is a valid (on most platforms) directory name, hence advising against spaces and other special characters.
I'll add some labels here so others can pitch in and we can think about how to fix this.

It looks like your app lives in a sub-directory of your Git repository, and you were relying on being able to use / in the name

Exactly. It was kind of a lazyness from me, but it was convenient as well.

Either way we added guards to ensure that the application_name (which is used for a directory name) is a valid (on most platforms) directory name

Actually, I think this is a good idea, so probably the best thing to do is to document it as a breaking change (and putting your reasoning there). IMO it's not a big deal to use different names, BC is what an issue here from my POV.

Closing after updating the changelog to reflect that this is a breaking change if you relied on the path naming to represent subdirectories.


longT5 BetterTransformer implementation

Feature request
longT5 BetterTransformer implementation
Motivation
Encoder-decoder model trained on large context allow machine translation tasks
Your contribution
I looked at the implementation of regular T5 and it doesnt look to complex, i tried to implement myself but didnt succeed. If i can contribute please let me know.
Thank you,
Omri

seconding this! would be great

Totally on board with this! Would love to see this feature added!

@fxmarty can we try tackle this together?
Thanks in advance

Hi for reference we are upstreaming SDPA in Transformers, maybe it would be a better fit for longT5: https://github.com/huggingface/transformers/issues/28005
Leaving this open as we may leverage nested tensors for longt5 (which are not in Transformers).


[Question]: Reseting Card FormData

Hello @sbycrosz, thanks for sharing this package. Got a question, please is there a way to reset the   form data/values such as in a lifecycle event like componentWillUnmount or even after data is retrieved and form is submitted etc?
Thanks.

Hey @tolu360,
The component will always start with an empty state (via this.state = {} on the constructor)
As for how to reset the form after data is retrieved and form is submitted, we did it by structuring the routes the following way:
  ShoppingCart -->  Add Credit Card Page (with the CreditCardInput)
                      |
      <---------------+
  //  pops back to previousPage onSubmit
  //  (effectively un-mounting CCInput & destroying the state)

Let me know if this answers your question!

Thanks for your response and for sharing your insights from your usage in production, it's really enlightening. Perhaps, like you have shared, navigating away from the scene/screen where CCInput is mounted does settles it (I am still testing CCInput within the context of just a screen).
Being able to do something like this.refs.CCInput.clear() may be a great idea as well. Great work by the way!

I think I'll park the this.refs.CCInput.clear() idea since it breaks the existing implementation (i.e. the move to previous field when the input become empty logic).
Also closing this issue, since most cases could be handled with just un-mounting the component


Dependencies for libheif.dll

Please provide the dependencies for libheif.dll, for example libde265.dll.

Alright, I have added the required DLLs. More specifically libde265.dll and sk4d.dll.


Add assert_json_eq! macro to simplify common use case

In many cases, especially unit tests, it is required to compare two arbitrary json blobs - very often as strings, e.g. this:
#[test]
fn test_lib_output() {
  let json_result = my_lib.get_json_result();
  assert_eq!(r#"{"expected": 42, "result": 13}"#, json_result.to_string());
}

Sadly, this is not going to work because of two reasons:

the expected result must be perfectly identical to the jsonified result (spacing, newlines, utf-8 normalization/escaping, etc)
the order of the json keys must be identical

I think we all could benefit from a simple assertion macro, something like this (untested):
macro_rules! assert_json_eq {
    ($left:expr, $right:expr $(, $arg:tt)* $(,)?) => {
        let left = serde_json::from_str::<serde_json::Value>($left).unwrap();
        let right = serde_json::from_str::<serde_json::Value>($right).unwrap();
        assert_eq!(left, right ($($arg)+));
    };
}

Thanks for the suggestion! I think I would prefer not to build this into serde_json though.


Add missing Russian pagination control translation

According to https://github.com/symfony/symfony-demo/pull/233

Thank you @bocharsky-bw.


Introduce a failing check when test coverage decreases

Outcome of today's architecture discussion: let's start taking test coverage into account and report when it decreases.
Implementation is open.

just add the coverage to the makefile


1.4.0 Upgrade

This is a backport of @josh's work on our camo install for GitHub. The StreamLimiter stuff that was introduced in #34 failed to run reliably in production so we've reverted it. We've also removed the host blacklisting feature since it's not a concern anymore since we now run on heroku.
The two big improvements over the old versions are:

No longer forward client ip headers to third party systems. This avoids leaking information in things like README's to 3rd parties building advertising platforms.
Proxy SSL images instead of returning an http 301. Hosts that fail to verify ssl will 404 which is the same behavior that chrome and firefox adopt currently.

/cc @josh am I forgetting anything?

<EMAIL_ADDRESS>


crypto/x509/v3_sxnet.c: free sx before exiting and more

This pr involves lots of functions. Thank you for taking the time to review. :-)

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

You have merge commit in the PR, can you please drop it?

This pull request is ready to merge

Merged to master.  3.0 has conflicts.  Any chance of a separate PR for 3.0?

Merged to master. 3.0 has conflicts. Any chance of a separate PR for 3.0?

Of course. https://github.com/openssl/openssl/pull/17443


Feature Request: Instructions for Android

Using Fedora 24, I installed like this:
sudo dnf install nodejs protobuf protobuf-devel
sudo npm install -g bower
git clone https://github.com/justinleewells/pogo-optimizer
cd pogo-optimizer
npm install
bower install
node index
Having done that, the server is up and I installed the pem certificate on my phone. Android is warning me that a third party may be receiving traffic, so I took this to mean it's working.
Launched Pokemon Go, walked around, no pokemon show up on the intranet site. No warnings or errors on console.
Any tips or instructions for how to get this going on Android?

You don't have to walk, you have to go in your box and open the pokemons details in order to see something.

Pulled up the box, renamed a few, no warnings, no errors in console, no pokemon in list.
Is there a verbose mode?

Current experiencing a similar issue using MacOSX El Capitan and an iPhone 5c running 9.3.2.

have you set the server as a proxy on your phones wifi?

Oh, you know, no. It was missing from the instructions in the README. :o)
Any recommendations for how to do that on Android? (Or IOS for that matter, as the README doesn't explain how.)

On iOS you go to wifi and tap on the "i" icon at the and of the row of your currently connected wifi.
You scroll down till you see the proxy setting.
Select manual configuration and write the ip of your proxy and the port 8081.
should work similar on android

I set the proxy and still am not receiving any data

restart kill pokemon go and restart the app while connected to the proxy. The terminal will show you some new lines if it works

If you are on an android phone ca.pem does not work (not a supported file) I used : DroidCert to convert it. After that it worked like a charm !

For me, I didn't have a problem installing ca.pem; when you say it "doesn't work" do you mean you installed it and nothing happened, or you weren't able to install it?
Samsung Galaxy S7, Android 6.0.1.
@pdavid0 -- I assume you also had to set up a proxy too, though, right?

@eratio08 when i do that the app wont load at all

@artvol11 had connection problems myself - I removed the node modules folder and did a clean npm install - did the job for me (also check if the proxy setting are correct)

clean npm install fixed socket error, but now the data is not loading into the localhost:3000

@jnsnow Yes, I used the Proxy .
What I mean is that When you go in Setting > Security > Install From Storage
You can't install the ca.pem file you just downloaded, you have to convert it. Without that extra step I could not use pogo-optimizer.

@pdavid0 -- Yes, downloading the pem works just fine (it saves it to "My Files" on Android 6.0.1 @ S7) and then if you "open" the file, it offers to install it. Seems to work out OK in that regard.
For the proxy, are you using the native android proxy that you can access via the WiFi menu? I'm not having luck with that [here at work] but I will attempt to re-try it when I get home.
I'll send a PR with better instructions for Linux (hosts) and Android (devices) if/when I get it all working, with screenshots, etc.

Alright, the README has been updated a bit with some Fedora/Android instructions; closing this issue. Open new bugs for specific server issues!

@pdavid0  Hmm, unfortunately I don't know where else to reply, but now that I've got the proxy running, I have the same handshake issue as everyone else. pem was definitely installed, proxy is definitely active, but can't defeat the login screen, the toughest gym trainer of them all.

@jnsnow Yes to all your questions.


Issue 352: Clean up some memory leaks originating in the adapter's deleg...

...ates
Addresses https://github.com/emilsjolander/StickyListHeaders/issues/352

Awesome! Sorry for the extremely long delay


cleanup: Fix paths and syntax

Describe what this PR does
Minor cleanup of changed paths and deprecated syntax
Is there anything that requires special attention
This is a very small change that just fixes some minor things I run into when familiarizing myself with the project.
Related issues
Future concerns

Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:

/retest ci/centos/<job-name>: retest the <job-name> after unrelated
failure (please report the failure too!)
/retest all: run this in case the CentOS CI failed to start/report any test
progress or results

/test ci/centos/mini-e2e/k8s-1.23

/test ci/centos/upgrade-tests-cephfs


JSValue.tojavaObject(Object.class) should return Java representation

There are three points to this.
Object.class
JSValue.tojavaObject(Object.class) should return whatever that object would be in Java instead of this (of type JSValue).
This would allow pure Java bridge in the sense I'll try to describe here.
Sample
I'll be trying to pass the following object as a function argument from JS to Java:
{
    "some":"thing",
    "hell":0.0,
    "what":["is","this"],
    "this":{"is":"sparta"}
}

The Java function defines parameter of type Map<String, Object>.
Current behavior
Currently the resulting argument received by Java function could be described as Map<String, JSValue>, because everything coming from JS is a JSValue. Only the top-most element is resolved as Map<String, Object>.
What I get (ordering is not guaranteed, that's fine for now):
mapOf(
    "hell" => JSValue,
    "some" => JSValue,
    "this" => JSValue,
    "what" => JSValue
)

Expected behavior
What I want is to completely abstract JavaScript from the Java function, unless the parameter is defined as JSValue or its children.
Wanted result:
mapOf(
    "hell" => 0,
    "some" => "thing",
    "this" => mapOf("is" => "sparta"),
    "what" => listOf("is", "this")
)

The same result would even be passed if the function parameter type was Object.
String.class
Second case would be conversion to String. If Java function expects a string best effort should be made to convert whatever comes from JS to string. That means

throw on function (What's JSON representation of function? Is it valid case?)
stringify arrays
stringify objects
pass null and undefined as null
string as string via toString()
number as double via toNumber()

Detached results
Resulting objects should be detached from any original real JS objects. E.g.
return new HashMap<>(new JSObjectPropertiesMap(o, Object.class));

HashMap constructor resolves the dynamic map to actual stable values before passing that to the Java function.
Future enhancements
Ability to plug in Moshi so it resolves Map<String, Object> or JSON string to arbitrary Java object types automatically.
Motivation
I'm trying to replicate and expand the same API that WebView offers for registering JS to Java bridge using addJavascriptInterface. I want to hide any JS* objects from consumer. That also means a function handler should not need to extend JSObject or JSFunction.
I'm working on this and will file a separate issue/pull request.
(This part is now over my head so I'm using ByteBuddy to generate child classes of JSObject at runtime that delegate method calls to whatever class the consumer supplied.
Now what
I already have a working demo of the ideas described here (minus automated tests). Is any of this something that goes along with the goals of your library and you'd like to see merged?

Thanks for the detailed proposal.  Sure, this is something that would be quite useful.  I have never been completely happy with the implementation of toJavaObject(), but it worked for my limited purposes.  As it happens, I have a nearly working version of LiquidCore for iOS.  It is running Node.js on top of JavaScriptCore (rather than V8), and JSC object conversion to Objective-C and Swift already works as you describe.  So it would be nice to have symmetry between the platforms.
One thing, though, if you haven't already managed this.  You will probably need to add a test for handling circular values:
var a = {};
var b = { a : a };
a.b = b;

Passing either a or b to Java should not result in an endless loop.

I didn't solve it.  It comes out of the box with JavaScriptCore.  I'm not sure what it does with circular references.  I will have to devise a test.
However, this did come up when I was building out the micro service implementation.  JSON.stringify() is not safe from circularity.  See MicroService.java:279.

Closing due to lack of activity and demand.


Mobile - Update web-runner 1.2.24

Describe the task
Update web-runner 1.2.24
Refer: https://github.com/Koniverse/SubWallet-Extension/releases/tag/v1.2.24

Version test: https://www.diawi.com/qrcode/link/f1cfjT
Device test: IP 11, S20 FE
Validation passed.

Show earning position for Bifrost liquid staking
Update chainlist (https://github.com/Koniverse/SubWallet-Extension/issues/3425)

Add support for Pendulum assets (ASTR, vDOT, BNC)
Add support for Exosama network

Hide direct api usage of polkadot/js (https://github.com/Koniverse/SubWallet-Extension/issues/3308)


The Big sql Merge

Summary

Also contains #270 (which is still under review)
Please ask away about anything.
Don't run it yet, I still have to do the stress testing and migration testing.

Codecov Report

Merging #274 into master will increase coverage by 6.54%.
The diff coverage is 58.14%.

@@            Coverage Diff             @@
##           master     #274      +/-   ##
==========================================
+ Coverage   38.73%   45.28%   +6.54%
==========================================
  Files          11       22      +11
  Lines        1802     2745     +943
==========================================
+ Hits          698     1243     +545
- Misses       1020     1331     +311
- Partials       84      171      +87

Impacted Files
Coverage Δ

server/incident/filter_options.go
0.00% <0.00%> (ø)

server/incident/incident.go
0.00% <0.00%> (ø)

server/pluginkvstore/playbook_store.go
9.30% <0.00%> (-4.50%)
:arrow_down:

server/pluginkvstore/pluginapi_client.go
0.00% <0.00%> (ø)

server/sqlstore/pluginapi_client.go
0.00% <0.00%> (ø)

server/incident/service.go
15.10% <17.54%> (-2.56%)
:arrow_down:

server/sqlstore/data_migration.go
29.80% <29.80%> (ø)

server/sqlstore/store.go
38.46% <38.46%> (ø)

server/sqlstore/migrate.go
41.66% <41.66%> (ø)

server/pluginkvstore/incident_store.go
42.92% <56.66%> (+1.17%)
:arrow_up:

... and 21 more

Continue to review full report at Codecov.

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


Fix typo in autopep8.sh

This typo was introduced by #10746. I was about to post my review requesting this change, but @cmcfarlen approved and @bneradt merged before I submitted.

Thanks for the fiiix.


#647 Welcome screen: Update the text

#647 Welcome screen: Update the text

Changed the text of the buttons on the Welcome screen

@AlexeyKosinski @yaroslav-fedyshyn-nordwhale you can't approve if build is failing, or atleast ask to make it pass


Add or clarify the Common alert schema in the examples

When trying to setup via ARM the action groups the current examples do not contain the common alert schema.
This could easily be added to avoid additional searching and investigation.
Especially since recommendations are to use the common alert schema.
"useCommonAlertSchema": true
currently information on enabling the common alert schema is found in this section under another topic.
https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-common-schema#through-the-action-groups-rest-api
I would love to be able to have the complete ARM documentation with all the settings in one place and not put pieces together from different chapters.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3ef46ed0-e53c-c99e-ccfc-80f26f19820d
Version Independent ID: e0ee52b9-7f31-02e4-d10e-c5f71ee801fe
Content: Create action groups with Resource Manager templates - Azure Monitor
Content Source: articles/azure-monitor/platform/action-groups-create-resource-manager-template.md
Service: azure-monitor
Sub-service: alerts
GitHub Login: @dkamstra
Microsoft Alias: dukek

Thank you for your feedback! We will review and update as appropriate.

@dkamstra FYI

Like this

#closed
https://github.com/MicrosoftDocs/azure-docs-pr/pull/147764

#please-close


Slow execution time

The command output is very slow on macOS w/ fish shell. Reproduction rate is ~80% for me.

DEBUG: Execution timed out!

The execution timed out.

 'wait_command': 3,

It waited 3 seconds until timing out.

I'm also experiencing extremely slow response in Fish shell. I don't have the same problem in zsh.  See 'git --help'.

 See 'git --help'.

 If any of you could test current master and confirm, I'd be grateful.
Thanks!

Fixes for me


ELF: better handle corrupt files

such as when there's a missing symbol table and invalid relocation table. and then handle when Viv fails to load a workspace.
closes #2226
Checklist

[ ] No CHANGELOG update needed

[x] No new tests needed

[x] No documentation update needed

FYI @ygasparis


Replace unwrap() with error message

Forgot to remove unwrap in the previous PR (copy paste from unit test).

Codecov Report

Merging #1702 (4d756d7) into main (eb94eac) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##             main    #1702   +/-   ##
=======================================
  Coverage   65.48%   65.48%
=======================================
  Files         179      179
  Lines       35764    35764
=======================================
  Hits        23421    23421
  Misses      12343    12343

Merging with 1 approval since trivial and to be included before 3pm testing session.


[BUG] RuntimeError: Unable to find a valid cuDNN algorithm to run convolution

Describe the bug
Sometimes during indexing with a GPU the following error can arise
RuntimeError: Unable to find a valid cuDNN algorithm to run convolution

To Reproduce
Steps to reproduce the behavior:
client.index(index_name).add_documents(documents, batch_size=50, device='cuda', processes=4)

Expected behavior
It should index all the documents
Desktop (please complete the following information):

OS: ubuntu 20.04
RTX 3090

This is due to OOM with the GPU. The solution is to reduce the number of processes.
See https://stackoverflow.com/questions/60160874/tensorflow-2-1-failed-to-get-convolution-algorithm-this-is-probably-because-cud/64570063#64570063 and https://stackoverflow.com/questions/61467751/unable-to-find-a-valid-cudnn-algorithm-to-run-convolution


Safer deployment configuration override

Appends json to the end of the filePattern without needing to know anything about the rest of the default string. This change will ensure that if the plugin changes its defaults you are not left behind.

Thank you @jrjohnson :)


HDDS-9658. NPE while cleanup deleted container data

What changes were proposed in this pull request?
volume is not fully initialized when ContainerReader is performing verify and cleanup container data. So causing NPE for temp directory and container deleted path.
while reading volume, temp dir and deleted container dir is initialized before reading container with working dir (as one used for reading container data at same co-location).
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-9658
How was this patch tested?

test case updated to cover same scenario

Thanks for looking at this issue @sumitagrawl. I think the actual problem is that the container reader is being run before the volume is formatted, and that is what we should be fixing.

Volume format is done only after GETVERSION SCM call, but container and volume set is prepared before that only. I think the reason of this doing earlier during startup was to be ready before SCM Registeration.
We should move buildContainerSet() from OzoneContainer constructor to VersionEndpointTask after GETVERSION SCM call.
Related to functionality impact while moving, does not seems any impact.

I believe the only fix required here is to not start the ContainerReaders until the OzoneContainer is started. However, I do not yet understand why this did not fail earlier.

The occurrence is rare when cleanup of container is not complete during previous shutdown. so this is not observed.
Even in UT case, complete initialization is done of Volume object which is different from startup flow, so missed that point also.

Yeah we might have to do some refactoring to make sure the OzoneContainer does not need the containerSet initialized before it is started.

The occurrence is rare when cleanup of container is not complete during previous shutdown. so this is not observed.

This code would run regardless of any container cleanup and I would expect it to throw an NPE before any other ContainerReader code, including cleanup, even started. The volume must have been formatted if a container already existed there, so I'm not sure why this is not happening.

@errose28 Updated the changes

Thanks @sumitagrawl for the patch, @errose28, and @SaketaChalamchala for the reviews!


Failed to move away or delete existing target file

Failed to move away or delete existing target file: C:\Android\sdk\tools
Move it away manually and try again..
i am getting this issue while trying to install flutter

Have you tried the suggestion.

i am getting this issue while trying to install flutter

We would need a bit more concrete information to be able to understand what is going on.

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Fix issue where a 'group' select field in the user editor would always reset …

…to 'guest' (or whatever the first group option was), regardless of the actual value. This was happening because that 'group' field doesn't actually correspond to a real field, but rather is just an easier to work with frontend for a joinByArray. The conversion (saving) pipeline took this into account, but when retrieving the record from the database we never set the value of the field in order for it to properly populate on the frontend.

Good catch.
On Thu, Jun 30, 2016 at 4:42 PM, Austin Starin<EMAIL_ADDRESS>wrote:

Merged #602 https://github.com/punkave/apostrophe/pull/602.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/punkave/apostrophe/pull/602#event-709722894, or mute
the thread
https://github.com/notifications/unsubscribe/AAB9fVrDKX7jZ7xF-8NtKiQk-FvSSdipks5qRCpCgaJpZM4JCkbF
.

--
*THOMAS BOUTELL, *SUPPORT LEAD
P'UNK AVENUE |<PHONE_NUMBER>  |  punkave.com


qemu_update: Add update test from an old release

To ensure that we can update from very old releases, add a test with a fixed old release, here the Stable release that introduced arm64 support to have the same test logic for both architectures. Instead of modifying the helpers for multiple instance tests, a simple duplication was done and both tests will be rerun if one fails.
How to use
backport
Testing done
in http://jenkins.infra.kinvolk.io:8080/job/container/job/test/4873/console

[ ] Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
[ ] Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

@krnowak if you want we could make use of your helpers to integrate the reun logic and so on, not sure if it's worth?


rustc with musl target

Project description
I would love to have a rustc version that compiles static binaries on Linux.
I've hacked one together:
commit 67cf46e3a914f9d89a6b367e261b3d33ecbf5dc5
Author: Nicolas Mattia<EMAIL_ADDRESS>Date:   Tue Oct 15 17:25:55 2019 +0200

    wip

diff --git a/pkgs/development/compilers/rust/rustc.nix b/pkgs/development/compilers/rust/rustc.nix
index 430d22f7653..069fe08c6da 100644
--- a/pkgs/development/compilers/rust/rustc.nix
+++ b/pkgs/development/compilers/rust/rustc.nix
@@ -4,6 +4,9 @@
 , pkgconfig, openssl
 , which, libffi
 , withBundledLLVM ? false
+, pkgsStatic
+, musl
+, runCommand
 }:

 let
@@ -51,41 +54,45 @@ in stdenv.mkDerivation rec {
   # We need rust to build rust. If we don't provide it, configure will try to download it.
   # Reference: https://github.com/rust-lang/rust/blob/master/src/bootstrap/configure.py
   configureFlags = let
-    setBuild  = "--set=target.${stdenv.buildPlatform.config}";
-    setHost   = "--set=target.${stdenv.hostPlatform.config}";
-    setTarget = "--set=target.${stdenv.targetPlatform.config}";
-    ccForBuild  = "${pkgsBuildBuild.targetPackages.stdenv.cc}/bin/${pkgsBuildBuild.targetPackages.stdenv.cc.targetPrefix}cc";
-    cxxForBuild = "${pkgsBuildBuild.targetPackages.stdenv.cc}/bin/${pkgsBuildBuild.targetPackages.stdenv.cc.targetPrefix}c++";
-    ccForHost  = "${pkgsBuildHost.targetPackages.stdenv.cc}/bin/${pkgsBuildHost.targetPackages.stdenv.cc.targetPrefix}cc";
-    cxxForHost = "${pkgsBuildHost.targetPackages.stdenv.cc}/bin/${pkgsBuildHost.targetPackages.stdenv.cc.targetPrefix}c++";
-    ccForTarget  = "${pkgsBuildTarget.targetPackages.stdenv.cc}/bin/${pkgsBuildTarget.targetPackages.stdenv.cc.targetPrefix}cc";
-    cxxForTarget = "${pkgsBuildTarget.targetPackages.stdenv.cc}/bin/${pkgsBuildTarget.targetPackages.stdenv.cc.targetPrefix}c++";
+    ccGlibc  = "${pkgsBuildBuild.targetPackages.stdenv.cc}/bin/${pkgsBuildBuild.targetPackages.stdenv.cc.targetPrefix}cc";
+    cxxGlibc = "${pkgsBuildBuild.targetPackages.stdenv.cc}/bin/${pkgsBuildBuild.targetPackages.stdenv.cc.targetPrefix}c++";
+
+    # the musl-enabled GCC and G++
+    ccMusl  = "${pkgsStatic.stdenv.cc}/bin/${pkgsStatic.stdenv.cc.targetPrefix}cc";
+    cxxMusl = "${pkgsStatic.stdenv.cc}/bin/${pkgsStatic.stdenv.cc.targetPrefix}c++";
+    muslRoot =
+      let libunwind = pkgsStatic.llvmPackages_9.libunwind.override
+            { enableShared = false; };
+      in
+      runCommand "musl-root" {}
+    ''
+      mkdir -p $out
+      cp -r ${musl}/* $out
+      chmod +w $out/lib
+      cp ${libunwind}/lib/* $out/lib
+    '';
   in [
     "--release-channel=stable"
     "--set=build.rustc=${rustPlatform.rust.rustc}/bin/rustc"
     "--set=build.cargo=${rustPlatform.rust.cargo}/bin/cargo"
     "--enable-rpath"
     "--enable-vendor"
-    "--build=${stdenv.buildPlatform.config}"
-    "--host=${stdenv.hostPlatform.config}"
-    "--target=${stdenv.targetPlatform.config}"
+    "--build=x86_64-unknown-linux-gnu"
+    "--host=x86_64-unknown-linux-gnu"
+    "--target=x86_64-unknown-linux-musl"

-    "${setBuild}.cc=${ccForBuild}"
-    "${setHost}.cc=${ccForHost}"
-    "${setTarget}.cc=${ccForTarget}"
+    "--set=target.x86_64-unknown-linux-gnu.cc=${ccGlibc}"
+    "--set=target.x86_64-unknown-linux-gnu.linker=${ccGlibc}"
+    "--set=target.x86_64-unknown-linux-gnu.cxx=${cxxGlibc}"

-    "${setBuild}.linker=${ccForBuild}"
-    "${setHost}.linker=${ccForHost}"
-    "${setTarget}.linker=${ccForTarget}"
+    "--set=target.x86_64-unknown-linux-musl.cc=${ccMusl}"
+    "--set=target.x86_64-unknown-linux-musl.linker=${ccMusl}"
+    "--set=target.x86_64-unknown-linux-musl.cxx=${cxxMusl}"

-    "${setBuild}.cxx=${cxxForBuild}"
-    "${setHost}.cxx=${cxxForHost}"
-    "${setTarget}.cxx=${cxxForTarget}"
+    "--set=target.x86_64-unknown-linux-musl.musl-root=${muslRoot}"
   ] ++ optional (!withBundledLLVM) [
     "--enable-llvm-link-shared"
-    "${setBuild}.llvm-config=${llvmSharedForBuild}/bin/llvm-config"
-    "${setHost}.llvm-config=${llvmSharedForHost}/bin/llvm-config"
-    "${setTarget}.llvm-config=${llvmSharedForTarget}/bin/llvm-config"
+    "--set=target.x86_64-unknown-linux-gnu.llvm-config=${llvmSharedForBuild}/bin/llvm-config"
   ] ++ optional stdenv.isLinux [
     "--enable-profiler" # build libprofiler_builtins
   ];
@@ -132,7 +139,7 @@ in stdenv.mkDerivation rec {

   # remove references to llvm-config in lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so
   # and thus a transitive dependency on ncurses
-  postInstall = ''
+  postInstall = optionalString (!withBundledLLVM) ''
     find $out/lib -name "*.so" -type f -exec remove-references-to -t ${llvmShared} '{}' '+'
   '';

The idea is that I really, really don't want to go through the pkgsCross infrastructure as this involves using a regular rustc (pkgsBuild) but then build two static rustcs (pkgsHost + pkgsTarget) when using pkgsStatic (not even sure this is possible). Instead I'd rather just instruct the rustc build system to build an extra target (i.e. stdlib) targetting musl. The above works well (modulo the withBundledLLVM which I've always set to true so far).
Would love to hear your thoughts @dtzWill @matthewbauer .

If you are looking at cross-compilating with rustc, maybe you can check out github.com/tenx-tech/cargo2nix
Although, one major blocker with compiling musl binaries is that openssl on musl stops building at the moment, and it unfortunately prevents any meaningful networking application from being built.

FWIW, I just ran into this when investigating moving the firecracker derivation to be build-from-source. I can build the x86_64-unknown-linux-gnu target just fine, but the upstream project recommends using the x86_64-unknown-linux-musl target (and this is important since it provides its' own "jailer" that doesn't know about Nix).
It'd be convenient if I could just give target = "x86_64-unknown-linux-musl"; to rustPlatform.buildRustPackage, but that doesn't work today.

I got triggered into working on this, or at least a relevant part on it.
I managed to build static GUI apps with GTK (https://github.com/nh2/static-haskell-nix/issues/50#issuecomment-558569895), and next want to build static Rust GUI apps.
Of course I'll publish/upstream what I currently have in my git tree, but for the impatient and my own record, I needed
export LD_LIBRARY_PATH="${stdenv.cc.cc.lib}/lib:$LD_LIBRARY_PATH"

got get around the libgcc_s.so error, and commit https://github.com/NixOS/nixpkgs/commit/14ee26ccf5cf5f1d320a0a5d249a6b6ae3f2b105#diff-fb2bc02945c6ee61a9ea9fd6aeddd789 which brings upstream rustc commit https://github.com/rust-lang/rust/pull/63173/commits/5941acd80faaf9043cb48737c47d0b94023eddc3 in which fixes the couldn't find libunwind.a in musl dir error, using llvmPackages_9.libraries.libunwind.

Also super relevant are the Alpine package description and its patches: https://git.alpinelinux.org/aports/tree/community/rust?id=351e828ddb447e649acfc38775596d290f92cb05

Full output of my current blocker:
   Compiling rustc_save_analysis v0.0.0 (/build/rustc-1.39.0-src/src/librustc_save_analysis)
   Compiling rustc-main v0.0.0 (/build/rustc-1.39.0-src/src/rustc)
    Finished release [optimized] target(s) in 8m 01s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-musl -> x86_64-unknown-linux-musl / x86_64-unknown-linux-musl)
Building stage0 codegen artifacts (x86_64-unknown-linux-musl -> x86_64-unknown-linux-musl, llvm)
   Compiling build_helper v0.1.0 (/build/rustc-1.39.0-src/src/build_helper)
   Compiling cc v1.0.35
   Compiling rustc_codegen_llvm v0.0.0 (/build/rustc-1.39.0-src/src/librustc_codegen_llvm)
   Compiling rustc_llvm v0.0.0 (/build/rustc-1.39.0-src/src/librustc_llvm)
error: failed to run custom build command for `rustc_llvm v0.0.0 (/build/rustc-1.39.0-src/src/librustc_llvm)`

Caused by:
  process didn't exit successfully: `/build/rustc-1.39.0-src/build/x86_64-unknown-linux-musl/stage0-codegen/release/build/rustc_llvm-3aa2ad75c0334416/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=REAL_LIBRARY_PATH_VAR
cargo:rerun-if-env-changed=REAL_LIBRARY_PATH
cargo:rerun-if-changed=/nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/bin/llvm-config
cargo:rerun-if-env-changed=LLVM_CONFIG
cargo:rustc-cfg=llvm_component="aarch64"
cargo:rustc-cfg=llvm_component="amdgpu"
cargo:rustc-cfg=llvm_component="arm"
cargo:rustc-cfg=llvm_component="asmparser"
cargo:rustc-cfg=llvm_component="bitreader"
cargo:rustc-cfg=llvm_component="bitwriter"
cargo:rustc-cfg=llvm_component="hexagon"
cargo:rustc-cfg=llvm_component="instrumentation"
cargo:rustc-cfg=llvm_component="ipo"
cargo:rustc-cfg=llvm_component="linker"
cargo:rustc-cfg=llvm_component="lto"
cargo:rustc-cfg=llvm_component="mips"
cargo:rustc-cfg=llvm_component="msp430"
cargo:rustc-cfg=llvm_component="nvptx"
cargo:rustc-cfg=llvm_component="powerpc"
cargo:rustc-cfg=llvm_component="riscv"
cargo:rustc-cfg=llvm_component="sparc"
cargo:rustc-cfg=llvm_component="systemz"
cargo:rustc-cfg=llvm_component="webassembly"
cargo:rustc-cfg=llvm_component="x86"
cargo:rustc-cfg=llvm_has_msp430_asm_parser
cargo:rerun-if-changed-env=LLVM_RUSTLLVM
cargo:rerun-if-changed=../rustllvm/Linker.cpp
cargo:rerun-if-changed=../rustllvm/ArchiveWrapper.cpp
cargo:rerun-if-changed=../rustllvm/PassWrapper.cpp
cargo:rerun-if-changed=../rustllvm/rustllvm.h
cargo:rerun-if-changed=../rustllvm/.editorconfig
cargo:rerun-if-changed=../rustllvm/RustWrapper.cpp
cargo:rerun-if-changed=../rustllvm/README
TARGET = Some("x86_64-unknown-linux-musl")
OPT_LEVEL = Some("2")
HOST = Some("x86_64-unknown-linux-musl")
CXX_x86_64-unknown-linux-musl = Some("/nix/store/k1bj2ldn9572pdf3szq60k7iln45rjwz-gcc-wrapper-8.3.0/bin/c++")
CXXFLAGS_x86_64-unknown-linux-musl = Some("-ffunction-sections -fdata-sections -fPIC -m64")
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,mmx,sse,sse2")
running: "/nix/store/k1bj2ldn9572pdf3szq60k7iln45rjwz-gcc-wrapper-8.3.0/bin/c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include" "-std=c++11" "-fno-exceptions" "-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-D__STDC_LIMIT_MACROS" "-DLLVM_COMPONENT_AARCH64" "-DLLVM_COMPONENT_AMDGPU" "-DLLVM_COMPONENT_ARM" "-DLLVM_COMPONENT_ASMPARSER" "-DLLVM_COMPONENT_BITREADER" "-DLLVM_COMPONENT_BITWRITER" "-DLLVM_COMPONENT_HEXAGON" "-DLLVM_COMPONENT_INSTRUMENTATION" "-DLLVM_COMPONENT_IPO" "-DLLVM_COMPONENT_LINKER" "-DLLVM_COMPONENT_LTO" "-DLLVM_COMPONENT_MIPS" "-DLLVM_COMPONENT_MSP430" "-DLLVM_COMPONENT_NVPTX" "-DLLVM_COMPONENT_POWERPC" "-DLLVM_COMPONENT_RISCV" "-DLLVM_COMPONENT_SPARC" "-DLLVM_COMPONENT_SYSTEMZ" "-DLLVM_COMPONENT_WEBASSEMBLY" "-DLLVM_COMPONENT_X86" "-DNDEBUG" "-o" "/build/rustc-1.39.0-src/build/x86_64-unknown-linux-musl/stage0-codegen/x86_64-unknown-linux-musl/release/build/rustc_llvm-40f65fabdfc6e7e7/out/../rustllvm/PassWrapper.o" "-c" "../rustllvm/PassWrapper.cpp"
cargo:warning=In file included from /nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include/llvm-c/DataTypes.h:28,
cargo:warning=                 from /nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include/llvm-c/Types.h:17,
cargo:warning=                 from /nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include/llvm-c/BitReader.h:22,
cargo:warning=                 from ../rustllvm/rustllvm.h:1,
cargo:warning=                 from ../rustllvm/PassWrapper.cpp:6:
cargo:warning=/nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/include/c++/8.3.0/cmath:45:15: fatal error: math.h: No such file or directory
cargo:warning= #include_next <math.h>
cargo:warning=               ^~~~~~~~
cargo:warning=compilation terminated.
exit code: 1

--- stderr
thread 'main' panicked at '

Internal error occurred: Command "/nix/store/k1bj2ldn9572pdf3szq60k7iln45rjwz-gcc-wrapper-8.3.0/bin/c++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include" "-std=c++11" "-fno-exceptions" "-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-D__STDC_LIMIT_MACROS" "-DLLVM_COMPONENT_AARCH64" "-DLLVM_COMPONENT_AMDGPU" "-DLLVM_COMPONENT_ARM" "-DLLVM_COMPONENT_ASMPARSER" "-DLLVM_COMPONENT_BITREADER" "-DLLVM_COMPONENT_BITWRITER" "-DLLVM_COMPONENT_HEXAGON" "-DLLVM_COMPONENT_INSTRUMENTATION" "-DLLVM_COMPONENT_IPO" "-DLLVM_COMPONENT_LINKER" "-DLLVM_COMPONENT_LTO" "-DLLVM_COMPONENT_MIPS" "-DLLVM_COMPONENT_MSP430" "-DLLVM_COMPONENT_NVPTX" "-DLLVM_COMPONENT_POWERPC" "-DLLVM_COMPONENT_RISCV" "-DLLVM_COMPONENT_SPARC" "-DLLVM_COMPONENT_SYSTEMZ" "-DLLVM_COMPONENT_WEBASSEMBLY" "-DLLVM_COMPONENT_X86" "-DNDEBUG" "-o" "/build/rustc-1.39.0-src/build/x86_64-unknown-linux-musl/stage0-codegen/x86_64-unknown-linux-musl/release/build/rustc_llvm-40f65fabdfc6e7e7/out/../rustllvm/PassWrapper.o" "-c" "../rustllvm/PassWrapper.cpp" with args "c++" did not execute successfully (status code exit code: 1).

', /build/rustc-1.39.0-src/vendor/cc/src/lib.rs:2398:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

command did not execute successfully: "/nix/store/21gn0gg7h187wfbw8jb6ywi5id7vi1yw-cargo-bootstrap-1.38.0/bin/cargo" "build" "-Zconfig-profile" "--target" "x86_64-unknown-linux-musl" "-Zbinary-dep-depinfo" "-j" "12" "--release" "--frozen" "--manifest-path" "/build/rustc-1.39.0-src/src/librustc_codegen_llvm/Cargo.toml" "--features" "" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
failed to run: /build/rustc-1.39.0-src/build/bootstrap/debug/bootstrap build --jobs 12

I've given up on rustc as packaged in nixpkgs. I'm using this instead, copied and tweaked from an older version of nixpkgs:
Only in rust/: 1_38_0.nix
Only in rust/: 1_39_0.nix
diff /Users/nicolas/nixpkgs/pkgs/development/compilers/rust/bootstrap.nix rust/bootstrap.nix
1c1
< { stdenv, fetchurl, callPackage, version, hashes }:
---
> { stdenv, fetchurl, callPackage }:
3a4,17
>   # Note: the version MUST be one version prior to the version we're
>   # building
>   version = "1.38.0";
>
>   # fetch hashes by running `print-hashes.sh 1.38.0`
>   hashes = {
>    i686-unknown-linux-gnu = "41aed8a350e24a0cac1444ed99b3dd24a90bc581dd88cb420c6e547d6b5f57af";
>    x86_64-unknown-linux-gnu = "adda26b3f0609dbfbdc2019da4a20101879b9db2134fae322a4e863a069ec221";
>    armv7-unknown-linux-gnueabihf = "8b1bf1680a61a643d6b5c7a3b1a1ce88448652756395e20ba5846739cbd085c4";
>    aarch64-unknown-linux-gnu = "06afd6d525326cea95c3aa658aaa8542eab26f44235565bb16913ac9d12b7bda";
>    i686-apple-darwin = "cdbf2807774bed350a3af6f41d7f7dd7ceff28777cde310c3ba90033188eb2f8";
>    x86_64-apple-darwin = "bd301b78ddcd5d4553962b115e1dca5436dd3755ed323f86f4485769286a8a5a";
>   };
>
diff /Users/nicolas/nixpkgs/pkgs/development/compilers/rust/default.nix rust/default.nix
1,6d0
< { rustcVersion
< , rustcSha256
< , bootstrapVersion
< , bootstrapHashes
< , selectRustPackage
< }:
12c6
< , pkgsBuildTarget, pkgsBuildBuild
---
> , path
19c13,14
<     buildRustPackage = callPackage ../../../build-support/rust {
---
>     # XXX: we should probably replace this with naersk
>     buildRustPackage = callPackage (path + /pkgs/build-support/rust) {
22c17
<       fetchcargo = buildPackages.callPackage ../../../build-support/rust/fetchcargo.nix {
---
>       fetchcargo = buildPackages.callPackage (path + /pkgs/build-support/rust/fetchcargo.nix) {
45,48c40
<     prebuilt = callPackage ./bootstrap.nix {
<       version = bootstrapVersion;
<       hashes = bootstrapHashes;
<     };
---
>     prebuilt = callPackage ./bootstrap.nix {};
55c47
<           (selectRustPackage buildPackages).packages.prebuilt);
---
>           buildPackages.rust.packages.prebuilt);
59c51
<       buildRustPackages = (selectRustPackage buildPackages).packages.stable;
---
>       buildRustPackages = buildPackages.rust.packages.stable;
63,65d54
<         version = rustcVersion;
<         sha256 = rustcSha256;
<
70,72c59,61
<         pkgsBuildBuild = pkgsBuildBuild // { targetPackages.stdenv = llvmPackages_5.stdenv; };
<         pkgsBuildHost = pkgsBuildBuild // { targetPackages.stdenv = llvmPackages_5.stdenv; };
<         pkgsBuildTarget = pkgsBuildTarget // { targetPackages.stdenv = llvmPackages_5.stdenv; };
---
>         #pkgsBuildBuild = pkgsBuildBuild // { targetPackages.stdenv = llvmPackages_5.stdenv; };
>         #pkgsBuildHost = pkgsBuildBuild // { targetPackages.stdenv = llvmPackages_5.stdenv; };
>         #pkgsBuildTarget = pkgsBuildTarget // { targetPackages.stdenv = llvmPackages_5.stdenv; };
Common subdirectories: /Users/nicolas/nixpkgs/pkgs/development/compilers/rust/rls and rust/rls
diff /Users/nicolas/nixpkgs/pkgs/development/compilers/rust/rust-src.nix rust/rust-src.nix
9c9
<     rm -rf $out/{ci,doc,etc,grammar,llvm-project,llvm-emscripten,rtstartup,rustllvm,test,tools,vendor,stdarch}
---
>     rm -rf $out/{ci,doc,driver,etc,grammar,llvm,rt,rtstartup,rustllvm,test,tools,vendor}
diff /Users/nicolas/nixpkgs/pkgs/development/compilers/rust/rustc.nix rust/rustc.nix
1c1,2
< { stdenv, removeReferencesTo, pkgsBuildBuild, pkgsBuildHost, pkgsBuildTarget
---
> { stdenv, removeReferencesTo
> , lib
3c4
< , llvm_9, darwin, git, cmake, rustPlatform
---
> , llvm_8, llvmPackages_8, darwin, git, cmake, rustPlatform
7,8c8,12
< , version
< , sha256
---
> , pkgsStatic
> , pkgs
> , runCommand
> , musl
> , makeWrapper
10a15,23
> # We make some assumptions about the platform below, this is just a sanity
> # check
> assert
>   if stdenv.isLinux then
>     stdenv.buildPlatform.config == "x86_64-unknown-linux-gnu"
>   else
>     stdenv.buildPlatform.config == "x86_64-apple-darwin"
>   ;
>
11a25,33
>   targets =
>     [
>       "${stdenv.buildPlatform.config}"
>       "wasm32-unknown-unknown"
>     ]
>     # on Linux we also build the musl target for fully static executables
>     ++ lib.optionals stdenv.isLinux [ "x86_64-unknown-linux-musl" ]
>     ;
>   host = stdenv.buildPlatform.config;
15,18d36
<   llvmSharedForBuild = pkgsBuildBuild.llvm_9.override { enableSharedLibraries = true; };
<   llvmSharedForHost = pkgsBuildHost.llvm_9.override { enableSharedLibraries = true; };
<   llvmSharedForTarget = pkgsBuildTarget.llvm_9.override { enableSharedLibraries = true; };
<
20c38
<   llvmShared = llvm_9.override { enableSharedLibraries = true; };
---
>   llvmShared = llvm_8.override { enableSharedLibraries = true; };
23c41
<   inherit version;
---
>   version = "1.39.0";
27c45
<     inherit sha256;
---
>     sha256 = "0mwkc1bnil2cfyf6nglpvbn2y0zfbv44zfhsd5qg4c9rm6vgd8dl";
48c66
<     ++ optional stdenv.isDarwin "-rpath ${llvmSharedForHost}/lib";
---
>     ++ optional stdenv.isDarwin "-rpath ${llvmShared}/lib";
56,64c74,94
<     setBuild  = "--set=target.${stdenv.buildPlatform.config}";
<     setHost   = "--set=target.${stdenv.hostPlatform.config}";
<     setTarget = "--set=target.${stdenv.targetPlatform.config}";
<     ccForBuild  = "${pkgsBuildBuild.targetPackages.stdenv.cc}/bin/${pkgsBuildBuild.targetPackages.stdenv.cc.targetPrefix}cc";
<     cxxForBuild = "${pkgsBuildBuild.targetPackages.stdenv.cc}/bin/${pkgsBuildBuild.targetPackages.stdenv.cc.targetPrefix}c++";
<     ccForHost  = "${pkgsBuildHost.targetPackages.stdenv.cc}/bin/${pkgsBuildHost.targetPackages.stdenv.cc.targetPrefix}cc";
<     cxxForHost = "${pkgsBuildHost.targetPackages.stdenv.cc}/bin/${pkgsBuildHost.targetPackages.stdenv.cc.targetPrefix}c++";
<     ccForTarget  = "${pkgsBuildTarget.targetPackages.stdenv.cc}/bin/${pkgsBuildTarget.targetPackages.stdenv.cc.targetPrefix}cc";
<     cxxForTarget = "${pkgsBuildTarget.targetPackages.stdenv.cc}/bin/${pkgsBuildTarget.targetPackages.stdenv.cc.targetPrefix}c++";
---
>     ccForBuild  = "${stdenv.cc}/bin/${stdenv.cc.targetPrefix}cc";
>     cxxForBuild = "${stdenv.cc}/bin/${stdenv.cc.targetPrefix}c++";
>
>     # musl-enabled cc, used in linux builds
>     ccMusl  = "${pkgsStatic.stdenv.cc}/bin/${pkgsStatic.stdenv.cc.targetPrefix}cc";
>     cxxMusl = "${pkgsStatic.stdenv.cc}/bin/${pkgsStatic.stdenv.cc.targetPrefix}c++";
>     muslRoot =
>       # the musl-root requires a libunwind.a, so we provide one from llvm
>       # XXX: create ticket about libunwind.a from LLVM breaking because rustc
>       # doesn't link-in libstdc++
>       let libunwind = pkgsStatic.callPackage ../packages/libunwind.nix
>             { enableShared = false; };
>       in
>       runCommand "musl-root" {}
>     ''
>       mkdir -p $out
>       cp -r ${musl}/* $out
>       chmod +w $out/lib
>       cp ${libunwind}/lib/libunwind.a $out/lib/libunwind.a
>     '';
>
73,86c103
<     "--target=${stdenv.targetPlatform.config}"
<
<     "${setBuild}.cc=${ccForBuild}"
<     "${setHost}.cc=${ccForHost}"
<     "${setTarget}.cc=${ccForTarget}"
<
<     "${setBuild}.linker=${ccForBuild}"
<     "${setHost}.linker=${ccForHost}"
<     "${setTarget}.linker=${ccForTarget}"
<
<     "${setBuild}.cxx=${cxxForBuild}"
<     "${setHost}.cxx=${cxxForHost}"
<     "${setTarget}.cxx=${cxxForTarget}"
<   ] ++ optional (!withBundledLLVM) [
---
>     "--target=${lib.concatStringsSep "," targets}"
88,91c105,117
<     "${setBuild}.llvm-config=${llvmSharedForBuild}/bin/llvm-config"
<     "${setHost}.llvm-config=${llvmSharedForHost}/bin/llvm-config"
<     "${setTarget}.llvm-config=${llvmSharedForTarget}/bin/llvm-config"
<   ] ++ optional stdenv.isLinux [
---
>     "--set=target.${stdenv.buildPlatform.config}.llvm-config=${llvmShared}/bin/llvm-config"
>     ] ++ lib.optionals stdenv.isLinux
>     [
>     "--set=target.x86_64-unknown-linux-gnu.cc=${ccForBuild}"
>     "--set=target.x86_64-unknown-linux-gnu.linker=${ccForBuild}"
>     "--set=target.x86_64-unknown-linux-gnu.cxx=${cxxForBuild}"
>
>     "--set=target.x86_64-unknown-linux-musl.cc=${ccMusl}"
>     "--set=target.x86_64-unknown-linux-musl.linker=${ccMusl}"
>     "--set=target.x86_64-unknown-linux-musl.cxx=${cxxMusl}"
>     "--set=target.x86_64-unknown-linux-musl.musl-root=${muslRoot}"
>
>
93c119,124
<   ];
---
>     ] ++ lib.optionals stdenv.isDarwin
>     [
>     "--set=target.x86_64-apple-darwin.cc=${ccForBuild}"
>     "--set=target.x86_64-apple-darwin.linker=${ccForBuild}"
>     "--set=target.x86_64-apple-darwin.cxx=${cxxForBuild}"
>     ];
125c156
<     which libffi removeReferencesTo pkgconfig
---
>     which libffi removeReferencesTo pkgconfig makeWrapper
136a168
>   # XXX: change path wrapping
138a171,176
>
>     # rustdoc needs a cc
>     # we wrap it with a new PATH until 1.39:
>     # https://github.com/rust-lang/cargo/issues/7529
>     wrapProgram $out/bin/rustdoc \
>       --prefix PATH ":" "${stdenv.cc}/bin"
diff /Users/nicolas/nixpkgs/pkgs/development/compilers/rust/setup-hook.sh rust/setup-hook.sh
2c2
< if [[ -z ${IN_NIX_SHELL-} && -z ${CARGO_HOME-} ]]; then
---
> if [[ -z $IN_NIX_SHELL && -z $CARGO_HOME ]]; then

with libunwind:
# We need libunwind-9.0.0 because earlier versions link c++ symbols we don't
# have to have to link to
{ fetchurl, stdenv, cmake, enableShared ? true }:
let
  version = "9.0.0";
  fetch = sha256: fetchurl {
    url = "https://releases.llvm.org/${version}/libunwind-${version}.src.tar.xz";
    inherit sha256;
  };
in
stdenv.mkDerivation rec {
  pname = "libunwind";
  inherit version;

  src = fetch "1chd1nz4bscrs6qa7p8sqgk5df86ll0frv0f451vhks2w44qsslp";

  nativeBuildInputs = [ cmake ];

  enableParallelBuilding = true;

  cmakeFlags = stdenv.lib.optional (!enableShared) "-DLIBUNWIND_ENABLE_SHARED=OFF";
}

Hope that helps, let me know if you have any questions.

Still struggling with the includ error.
$ /nix/store/k1bj2ldn9572pdf3szq60k7iln45rjwz-gcc-wrapper-8.3.0/bin/c++ "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I/nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include" "-std=c++11" "-fno-exceptions" "-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-D__STDC_LIMIT_MACROS" "-DLLVM_COMPONENT_AARCH64" "-DLLVM_COMPONENT_AMDGPU" "-DLLVM_COMPONENT_ARM" "-DLLVM_COMPONENT_ASMPARSER" "-DLLVM_COMPONENT_BITREADER" "-DLLVM_COMPONENT_BITWRITER" "-DLLVM_COMPONENT_HEXAGON" "-DLLVM_COMPONENT_INSTRUMENTATION" "-DLLVM_COMPONENT_IPO" "-DLLVM_COMPONENT_LINKER" "-DLLVM_COMPONENT_LTO" "-DLLVM_COMPONENT_MIPS" "-DLLVM_COMPONENT_MSP430" "-DLLVM_COMPONENT_NVPTX" "-DLLVM_COMPONENT_POWERPC" "-DLLVM_COMPONENT_RISCV" "-DLLVM_COMPONENT_SPARC" "-DLLVM_COMPONENT_SYSTEMZ" "-DLLVM_COMPONENT_WEBASSEMBLY" "-DLLVM_COMPONENT_X86" "-DNDEBUG" "-o" "/build/rustc-1.39.0-src/build/x86_64-unknown-linux-musl/stage0-codegen/x86_64-unknown-linux-musl/release/build/rustc_llvm-40f65fabdfc6e7e7/out/../rustllvm/PassWrapper.o" "-c" "../rustllvm/PassWrapper.cpp" -idirafter asdf -v
...
 search starts here:
#include <...> search starts here:
 /nix/store/9zg130vcrkz1rfrkjrxrh94wqgzgadr1-file-5.37/include
 /nix/store/26n4hxnaw8rkfvw20f3v23cg2wyp32id-python-2.7.16/include
 /nix/store/n6rwwc63pzxc03bphc8ac6fdkyxfwpgf-libffi-3.2.1-dev/include
 /nix/store/djr3xbw4k3w8nm6qxv884vahfhw2szm5-musl-1.1.22-dev/include
 /nix/store/khkpaayqdqzv5ja88jjwsi5zg07xk4jk-openssl-1.1.1d-dev/include
 /nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include
 /nix/store/5cjsn99jwpyfc03y1va0xdhwd12vs7di-ncurses-6.1-20190112-dev/include
 /nix/store/kav11lvmpykhr8ikn4r1wzdhzl4330fq-zlib-1.2.11-dev/include
 /nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/lib/gcc/x86_64-unknown-linux-musl/8.3.0/../../../../include/c++/8.3.0
 /nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/lib/gcc/x86_64-unknown-linux-musl/8.3.0/../../../../include/c++/8.3.0/x86_64-unknown-linux-musl
 /nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/lib/gcc/x86_64-unknown-linux-musl/8.3.0/../../../../include/c++/8.3.0/backward
 /nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/include
 /nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/lib/gcc/x86_64-unknown-linux-musl/8.3.0/include
 /nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/lib/gcc/x86_64-unknown-linux-musl/8.3.0/include-fixed
End of search list.
GNU C++11 (GCC) version 8.3.0 (x86_64-unknown-linux-musl)
	compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.17.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 648f9d22571b7b9c46e5f05e2d3aee6f
In file included from /nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include/llvm-c/DataTypes.h:28,
                 from /nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include/llvm-c/Types.h:17,
                 from /nix/store/77cdrqqd7icjca7y91ivlrj9k9igaf1d-llvm-9.0.0/include/llvm-c/BitReader.h:22,
                 from ../rustllvm/rustllvm.h:1,
                 from ../rustllvm/PassWrapper.cpp:6:
/nix/store/68kld13k9h11lj13zk3il4x6fxncwxkh-gcc-8.3.0/include/c++/8.3.0/cmath:45:15: fatal error: math.h: No such file or directory
 #include_next <math.h>
               ^~~~~~~~
compilation terminated.

I can't figure out how to add stuff to the end of the search path.
Even my -idirafter asdf is added before the relevant includes.

I got it to build.
-idirafter on the musl include dir didn't work because the musl path was already a normal -isystem, and the deduplication logic ignored -idirafter in that case.
My mistake was to add musl/musl.dev to buildInputs of rustc in the first place.

Next obstacle:
error: cannot produce proc-macro for `failure_derive v0.1.5` as the target `x86_64-unknown-linux-musl` does not support these crate types
``

Which is probably https://github.com/rust-lang/rust/issues/40174.

@nh2 that's because you're cross compiling rustc itself, which means that the proc macro crates (TH) need to be compiled for that target as well, though unfortunately (AFAIR) they must be dynamically linked (like GHC by default only loading .sos for TH), that's when I gave up

that's because you're cross compiling rustc itself

@nmattia But I'm not cross compiling (using none of the cross infrastructure), I'm just compiling with musl as my libc.
(I've also clarified with an edit that I have finished building rustc, the next build error is in compiling cargo with the finished rustc.)
My understanding of the situation from the linked issue https://github.com/rust-lang/rust/issues/40174 is that when the musl --target is given, rust compiles only static executables and libraries (not sure why, perhaps they thought that's the main thing you want to do with musl? If yes it that assumption should probably be discard), and proc macro crates need shared libs.
I think the Alpine patches in https://git.alpinelinux.org/aports/tree/community/rust?id=351e828ddb447e649acfc38775596d290f92cb05 handle this, also by introducing a custom targets (e.g. x86_64-alpine-linux-musl in alpine-target.patch). We probably have to do something similar.

I have commented upstream: https://github.com/rust-lang/rust/pull/58575#issuecomment-568098210

I have commented upstream: rust-lang/rust#58575 (comment)

Apparently this is fixed in 1.44.0-beta: https://github.com/rust-lang/rust/issues/40174#issuecomment-619007306

Still important to me - would love to get this in nixpkgs!

I was able to build rustc 1.47 with musl target without any modifications. I tried to build fd and got a result, but it instantly segfaults on start.

Oh! It works fine when I use rustc 1.45, because it the issue described above is https://github.com/NixOS/nixpkgs/issues/94228. So we already have a rustc compiler capable of building for musl in nixpkgs, and it is even in the binary cache. Maybe we should add a line to the static overlay to set the default rust version to 1.45 when building pkgsStatic.*.

This works:
with import <nixpkgs> {}; pkgsStatic.fd.override {
  rustPlatform = makeRustPlatform rustPackages_1_45;
}

And this works as well:
with import <nixpkgs> {}; pkgsStatic.fd.overrideAttrs (oA: {
  CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER = "${llvmPackages_9.lld}/bin/lld";
})

I would rather not pin to 1.45. You're on the right track I think, using lld instead of gold. I've fixed one bug with gold in https://github.com/NixOS/nixpkgs/pull/101666, but I don't think that's the only thing wrong with it. At this point, my suggestion is to disable it entirely for Musl.

@petabyteboy do you have any code example on how to use that to make buildRustPackage works for musl target? do we need to compile rustc using musl target? Right now I'm using rustc from nixpkgs-mozilla.

Yes. The examples above actually use buildRustPackage since the fd derivation I'm overriding is using buildRustPackage. But here's another example with a package that's defined in the example file itself:
with import <nixpkgs> {
  overlays = [
    (self: super: {
      mypackage = self.rustPlatform.buildRustPackage {
        pname = "mypackage";
        version = "1.0.0";
        src = ./.;
        cargoSha256 = "...";
        CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER = "${self.buildPackages.llvmPackages_10.l
ld}/bin/lld";
      };
    })
  ];
};

pkgsStatic.mypackage

@petabyteboy thank you very much!! I've tried with your setup, I get this error:
sl --frozen
   Compiling libc v0.2.80
error[E0463]: can't find crate for `std`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `libc`

To learn more, run the command again with --verbose.

I think I am at rustPackages_1_48. The rustc is compiled actually. Now I am still trying with rustPackages_1_45. In case I'm missing something, if you want to look into the repo, this is what I got so far.
As for nixpkgs-mozilla, I'll try open issue there.

There's no need to override the rust compiler or to set the target/TARGET variable in the build environment when you have crossSystem. Also no need to explicitly use prev.pkgsStatic anywhere. All buildInputs will be automatically cross-compiled as static libraries as well. If you still need to change something about libraries to make them compile statically, you can add this to a crossOverlay.

The issue you are seeing is with the new Rust 1.48 that was merged with staging-next this week.

@petabyteboy thank you! so I have use rustPackages_1_45 but still got this error:
error: cannot produce dylib for `rustc_driver v0.0.0 (/tmp/nix-build-rustc-1.45.2-x86_64-unknown-linux-musl.drv-0/rustc-1.45.2-src/src/librustc_driver)` as the target `x86_64-unknown-linux-musl` does not support these crate types
command did not execute successfully: "/nix/store/9n9adic3pfzixw5dcfavv18z257ri62j-cargo-1.45.2/bin/cargo" "build" "--target" "x86_64-unknown-linux-musl" "-Zdual-proc-macros" "-Zbinary-dep-depinfo" "-j" "1" "--release" "--frozen" "--features" " llvm" "--manifest-path" "/tmp/nix-build-rustc-1.45.2-x86_64-unknown-linux-musl.drv-0/rustc-1.45.2-src/src/rustc/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
failed to run: /tmp/nix-build-rustc-1.45.2-x86_64-unknown-linux-musl.drv-0/rustc-1.45.2-src/build/bootstrap/debug/bootstrap build --jobs 1
Build completed unsuccessfully in 2:26:19
make: *** [Makefile:18: all] Error 1

Now I'm still building the package again (compiling rustc every time I failed is really tedious :p)
I'll let you know the progress.

Try Rust 1.47 from nixpkgs 24eb3f87fc610f18de7076aee7c5a84ac5591e3e

You can find another example here: https://github.com/petabyteboy/chaostomato/blob/main/default.nix
The CI for that that repository uses the binary cache at https://chaostomato.cachix.org/. You should be able to reproduce the result using this command:
nix build -f https://github.com/petabyteboy/chaostomato/archive/a3349078b9625d204aee7f9994e019d7f58a1ce5.tar.gz \
  --option trusted-public-keys "chaostomato.cachix.org-1:MtFdKLf8Hkmsih2TNxX8X3mnQdR0Xr8+BHpQoVr1TE8= cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=" \
  --option substituters "https://chaostomato.cachix.org https://cache.nixos.org/" \
  pkgsStatic.chaostomato

Try Rust 1.47 from nixpkgs 24eb3f8

@petabyteboy using rust 1.47 works, thanks. Though I haven't used it to build openssl. Using latest nixpkgs, I got an error in LLVM build.

It’s unclear from the comments if this now simply works, and could be closed?

I haven't read all the thread, but I sucessfully cross-compiled a x86_64 linux musl executable with crate2nix.


perf: update auro-icon version

Alaska Airlines Pull Request
Type of change:
Please delete options that are not relevant.

[ ] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team
Summary by Sourcery
Enhancements:

Update auro-icon version to the latest release.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Translated manual pages to ja_JP

I translated all untranslated manual pages into Japanese.
Sorry for the number of files.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Wow that's huge, thank you so much!