Re: Librsvg 2.41.0 is released

[Colin Walters]

On Wed, Jan 18, 2017, at 05:42 PM, Colin Walters wrote:

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

I did this:

https://github.com/ostreedev/ostree/pull/669

(Previously: https://github.com/ostreedev/ostree/pull/656 )

___
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

[Colin Walters]

On Thu, Jan 5, 2017, at 10:26 PM, Hubert Figuière wrote:

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

That's a very useful post.

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

Yeah, makes sense to me in the short term, until packaging tools catch up
and some of this can be generated and shared across projects.  But that's
a huge topic, getting into handling multiple concurrent versions, Rust ABI 
stability etc.

What we're doing here with librsvg seems to be a very ambitious use of
Rust - I think something smaller like what Firefox is doing by having some
smaller bits where it'd be a build time option for a while would
help ease the transition.

I guess in practice the previous librsvg branch will be that build time option.


___
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

[Michael Catanzaro]

On Fri, 2017-01-13 at 11:34 -0600, Federico Mena Quintero wrote:
> Oh oh oh, we were talking about different things.  You are talking
> about statically linking a library that registers a GType; I was
> talking about two things (static or not) that link to a shared
> library
> that in turns registes a GType.
> 
> Yeah, your case would be a problem :)

That said, there is still a distro adoption problem. Our goal should be
to get the new librsvg into distros. Distros like Debian or Fedora
would be happy to package gtk-rs so librsvg can link to it dynamically.
Static linking is a significant barrier to adoption here.

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

[Federico Mena Quintero]

On Thu, 2017-01-12 at 11:37 -0800, Christian Hergert wrote:
> 
> Even the g_once magic is not enough because they would have separate
> data sections for the static cached type id. So the get_type() for
> the
> failed registration would have G_TYPE_INVALID.
> 
Oh oh oh, we were talking about different things.  You are talking
about statically linking a library that registers a GType; I was
talking about two things (static or not) that link to a shared library
that in turns registes a GType.

Yeah, your case would be a problem :)

  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

[Christian Hergert]

On 01/12/2017 08:11 AM, Federico Mena Quintero wrote:
> How does one get this to happen?  
> 
> Is it only a problem if two threads race to pass the same type_name to
> g_type_register_*()?
> 
> Or if a library defines a shitty foo_get_type() without the g_once
> magic from G_DEFINE_TYPE(), and gets called from two threads?

Even the g_once magic is not enough because they would have separate
data sections for the static cached type id. So the get_type() for the
failed registration would have G_TYPE_INVALID.

But even if you were careful to do a g_type_from_name() as a fallback,
you still risk the statically linked implementations being incompatible
from version skew.

___
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

[Federico Mena Quintero]

On Wed, 2017-01-11 at 18:18 -0800, Christian Hergert wrote:
> 
> Not sure, its a runtime error you would see when a downstream would
> try
> to register an already registered GType.

How does one get this to happen?  

Is it only a problem if two threads race to pass the same type_name to
g_type_register_*()?

Or if a library defines a shitty foo_get_type() without the g_once
magic from G_DEFINE_TYPE(), and gets called from two threads?

> It might work today, just something to consider. One example might be
> if
> the glib-rs marshaler decided to created a string boxed type for UTF-
> 8
> strings to avoid further deep copies.

Nah, it's Rust-only magic to deal conveniently with passing/getting
arguments to/from glib.  Where the GObject introspection annotations
say transfer-full, you can call String::from_glib_full(ptr_to_c_char);
where they say transfer-none, you can call String::from_glib_none(ptr).
 It doesn't register new GTypes at all.

  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

[Christian Hergert]

On 01/11/2017 04:06 PM, Federico Mena Quintero wrote:
> How would you write a correctness test for this?  Or what specific set
> of conditions would cause an error here?

Not sure, its a runtime error you would see when a downstream would try
to register an already registered GType.

> Librsvg *only* uses the Cairo part from gtk-rs right now; it doesn't
> use the GTK+ bindings.  It also uses little bits from glib-rs, but just
>  for marshaling strings.

It might work today, just something to consider. One example might be if
the glib-rs marshaler decided to created a string boxed type for UTF-8
strings to avoid further deep copies.

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

[Federico Mena Quintero]

On Mon, 2017-01-09 at 13:11 -0800, Christian Hergert wrote:
> 
> Does a static link of gtk-rs in librsvg prevent others from using
> gtk-rs
> in consuming applications because any GType (glue code!) has been
> registered which will conflict with an applications use of gtk-rs.

How would you write a correctness test for this?  Or what specific set
of conditions would cause an error here?

Librsvg *only* uses the Cairo part from gtk-rs right now; it doesn't
use the GTK+ bindings.  It also uses little bits from glib-rs, but just
 for marshaling strings.

  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

[Federico Mena Quintero]

