Tumbleweed - Review of the week 2018/03

classic Classic list List threaded Threaded
104 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: btrfs /var changes

Thorsten Kukuk
On Sun, Jan 21, Richard Brown wrote:

> #2 The guide assumes @ is the correct subvoulme to add the new /var.
> This is incorrect for many many users.
> @ does not exist on any installations that are upgraded from old
> release versions of openSUSE (including installations of Tumbleweed
> circa 2015 or earlier - it was only introduced around the period of
> Leap 42.1 IIRC)

Everybody not having /@ should do a fresh installation asap if he
plans to use snapshots or rollback ...

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs /var changes

Thorsten Kukuk
In reply to this post by Andrei Borzenkov
On Sun, Jan 21, Andrei Borzenkov wrote:

> You cannot forbid users to chose arbitrary filesystem layout during
> installation. If this is so dangerous, snapper should refuse to perform
> rollback (or even create snapshots actually). If snapper allows it, how
> can you blame users?

Because snapper makes a filesystem snapshot and rollback, not a system
snapshot.
What is the difference? snapper does not care at all if this is your
home partition, data partition or root filesystem. This doesn't make
any difference for snapper. And since snapper does not know what you
snapshot and if rollback can work, it cannot warn you.

That's why snapper/rollback of the root filesystem is only supported
with the default filesystem layout (including /@) and nothing else.
But this does not mean, that you cannot create a complete different
layout which works, too. As we e.g. did for openSUSE Kubic.

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Aleksa Sarai
In reply to this post by John Paul Adrian Glaubitz
On 2018-01-21, John Paul Adrian Glaubitz <[hidden email]> wrote:
> >> This is actually a huge change as librsvg is a core library with a large
> >> number of reverse dependencies now partially written in a programming
> >> language with limited architecture support.
> >
> > Yes, I agree this is a problem -- maybe we should keep around an old
> > version of librsvg purely for "tier 2" architecture support?
>
> Aren't arm64, ppc64el and s390x tier 1 architectures in SLE?

I meant "tier 2" from the PoV of Rust, not SLE.

> >> Finally, one problem with Rust that I ran into when working on the
> >> Rust compiler code itself is the high volatility of the language and the
> >> code. Things that used to build fine with Rust 1.19 would break with
> >> 1.20 and so on. From a distribution maintainer's point of view, this
> >> can be very tedious and annoying.
> >
> > This is not correct for the *stable* compiler, because they provide
> > stability guarantees for it and they do regular "crater runs" (rebuild
> > every crate in the Rust ecosystem, checking if there are any new errors
> > or warnings). I find it quite improbable that you hit this issue in the
> > *stable* compiler (and if you did, it was a bug, and I hope you reported
> > it). The *unstable* compiler (by it's nature) doesn't provide any such
> > guarantees.
>
> One example for this is the fact that you need exactly version N-1 to
> build version N of the Rust compiler. Using a slightly older version or
> even version N does not work. Tried that several times.
This is an exception, not the rule, and is something that is solved by
packaging (as it has been solved in openSUSE with the bootstrap
packages). There are several other compilers that have this requirement
(Go does for example -- though to be honest we ignore it when packaging
for the most part).

--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Matthias Gerstner
In reply to this post by Marco Calistri-3
Hi,

> >>   * Default firewall module picked for new installs is now firewalld
> >
> > when will SuSEfirewall2 be migrated to the new firewalld?
> >
> > tks,
> >
> ...And what happens to users which are relying on Susefirewall2 with
> custom rules and settings?
>
> The firewalld migration is/will be mandatory/silent or could be decided
> by the user?
We're in the process of changing the default firewall from SuSEfirewall2
to firewalld for SLE-15 and openSUSE Leap 15. The YaST installer should
now be able to enable/disable firewalld and open/close the ssh port for
it.

The YaST firewall module will try to start the firewall-config X
application for configuring firewalld at the moment. There will be some
time without a YaST curses GUI for firewalld. firewalld comes with the
firewall-cmd command line tool for configuring it.

There will not be an automated migration path from an old SuSEfirewall2
configuration to a firewalld configuration. There is a package
"susefirewall2-to-firewalld" which contains a utility for converting
SuSEfirewall2 configurations to firewalld. It's only a supporting tool
that tries to do the right thing. But it requires manual interaction and
review of the resulting firewall rules.

SuSEfirewall2 can stay in Tumbleweed for the moment but there are no
plans to ship it as a legacy module in releases (at least not in
SLE-15). SuSEfirewall2 and firewalld can live side by side but the user
needs to take care that only one of them is active at any time.

For users that extensively use SuSEfirewall2 with custom rules etc.
I recommend to carefully setup new firewall rules using firewalld
command line or GUI utilities. firewalld allows to pass raw iptables
rules and also so called "rich rules" (proprietary simpler syntax
provided by firewalld). These can be used to add custom rules to
firewalld that are not otherwise covered by firewalld features.

Regards

Matthias

--
Matthias Gerstner <[hidden email]>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
https://www.suse.com/security
Telefon: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553

SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nuernberg)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

John Paul Adrian Glaubitz
In reply to this post by Aleksa Sarai
On 01/22/2018 02:09 AM, Aleksa Sarai wrote:
>> Aren't arm64, ppc64el and s390x tier 1 architectures in SLE?
>
> I meant "tier 2" from the PoV of Rust, not SLE.

