Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1213862 > unrolled thread

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) Jonas Smedegaard <dr@jones.dk> - 2024-09-21 16:30 +0200
    Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) noisycoil@tutanota.com - 2024-09-21 21:00 +0200
      Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) Jonas Smedegaard <dr@jones.dk> - 2024-09-21 21:20 +0200
        Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) noisycoil@tutanota.com - 2024-09-21 22:10 +0200
          Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) Jonas Smedegaard <dr@jones.dk> - 2024-09-21 22:30 +0200
            Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) noisycoil@tutanota.com - 2024-09-21 23:10 +0200
              Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) Jonas Smedegaard <dr@jones.dk> - 2024-09-21 23:40 +0200
                Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) Alexander Kjäll <alexander.kjall@gmail.com> - 2024-09-22 09:30 +0200
                  Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) Sylvestre Ledru <sylvestre@debian.org> - 2024-09-22 09:40 +0200
                  Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility) noisycoil@tutanota.com - 2024-09-22 11:20 +0200

#1213862 — Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Multipart message — attachments visible in raw view] — view raw

Hi NoisyCoil (and Andrej),

> Right now src:rust-usvg and src:rust-resvg are in NEW and will
> probably be rejected since they build librust-{u,re}svg-dev, which
> albeit having been removed from testing are still in unstable.

Introduction of a binary package in another source package is not a
reason for rejection, as I understand it: That sounds like the only way
to, well, doing exactly that: Move a binary package to being maintained
in another source package.

While I don't expect the package to be rejected, please do anyway
immediately upload an update to your packages which provides also the
executables, to avoid bothering ftpmasters twice with a NEW processing.

Yes, I have invested quite some time into packaging these, but my time
has been mainly in building from true source (not from pre-generated
not-preferred-form-for-editing assets distributed via crates.io), and
composing a sensible migration path from previous maintenance to that
(in my opinion) ideal packaging style. I have no special interest in
maintaining these packages, however, and if your packaging style is
different then there is no need for the work I have spent time on.

So please go ahead and take over maintenance of these packages (if also
ok with the previous maintainer, Andrej Shadura, obviously), just make
sure that you take over all of it, not only the library parts.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [next] | [standalone]

#1213890

> Introduction of a binary package in another source package is not a reason
> for rejection, as I understand it: That sounds like the only way to, well, doing
> exactly that: Move a binary package to being maintained in another source
> package.

Sure, but I would expect at least removal of the older source package from unstable first, or explicit consent from the previous maintainer to the overtake.

> So please go ahead and take over maintenance of these packages (if also
> ok with the previous maintainer, Andrej Shadura, obviously), just make
> sure that you take over all of it, not only the library parts.

I pushed the changes to debcargo-conf's current packaging of usvg/resvg needed to build the binaries to my personal repo: https://salsa.debian.org/NoisyCoil/debcargo-conf/-/commits/usvg-resvg. As far as the binaries are concerned, packaging-wise, only the manpages are missing (and proper d/changelog entries). C-library packages are not included as they are not built by neither package (nor they could be within debcargo-conf IIUC). Still, as I've already expressed in my last emails, I am not interested in maintaining the binaries. If Andrej, or tarzeau (both in cc), or really anyone else, is interested in doing so, they can just signal their interest and I'll add them to the Uploaders, add the manpages and re-upload the packages (again, through to my sponsor). Otherwise I see no value in re-uploading packages no-one is actually interested in maintaining, all the more if they were already removed from testing.

[toc] | [prev] | [next] | [standalone]

#1213894

[Multipart message — attachments visible in raw view] — view raw

Quoting noisycoil@tutanota.com (2024-09-21 20:36:55)
> > Introduction of a binary package in another source package is not a reason
> > for rejection, as I understand it: That sounds like the only way to, well, doing
> > exactly that: Move a binary package to being maintained in another source
> > package.
> 
> Sure, but I would expect at least removal of the older source package from unstable first, or explicit consent from the previous maintainer to the overtake.
> 
> > So please go ahead and take over maintenance of these packages (if also
> > ok with the previous maintainer, Andrej Shadura, obviously), just make
> > sure that you take over all of it, not only the library parts.
> 
> I pushed the changes to debcargo-conf's current packaging of usvg/resvg needed to build the binaries to my personal repo: https://salsa.debian.org/NoisyCoil/debcargo-conf/-/commits/usvg-resvg. As far as the binaries are concerned, packaging-wise, only the manpages are missing (and proper d/changelog entries). C-library packages are not included as they are not built by neither package (nor they could be within debcargo-conf IIUC). Still, as I've already expressed in my last emails, I am not interested in maintaining the binaries. If Andrej, or tarzeau (both in cc), or really anyone else, is interested in doing so, they can just signal their interest and I'll add them to the Uploaders, add the manpages and re-upload the packages (again, through to my sponsor). Otherwise I see no value in re-uploading packages no-one is actually interested in maintaining, all the more if they were already removed from testing.

