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: Rust

John Paul Adrian Glaubitz
On 01/23/2018 11:56 AM, Hadrien Grasland wrote:
> PS: By the way, if you go and have a look at the build log for the firefox package on armhf that you mention, you will find that the problem is that the build machine ran out of RAM ("terminate called after throwing an instance of 'std::bad_alloc'"). This has nothing to do with Rust, it is a common problem with large C++ projects too. You may want to beef up the corresponding build node or to reduce the amount of concurrent build processes.

This was just an example. I didn't check why the build failed *this* time.

Again, I am a build engineer at Debian for many architecture and tons of
packages have been going through my hands. You can just take my word here,
ok?

Thanks,
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 Aleksa Sarai
On 01/23/2018 12:14 PM, Aleksa Sarai wrote:> You mention that Go does a lot of testing to avoid regressions, *so does
> the Rust community*. They do a "crater run" (rebuild and unit-test of
> all crates on crates.io) on a regular cadence during development, when
> large features are being considered for merging, and for gating
> releases.

They test on x86_64/x86 *only*.

Is openSUSE x86_64/x86 only?

> If they find an issue they either fix it in the compiler (if it's a
> regression) or they go to the project itself and submit a patch (if it's
> actually a bug in the project). This is one of the things that is
> mentioned in literally every talk about the Rust development process.

Cool. Can you fix Rust on mips* and powerc32, please? I have been trying
to bootstrap it on these targets on and off for several months now.

Rust upstream is super fast and busy fixing the compiler on non-x86
platforms. NOT.

>> 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 agree that their attitude toward distributions is a problem (for us
> obviously, but also for users IMO). But this is also an attitude that is
> shared by a very large number of languages and projects these days.

The other projects aren't trying to mess with core packages, Rust does.

If NodeJS or Go blow up in your face, you aren't breaking half your
distribution. That's a HUGE difference.

> I cannot help but think that the root cause of this problem is that we
> have not done a good job (as distribution developers in general) of
> convincing people of the benefits of having a distribution that has a
> global view of packaging of a system.

I'm pretty sure we have done an excellent job at that. Otherwise we wouldn't
have customers who are giving us money for that.

You are making the mistake that you assume that people running bleeding
edge software have a large relevance for what we do. They don't.