Yes, I know. It was more a rhetorical question to underline the
problem. But it was probably unnecessary.

>> One example for this is the fact that you need exactly version N-1 to
>> build version N of the Rust compiler. Using a slightly older version or
>> even version N does not work. Tried that several times.
>
> This is an exception, not the rule, and is something that is solved by
> packaging (as it has been solved in openSUSE with the bootstrap
> packages).

"@daym Have you tried building Rust with exactly one version before?
  Rust version 1.x only supports bootstrapping from version 1.(x-1), not
  1.(x-2) or below, and also not 1.x or newer. And can you maybe paste an
  error somewhere?"

> https://github.com/rust-lang/rust/issues/45593#issuecomment-340187339

You also realize this when you try building rustc from source. When you
build 1.23, it downloads 1.22 and so on.

Furthermore, keeping Firefox up to date already puts requirements on
the Rust version. I can't find the mailing list thread at the moment,
but one of Debian's Rust maintainers who also works upstream at Mozilla
has said that Rust always has to be updated as well when you want
to update Firefox. This is very problematic for LTS distributions when
they are shipping Firefox ESR which is going to introduce a Rust
dependency with the next ESR release which will be version 60.

So, if SLE wants to update to the next ESR release of Firefox, it
will also have to include Rust in the same maintenance request.

> There are several other compilers that have this requirement
> (Go does for example -- though to be honest we ignore it when packaging
> for the most part).

That's not true. Golang-go can be built using gcc-go which can be bootstrapped
purely from C. In fact, the Golang-Go compiler is currrently built using gcc-go
in Debian.

Upstream Go always ensures that golang-go can be built with gcc-go. Rust
has mrustc for that, but that one isn't supporting anything beyond
x86 at the moment.

Adrian
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs /var changes

Roger Whittaker-2
In reply to this post by Thorsten Kukuk
On Sun, Jan 21, 2018 at 10:06:00PM +0100, Thorsten Kukuk wrote:

> Everybody not having /@ should do a fresh installation asap if he
> plans to use snapshots or rollback ...

I found that when doing a fresh installation one gets a different
result (/@ or not /@) according to which of the two choices under
"Expert Partitioning" one chooses.

Using the choice that is "based on existing partitions" I didn't get
/@ even if I had already manually removed the old root partition.



--
============================
Roger Whittaker
[hidden email]
============================
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Mykola Krachkovsky
In reply to this post by Patrick Shanahan-2
неділя, 21 січня 2018 р. 15:05:23 EET Patrick Shanahan написано:
> * Mykola Krachkovsky <[hidden email]> [01-21-18 07:44]:
> > IMHO, there is no sense to port SuSEfirewall2 (Perl front-end for
> > iptables) to firewalld (another, Python, front-end for iptables). But
> > making GUI for YaST, something like yast-firewalld, looks fine.
>
> you are saying *yast-firewalld* would apply the same "custom" rules and
> settings?

No, I mean it would be your choice to keep good ol' SuSEfirewall2+yast-firewall
or migrate to firewalld+(hypothetical)yast-firewalld, using susefirewall2-to-
firewalld or just recreate custom rules manually.

--
Kind regards,
Mykola Krachkovsky
--
Найкращі побажання,
Микола Крачковський

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Aleksa Sarai
In reply to this post by John Paul Adrian Glaubitz
On 2018-01-22, John Paul Adrian Glaubitz <[hidden email]> wrote:

> > > One example for this is the fact that you need exactly version N-1 to
> > > build version N of the Rust compiler. Using a slightly older version or
> > > even version N does not work. Tried that several times.
> >
> > This is an exception, not the rule, and is something that is solved by
> > packaging (as it has been solved in openSUSE with the bootstrap
> > packages).
>
> "@daym Have you tried building Rust with exactly one version before?
>  Rust version 1.x only supports bootstrapping from version 1.(x-1), not
>  1.(x-2) or below, and also not 1.x or newer. And can you maybe paste an
>  error somewhere?"
>
> > https://github.com/rust-lang/rust/issues/45593#issuecomment-340187339
>
> You also realize this when you try building rustc from source. When you
> build 1.23, it downloads 1.22 and so on.
>
> Furthermore, keeping Firefox up to date already puts requirements on
> the Rust version. I can't find the mailing list thread at the moment,
> but one of Debian's Rust maintainers who also works upstream at Mozilla
> has said that Rust always has to be updated as well when you want
> to update Firefox. This is very problematic for LTS distributions when
> they are shipping Firefox ESR which is going to introduce a Rust
> dependency with the next ESR release which will be version 60.
I'm not sure we're understanding each other here -- my point was that
the *only* Rust project which has this policy for compiling new versions
is the Rust compiler. No other Rust project requires this. That's what I
meant by "exception, not the rule". So I agree with what you wrote, but
it doesn't have much to do with what I was trying to say, which is that
the following quote ...

> > Finally, one problem with Rust that I ran into when working on the
> > Rust compiler code itself is the high volatility of the language and the
> > code. Things that used to build fine with Rust 1.19 would break with
> > 1.20 and so on. From a distribution maintainer's point of view, this
> > can be very tedious and annoying.