Noooo, no no - that's not how we are playing this!

Either you take over and you *maintain* the project, or you back off.

Doing a one-off release of the easy part - the library only, and then
instead of stepping up and doing the rest you argue that falling out of
testing is an indication that it is irrelevant? Come on - grow up!

I take back my endorsement. Please clean up the mess you did with your
accidental one-off relase, and let people that care for long-term and
proper maintenance handle it.

Or do the right thing and *care* for the package!  The whole thing.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#1213896

Jonas, you must have missed one piece of my first email, which I report below:

> Jonas, I apologize for the duplicated work. Since you've been working on this
> for a long time I am more than willing to step down from {u,re}svg once the
> sources are rejected. I am no user of resvg and I am not interested in
> maintaining it other than to provide the rust library.

("once the sources are rejected" to me reads as "when the sources are rejected", not "if", because I'd still expect rejection for the reasons I explained). So I agree with you, and I said it from the first time: I am more than willing to back off. No reason to do otherwise.

Then I wrote:

> if someone from the Rust Team (in cc) wanted to maintain resvg we could
> also remove src:resvg from unstable and go forward with my (sponsored)
> uploads. I am ok with both solutions, but I would like Jonas to have the final
> word on this given his longstanding interest in resvg.

Meaning if no one from the Team is interested, provided that you still are, I'd rather not go forward with the uploads. If rejection is not automatic and I'll have to get in touch with the FTPMasters, then I will. The reason why I pinged you in private about this thread earlier today is precisely because the FTPMasters are going forward with my NEW uploads and I need an answer as soon as possible so I know what to do.

But then you answered

> I have no special interest in maintaining these packages

from which I gathered... you're not interested? So if you're not interested, I'm not interested, no one from the Team showed up to signal interest, the package was removed from testing... then why should I want to re-upload the binaries? No issue with the long-term maintenance of the libraries, which I do need as a dependency, but the binaries?

This being said, if you are going to maintain resvg+usvg in whatever form you like, then thank you as it will mean less work for me. Please confirm you're going to do so, this way I know how to deal with the packages in NEW.

[toc] | [prev] | [next] | [standalone]

#1213897

[Multipart message — attachments visible in raw view] — view raw

Quoting noisycoil@tutanota.com (2024-09-21 21:59:50)
> Jonas, you must have missed one piece of my first email, which I report below:
> 
> > Jonas, I apologize for the duplicated work. Since you've been working on this
> > for a long time I am more than willing to step down from {u,re}svg once the
> > sources are rejected. I am no user of resvg and I am not interested in
> > maintaining it other than to provide the rust library.
> 
> ("once the sources are rejected" to me reads as "when the sources are rejected", not "if", because I'd still expect rejection for the reasons I explained). So I agree with you, and I said it from the first time: I am more than willing to back off. No reason to do otherwise.
> 
> Then I wrote:
> 
> > if someone from the Rust Team (in cc) wanted to maintain resvg we could
> > also remove src:resvg from unstable and go forward with my (sponsored)
> > uploads. I am ok with both solutions, but I would like Jonas to have the final
> > word on this given his longstanding interest in resvg.
> 
> Meaning if no one from the Team is interested, provided that you still are, I'd rather not go forward with the uploads. If rejection is not automatic and I'll have to get in touch with the FTPMasters, then I will. The reason why I pinged you in private about this thread earlier today is precisely because the FTPMasters are going forward with my NEW uploads and I need an answer as soon as possible so I know what to do.
> 
> But then you answered
> 
> > I have no special interest in maintaining these packages
> 
> from which I gathered... you're not interested? So if you're not interested, I'm not interested, no one from the Team showed up to signal interest, the package was removed from testing... then why should I want to re-upload the binaries? No issue with the long-term maintenance of the libraries, which I do need as a dependency, but the binaries?
> 
> This being said, if you are going to maintain resvg+usvg in whatever form you like, then thank you as it will mean less work for me. Please confirm you're going to do so, this way I know how to deal with the packages in NEW.

I have an interest in resvg staying in Debian.

I have no special interest in me being the person ensuring that resvg
stays in Debian.

If you take over maintenance of resvg, and you do that by only caring
for the library, and adding back the executable and its man page only if
someone else does the work for you, then I would rather add resvg as
package number 663 in the horribly long list of packages I have taken
responsibility for.

What is the short version of the above 3 sentences? That I prefer to
maintain resvg or that I prefer to not maintain resvg?

I kindly ask you to *maintain* what you choose to maintain in Debian.

I highly appreciate that you maintain packages in Debian, regardless of
the amount.

I do not like it if you maintain without fully maintaining, regardless
of the amount.  Then I prefer to pile more onto my own list.  But no, I
really do not prefer to maintain more packages.

If you uploaded by accident, and don't want to maintain what you
uploaded, then I (am confused why you uploaded at all, and) want you to
simply say "whoops" and correct your mistake.  Not offer to maintain the
package if you are not really willing to do that.

If you never offered to maintain resvg then how did this conversation
emerge? Did I try to bend your words, when all you initially said was
"whoops" and informing me that it was a bleep on the radar soon gone?
If that's the case then I apologize for the confusion I have caused:
Please simply continue correcting your mistake, no need to elaborate on
all the possible ways *others* than yourself can handle the package
onwards.

Thanks,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#1213899

> If you never offered to maintain resvg then how did this conversation
> emerge? Did I try to bend your words, when all you initially said was
> "whoops" and informing me that it was a bleep on the radar soon gone?
> If that's the case then I apologize for the confusion I have caused:
> Please simply continue correcting your mistake, no need to elaborate on
>all the possible ways *others* than yourself can handle the package
> onwards.

What I was trying to say initially was: I made a mistake and I can back off, but given the work I already did, including the binaries and completing the packaging is very easy (I already kinda did it at this point), so if anyone is interested in actually maintaining the binaries (I am not) they can just stick their names on it and have resvg+usvg back in Debian with little effort. Unless Jonas wants to complete the packaging, in which case he should have precedence anyway since he expressed interest in doing this for quite a while.

> I kindly ask you to *maintain* what you choose to maintain in Debian.

> I do not like it if you maintain without fully maintaining, regardless
> of the amount.

> [I] am confused why you uploaded at all

As I'm sure you know, even if you may disagree, it is within the Rust Team's packaging policy to only build the library and not the binaries. This is not considered to be "not fully maintaining". I agree that it's preferable to build everything available in the source however (especially if the binaries were already in Debian and not totally new!), this is why I insisted from the start that it would be nice if someone could use my work and upload the binaries too. When you said you were not specifically interested in the package I took it literally and thought that if no one was interested in building the whole package, then only uploading the libraries (which on the contrary are very much needed) would be enough. I apologize for the misunderstanding.

You saying you are interested in having the whole resvg in Debian is enough for me, I'll take care of whatever is left in NEW.

[toc] | [prev] | [next] | [standalone]

#1213903

[Multipart message — attachments visible in raw view] — view raw

Quoting noisycoil@tutanota.com (2024-09-21 23:06:42)
> > If you never offered to maintain resvg then how did this conversation
> > emerge? Did I try to bend your words, when all you initially said was
> > "whoops" and informing me that it was a bleep on the radar soon gone?
> > If that's the case then I apologize for the confusion I have caused:
> > Please simply continue correcting your mistake, no need to elaborate on
> >all the possible ways *others* than yourself can handle the package
> > onwards.
> 
> What I was trying to say initially was: I made a mistake and I can back off, but given the work I already did, including the binaries and completing the packaging is very easy (I already kinda did it at this point), so if anyone is interested in actually maintaining the binaries (I am not) they can just stick their names on it and have resvg+usvg back in Debian with little effort. Unless Jonas wants to complete the packaging, in which case he should have precedence anyway since he expressed interest in doing this for quite a while.
> 
> > I kindly ask you to *maintain* what you choose to maintain in Debian.
> 
> > I do not like it if you maintain without fully maintaining, regardless
> > of the amount.
> 
> > [I] am confused why you uploaded at all
> 
> As I'm sure you know, even if you may disagree, it is within the Rust Team's packaging policy to only build the library and not the binaries. This is not considered to be "not fully maintaining". I agree that it's preferable to build everything available in the source however (especially if the binaries were already in Debian and not totally new!), this is why I insisted from the start that it would be nice if someone could use my work and upload the binaries too. When you said you were not specifically interested in the package I took it literally and thought that if no one was interested in building the whole package, then only uploading the libraries (which on the contrary are very much needed) would be enough. I apologize for the misunderstanding.

WTF?

No, I was unaware of this additional deviation from Debian.  Thanks for
bringing it to my attention.  Knowing that, it makes better sense that
you can be talking about the option to taking over a package while not
even caring to mention that if doing so, you will be ditching the
executable part of it.


> You saying you are interested in having the whole resvg in Debian is
enough for me, I'll take care of whatever is left in NEW.

Thanks.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#1213920

Hi

I'm not sure that is really our policy? We package multiple binaries
for packages that have them.

There is also a lot of crates on crates.io that have binaries that
isn't really intended/ready for inclusion in a major linux
distribution, and more written as a demo of what the library can do,
those we tend to disable.

//Alex

Den lör 21 sep. 2024 kl 23:37 skrev Jonas Smedegaard <dr@jones.dk>:
>
> Quoting noisycoil@tutanota.com (2024-09-21 23:06:42)
> > > If you never offered to maintain resvg then how did this conversation
> > > emerge? Did I try to bend your words, when all you initially said was
> > > "whoops" and informing me that it was a bleep on the radar soon gone?
> > > If that's the case then I apologize for the confusion I have caused:
> > > Please simply continue correcting your mistake, no need to elaborate on
> > >all the possible ways *others* than yourself can handle the package
> > > onwards.
> >
> > What I was trying to say initially was: I made a mistake and I can back off, but given the work I already did, including the binaries and completing the packaging is very easy (I already kinda did it at this point), so if anyone is interested in actually maintaining the binaries (I am not) they can just stick their names on it and have resvg+usvg back in Debian with little effort. Unless Jonas wants to complete the packaging, in which case he should have precedence anyway since he expressed interest in doing this for quite a while.
> >
> > > I kindly ask you to *maintain* what you choose to maintain in Debian.
> >
> > > I do not like it if you maintain without fully maintaining, regardless
> > > of the amount.
> >
> > > [I] am confused why you uploaded at all
> >
> > As I'm sure you know, even if you may disagree, it is within the Rust Team's packaging policy to only build the library and not the binaries. This is not considered to be "not fully maintaining". I agree that it's preferable to build everything available in the source however (especially if the binaries were already in Debian and not totally new!), this is why I insisted from the start that it would be nice if someone could use my work and upload the binaries too. When you said you were not specifically interested in the package I took it literally and thought that if no one was interested in building the whole package, then only uploading the libraries (which on the contrary are very much needed) would be enough. I apologize for the misunderstanding.
>
> WTF?
>
> No, I was unaware of this additional deviation from Debian.  Thanks for
> bringing it to my attention.  Knowing that, it makes better sense that
> you can be talking about the option to taking over a package while not
> even caring to mention that if doing so, you will be ditching the
> executable part of it.
>
>
> > You saying you are interested in having the whole resvg in Debian is
> enough for me, I'll take care of whatever is left in NEW.
>
> Thanks.
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  * Sponsorship: https://ko-fi.com/drjones
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#1213921

[Multipart message — attachments visible in raw view] — view raw

Le 22/09/2024 à 09:16, Alexander Kjäll a écrit :
> Hi
>
> I'm not sure that is really our policy? We package multiple binaries
> for packages that have them.
>
> There is also a lot of crates on crates.io that have binaries that
> isn't really intended/ready for inclusion in a major linux
> distribution, and more written as a demo of what the library can do,
> those we tend to disable.
Some examples of this:

https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/snapbox/debian/debcargo.toml#L4

https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/remove-dir-all/debian/debcargo.toml#L4

etc

S

[toc] | [prev] | [next] | [standalone]

#1213930

Hi Alex,

> I'm not sure that is really our policy? We package multiple binaries
> for packages that have them.

From the "Packaging binaries" section in debcargo-conf's `rust_hacks.md`:

> If a package ships a binary but you only want to use it as library add this stanza in debcargo.toml:
>
> ```
> [packages.lib]
> bin = false
> ```

Currently there are at least 85 crates packaging only the library and disabling the binaries.

Best.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web