> I think us trying to ship projects that use Rust Nightly would be
> absolute madness (I also think it's mad to depend on Rust Nightly
> features for a "stable" project, but that's a separate topic). However,
> we can avoid the nightly problem by not shipping things that depend on
> nightly (neither Firefox nor the library that spawned this discussion
> depend on Nightly).

I consider this absolute madness:

glaubitz@suse-laptop:~> osc whatdependson openSUSE:Factory librsvg standard x86_64 | wc -l
314
glaubitz@suse-laptop:~>

And this doesn't even include transitive dependencies.

>> 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.
>
> Not always, but there have been cases (we're talking ~2 years ago) where
> a Go upgrade has broken Docker in subtle ways. This was before runc was
> a separate project, and they were still using "os/exec" for parts of
> container setup (which obviously proved to be a horrible idea, and now
> we have the whole nsexec magic that I'm tasked with maintaining upstream).

The difference is that Go isn't trying to push itself as a systems programming
language trying to replace core components of a Linux distribution.

If Go breaks, it doesn't potentially affect the whole distribution. In the
case of Rust when replacing something as librsvg or coreutils with a Rust
version, it does.

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 Aleksa Sarai
On 01/23/2018 12:18 PM, Aleksa Sarai wrote:
> On 2018-01-23, John Paul Adrian Glaubitz <[hidden email]> wrote:
>> Furthermore, the distribution kernels don't bring such breaking changes,
>> plus the upstream kernel also NEVER breaks any userland.
>
> Except when they do -- in which case we chalk it up as a mistake, Linus
> gets angry at someone, and we all move along with our day. We don't
> suddenly start shouting that "Linux is unstable!".

Can you refer to a link where the Linux kernel broke userland the last
time and the patch was actually merged?

Thanks,
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

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

Le 23/01/2018 à 13:15, John Paul Adrian Glaubitz a écrit :

> On 01/23/2018 11:42 AM, Hadrien Grasland wrote:
>> Then maybe your time would be better spent working together with the
>> Rust team to ensure that they can and do run their tests on armhf as
>> well?
>
> Am I the person who is trying to push Rust everywhere?
>
> Rust upstream wants Rust to succeed as a systems programming language.
> It's
> therefore their responsibility to make sure the compiler works
> properly on
> the supported targets.
>
> If they cannot achieve that, they should stop trying to claim how
> superior
> Rust is over other languages and stop trying to push it as a systems
> programming language.
>
> I am already doing lots of upstream work in various projects. But this
> isn't my main job, so you can't expect me to do the homework of the
> Rust developers.
>
> Adrian

I appreciate your point of view. Indeed, improving upstream testing
should not be your main job as a distribution maintainer. That being
said, there is a reason why Debian lends testing hardware to projects
like the FreePascal compiler: while it is probably not the right thing
to do, it is both the nice and the pragmatic thing to do.

Given Rust's immense productivity benefits in the system programming
space with respect to C and C++, people are bound to use it. Much like
they use bleeding-edge C++, Node.js, custom package managers like Maven
and PyPI and all other kind of programming environments which make the
life of distribution maintainers hard. It is unescapable, in the sense
that you cannot simply wish the language and its implementation away
from your radar, rant about every Rust-based package that you see pass
by, and be done with it. What happens to librsvg today, is happening to
gstreamer and other GNOME projects tomorrow, and at some point you will
need to face the issue anyhow.

Given that, the next best thing to do after obliterating the perceived
nuisance is to work on making the product better so that it fits your
needs. This is what distribution maintainers have always done: if the
project is not quick enough, write the patch yourself, and send it to
upstream with a friendly note. Backport fixes from newer versions into
the version that you distribute. Help the developer test on new
architectures that the distribution supports. Ultimately, these kind of
actions benefit the distribution too.

Which is why I am saying that working with the Rust community might be
more productive, and ultimately beneficial to you, than merely
complaining about its current state.

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

Frederic Crozat-4
In reply to this post by John Paul Adrian Glaubitz
Le mardi 23 janvier 2018 à 13:26 +0100, John Paul Adrian Glaubitz a
écrit :

> On 01/23/2018 12:14 PM, Aleksa Sarai wrote:> You mention that Go does
> a lot of testing to avoid regressions, *so does
> >
> > the Rust community*. They do a "crater run" (rebuild and unit-test
> > of
> > all crates on crates.io) on a regular cadence during development,
> > when
> > large features are being considered for merging, and for gating
> > releases.
>
> They test on x86_64/x86 *only*.
>
> Is openSUSE x86_64/x86 only?
>
> >
> > If they find an issue they either fix it in the compiler (if it's a
> > regression) or they go to the project itself and submit a patch (if
> > it's
> > actually a bug in the project). This is one of the things that is
> > mentioned in literally every talk about the Rust development
> > process.
>
> Cool. Can you fix Rust on mips* and powerc32, please? I have been
> trying
> to bootstrap it on these targets on and off for several months now.

Reminder. This is the *openSUSE Factory* mailing list. 

You are really out of topic here. Please move this discussion
elsewhere.


> I consider this absolute madness:
>
> glaubitz@suse-laptop:~> osc whatdependson openSUSE:Factory librsvg
> standard x86_64 | wc -l
> 314
> glaubitz@suse-laptop:~>

How about you discuss with librsvg upstream ? 

Hint: I wouldn't be surprised if Federico follows this mailing list..

--
Frederic Crozat
Enterprise Desktop Release Manager
SUSE

--
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 Tue, 2018-01-23 at 13:12 +0100, John Paul Adrian Glaubitz wrote:
> On 01/23/2018 11:26 AM, Alberto Planas Dominguez wrote:

> > We are diverging for the main topic. Your assert is that Rust is
> > willing to break code that target stable-Rust in almost each
> > release,
> > and I think that this is a missunderstanding about the expectations
> > that are fair to use agains the compiler. That is all.
>
> No, we are not.
>
> Two main points are still valid:
>
> 1) Rust is not as stable as it should be for core packages.

But this is an affirmation that needs some data. As explained before
Rust stable will guarantee that the same package that compiles for one
version will compile for the next. I am still waiting for an example
where this is not true, and I am not able to see the build failure in
librsvg in OBS.

> 2) Rust doesn't consider architectures which SUSE considers
>     supported as supported. This is definitely a problem.

I can see a problem in S390X, is a tier 2 but I am sure that there a
bugs there. But is different for ARM: there is some effort in moving it
to tier 1.

> > https://wiki.debian.org/ftpmaster_Removals#Reverse_Dependencies
> > Sorry if I make this impression. I didn't choose the right words.
> > What
> > I try to say is that tier 2 is not exacly "doesn't care about
> > anything besides x86/x86_64". Is simply reflecting that some
> > automatic tests are not running for each commit to the compiler,
> > but is expected to work. And in the case of Android and ARM is
> > clearly working.
>
> And you are missing the point. Working now doesn't mean it's not
> going
> to break for the next version.

I am not. My point is that the affirmation "doesn't care about anything
besides x86/x86_64" is not true. There are test running for t2
architectures, but not all the time the automatic test are executed.
This indicate lack or resources and documentation, but also an effort
to change the situation.

But, we can agree that the expectations for a compiler in t2 is not
like in t1.

> Again, a compiler which is not verified to pass it's testsuite should
> not be used for production code in my experience. I have seen too
> many
> things break on the buildds in Debian when the testsuites for gcc
> were
> disabled.

We agree on this.

> Not having Rust upstream build the compiler natively and run the
> testsuite
> on architectures that SUSE considers to be supported is a problem in
> my experience.

In this too.


--
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: Rust

Dominique Leuenberger / DimStar
On Tue, 2018-01-23 at 13:49 +0100, Alberto Planas Dominguez wrote:

> On Tue, 2018-01-23 at 13:12 +0100, John Paul Adrian Glaubitz wrote:
> > On 01/23/2018 11:26 AM, Alberto Planas Dominguez wrote:
> > > We are diverging for the main topic. Your assert is that Rust is
> > > willing to break code that target stable-Rust in almost each
> > > release,
> > > and I think that this is a missunderstanding about the expectations
> > > that are fair to use agains the compiler. That is all.
> >
> > No, we are not.
> >
> > Two main points are still valid:
> >
> > 1) Rust is not as stable as it should be for core packages.
>
> But this is an affirmation that needs some data. As explained before
> Rust stable will guarantee that the same package that compiles for one
> version will compile for the next. I am still waiting for an example
> where this is not true, and I am not able to see the build failure in
> librsvg in OBS.
I did make one example of this:
https://lists.opensuse.org/opensuse-factory/2018-01/msg00488.html