... is not accurate for any project other than the Rust compiler (and
the reason for the Rust compiler having this requirement is so that they
can use new language features in the compiler itself, not because of
stability issues with the language). Any other Rust project must be able
to build on 1.x and 1.(x+1) with no changes (and the Rust compiler team
tests this quite heavily).

> So, if SLE wants to update to the next ESR release of Firefox, it
> will also have to include Rust in the same maintenance request.

We ship a new Go package with most new Docker releases as well (as they
usually update the compiler they use every couple of releases, and in
the past there were bugs where Docker would break if it was built with
the wrong compiler version). This is not really a new thing.

> > There are several other compilers that have this requirement
> > (Go does for example -- though to be honest we ignore it when packaging
> > for the most part).
>
> That's not true. Golang-go can be built using gcc-go which can be bootstrapped
> purely from C. In fact, the Golang-Go compiler is currrently built using gcc-go
> in Debian.
>
> Upstream Go always ensures that golang-go can be built with gcc-go. Rust
> has mrustc for that, but that one isn't supporting anything beyond
> x86 at the moment.
Hmmm, this is a policy that appears to have changed after the compiler
rewrite to Go. I distinctly remember watching a talk where rsc described
that they would require you to have version (n-1) of the compiler in
order to build version n -- so that the compiler could take advantage of
new language features -- and you would start the bootstrapping at go1.4.

However, the documentation (and build tools) make no mention of this and
just say that you can build everything with go1.4. That's a little bit
odd. But yes, I am aware that this is how we (and other distributions)
build Go, I was just under the impression that we packaged it this way
with go1.5 because "it just worked" and it removed the (n-1)
bootstrapping problem.

I stand corrected.

--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

John Paul Adrian Glaubitz
On 01/22/2018 04:22 PM, Aleksa Sarai wrote:
> I'm not sure we're understanding each other here -- my point was that
> the *only* Rust project which has this policy for compiling new versions
> is the Rust compiler. No other Rust project requires this. That's what I
> meant by "exception, not the rule". So I agree with what you wrote, but
> it doesn't have much to do with what I was trying to say, which is that
> the following quote ...

So, you say it's guaranteed that only the Rust compiler will only ever use
particular code that will be deprecated in release N+1 or only available
in release N-1?

I did build test it myself. I tried building Rust 1.22 with Rust 1.20
which failed with actual compiler errors, not just a warning that I have
to use the proper version. And I think it's absolutely not unlikely that
Rust project X will run into such a problem as well. What keeps Rust
project X from using certain language features that were only recently
added or removed?

The problem with Rust is simply the lack of stabilization. It's absolutely
insane that they think it's ok to break compatibility in minor versions
and it blows my mind that so many people find that acceptable.

Rust upstream lives in a universe where they think that distributions
are an outdated concept. This is why they are shipping their own
package manager and consider such breaking changes in minor releases
acceptable.

>>> Finally, one problem with Rust that I ran into when working on the
>>> Rust compiler code itself is the high volatility of the language and the
>>> code. Things that used to build fine with Rust 1.19 would break with
>>> 1.20 and so on. From a distribution maintainer's point of view, this
>>> can be very tedious and annoying.
>
> ... is not accurate for any project other than the Rust compiler (and
> the reason for the Rust compiler having this requirement is so that they
> can use new language features in the compiler itself, not because of
> stability issues with the language). Any other Rust project must be able
> to build on 1.x and 1.(x+1) with no changes (and the Rust compiler team
> tests this quite heavily).

What keeps project X from using certain features of Rust? I have seen
projects which would only build with Rust Nightly.

>> So, if SLE wants to update to the next ESR release of Firefox, it
>> will also have to include Rust in the same maintenance request.
>
> We ship a new Go package with most new Docker releases as well (as they
> usually update the compiler they use every couple of releases, and in
> the past there were bugs where Docker would break if it was built with
> the wrong compiler version). This is not really a new thing.

I don't think you always need the latest version of Go for updating
Docker. I have worked with both codebases myself and never ran into
this issue.

>> Upstream Go always ensures that golang-go can be built with gcc-go. Rust
>> has mrustc for that, but that one isn't supporting anything beyond
>> x86 at the moment.
>
> Hmmm, this is a policy that appears to have changed after the compiler
> rewrite to Go. I distinctly remember watching a talk where rsc described
> that they would require you to have version (n-1) of the compiler in
> order to build version n -- so that the compiler could take advantage of
> new language features -- and you would start the bootstrapping at go1.4.

Huh? If it changed after the compiler rewrite in Go, wouldn't that mean
that before that the compiler wasn't written in Go which means that you
didn't have that problem in the first place?

> However, the documentation (and build tools) make no mention of this and
> just say that you can build everything with go1.4. That's a little bit
> odd. But yes, I am aware that this is how we (and other distributions)
> build Go, I was just under the impression that we packaged it this way
> with go1.5 because "it just worked" and it removed the (n-1)
> bootstrapping problem.
>
> I stand corrected.

Fair enough.

Adrian
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Dominique Leuenberger / DimStar
In reply to this post by Aleksa Sarai
On Tue, 2018-01-23 at 02:22 +1100, Aleksa Sarai wrote:

