Re: Uncoordinated upload of the rustified librsvg

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

Re: Uncoordinated upload of the rustified librsvg

Jeremy Bicha-5
On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski <[hidden email]> wrote:
> Perhaps we should quickly upload a revert, using the last good version of
> librsvg, before things degrade?  Effectively removing librsvg on 11 archs
> (not counting non-official ones) stops any GUI there.  Including proverbial
> fvwm.

It sounds to me like you're saying that to fix librsvg being out of
date on 11 arches, we need to make it out of date on every
architecture.

What is the actual consequence of the latest librsvg being unbuildable
on those arches? The old binaries won't automatically be removed
there, right?

As I mentioned in #debian-devel, librsvg is a security-sensitive
library. The Debian GNOME team has long wanted a supported version of
librsvg to be buildable on all release architectures in time for the
Buster release to ease the maintainability burden on the Security team
(as well as benefiting from some hardening improvements).

I didn't and don't mean to upset you. It honestly didn't occur to me
that I ought to talk to ports maintainers before uploading packages
that won't build on ports.

Instead of putting all the blame on the GNOME team, maybe you could
have expressed your concerns during the months that librsvg was still
in experimental? Or maybe you could have said "Rust is now available
on all release architectures, but please talk to us before uploading a
rustified library." While today's upload was apparently a surprise, I
don't think it should have been a surprise that this upload was
coming.

Reference
--------------
https://mail.gnome.org/archives/desktop-devel-list/2017-December/msg00072.html

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Re: Uncoordinated upload of the rustified librsvg

Samuel Thibault-8
Jeremy Bicha, le sam. 03 nov. 2018 21:04:49 -0400, a ecrit:

> On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski <[hidden email]> wrote:
> > Perhaps we should quickly upload a revert, using the last good version of
> > librsvg, before things degrade?  Effectively removing librsvg on 11 archs
> > (not counting non-official ones) stops any GUI there.  Including proverbial
> > fvwm.
>
> It sounds to me like you're saying that to fix librsvg being out of
> date on 11 arches, we need to make it out of date on every
> architecture.
>
> What is the actual consequence of the latest librsvg being unbuildable
> on those arches? The old binaries won't automatically be removed
> there, right?

No, but various problems quickly arise:

- no new arch can build it.
- if a bug needs to be fixed in it for ports it can't be built.
- if it is involved in a transition, it can't be rebuilt, thus holding
  the transition for those archs.
- ftpmasters don't like lingering binaries.

A temporary solution could be to upload the previous version under a
different source package name, but that builds the same binary packages,
and only on archs which don't have rust (yet). Such package won't get
upstream updates etc. but it doesn't need to enter testing anyway.

Samuel

Reply | Threaded
Open this post in threaded view
|

Re: Uncoordinated upload of the rustified librsvg

Mattia Rizzolo-5
In reply to this post by Jeremy Bicha-5
On Sat, Nov 03, 2018 at 09:04:49PM -0400, Jeremy Bicha wrote:
> It sounds to me like you're saying that to fix librsvg being out of
> date on 11 arches, we need to make it out of date on every
> architecture.

"out of date" has a specific meaning in the context of buildds: it means
that the latest version is not built.  Reverting back to a previous
version of librsvg would actually make all the arches "up to date" in
that lingo.

> What is the actual consequence of the latest librsvg being unbuildable
> on those arches? The old binaries won't automatically be removed
> there, right?

In this case not, but be aware that the archive software used in Debian
Ports doesn't have support for "cruft", which means that if a package
bumps its soname the old binaries are removed as soon as the last source
package building them disappear.

> Instead of putting all the blame on the GNOME team, maybe you could
> have expressed your concerns during the months that librsvg was still
> in experimental?

I at least had that impression even while being a bystander.  I do
recall Adrian mumbling about how annoying rust was for ports and I even
recall some discussion involving rsvg in it several months ago.
You really didn't understand that rsvg was a concerns for the ports
architectures?

--
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

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

Re: Uncoordinated upload of the rustified librsvg

Samuel Thibault-8
Mattia Rizzolo, le dim. 04 nov. 2018 10:40:01 +0100, a ecrit:
> On Sat, Nov 03, 2018 at 09:04:49PM -0400, Jeremy Bicha wrote:
> > What is the actual consequence of the latest librsvg being unbuildable
> > on those arches? The old binaries won't automatically be removed
> > there, right?
>
> In this case not, but be aware that the archive software used in Debian
> Ports doesn't have support for "cruft", which means that if a package
> bumps its soname the old binaries are removed as soon as the last source
> package building them disappear.

AFAIK the decruftification is still manual, the archive software does
provide the different versions for different archs. Even for arch:all
packages, changes were done to expose the proper out-of-date version to
proper archs.

But ftp-master doesn't like lingering packages :)

> > Instead of putting all the blame on the GNOME team, maybe you could
> > have expressed your concerns during the months that librsvg was still
> > in experimental?
>
> I at least had that impression even while being a bystander.  I do
> recall Adrian mumbling about how annoying rust was for ports and I even
> recall some discussion involving rsvg in it several months ago.
> You really didn't understand that rsvg was a concerns for the ports
> architectures?

I don't think this question is useful. One indeed doesn't always realize
the consequences one's actions, one can't blame somebody for that, shit
just happens :) Let's just work on finding a workable solution.

Samuel

Reply | Threaded
Open this post in threaded view
|

Re: Uncoordinated upload of the rustified librsvg

Jeremy Bicha-5
In reply to this post by Jeremy Bicha-5
On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings <[hidden email]> wrote:
> I do like the proposal of adding a librsvg-c for just the architectures
> that don't have Rust (yet).