granted, it's the only example I know from openSUSE Tumbleweed

Cheers
Dominique

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

Re: Rust

Alberto Planas Dominguez
In reply to this post by Hadrien Grasland
On Tue, 2018-01-23 at 13:40 +0100, Hadrien Grasland wrote:

> Which is why I am saying that working with the Rust community might
> be
> more productive, and ultimately beneficial to you, than merely
> complaining about its current state.

I really think that this is the best conclusion that we can have for
this thread.

--
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: Rust

Alberto Planas Dominguez
In reply to this post by Dominique Leuenberger / DimStar
On Tue, 2018-01-23 at 13:55 +0100, Dominique Leuenberger / DimStar
wrote:

> On Tue, 2018-01-23 at 13:49 +0100, Alberto Planas Dominguez wrote:
> > On Tue, 2018-01-23 at 13:12 +0100, John Paul Adrian Glaubitz wrote:
> > > On 01/23/2018 11:26 AM, Alberto Planas Dominguez wrote:
> > > > We are diverging for the main topic. Your assert is that Rust
> > > > is
> > > > willing to break code that target stable-Rust in almost each
> > > > release,
> > > > and I think that this is a missunderstanding about the
> > > > expectations
> > > > that are fair to use agains the compiler. That is all.
> > >
> > > No, we are not.
> > >
> > > Two main points are still valid:
> > >
> > > 1) Rust is not as stable as it should be for core packages.
> >
> > But this is an affirmation that needs some data. As explained
> > before
> > Rust stable will guarantee that the same package that compiles for
> > one
> > version will compile for the next. I am still waiting for an
> > example
> > where this is not true, and I am not able to see the build failure
> > in
> > librsvg in OBS.
>
> I did make one example of this:
> https://lists.opensuse.org/opensuse-factory/2018-01/msg00488.html
>
> granted, it's the only example I know from openSUSE Tumbleweed

Oh thanks! But this is easy to explain:

https://blog.rust-lang.org/2018/01/04/Rust-1.23.html

This is to remove a warning. Probably FF is compiling with
`deny(warnings)` somewhere.