>
> > > Finally, one problem with Rust that I ran into when working on the
> > > Rust compiler code itself is the high volatility of the language and the
> > > code. Things that used to build fine with Rust 1.19 would break with
> > > 1.20 and so on. From a distribution maintainer's point of view, this
> > > can be very tedious and annoying.
>
> ... is not accurate for any project other than the Rust compiler (and
> the reason for the Rust compiler having this requirement is so that they
> can use new language features in the compiler itself, not because of
> stability issues with the language). Any other Rust project must be able
> to build on 1.x and 1.(x+1) with no changes (and the Rust compiler team
> tests this quite heavily).
At least for the upgrade to rust 1.23, we needed to hunt a patch for
Firefox, because FF 57 did not build otherwise

https://build.opensuse.org/package/view_file/openSUSE:Factory/MozillaFi
refox/mozilla-rust-1.23.patch?expand=1

With Rust 1.22, FF 57 built 'just fine' - so this just as a counter-
example.

But then, new warnings/errors in newer compiler versions is not unique
to rust: gcc does that too :) (less common in 'minor version releases'
though)

Cheers
Dominique

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

John Paul Adrian Glaubitz
On 01/22/2018 04:47 PM, Dominique Leuenberger / DimStar wrote:
> But then, new warnings/errors in newer compiler versions is not unique
> to rust: gcc does that too :) (less common in 'minor version releases'
> though)

Exactly. The difference is that gcc brings such changes in major releases,
not in a new minor release after six weeks. And in the case of gcc it's
usually only a new warning that was introduced that you could even turn
off in the worst case.

The problem with Rust that I ran into was that a certain keyword was no
longer supported. So, they actually changed the language spec - in a minor
release :O.

In any case, Ubuntu, Fedora and Debian are still using the non-Rust version
of librsvg. So far, only Arch and openSUSE seem to be using the Rust
version.

Adrian
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rust (was: Tumbleweed - Review of the week 2018/03)

Alberto Planas Dominguez
In reply to this post by John Paul Adrian Glaubitz
On Mon, 2018-01-22 at 16:36 +0100, John Paul Adrian Glaubitz wrote:

> On 01/22/2018 04:22 PM, Aleksa Sarai wrote:
> > I'm not sure we're understanding each other here -- my point was
> > that
> > the *only* Rust project which has this policy for compiling new
> > versions
> > is the Rust compiler. No other Rust project requires this. That's
> > what I
> > meant by "exception, not the rule". So I agree with what you wrote,
> > but
> > it doesn't have much to do with what I was trying to say, which is
> > that
> > the following quote ...
>
> So, you say it's guaranteed that only the Rust compiler will only
> ever use
> particular code that will be deprecated in release N+1 or only
> available
> in release N-1?
>
> I did build test it myself. I tried building Rust 1.22 with Rust 1.20
> which failed with actual compiler errors, not just a warning that I
> have
> to use the proper version. And I think it's absolutely not unlikely
> that
> Rust project X will run into such a problem as well. What keeps Rust
> project X from using certain language features that were only
> recently
> added or removed?
>
> The problem with Rust is simply the lack of stabilization. It's
> absolutely
> insane that they think it's ok to break compatibility in minor
> versions
> and it blows my mind that so many people find that acceptable.

Sorry but I think that you have a missunderstanding here (or is me the
one that do not get your point)

Rust is really stable as a language. But the stability guarantee
provided by Rust needs to be understanding as this:

* I create a source S, that compile in Rust R and behaves like B

Rust guarantee that S, when compiled in R+1, R+2 .. R+n will compile,
and the result will behave like B.

There is a process of deprecation, and there is a process of optional
enablement of new features, and this section can require the removal of
some lines in future versions of the compiler, when this change is
enabled by default.

What you are referring is a different issue:

* I create a source S, that compile in Rust R and behaves like B, but I
require that my new version S+1 will also compile for the old version
of R.

That is simply ...  uhm ... like no. No one can guarantee this. A new
version of your code, if use specific features enabled in one version
of Rust, will not compile in a old version of Rust that do not provide
this feature at all.

> Rust upstream lives in a universe where they think that distributions
> are an outdated concept. This is why they are shipping their own
> package manager and consider such breaking changes in minor releases
> acceptable.

I really do not get your point. Cargo is like make, is not (and will
never be) a full feature package manager. Is true that there is an
overlap: cargo can download from crates.io, but is not the way to
install anything into the system. This is responsibility of the OS. Is
only a helper to the developer, during the development process.

Cargo is a living code, that is attached to the Rust version. There is
a relation between both, so generaly an update of one require the
update of the other. What is wrong with that?

> What keeps project X from using certain features of Rust? I have seen
> projects which would only build with Rust Nightly.

That is a decision of the developer. I can agree that some code that
depends on Nightly are not good candidates to be package in the OS
(like Rocket). But this do not make any 'wrong thing' in the Rust side.
Is the developer who decide that the unestable feature that is provided
with nightly is OK for the project. Eventually this feature will live
in stable (or not), and in any case is responsibility of the developer
to change the code to adjust with the new shape of this feature. But
once is there, this program (in this exact version) will compile in any
future Rust.

You have the same problem with C++, but in a different speed. I can use
GNU options, or C++17 in my new version of the project, that of course
will not copile in gcc 4.6.