On Fri, 2017-01-06 at 05:25 +0200, Adrian Perez de Castro wrote:
> them, and unpack them in the proper location. Then "cargo build"
> doesn't need
> to fetch things itself. For more on this, there's interesting
> comments here:
> 
>   https://github.com/rust-lang/cargo/issues/1330
> 
This is very interesting; thanks for the link.

I haven't submitted librsvg 2.41 to the openSUSE Build Service yet, but
this will certainly come in handy.

  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

[Zeeshan Ali (Khattak)]

Hi,

On 5 January 2017 at 19:34, Ross Burton  wrote:
>
> 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.

FWIW, We use it in Genivi Development Platform. We were using an old
git version and we faced a lot of issues with that but I'm told that
most of those issues have been resolved. We recently (3 weeks ago)
upgraded to latest git and so far haven't seen any issues.

-- 
Regards,

Zeeshan Ali
___
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

[Michael Catanzaro]

On Fri, 2017-01-06 at 05:25 +0200, Adrian Perez de Castro wrote:
> Could you elaborate on what's the issue with gtk-rs? The way things
> work, the
> code from it will be statically linked into librsvg, and if librsvg
> uses
> actual {GTK+,GLib,cairo} functions, then librsvg links *dynamically*
> to
> lib{gtk+,glib,cairo} (the ones made in C) as it would do anyway
> before when
> Rust wasn't used. Only the glue bits from gtk-rs which allow to use
> the
> libraries from Rust are linked into librsvg. Honestly, I fail to see
> how this
> is a problem.

The problem is that our distributors expect or require that
applications dynamically link to libraries. I would not expect gtk-rs
to be an exception to this rule.

On Fri, 2017-01-06 at 05:25 +0200, Adrian Perez de Castro wrote:
> > 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.
> 
> Wrong. The way things are, gtk-rs is only needed at build time.

If it's statically linked into librsvg, then there's one copy of it for
each library in the runtime that wants to use it. In five years the
runtime would wind up with several different copies of gtk-rs. This
would be a problem.

Is there some real obstacle to dynamic linking, like a normal Linux
library? This is already supported and works fine, right...?

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

[Christian Hergert]

On 01/05/2017 07:25 PM, Adrian Perez de Castro wrote:
> Could you elaborate on what's the issue with gtk-rs? The way things work, the
> code from it will be statically linked into librsvg, and if librsvg uses
> actual {GTK+,GLib,cairo} functions, then librsvg links *dynamically* to
> lib{gtk+,glib,cairo} (the ones made in C) as it would do anyway before when
> Rust wasn't used. Only the glue bits from gtk-rs which allow to use the
> libraries from Rust are linked into librsvg. Honestly, I fail to see how this
> is a problem.

I hesitate to join the conversation because I'm uninformed. But I will!

When "static linking" and GObject are used in the same sentence red
flags start flying because they often do not play well together.

I think the real question about whether or not static linking is okay
from a correctness perspective, can be framed as:

Does a static link of gtk-rs in librsvg prevent others from using gtk-rs
in consuming applications because any GType (glue code!) has been
registered which will conflict with an applications use of gtk-rs.

This must be answered first and foremost.

-- Christian



signature.asc
Description: OpenPGP digital signature
___
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

[Adrian Perez de Castro]

Hi,

A couple of thoughs inline below...

On Thu, 05 Jan 2017 20:58:48 -0600, 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?

Regarding not having network access when building: There is "cargo fetch" if
it's okay to download things in a separate step. One could potentially take a
snapshot of the dependencies needed to build librsvg, make a tarball with
them, and unpack them in the proper location. Then "cargo build" doesn't need
to fetch things itself. For more on this, there's interesting comments here:

  https://github.com/rust-lang/cargo/issues/1330

Could you elaborate on what's the issue with gtk-rs? The way things work, the
code from it will be statically linked into librsvg, and if librsvg uses
actual {GTK+,GLib,cairo} functions, then librsvg links *dynamically* to
lib{gtk+,glib,cairo} (the ones made in C) as it would do anyway before when
Rust wasn't used. Only the glue bits from gtk-rs which allow to use the
libraries from Rust are linked into librsvg. Honestly, I fail to see how this
is a problem.

> 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 think most of the negative reactions against cargo come from the fact that
people don't think about it as “it is a build tool, like Make”, but instead
as “it is a package manager, WARNING, WARNING, rpm/apt/whatever is in danger”.

(It certainly can do more things, but “build tool” is exactly how it's used
for librsvg.)

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

Wrong. The way things are, gtk-rs is only needed at build time.

Hope the clarifications/ideas above can help.

Cheers,

—
  Adrián


pgpgX1khJAwVn.pgp
Description: PGP signature
___
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

[Hubert Figuière]