And actually this is a good example about the stability guarantees that
Rust is expected to provide. `std::ascii::AsciiExt` is a trait that is
not used anymore, instead of dropping it from the standard library they
provide an empty trait. Because of this, a warning is generated: the
program will compile, and will behave as when it was compiled with an
older version. The issue here is that FF is considering warnings as
errors.

--
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

Michal Kubecek
In reply to this post by John Paul Adrian Glaubitz
On Tuesday, 23 January 2018 13:27 John Paul Adrian Glaubitz wrote:
> On 01/23/2018 12:18 PM, Aleksa Sarai wrote:
> > On 2018-01-23, John Paul Adrian Glaubitz <[hidden email]>
wrote:
> >> Furthermore, the distribution kernels don't bring such breaking
> >> changes, plus the upstream kernel also NEVER breaks any userland.
> >
> > Except when they do -- in which case we chalk it up as a mistake,
> > Linus gets angry at someone, and we all move along with our day. We
> > don't suddenly start shouting that "Linux is unstable!".
>
> Can you refer to a link where the Linux kernel broke userland the last
> time and the patch was actually merged?

I don't have an example at hand but there are cases when the breakage
wasn't found until the commit reached mainline (maybe even a release).
But it would be hard to find an example when it wasn't reverted after
the problem was found.

Michal Kubeček



--
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 Frederic Crozat-4
On 01/23/2018 01:46 PM, Frederic Crozat wrote:

>> I consider this absolute madness:
>>
>> glaubitz@suse-laptop:~> osc whatdependson openSUSE:Factory librsvg
>> standard x86_64 | wc -l
>> 314
>> glaubitz@suse-laptop:~>
>
> How about you discuss with librsvg upstream ?
>
> Hint: I wouldn't be surprised if Federico follows this mailing list..

I tried. Answer: INVALID, WONTFIX [1]. :-)

Adrian

> [1] https://bugzilla.gnome.org/show_bug.cgi?id=777171
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rust

John Paul Adrian Glaubitz
In reply to this post by Hadrien Grasland
On 01/23/2018 01:40 PM, Hadrien Grasland wrote:
> Given Rust's immense productivity benefits in the system programming space with respect to C and C++, people are bound to use it. Much like they use bleeding-edge C++, Node.js, custom package managers like Maven and PyPI and all other kind of programming environments which make the life of distribution maintainers hard. It is unescapable, in the sense that you cannot simply wish the language and its implementation away from your radar, rant about every Rust-based package that you see pass by, and be done with it. What happens to librsvg today, is happening to gstreamer and other GNOME projects tomorrow, and at some point you will need to face the issue anyhow.

Well, I have seen in the past what happened when GNOME upstream was ignoring downstream
complaints. There was a bug in gvfs-metadata that GNOME upstream insisted didn't exist
and just kept closing the bug report in the RedHat bug tracker.

At some point, a "strategic customer" ran into the problem as well. And, all of a sudden,
GNOME upstream admitted their mistake and fixed the bug. So, I wouldn't see GNOME as
a prime example on how software in the open source community should work.

Plus, if you look at the number of forks that GNOME's decisions have triggered in the
past (MATE, Cinnamon, Deepin etc), it clearly shows that this development model
doesn't fly in the long-term.

Also, I don't think that something like this will fly on the longterm with Linux
distributions:

glaubitz@suse-laptop:~/suse/openSUSE:Factory/librsvg/librsvg-2.42.0/rust/vendor> find . -name "*.rs" |wc -l
988
glaubitz@suse-laptop:~/suse/openSUSE:Factory/librsvg/librsvg-2.42.0/rust/vendor>

This undermines the work of security teams in Linux distributions. At least in Debian,
including third-party libraries instead of using the versions available in the distribution
tree is not allowed.

I'm very much surprised that this is apparently acceptable in openSUSE. If every
Rust package is going to be like that in the future, I'll already sent out my
condolences to anyone working on distribution security teams.

> Given that, the next best thing to do after obliterating the perceived nuisance is to work on making the product better so that it fits your needs. This is what distribution maintainers have always done: if the project is not quick enough, write the patch yourself, and send it to upstream with a friendly note. Backport fixes from newer versions into the version that you distribute. Help the developer test on new architectures that the distribution supports. Ultimately, these kind of actions benefit the distribution too.