--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Hadrien Grasland
In reply to this post by John Paul Adrian Glaubitz
Hi John,

Just chipping in as a Rust developer, and wanted to clear up what I
perceive as some misunderstanding:


Le 22/01/2018 à 16:36, John Paul Adrian Glaubitz a écrit :

> On 01/22/2018 04:22 PM, Aleksa Sarai wrote:
>> I'm not sure we're understanding each other here -- my point was that
>> the *only* Rust project which has this policy for compiling new versions
>> is the Rust compiler. No other Rust project requires this. That's what I
>> meant by "exception, not the rule". So I agree with what you wrote, but
>> it doesn't have much to do with what I was trying to say, which is that
>> the following quote ...
>
> So, you say it's guaranteed that only the Rust compiler will only ever
> use
> particular code that will be deprecated in release N+1 or only available
> in release N-1?

The Rust compiler uses unstable internal interfaces, which are not
exposed to code which builds on stable releases. The closest equivalent
which I can think of in the C/++ world is the GCC/binutils duo: to build
and use GCC, you need a matching release of binutils, which maps to a
relatively narrow time window. Use too new or too old a release of
binutils, and your GCC build will fail with weird assembler and linker
errors. And conversely, like any C/++ program, binutils itself has some
compiler version requirements.

This does not preclude GCC and binutils from providing stability
guarantees on the programs which they accept to compile, but it is a
concern that must be kept in mind when maintaining GCC and binutils
packages. From this perspective, the Rust compiler's bootstrapping
requirements are not different.


> I did build test it myself. I tried building Rust 1.22 with Rust 1.20
> which failed with actual compiler errors, not just a warning that I have
> to use the proper version. And I think it's absolutely not unlikely that
> Rust project X will run into such a problem as well. What keeps Rust
> project X from using certain language features that were only recently
> added or removed?

Since Rust 1.0, users of stable versions of the Rust compiler enjoy a
number of stability guarantees:

  * Stable language features may only be added and deprecated, not
    removed, so code which builds on version N is guaranteed to build on
    version N+1.
  * While feature removal and breaking changes to existing features are
    eventually planned, they will be done via an epoch mechanism similar
    to the one used by C and C++. Think about C 89/99/11 and C++
    98/11/14/17.

In short, the only thing that must be taken care of, from a distribution
maintainer's perspective, is that an application must be compiled with a
sufficiently recent stable Rust compiler. This is not a new concern
(e.g. it has been an issue in the C++ world for a while). If, on the
other hand, you find a package which does not build with a _newer_
release of the Rust compiler than was available at its release date, it
is a bug, and you should report it to the Rust team.


>
> The problem with Rust is simply the lack of stabilization. It's
> absolutely
> insane that they think it's ok to break compatibility in minor versions
> and it blows my mind that so many people find that acceptable.

Adding features in a minor software release is considered okay in any
modern software versioning scheme. It is only when existing features are
changed or removed that compatibility is considered to be broken.


> Rust upstream lives in a universe where they think that distributions
> are an outdated concept. This is why they are shipping their own
> package manager and consider such breaking changes in minor releases
> acceptable.

You must understand where they are coming from. Most Linux distributions
consider it okay to ship software which lags 5+ years behind official
upstream releases, which is not acceptable for a fast-moving software
project like Rust (or even to any software project where new releases
matter, such as hardware drivers, web browsers, and office suites). And
some of the platforms that they target do not ship a standard package
management mechanism at all. The rolling release users among us are
sadly the minority here.

Rust's distribution tools cater to the vast majority of users who are
stuck with obsolete operating system packages and want to get modern
work done nonetheless. To do this, they sometimes need to bypass the
standard distribution package management scheme. But this need not
concern you as a distribution maintainer, much like you need not be
concerned about users who build and install more recent software
releases from source: what users do with their machine is solely their
business, so long as they don't come complain when their personal
fiddling breaks the system.


>
>>>> Finally, one problem with Rust that I ran into when working on the
>>>> Rust compiler code itself is the high volatility of the language
>>>> and the
>>>> code. Things that used to build fine with Rust 1.19 would break with
>>>> 1.20 and so on. From a distribution maintainer's point of view, this
>>>> can be very tedious and annoying.
>>
>> ... is not accurate for any project other than the Rust compiler (and
>> the reason for the Rust compiler having this requirement is so that they
>> can use new language features in the compiler itself, not because of
>> stability issues with the language). Any other Rust project must be able
>> to build on 1.x and 1.(x+1) with no changes (and the Rust compiler team
>> tests this quite heavily).
>
> What keeps project X from using certain features of Rust? I have seen
> projects which would only build with Rust Nightly.

Software which opts into nightly-only unstable Rust features should be
considered unstable as well, and is not a good fit for distribution via
normal Linux distribution package management schemes. It should thus be
rejected from official Linux distribution repositories. Users who want
to install and use such packages will be fine with manually building
their own versions, and dealing with compiler breakages as they happen.

Cheers,
Hadrien
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Hadrien Grasland
In reply to this post by John Paul Adrian Glaubitz
Hi Adrian,


Le 22/01/2018 à 16:54, John Paul Adrian Glaubitz a écrit :

