Re: Librsvg 2.41.0 is released

2017-01-05 Thread Hubert Figuière 
Hi,

On 05/01/17 09:58 PM, Michael Catanzaro wrote:
> On Thu, 2017-01-05 at 19:25 -0600, Federico Mena Quintero wrote:
>> That *will* download, compile, and link stuff like gtk-rs statically
>> into librsvg.so.  I don't think this is a problem in the long term: 
>> with things like Flatpak we are already moving away from distros
>> trying
>> to mandate which dependencies one uses, and moving towards developers
>> making that choice on their own.
> 
> Hi,
> 
> It's a total blocker for inclusion in Fedora, where builds have no
> network access, and where we are very strongly discouraged from linking
> to libraries like gtk-rs. I imagine openSUSE is going to have the same
> network access problem, right? Have you tried building it on OBS?


Reading this:

https://czanik.blogs.balabit.com/2016/07/how-to-package-rust-applications-to-rpm-using-vendoring/

(It is from July and the tools have evolved).

Maybe `make dist` could perform a `cargo vendor`, and we could make this
the standard practice?


Hub
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Michael Catanzaro 
On Thu, 2017-01-05 at 19:25 -0600, Federico Mena Quintero wrote:
> That *will* download, compile, and link stuff like gtk-rs statically
> into librsvg.so.  I don't think this is a problem in the long term: 
> with things like Flatpak we are already moving away from distros
> trying
> to mandate which dependencies one uses, and moving towards developers
> making that choice on their own.

Hi,

It's a total blocker for inclusion in Fedora, where builds have no
network access, and where we are very strongly discouraged from linking
to libraries like gtk-rs. I imagine openSUSE is going to have the same
network access problem, right? Have you tried building it on OBS?

We all want the new Rustified librsvg to make its way into
distributions as soon as possible. I doubt it's going to happen anytime
soon so long as the build involves cargo, so I really hope we can find
some solution to this. Rust is critical to hardening future GNOME
software against attackers, and it's awesome that Federico has been
pushing this forward with librsvg. Now we surely don't want some silly
build system issue blocking that from going out to users.

I also don't agree that Flatpak makes static linking acceptable for
librsvg, because librsvg is a very important platform library and part
of our GNOME runtime. We're probably going to want to have gtk-rs in
the runtime sooner or later to promote Rust development, right? Surely
we're not going to want two different copies of it there.

On Thu, 2017-01-05 at 19:25 -0600, Federico Mena Quintero wrote:
> If you really want to avoid librsvg 2.41 for jhbuild, then hardcode
> it
> to the 2.40.16 tarball.  I will not be doing any maintenance on the
> 2.40 series anymore.
> 
> In the meantime, build systems are really not my thing, and I would
> appreciate help in making this all work with jhbuild / gnome-
> continuous.

I have it working in jhbuild now with that branch (which points to your
2.40.16 commit). I could just as well have used a tarball; no
preference from me there.

By the way, is 2.41.0 a stable release? Maybe should we call it 2.42.0
then? cargo aside, packagers are kinda trained to ignore those odd
minor versions and might need some prodding to realize it should be
shipped.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Nirbheek Chauhan 
On Fri, Jan 6, 2017 at 6:59 AM, Federico Mena Quintero
 wrote:
> On Thu, 2017-01-05 at 20:21 +0100, Michael Biebl wrote:
>>
>> It has been mentioned on #debian-devel that rustc is really only
>> supported on i386 and amd64 (as a so-called tier1 architecture).
>> https://buildd.debian.org/status/package.php?p=rustc=sid looks
>> pretty sad.
>>
>> Just curious if you aware of this limited portability?
>>
>
> Yes, and I don't lose sleep over it :)
>
> A couple of years ago people were screaming that GNOME didn't build on
> S390.  Some distro picked up the work and now things are fine.  I
> expect them to do the same for Rust.
>