I think you are ignoring the fact that open source projects can also be forked
and if GNOME/Freedesktop upstream is enforcing Rust onto its users before it's
ready for prime time, you will see more forks happen.

Debian (and therefore Ubuntu) is not going to adopt the rustified version of
librsvg anytime soon. So, don't count your chickens until they are hatched :-).

PS: I just tried building rust 1.23 on MIPS and POWERPC32 today, still fails.

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

John Paul Adrian Glaubitz
In reply to this post by Alberto Planas Dominguez
On 01/23/2018 01:49 PM, Alberto Planas Dominguez wrote:
>> 2) Rust doesn't consider architectures which SUSE considers
>>      supported as supported. This is definitely a problem.
>
> I can see a problem in S390X, is a tier 2 but I am sure that there a
> bugs there. But is different for ARM: there is some effort in moving it
> to tier 1.

Great, then there is only MIPS*, PPC*, and S390 left. Not even talking
about things like RISC-V or SPARC.

>> And you are missing the point. Working now doesn't mean it's not
>> going
>> to break for the next version.
>
> I am not. My point is that the affirmation "doesn't care about anything
> besides x86/x86_64" is not true. There are test running for t2
> architectures, but not all the time the automatic test are executed.
> This indicate lack or resources and documentation, but also an effort
> to change the situation.
>
> But, we can agree that the expectations for a compiler in t2 is not
> like in t1.

I just tried building Rust 1.23 on Debian unstable (MIPS) today, still
fails. Both for native and cross-builds. Tried a cross-build for PPC32
yesterday, also failed. Both architectures are Tier 2 and I didn't even
manage to get it to build, not even talking about running the testsuite.

>> Again, a compiler which is not verified to pass it's testsuite should
>> not be used for production code in my experience. I have seen too
>> many
>> things break on the buildds in Debian when the testsuites for gcc
>> were
>> disabled.
>
> We agree on this.
>
>> Not having Rust upstream build the compiler natively and run the
>> testsuite
>> on architectures that SUSE considers to be supported is a problem in
>> my experience.
>
> In this too.

Then why do you think it's ok to have librsvg rustified at this point?

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

John Paul Adrian Glaubitz
In reply to this post by Alberto Planas Dominguez
On 01/23/2018 01:56 PM, Alberto Planas Dominguez wrote:
>> Which is why I am saying that working with the Rust community might
>> be
>> more productive, and ultimately beneficial to you, than merely
>> complaining about its current state.
>
> I really think that this is the best conclusion that we can have for
> this thread.

I have:

> https://github.com/rust-lang/rust/commits?author=glaubitz
> https://github.com/rust-lang/rust/search?q=glaubitz&type=Issues&utf8=%E2%9C%93
> https://github.com/mozilla/gecko-dev/commits?author=glaubitz

I am not sure why you think I didn't do that already.

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

H.Merijn Brand
In reply to this post by John Paul Adrian Glaubitz
On Tue, 23 Jan 2018 18:16:04 +0100, John Paul Adrian Glaubitz
<[hidden email]> wrote:

> On 01/23/2018 01:49 PM, Alberto Planas Dominguez wrote:
> >> 2) Rust doesn't consider architectures which SUSE considers
> >>      supported as supported. This is definitely a problem.  
> >
> > I can see a problem in S390X, is a tier 2 but I am sure that there a
> > bugs there. But is different for ARM: there is some effort in moving it
> > to tier 1.  
>
> Great, then there is only MIPS*, PPC*, and S390 left. Not even talking
> about things like RISC-V or SPARC.
and PA-RISC/PA-RISC2 (HP-UX)

Things like this have caused nightmares for me to port OpenSource stuff
to HP-UX

--
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.27   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rust

Hadrien Grasland
In reply to this post by John Paul Adrian Glaubitz
Le 23/01/2018 à 18:16, John Paul Adrian Glaubitz a écrit :
> I just tried building Rust 1.23 on Debian unstable (MIPS) today, still
> fails. Both for native and cross-builds. Tried a cross-build for PPC32
> yesterday, also failed. Both architectures are Tier 2 and I didn't even
> manage to get it to build, not even talking about running the testsuite.

The fact that the rust team managed to build rustc 1.23 packages for
these architectures (along with many of the others that you mention) and
you don't manage suggests that rustc compatibility isn't the problem here:

https://www.rust-lang.org/fr-FR/other-installers.html