> On 01/22/2018 04:47 PM, Dominique Leuenberger / DimStar wrote:
>> But then, new warnings/errors in newer compiler versions is not unique
>> to rust: gcc does that too :) (less common in 'minor version releases'
>> though)
>
> Exactly. The difference is that gcc brings such changes in major
> releases,
> not in a new minor release after six weeks. And in the case of gcc it's
> usually only a new warning that was introduced that you could even turn
> off in the worst case.

...that is, until you end up on a codebase which:

  * Has -Werror hardcoded deep into its build system.
  * Relies on code which does not follow the C/++ standard to get
    compiled by accident.
  * Relies on undefined behaviour, or another codegen characteristic
    that is considered an unimportant detail by GCC's optimizer.
  * Uses compiler version detection macros which have not been adapted
    to the new GCC release.
  * Causes an ICE in that specific release of GCC, which was introduced
    by accident in what was supposed to be a simple bugfix.

Relying on UB especially happens more often than one would think, and is
basically the kernel of truth behind the old "-O3 breaks code" meme.

No matter which way one looks at it, compiler updates are unfortunately
always a bit of a risky business from a Linux distribution maintainer's
point of view.


>
> The problem with Rust that I ran into was that a certain keyword was no
> longer supported. So, they actually changed the language spec - in a
> minor
> release :O.

If that happened to a stable Rust feature, again, this is a major bug,
and you should report it. Which keyword was that?

Cheers,
Hadrien

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

Marco Calistri-3
In reply to this post by Mykola Krachkovsky
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Il 21/01/2018 10:42, Mykola Krachkovsky ha scritto:

> субота, 20 січня 2018 р. 15:06:47 EET Marco Calistri написано:
>> Il 20/01/2018 10:51, Patrick Shanahan ha scritto:
>>> when will SuSEfirewall2 be migrated to the new firewalld?
>>>
>>> tks,
>>
>> ...And what happens to users which are relying on Susefirewall2
>> with custom rules and settings?
>>
>> The firewalld migration is/will be mandatory/silent or could be
>> decided by the user?
>>
>> Thanks and regards,
>
> IMHO, there is no sense to port SuSEfirewall2 (Perl front-end for
> iptables) to firewalld (another, Python, front-end for iptables).
> But making GUI for YaST, something like yast-firewalld, looks
> fine.

I've for the moment executed a "zypper al firewalld" since I want keep
using Susefirewall2.

Regards,

- --
Marco Calistri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJaZhUcAAoJEF8u7h9gwTTlWFQH/RSA4cPxNMCpzwNKH5sGQv+K
ENMHM+SHPJavaKgaP1A//2bS9gQF3OzNlNpT3sLvpYjCpLZjjnaHX001Ku2Q2/Z9
dGpWqgQWol3kVhVXV9kvpfc2CorY6UBLqajMim4gWGlJwghY9ZMciNpLQU8V1a9k
lfD9IcgYhoTRBZ8cuTxJZLe3iRI+5G94GJj6lQfzNNMco5YlZ1hwBUaKH8ZpxILq
7f98DGIg0SKTDINL9wukcxGeXWSC9YyQ10MOLRAidvYa0g7Mx5osR97Cl8OYTLm3
b0JsyuYnYWAaEvXp6F/b4bZ1Kr13bXZ1aJL5+RFYL/WWpxf/lgx/CK6fonIqJ0k=
=d3IM
-----END PGP SIGNATURE-----
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Reply | Threaded
Open this post in threaded view
|

Re: Rust

John Paul Adrian Glaubitz
In reply to this post by Alberto Planas Dominguez
On 01/22/2018 05:06 PM, Alberto Planas Dominguez wrote:

> Sorry but I think that you have a missunderstanding here (or is me the
> one that do not get your point)
>
> Rust is really stable as a language. But the stability guarantee
> provided by Rust needs to be understanding as this:
>
> * I create a source S, that compile in Rust R and behaves like B
>
> Rust guarantee that S, when compiled in R+1, R+2 .. R+n will compile,
> and the result will behave like B.

This is not the experience I made. I had sources that built with R-1
but not with R or R+1.

> There is a process of deprecation, and there is a process of optional
> enablement of new features, and this section can require the removal of
> some lines in future versions of the compiler, when this change is
> enabled by default.

Deprecation is fine when you do it gradually. It's too fast when you
do it between minor releases.

>> Rust upstream lives in a universe where they think that distributions
>> are an outdated concept. This is why they are shipping their own
>> package manager and consider such breaking changes in minor releases
>> acceptable.
>
> I really do not get your point. Cargo is like make, is not (and will
> never be) a full feature package manager. Is true that there is an
> overlap: cargo can download from crates.io, but is not the way to
> install anything into the system. This is responsibility of the OS. Is
> only a helper to the developer, during the development process.

Firefox makes extensive use of cargo's feature to download packages
from crate.io. I don't know why you think it's not a package manager.

> Cargo is a living code, that is attached to the Rust version. There is
> a relation between both, so generaly an update of one require the
> update of the other. What is wrong with that?

I didn't say anything about that, did I?