Speaking of s390, it looks like there's people on the Rust end that
are using it and working on it too :)

https://twitter.com/gwesfisher/status/817175453559570433
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Federico Mena Quintero 
On Thu, 2017-01-05 at 20:21 +0100, Michael Biebl wrote:
> 
> It has been mentioned on #debian-devel that rustc is really only
> supported on i386 and amd64 (as a so-called tier1 architecture).
> https://buildd.debian.org/status/package.php?p=rustc=sid looks
> pretty sad.
> 
> Just curious if you aware of this limited portability?
> 

Yes, and I don't lose sleep over it :)

A couple of years ago people were screaming that GNOME didn't build on
S390.  Some distro picked up the work and now things are fine.  I
expect them to do the same for Rust.

  Federico
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Federico Mena Quintero 
On Thu, 2017-01-05 at 11:37 -0600, Michael Catanzaro wrote:
> 
> Hm, I'm excited for Rust, but I think we probably do not want GNOME
> to
> depend on an alternative package manager like cargo, right? At least
> that would require some serious discussion here first.

Librsvg still uses autotools; it just calls cargo when building the
Rust sub-library, that is then linked statically into the final
librsvg.so.

That *will* download, compile, and link stuff like gtk-rs statically
into librsvg.so.  I don't think this is a problem in the long term: 
with things like Flatpak we are already moving away from distros trying
to mandate which dependencies one uses, and moving towards developers
making that choice on their own.

> For now, I've pushed an librsvg-2-40 branch and switched jhbuild to
> use
> that. Please remember to update jhbuild and Continuous when adding
> new
> dependencies. ;)

If you really want to avoid librsvg 2.41 for jhbuild, then hardcode it
to the 2.40.16 tarball.  I will not be doing any maintenance on the
2.40 series anymore.

In the meantime, build systems are really not my thing, and I would
appreciate help in making this all work with jhbuild / gnome-
continuous.

  Federico
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Emmanuele Bassi 
I'd be very careful in framing this issue in absolute terms like you've
been doing. For instance, I think you need to be explicit in saying you're
speaking with your Fedora packager hat on. Personally, I have no problem in
having people rely on pip, cpanm, npm, or cargo to get their software in
order to build ours - just like I have no issues when people need
autoconf-archive for a fancy m4 macro. I would not ask programmers that
wish to add to our platform to bend over backwards and use tools that are
not part of the common workflow of their community and platform in order to
satisfy the requirements imposed by third parties like Linux distributions.

"It downloads third party software" is not a convincing rationale when we
are pushing for things like Flatpak, or when we use things like SCSS to
generate our CSS.

Additionally, the fact that something that is commonly used by millions of
developers around the world is "unacceptable" to Linux distributions is
what I was referring to as "routing around". Personally, I couldn't care
less about the damage inflicted upon me by Linux distributors, so to me
there is no problem to be solved at all - just a reality that should have
long since been accepted, like bundling.

Ciao,
 Emmanuele.

On Thu, 5 Jan 2017 at 21:06, Michael Catanzaro  wrote:

> On Thu, 2017-01-05 at 18:25 +, Emmanuele Bassi wrote:
>
> > I don't see why not. Cargo is not just a "package manager" (unless by
>
> > "package manager" you mean "something that clones a list of Git
>
> > repositories") but also the preferred build system for Rust.
>
>
>
> It downloads third-party software, which is sure to be unacceptable for
>
> virtually all of our distributors. I expect we will have to handle this
>
> the same way we do pip: not use it at all.
>
>
>
> I trust the developers most interested in promoting Rust in the GNOME
>
> ecosystem are also be interested in solving this build system problem.
>
> meson already has some degree of support for Rust, for example. No
>
> doubt this is a challenge that can be surmounted.
>
>
>
> Michael
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Michael Catanzaro 
On Thu, 2017-01-05 at 18:25 +, Emmanuele Bassi wrote:
> I don't see why not. Cargo is not just a "package manager" (unless by
> "package manager" you mean "something that clones a list of Git
> repositories") but also the preferred build system for Rust.