I did not find a build log at
https://buildd.debian.org/status/package.php?p=rustc&suite=sid , so I
assume you did this on a private session. Can you send me a build log so
that I can have a look, just in case something interesting stands out to
my eyes? Hopefully it's just a minor system configuration issue...

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: kernel stability

Bernhard M. Wiedemann-5
In reply to this post by Michal Kubecek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 2018-01-23 13:55, Michal Kubecek wrote:
> But it would be hard to find an example when it wasn't reverted
> after the problem was found.

things like regressions in vanilla kernel for several months
(introduced in 4.13, fixed in 4.15-rc8)
https://bugzilla.opensuse.org/show_bug.cgi?id=1075613

and regressions introduced by backports to old stable Leap kernels:
https://bugzilla.opensuse.org/show_bug.cgi?id=1063570

yes, we could downgrade to older kernels in both cases, but then you
don't have the latest security fixes which is not what you want either
for systems you actually care about.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQRk4KvQEtfG32NHprVJNgs7HfuhZAUCWmefmwAKCRBJNgs7Hfuh
ZGY3AKCfwhQU2kwjt1YJmdpfq2Hc8yxTswCfbav7LABDJWE0pWnT5aVoWet7ArI=
=Zdjl
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rust

Hadrien Grasland
In reply to this post by John Paul Adrian Glaubitz
Le 23/01/2018 à 18:11, John Paul Adrian Glaubitz a écrit :
> Plus, if you look at the number of forks that GNOME's decisions have
> triggered in the
> past (MATE, Cinnamon, Deepin etc), it clearly shows that this
> development model
> doesn't fly in the long-term.

I am not convinced by this argument. The open-source community loves to
fork projects as soon as a big changes happen (which, like any big
change, are bound to cause some disagreement), and sometimes just does
so out of the blue for the fun of it. In that sense, a fork does not
speak in any way about the well-being of the project which is being
forked, and does not usually have a lot of long-term consequences for
said project.

To convince yourself of that, consider historical examples:

  * When the KDE3 -> KDE4 transition happened, the Trinity project
    forked KDE3 (which pretty much parallels MATE with GNOME 2). And now
    that KDE is putting X11 in maintenance mode, I am ready to bet that
    some X11 enthusiast is going to fork KDE again.
  * Wayland has seen Canonical go Mir, and now NVidia are trying to
    cause a community split in there again.
  * Before systemd became the norm, there were 3 popular init clones
    around in the Linux ecosystem.
  * The BSD community dedicates most of its manpower to writing
    BSD-licensed equivalents of existing GPL-licensed code out there.

Forks and competing clones mean that there are people in a community who
disagree about something, which is generally healthy even though it has
the unfortunate effect of splitting manpower. It means that we avoid an
Apple-like stagnating technical monoculture, for example. Sometimes
forks have a good idea and prosper (like Cinnamon), or even replace
their genitor (like systemd), other times they fail to evolve beyond
their original concept, stagnate, and end up dying from technical debt
poisoning (like Unity). Nobody can tell which one it will be in advance,
I would say.

On the other hand, I find your other point more interesting:


> Also, I don't think that something like this will fly on the longterm
> with Linux
> distributions:
>
> glaubitz@suse-laptop:~/suse/openSUSE:Factory/librsvg/librsvg-2.42.0/rust/vendor>
> find . -name "*.rs" |wc -l
> 988
> glaubitz@suse-laptop:~/suse/openSUSE:Factory/librsvg/librsvg-2.42.0/rust/vendor>
>
>
> This undermines the work of security teams in Linux distributions. At
> least in Debian,
> including third-party libraries instead of using the versions
> available in the distribution
> tree is not allowed.
>
> I'm very much surprised that this is apparently acceptable in
> openSUSE. If every
> Rust package is going to be like that in the future, I'll already sent
> out my
> condolences to anyone working on distribution security teams.

This point is actually not Rust-specific in my eyes. I see it as
something which has been brewing for a while in the programming
community, and I'm surprised that the issue has never arised earlier.