>> What keeps project X from using certain features of Rust? I have seen
>> projects which would only build with Rust Nightly.
>
> That is a decision of the developer. I can agree that some code that
> depends on Nightly are not good candidates to be package in the OS
> (like Rocket). But this do not make any 'wrong thing' in the Rust side.
> Is the developer who decide that the unestable feature that is provided
> with nightly is OK for the project. Eventually this feature will live
> in stable (or not), and in any case is responsibility of the developer
> to change the code to adjust with the new shape of this feature. But
> once is there, this program (in this exact version) will compile in any
> future Rust.

You can always say it's the developer's fault. However, that doesn't
really help you in this case when you're a distribution maintainer,
you're still in the situation that you cannot upgrade package X
without updating the compiler or breaking package Y.

> You have the same problem with C++, but in a different speed. I can use
> GNU options, or C++17 in my new version of the project, that of course
> will not copile in gcc 4.6.

Different speed is a huge understatement, a seriously huge understatement.

C++ or Fortran are much more careful when making such changes in order
to not break existing code bases. Simply because you cannot expect all
your users to constantly update their codebase just because they are
updating their toolchain.

And you didn't even address the problem that Rust upstream effectively
doesn't care about anything besides x86/x86_64.

Adrian
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

John Paul Adrian Glaubitz
In reply to this post by Hadrien Grasland
On 01/22/2018 05:38 PM, Hadrien Grasland wrote:
> ...that is, until you end up on a codebase which:
>
>   * Has -Werror hardcoded deep into its build system.

That doesn't make any sense. You can always override/amend CFLAGS/CXXFLAGS. There
is no such thing as "deeply hardcoded".

>   * Relies on code which does not follow the C/++ standard to get
>     compiled by accident.

Never seen that.

>   * Relies on undefined behaviour, or another codegen characteristic
>     that is considered an unimportant detail by GCC's optimizer.

Never seen that.

>   * Uses compiler version detection macros which have not been adapted
>     to the new GCC release.

That would speak of a very poor build system. Yet, I don't think I have
run into such a problem.

>   * Causes an ICE in that specific release of GCC, which was introduced
>     by accident in what was supposed to be a simple bugfix.

Very rare. So far I have only seen such problems on less common architectures
and it was always a breeze to get these things fixed with upstream.

> Relying on UB especially happens more often than one would think, and is basically the kernel of truth behind the old "-O3 breaks code" meme.
>
> No matter which way one looks at it, compiler updates are unfortunately always a bit of a risky business from a Linux distribution maintainer's point of view.

Thanks, but I have helped with several gcc transitions in Debian. I never saw anything
there as close as with Rust. The changes in gcc actually made sense to me, as I said,
I was always able to address them with either very simple patches or by just disabling
a certain warning.

What about the fact that Rust only considers x86/x86_64 to be a tier 1 architecture?

We have just recently seen with Spectre and Meltdown how bad it is to merely focus
on x86.

Adrian
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Tumbleweed - Review of the week 2018/03

John Paul Adrian Glaubitz
In reply to this post by Hadrien Grasland
On 01/22/2018 05:12 PM, Hadrien Grasland wrote:
> The Rust compiler uses unstable internal interfaces, which are not exposed to code which builds on stable releases. The closest equivalent which I can think of in the C/++ world is the GCC/binutils duo: to build and use GCC, you need a matching release of binutils, which maps to a relatively narrow time window. Use too new or too old a release of binutils, and your GCC build will fail with weird assembler and linker errors. And conversely, like any C/++ program, binutils itself has some compiler version requirements.

I'm pretty confident there is never a problem when binutils is too new,
at least I haven't run into such a problem with my porting work within
Debian.

And, furthermore, the key point here again is the speed of change: gcc
doesn't introduce breaking changes every six weeks, Rust does.

>> The problem with Rust is simply the lack of stabilization. It's absolutely
>> insane that they think it's ok to break compatibility in minor versions
>> and it blows my mind that so many people find that acceptable.
>
> Adding features in a minor software release is considered okay in any modern software versioning scheme. It is only when existing features are changed or removed that compatibility is considered to be broken.

I wouldn't consider a toolchain a normal piece of software. A toolchain is
one of the basic building blocks of your whole distribution. It shouldn't
change in crazy ways when you just perform a minor update.

>> Rust upstream lives in a universe where they think that distributions
>> are an outdated concept. This is why they are shipping their own
>> package manager and consider such breaking changes in minor releases
>> acceptable.
>
> You must understand where they are coming from. Most Linux distributions consider it okay to ship software which lags 5+ years behind official upstream releases, which is not acceptable for a fast-moving software project like Rust (or even to any software project where new releases matter, such as hardware drivers, web browsers, and office suites). And some of the platforms that they target do not ship a standard package management mechanism at all. The rolling release users among us are sadly the minority here.

Well, your perspective would change if you're responsible for maintaining
several hundreds desktop machines with several hundred users. Installing
a rolling release distribution in such setups would be a nightmare because
you would be busy all day long to fix all kinds of regressions.

And I'm not necessarily talking about regressions in the form of bugs. It
can already be a regression if feature X behaves differently or extension
Y doesn't work anymore.

It's really frustrating how many upstream projects are refusing to understand
this. So many just say "Awww, just go ahead and update to the latest upstream
version, no big deal. I've been running Arch on my single-user, single-machine
setup for years without problems." It simply doesn't work that way in the
enterprise world.

