Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
On 15 Nov 2018, at 00:41, Michael Biebl wrote: > > Am 15.11.18 um 01:14 schrieb Michael Biebl: >> Am 15.11.2018 um 00:15 schrieb Jeremy Bicha: >>> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz >> > I don't have experience with archive management for non-release > architectures at all. 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. >> >> 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. >> > > Forgot to add: src:consolekit did not build any arch:all package. > > 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
Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
Am 15.11.18 um 01:14 schrieb Michael Biebl: > Am 15.11.2018 um 00:15 schrieb Jeremy Bicha: >> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz > I don't have experience with archive management for non-release architectures at all. >>> >>> 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. > > 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. > Forgot to add: src:consolekit did not build any arch:all package. If you say, that this should not be possible, why did this work for consolekit? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
Am 15.11.2018 um 00:15 schrieb Jeremy Bicha: > On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz >>> I don't have experience with archive management for non-release >>> architectures at all. >> >> 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. 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 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
On 14 Nov 2018, at 23:15, Jeremy Bicha wrote: > > On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz > wrote: >> >> Hi Jeremy! >> >> On 11/14/18 10:52 PM, Jeremy Bicha wrote: >>> 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). >> >> 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! >> >>> 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. >> >> 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 >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaub...@debian.org >> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de >> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > Would an arch:all librsvg-c-doc package be sufficient for the "must > build a binary package on a release architecture" requirement? 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
Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz wrote: > > Hi Jeremy! > > On 11/14/18 10:52 PM, Jeremy Bicha wrote: > > 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). > > 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! > > > 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. > > 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 > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 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
Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
Hi Jeremy! On 11/14/18 10:52 PM, Jeremy Bicha wrote: > 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). 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! > 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. 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 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, glaub...@physik.fu-berlin.de Owner: jbi...@debian.org 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