This sounds reasonable. Thanks Samuel for the suggestion. Any
volunteers to maintain this new old package?

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Re: Uncoordinated upload of the rustified librsvg

Jeremy Bicha-5
On Sun, Nov 4, 2018 at 2:30 PM Jeremy Bicha <[hidden email]> wrote:
> On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings <[hidden email]> wrote:
> > I do like the proposal of adding a librsvg-c for just the architectures
> > that don't have Rust (yet).
>
> This sounds reasonable. Thanks Samuel for the suggestion. Any
> volunteers to maintain this new old package?

To move forward on the technical fix for the primary issue raised in
this thread, let me repeat and restate:

It looks like we will want to have a librsvg-c source package to build
the older librsvg for architectures that don't support Rust yet.

While the Debian GNOME team could maintain librsvg-c's packaging
alongside librsvg, I'd be happier if someone who cares more about
ports would maintain it. Any volunteers?

At a minimum, I don't have an easy way to do the initial binary build
of librsvg-c required for the NEW queue.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Re: Uncoordinated upload of the rustified librsvg

Jeremy Bicha-5
In reply to this post by Jeremy Bicha-5
On Sat, Nov 3, 2018 at 5:54 PM John Paul Adrian Glaubitz
<[hidden email]> wrote:
> I'm really annoyed and disappointed by this move and feel really let down by this
> behavior. No heads up, no coordination, no nothing.

There was some coordination but the coordination was for release
architectures. The coordination was with the Release Team and not with
whoever maintains ports. See https://bugs.debian.org/907626

I guess to some degree I consider the ports to be as much or as little
a part of Debian as nonfree is. Officially, they aren't part of a
strict definition of Debian, but they are part of the broader Debian
ecosystem.

It's difficult for me to even know how to raise issues with ports. I
filed https://bugs.debian.org/908600 for a fairly minor package 2
months ago. I guess I did that sort of right except I only did the
usertag for kfreebsd and not for hurd. I even did some minor
enablement work for mutter for hurd/kfreebsd recently but I'm
absolutely not a porter and I've never used those ports.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

Re: Uncoordinated upload of the rustified librsvg

Manuel A. Fernandez Montecelo-2
In reply to this post by Jeremy Bicha-5
Hi,

2018-11-06 14:19 Jeremy Bicha:
>
>It looks like we will want to have a librsvg-c source package to build
>the older librsvg for architectures that don't support Rust yet.
>
>While the Debian GNOME team could maintain librsvg-c's packaging
>alongside librsvg, I'd be happier if someone who cares more about
>ports would maintain it. Any volunteers?

tl;dr:
It might sound as if I what I'll suggest is to put back the work for you
gratuitously, but I honestly think that you (GNOME team) should keep
being the maintainers of a re-uploaded librsvg-c package, at least for
the time being.

Long:
... For the following reasons:

1) You've been maintaining it for years and have the experience (cadence
   of releases/updates, upstream repos and bug trackers, etc), while
   anyone else getting involved now will not have such experience,
   unless they have been in contact with this library or maintenance of
   GNOME packages before.

   Of course, if anyone volunteers, great, either as part of GNOME team
   or independently.  From my side, I am already struggling with what I
   have and I am planning to reduce my involvement in some areas.

1.1) I think that at least the initial job should be done by you as a
     kind of "orphaning" and moving it to QA, if you really don't want
     to maintain it from day one.

1.2) The librsvg-c has to be in sync with the -rust one and be uploaded
     in lockstep if the package binary names change, or have to conflict
     for one reason or another, so it has to either have the same
     maintainer or have close coordination.

2) I hope not, but if the new Rust implementation becomes problematic
   for stable-release arches, GNOME might need the C implementation in
   some of them, or alternatively dropping GNOME completely on those
   arches.

   If those stable-release arches do not have GNOME or any librsvg
   available, for sure they will drop as stable-release arches, since
   the requirement of building 98% of the archive will not be met.

3) Presumably the maintenance burden will be low, if that C
   implementation is dead, and will only need security fixes if Suse,
   RedHat and similar distros still maintain it, which I guess they do.
   And since it will not affect the most popular architectures or stable
   releases, it will not require urgent action.

5) From what you said in another email of this thread, I was surprised
   that you consider "ports" as a kind of "nonfree" and, in a way, not
   part of Debian.  For me, it's just about the same as breaking
   rev-dependencies: some arches have more users that many packages
   which are rev-dependencies of a given package, and breaking rev-deps
   when updating packages is generally frowned-upon.

   But let's leave that aside.

   Nowadays most of the architectures in Ports are from hardware "on its
   way out" due to being proprietary and not being produced anymore
   (alpha, hppa, etc) or playing around with other kernels.

   But Ports was also originally, and nowadays primarily, the way into
   Debian-Stable for new architectures.  Not long ago (2014-2015) three
   architectures entered Debian in such a way and they are now release
   architectures: arm64, ppc64le and mips64el.

   Maybe they don't rank high in popcon because they don't have it
   enabled, but there many people using arm64 in boards or laptops, and
   there are institutions running whole clusters or supercomputers, or
   workstations (but that's mostly x86_64 nowadays), doing science or
   serving faculty and students.  Some of them even use GNOME --
   probably not the ones in supercomputers though ;-)

   You'll want to have GNOME users in the next big architecture, and
   that architecture will come trough debian-ports.

   So independent of all else, I think that debian-ports is way more
   important than non-free, on which very few people relies upon except
   for firmware.  But people in this thread seem to think otherwise,
   so... dunno.


>At a minimum, I don't have an easy way to do the initial binary build
>of librsvg-c required for the NEW queue.

There are porterboxes for that, but if it helps, I can build it for you.


Cheers.
--
Manuel A. Fernandez Montecelo <[hidden email]>