> Rust's distribution tools cater to the vast majority of users who are stuck with obsolete operating system packages and want to get modern work done nonetheless. To do this, they sometimes need to bypass the standard distribution package management scheme. But this need not concern you as a distribution maintainer, much like you need not be concerned about users who build and install more recent software releases from source: what users do with their machine is solely their business, so long as they don't come complain when their personal fiddling breaks the system.

It very much becomes concern if a new version of application X requires
an additional of 250 packages to be updated. It becomes a nightmare from
a security point of view. Who is going to review all these additional
updated packages?

What's the point of all these fancy security features Rust have when you
end up having 25 different versions of libfoo installed on your system?

You might as well then just stop installing security updates.

Adrian
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rust

Alberto Planas Dominguez
In reply to this post by John Paul Adrian Glaubitz
On Mon, 2018-01-22 at 18:08 +0100, John Paul Adrian Glaubitz wrote:
> On 01/22/2018 05:06 PM, Alberto Planas Dominguez wrote:

> > * I create a source S, that compile in Rust R and behaves like B
> >
> > Rust guarantee that S, when compiled in R+1, R+2 .. R+n will
> > compile,
> > and the result will behave like B.
>
> This is not the experience I made. I had sources that built with R-1
> but not with R or R+1.

In that case a bug report needs to be submited. After 1.0, this is not
supposed the happend. Is this happening in a public project? (sorry if
the name of this project was announced before, I joined late)

As a mater of fact there are some changes that were not backward
compatible, but those were bugs that affected the soundness of the
compiler, and the usage was not very common. In any case I am not aware
of any project that was hit by those changes.

> Firefox makes extensive use of cargo's feature to download packages
> from crate.io. I don't know why you think it's not a package manager.

For example, you cannot uninstall packages with cargo. Also was never
recommended to install anything in the system.

Is more similar to pip, gem, maven, go get, they can be used to fetch
code that is needed during the development phase. But also is like
`make`, because orchestrate the compilation.


> > Cargo is a living code, that is attached to the Rust version. There
> > is
> > a relation between both, so generaly an update of one require the
> > update of the other. What is wrong with that?
>
> I didn't say anything about that, did I?

Right. No, you didn't. My intention was extrapolate this example with
the observation that Rust N needs Rust N-1 to compile but do not work
for N-2. I didn't make my point clear, so lets forget about cargo as an
example.


> > > What keeps project X from using certain features of Rust? I have
> > > seen
> > > projects which would only build with Rust Nightly.
> >
> > That is a decision of the developer. I can agree that some code
> > that
> > depends on Nightly are not good candidates to be package in the OS
> > (like Rocket). But this do not make any 'wrong thing' in the Rust
> > side.
> > Is the developer who decide that the unestable feature that is
> > provided
> > with nightly is OK for the project. Eventually this feature will
> > live
> > in stable (or not), and in any case is responsibility of the
> > developer
> > to change the code to adjust with the new shape of this feature.
> > But
> > once is there, this program (in this exact version) will compile in
> > any
> > future Rust.
>
> You can always say it's the developer's fault. However, that doesn't
> really help you in this case when you're a distribution maintainer,
> you're still in the situation that you cannot upgrade package X
> without updating the compiler or breaking package Y.

I understand, but your argument is not fair. If a developer use
unstable features for version X, this code will compile very narrow
window of compilers, and there is not guarantee that this feature that
live in nightly will reach beta or stable. This make, by definition,
this software unsuitable for packaging.

But if a package use a version of Rust that is stable, this package
will compile when you update in OBS the version of Rust.

> > You have the same problem with C++, but in a different speed. I can
> > use
> > GNU options, or C++17 in my new version of the project, that of
> > course
> > will not copile in gcc 4.6.
>
> Different speed is a huge understatement, a seriously huge
> understatement.

Well C++03, C++11, C++14, C++17. You are right, but is not fair to
compare a language that is 35 y.o (from 1983) with one that is from
2015.

> C++ or Fortran are much more careful when making such changes in
> order
> to not break existing code bases.

And so is Rust. Changes that can affect the guarantee of back-
compatibility are evaluated against crates.io. This procude data of the
impact of the change.

>  Simply because you cannot expect all
> your users to constantly update their codebase just because they are
> updating their toolchain.

I can see that is a problem that if I want the last version of exa or
ripgrep, and this version use features included in 1.24, I will need to
update the compiler. But is not expected that this update will break
any codebase that use Rust stable.

This is a side effect of a young ecosystem, that will fade out
eventually. Also the epoch RFC will help here. But this doesn't mean
that Rust is constantly breaking your code.


> And you didn't even address the problem that Rust upstream
> effectively
> doesn't care about anything besides x86/x86_64.

Sure. Clearly FF is not running on ARM on Android. I think that you
have another missunderstanding on Tier 2 concept here [1]

[1] https://forge.rust-lang.org/platform-support.html


--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: btrfs /var changes

Achim Gratz
In reply to this post by Thorsten Kukuk
Thorsten Kukuk writes:
> Everybody not having /@ should do a fresh installation asap if he
> plans to use snapshots or rollback ...

How should I check and why is a re-install my only option?  I might do a
re-install (I did that before), but there really ought to be a way of
saving the package list and customizations someplace and have the
installer use that.  I tend to find missing packages or customizations
for the first few weeks after a re-install.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

123456