It downloads third-party software, which is sure to be unacceptable for
virtually all of our distributors. I expect we will have to handle this
the same way we do pip: not use it at all.

I trust the developers most interested in promoting Rust in the GNOME
ecosystem are also be interested in solving this build system problem.
meson already has some degree of support for Rust, for example. No
doubt this is a challenge that can be surmounted.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Michael Biebl 
Hi there!

2017-01-04 1:48 GMT+01:00 Federico Mena Quintero :
> Librsvg 2.41.0 is just released!
>
> This is the first version to have Rust code in it.  The public API
> remains unchanged.  Apologies in advance to distros who will have to
> adjust their build systems for Rust - it's like taking a one-time
> vaccine; you'll be better off in the end for it.

It has been mentioned on #debian-devel that rustc is really only
supported on i386 and amd64 (as a so-called tier1 architecture).
https://buildd.debian.org/status/package.php?p=rustc=sid looks pretty sad.

Just curious if you aware of this limited portability?

[1] https://forge.rust-lang.org/platform-support.html
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Ross Burton 
On 5 January 2017 at 18:25, Emmanuele Bassi  wrote:

> As for Continuous, we should be able to add Rust to the Yocto base.
> Unfortunately, the build bot is still not running (and it hasn't been
> building images since early December), and I don't have access to it
> to check why.
>

There's a meta-rust layer already, although I've not actually used it yet
to vouch for how good/bad it is.

Ross
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Emmanuele Bassi 
On 5 January 2017 at 17:37, Michael Catanzaro  wrote:
> On Tue, 2017-01-03 at 18:48 -0600, Federico Mena Quintero wrote:
>> Librsvg 2.41.0 is just released!
>>
>> This is the first version to have Rust code in it.  The public API
>> remains unchanged.  Apologies in advance to distros who will have to
>> adjust their build systems for Rust - it's like taking a one-time
>> vaccine; you'll be better off in the end for it.
>
> Hm, I'm excited for Rust, but I think we probably do not want GNOME to
> depend on an alternative package manager like cargo, right?

I don't see why not. Cargo is not just a "package manager" (unless by
"package manager" you mean "something that clones a list of Git
repositories") but also the preferred build system for Rust.

> At least
> that would require some serious discussion here first.

I don't see why *GNOME* should discuss about this at all. This is a
build dependency, not a run time dependency. Sending an email to
distributor-list ought to be enough.

The new build dependency, on the other hand, may require some
additional discussion on a Linux distribution's mailing list — though,
considering the fact that every single programming language community
has been routing around Linux distributions for the past 20 years, I
don't expect anything to be resolved.

> For now, I've pushed an librsvg-2-40 branch and switched jhbuild to use
> that. Please remember to update jhbuild and Continuous when adding new
> dependencies. ;)

Rust and Cargo should just be part of the system dependencies; you
don't want to build them via jhbuild.

As for Continuous, we should be able to add Rust to the Yocto base.
Unfortunately, the build bot is still not running (and it hasn't been
building images since early December), and I don't have access to it
to check why.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

2017-01-05 Thread Michael Catanzaro 
On Tue, 2017-01-03 at 18:48 -0600, Federico Mena Quintero wrote:
> Librsvg 2.41.0 is just released!
> 
> This is the first version to have Rust code in it.  The public API
> remains unchanged.  Apologies in advance to distros who will have to
> adjust their build systems for Rust - it's like taking a one-time
> vaccine; you'll be better off in the end for it.

Hm, I'm excited for Rust, but I think we probably do not want GNOME to
depend on an alternative package manager like cargo, right? At least
that would require some serious discussion here first.

For now, I've pushed an librsvg-2-40 branch and switched jhbuild to use
that. Please remember to update jhbuild and Continuous when adding new
dependencies. ;)

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list