Package Name: librsvg-c Version: 2.40.20 Upstream Authors: Ximian, Eazel, Red Hat, Igalia, etc. License : LGPL-2+ Programming Lang: C Homepage: https://wiki.gnome.org/Projects/LibRsvg Description: SAX-based renderer library for SVG files The rsvg library is an efficient renderer for Scalable Vector Graphics (SVG) pictures. Other Info -------------- As requested, this is librsvg reintroduced for ports that don't supported the rustified librsvg yet. The name is because this is librsvg written in the C programming language (instead of in Rust). Packaging can be found at https://salsa.debian.org/gnome-team/librsvg-c Currently, the packaging builds the same binary package names as src:librsvg. There was a suggestion to use different binary names with versioned Provides (against the existing librsvg binary package names). I'm not sure that provides much benefit but we can discuss that. I don't have the ability to do the initial upload for this package since I don't have easy access to do the binary build required for ftp-master NEW. I don't have experience with archive management for non-release architectures at all. Thanks, Jeremy Bicha
Hello, Bug #913766 in librsvg-c reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/librsvg-c/commit/fcd9dc83170a0668a835ebe8891f2573e0cb54cf ------------------------------------------------------------------------ add Closes: #913766------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/913766
Hi Jeremy! Thanks a lot for your effort and the initiative, I really appreciate the idea. I also apologize for my harsh wording in the heated the discussion we had. I'm very glad that this - as it is always the case in Debian - is leading to a productive solution. Great! The problem that we have is that it's not possible to upload a package to Debian which does not build any binaries on the release architectures, the archive would be removed from the archive immediately. I assume what we could do is maybe have a package that is built from multiple sources so that it builds different binary packages for the Rust and non-Rust targets. I have CC'ed James Clarke and Adrian Bunk who might be interested in this discussion as well and probably can maybe help in the process. Again, thanks a lot for the efforts and sorry for my heated and unprofessional behavior. Thanks a lot! Adrian
On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: Would an arch:all librsvg-c-doc package be sufficient for the "must build a binary package on a release architecture" requirement? Thanks, Jeremy Bicha
People might frown on it, but other source packages (ab)use this, and it certainly works from a technical standpoint. I would hope there are no objections to this approach. However, kfreebsd-* and hurd-i386 are on ftp-master and don't (yet) have rust, so those will also keep the source package around. James
Am 15.11.2018 um 00:15 schrieb Jeremy Bicha: Is that really true? Fwiw, the consolekit package, before it was removed completely, was !linux-any, ie. it was only built for non-release architectures. Why not just upload librsvg-c as regular any package. Once it has passed NEW, I would make a second, source-only upload which lists only the non-rust architectures and I'd ask ftp-masters for the removal of the binaries on the rust architectures. Michael
Am 15.11.18 um 01:14 schrieb Michael Biebl: If you say, that this should not be possible, why did this work for consolekit?
Because it's not non-release, it's non-ftp-master, and hurd/kfreebsd are on ftp-master despite being very non-release. James