On 06/01/17 08:57 AM, Michael Catanzaro wrote:
> On Thu, 2017-01-05 at 20:58 -0600, Michael Catanzaro wrote:
>> and where we are very strongly discouraged from linking
>> to libraries like gtk-rs.
> 
> Whoops, I meant to write "discouraged from static linking"

Maybr it is a misunderstanding, but gtk-rs doesn't like Gtk3 statically.
Only the Rust code is. I don't see this as an issue. The Gtk3 ABI is
still being used.


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

[Michael Catanzaro]

On Thu, 2017-01-05 at 20:58 -0600, Michael Catanzaro wrote:
> and where we are very strongly discouraged from linking
> to libraries like gtk-rs.

Whoops, I meant to write "discouraged from static linking"

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

[Bastien Nocera]

On Fri, 2017-01-06 at 01:23 +, Emmanuele Bassi wrote:
> 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.

Does it matter when, when pushed to master and released, it was broken
for every developer?

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

False equivalence?

And the current librsvg, downloading helper libraries from the
Internet, wouldn't even compile under Flatpak.

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

librsvg isn't some little library we put in the application bundle.
It's at the same level as gtk+ in the core desktop dependencies.

Saying that it's all a problem with the distribution workflow is a lack
of understanding about what this workflow tried to avoid and fix.
Downloading random shit from the internet as part of the build isn't
secure, isn't reproduceable, is difficult to debug and integrate.

I don't think it's too much to ask that librsvg is compilable offline.
___
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

[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

[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

[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

[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

[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

[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

[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

[Michael Biebl]

Hi there!

2017-01-04 1:48 GMT+01:00 Federico Mena Quintero <feder...@gnome.org>:
> 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

[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

[Emmanuele Bassi]

On 5 January 2017 at 17:37, Michael Catanzaro <mcatanz...@gnome.org> 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

[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

Librsvg 2.41.0 is released

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

Librsvg 2.41.0 is available here:

  https://download.gnome.org/sources/librsvg/2.41/

SHA256 checksums:

25338a2596e391f4d41baaaee9f91435ff657180e1005504e773e4699c3485c6  
librsvg-2.41.0.news
06ce73d669efa537f7bb54bc442c01f467b356a4d7ea9326d1ab78da7c11afcc  
librsvg-2.41.0.changes
a13573cb4efe3678eaf8709ae3533d79b17d33d29ca78a1e03e81b6235577140  
librsvg-2.41.0.tar.xz

What's new in this release?

- The big news is that parts of librsvg are now implemented in the
  Rust programming language, instead of C.  The public API remains
  identical.  Rust should provide us with memory safety and nicer
  built-in abstractions for the code, as well as an easier way to do
  unit tests.  Special thanks to all the people who sent tips on Rust
  idioms, and to Sebastian Dröge and Hubert Figuière for the Automake bits.
- Added an "--enable-debug" option to configure.ac - this will tell
  the Rust compiler to generate debugging code, instead of working in
  release mode.  Note that you must still pass CFLAGS by hand by the
  regular means for the C code.
- For Windows builds, only MSVC 2012 and upward are supported now.
- Chun-wei Fan made it possible to regenerate the MSVC project files
  when Makefile.am changes.
- Fixed bgo#763386 - handle curveto segments where three control
  points are coincident.  Thanks to Massimo for the detailed test cases.
- Fixed bgo#603550 - Compute the luminance correctly when generating a
  mask.  Thanks to Mike Lewis for the patch.
- Fixed bgo#776297 - Only render markers in path, line, polygon,
  polyline elements.
- Fixed feImage filters when they reference SVG nodes; they were
  translated incorrectly.
- Fixed feComponentTransferFunction when there are duplicated feFuncX
  elements.
- Fixed bgo#761871 - handle reflection points for quadratic and cubic
  curves correctly.
- Fixed bgo#686953 - support the "marker" shorthand property.
- Fixed a few minor issues pointed out by Coverity.
- The path data parser now handles boolean values in Arc elements correctly.
- Fixed conformance bugs in gradient inheritance.
- Radial gradients now adjust the focus point correctly to be within
  the gradient's radius.
- Stroke width normalization is now conformant to the spec.
- Viewport-relative length normalization is now conformant to the spec.
- Added some of the official SVG 1.1 test files to our test suite.  Fixed
  a little bunch of conformance bugs.
- As a small optimization, we only push/pop CSS states when rendering
  will actually happen, instead of for all (potentially invisible) nodes.
- Code that has been converted to Rust:  marker orientations and
  rendering, path data parser, path building, length normalization,
  gradient inheritance, bounding boxes with affine transformations.
- Lots of refactoring to accomodate the Rust code, and general cleanups as well.
- Added tests/README.md with instructions on how to run the test suite
  and update it.
  rsvg-test can now skip files or directories that start with "ignore".
- Improved the README.

Enjoy!

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