The heart of the problem as far as I see it is that there is no perfect
software distribution method. Two extreme models have been popular for a
while, the Windows/OSX strategy of packaging every nontrivial dependency
with the application, and the Linux/BSD strategy of building one giant
software repository per software distribution. This dichotomy is making
the life of every multi-platform project difficult, especially so as
both strategies ultimately have very serious drawbacks:

  * The "package the world" approach not only causes oversized
    downloads, but makes backwards-compatible dependency updates (like,
    as you point out, security patches) unnecessarily slow to propagate
    through the ecosystem. Cross-application communication can also get
    fiendish in this approach, which does not encourage software to work
    together. And application installation, clean removal and update is
    also generally a mess.
  * The centralized repo approach, on its side, is much more convenient
    for the end user, but for the developer it means that software must
    be packaged N times instead of one (in order to please each
    distribution's repo management customs) and it gets very messy any
    time a dependency pushes a backwards-incompatible update. From a
    security point of view, other issues arise due because the
    centralized repo is a single point of failure, and third-party repos
    (which are often added out of necessity in order to get sufficiently
    recent software) are not held to the same quality and security
    standard as the main one.

Frustrated with this state of affair, the community of almost every
modern programming language has gone all "we can do better" and built
their own library distribution and dependency management mechanism. And
so we got Maven for Java, PyPI and Conda for Python, Gems for Ruby, go
get for Go, NPM for Javascript, Crates.io for Rust... and the list goes
on. These distribution mechanism vary widely in capabilities, but one
recurring theme is that application developers want to have more control
over their dependencies, and in particular to update them only after
in-house testing. This results in a strange hybrid between the two
historical approach:

  * There is ~one centralized repo per programming language, which is
    generally less problematic than one per Linux distribution in practice.
  * Applications package their dependencies and the one who performs the
    build gets to pick the dependency versions, like on Windows and OSX.

I am surprised that it is the first time that these custom package
management schemes get into a nontrivial conflict with the standard
system package management scheme of a Linux distro. AFAIK, these things
have been around for a long while, and even programming languages which
encourage statically linking everything are not new (think Go). So
hasn't anybody been thinking about this issue before?

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

Stefan Seyfried
In reply to this post by Hadrien Grasland
On 23.01.2018 08:46, Hadrien Grasland wrote:
> Tell that to the kernel maintainers next time they will break my video driver

If they break it, they fix it. Usually fast.

Unless you insist on using drivers of questionable legal status.

> or send someone's production system in an
> infinite bootloop in what was supposed to be a security update.

Well, the current (mainly) intel snafu is something you can hardly blame the Kernel guys for.

Apart from than, I'm running Kernel:HEAD kernels (which means: always the latest after -rc2 or so) since almost 10 years
wihtout such problems.

> And yet, for some reason, we in the Linux world never
> had much issue building on top of that.

Actually, for the kernel, there is a very strong commitment to "never break userspace" with an update.
If you find some userspace application that does no longer work after a kernel update, then Linus will make sure that
the change is reverted. No matter what.

Just one of the countless examples on lkml: https://lkml.org/lkml/2012/12/23/75

Well, unless the application has been using really *documented unstable* interfaces.


> Compared to what major Linux infrastructure projects like the kernel, Mesa, or KDE will still periodically send people
> through

Please provide an example for the Linux kernel of what they "sent you through".
And no, the illegal NVidia driver breaking does not count. Complain to NVidia about that.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rust

Bernhard M. Wiedemann-5
In reply to this post by Hadrien Grasland


On 2018-01-23 20:54, Hadrien Grasland wrote:
> I am surprised that it is the first time that these custom package
> management schemes get into a nontrivial conflict with the
> standard system package management scheme of a Linux distro. AFAIK,
> these things have been around for a long while, and even
> programming languages which encourage statically linking everything
> are not new (think Go). So hasn't anybody been thinking about this
> issue before?

we have hit these issues for years with Maven and nodejs/npm craziness
which is why an amazingly low number of these are properly packaged in
OBS, even though people would want things like etherpad, jenkins,
hadoop and more.
In some sense I feel this is hurting the spirit of open source
software, because more users and developers end up using binary blobs
without being able to build things from source.
E.g. when we build jenkins packages by taking the upstream .war file
as binary input, we cannot even apply simple patches to problems we find.

OTOH perl, python, ruby and some other ecosystems seem to often have
been considerate enough to not break backward compatibility, so that
things like gem2rpm and equivalents worked well enough to map their
concept of packages to ours.
Maybe it is also because their tools are designed to primarily ship
sources around
And maybe they also better avoid cyclic dependencies.

Ciao
Bernhard M.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

123456