Re: Uncoordinated upload of the rustified librsvg
Dear Jonathan, > >Debian's Dictionary is in a weird order; "Thank You" is right next to > >the definition of "Entitlement" > > Sorry this wasn't a helpful message. (I'm a little behind on this thread alas but I just wanted to thank you for following up with this retraction.) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Uncoordinated upload of the rustified librsvg
Seth Arnold schrieb: > It doesn't help that the distributions in general want to support Firefox > on more platforms than the Rust team supports as tier-1 platforms. A > constant cadence of updates every six weeks is faster than anything else > excepting the Linux kernel. It's a lot of work. Why doesn't Ubuntu ship the ESR releases in their stable releases, then? Cheers, Moritz
Re: Uncoordinated upload of the rustified librsvg
On Thu, Nov 08, 2018 at 03:12:38PM +0100, Adam Borowski wrote: On Thu, Nov 08, 2018 at 08:39:30AM -0500, Michael Stone wrote: On Wed, Nov 07, 2018 at 06:45:14PM -0800, Seth Arnold wrote: > It doesn't help that the distributions in general want to support Firefox > on more platforms than the Rust team supports as tier-1 platforms. A > constant cadence of updates every six weeks is faster than anything else > excepting the Linux kernel. It's a lot of work. Complaining that someone else's release schedule is too fast is frankly unreasonable--you're basically asking them to slow down development for your convenience. At least they're doing releases, which is much better than the current trend of "well, just use the latest git head". There's no downside to frequent releases. There is a big fat downside to requiring a very recent release to build the current one. And frequent releases make you feel that you can drop compat despite the time difference being small in absolute terms. Ie: "release early, release often" is good for technical reasons, but may fail psychological ones. But you can have the same issues with long releases. IOW, the release schedule is the wrong thing to complain about.
Re: Uncoordinated upload of the rustified librsvg
On Thu, Nov 08, 2018 at 08:39:30AM -0500, Michael Stone wrote: > On Wed, Nov 07, 2018 at 06:45:14PM -0800, Seth Arnold wrote: > > It doesn't help that the distributions in general want to support Firefox > > on more platforms than the Rust team supports as tier-1 platforms. A > > constant cadence of updates every six weeks is faster than anything else > > excepting the Linux kernel. It's a lot of work. > > Complaining that someone else's release schedule is too fast is frankly > unreasonable--you're basically asking them to slow down development for your > convenience. At least they're doing releases, which is much better than the > current trend of "well, just use the latest git head". There's no downside to frequent releases. There is a big fat downside to requiring a very recent release to build the current one. And frequent releases make you feel that you can drop compat despite the time difference being small in absolute terms. Ie: "release early, release often" is good for technical reasons, but may fail psychological ones. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came ⠈⠳⣄ together with silk (judging by today's amber stalls).
Re: Uncoordinated upload of the rustified librsvg
On Wed, Nov 07, 2018 at 06:45:14PM -0800, Seth Arnold wrote: It doesn't help that the distributions in general want to support Firefox on more platforms than the Rust team supports as tier-1 platforms. A constant cadence of updates every six weeks is faster than anything else excepting the Linux kernel. It's a lot of work. Complaining that someone else's release schedule is too fast is frankly unreasonable--you're basically asking them to slow down development for your convenience. At least they're doing releases, which is much better than the current trend of "well, just use the latest git head".
Re: Uncoordinated upload of the rustified librsvg
On Wed, Nov 07, 2018 at 11:07:09AM -0800, Josh Triplett wrote: > Rust is stable. Thank you for your contributions helping it work on more > architectures, but "does not have first-tier support for every > architecture ever" is not a component of "stabilize". Hello Josh, I can't speak for anyone except myself. I just want to call attention to what I think might be part of the communication disconnect I see here. Debian allows different amounts of test failures based on architecture: https://sources.debian.org/src/rustc/1.31.0%7Ebeta.4+dfsg1-1%7Eexp2/debian/rules/#L210 Ubuntu runs the tests but doesn't fail the build if any fail: https://launchpad.net/ubuntu/+source/rustc/1.29.2+dfsg1+llvm-0ubuntu1 Fedora appears to run the tests but doesn't fail the build if any fail: https://src.fedoraproject.org/rpms/rust/blob/master/f/rust.spec#_573 SUSE appears to skip the tests: https://build.opensuse.org/package/view_file/openSUSE:Factory/rust/rust.spec?expand=1 (no "x.py tests" anyway) Gentoo appears to skip the tests: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/rust/rust-1.29.2.ebuild (no "x.py tests" anyway) Arch appears to skip the tests: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/rust (no "x.py tests" anyway) Thus I suggest that "Rust has regressions" and "Rust isn't stable" reflects the frustrations of the packagers who have decided that Rust's tests are more annoying than they are useful. It doesn't help that the distributions in general want to support Firefox on more platforms than the Rust team supports as tier-1 platforms. A constant cadence of updates every six weeks is faster than anything else excepting the Linux kernel. It's a lot of work. Thanks signature.asc Description: PGP signature
Re: Uncoordinated upload of the rustified librsvg
On Thu, Nov 08, 2018 at 06:28:29AM +0900, Mike Hommey wrote: > On Wed, Nov 07, 2018 at 01:21:44PM -0800, Josh Triplett wrote: > > > I have worked with the Rust upstream sources > > > well enough to know these issues. You have a regression in Rust 1.25 and > > > you will have a very hard time trying to bisect the issues simply because > > > you cannot even build 1.25 using a 1.19 compiler because the language > > > has changed too much in the mean time. > > > > Why do you need to build 1.25 with a 1.19 compiler in order to bisect? > > Presumably because none of versions 1.20 to 1.24 work. Then you wouldn't need to start bisection at version 1.25, if version 1.20 broke. But that aside, this is one of *many* reasons why such efforts can't have a cadence of occurring six versions apart.
Re: Uncoordinated upload of the rustified librsvg
On Wed, Nov 07, 2018 at 01:21:44PM -0800, Josh Triplett wrote: > > I have worked with the Rust upstream sources > > well enough to know these issues. You have a regression in Rust 1.25 and > > you will have a very hard time trying to bisect the issues simply because > > you cannot even build 1.25 using a 1.19 compiler because the language > > has changed too much in the mean time. > > Why do you need to build 1.25 with a 1.19 compiler in order to bisect? Presumably because none of versions 1.20 to 1.24 work. Mike
Re: Uncoordinated upload of the rustified librsvg
On Wed, Nov 07, 2018 at 08:47:53PM +0100, John Paul Adrian Glaubitz wrote: > On 11/7/18 8:07 PM, Josh Triplett wrote: > >> Well, I wouldn't bet on that. I know that a lot of people have the > >> feeling that rewriting everything in Rust will solve all problems > >> in software we have nowadays but that's not the case. Rewriting large > >> projects is associated with a high cost and not many companies are > >> willing to pay for that. Also, there have already been several > >> vulnerabilities in Rust and Cargo as well, so the safety is not > >> really an argument. > > > > I really don't feel the need to recreate extensive language arguments > > here. I think it safe to say that Rust's small handful of documented > > issues in the standard library pales in comparison to the history of > > whole classes of bugs in C programs. But the point of this thread is not > > advocacy, it's simple observation. > > I don't think the majority of bugs exist because of C language issues. Which is not what I said. I said that the small handful of security bugs in the Rust standard library (none of which had any significant impact) pale in comparison to the number of security bugs due to C. And again, this is *not* the thread for language advocacy; there is no value in having a Rust vs C argument here. This line of argument will not change whether upstreams adopt Rust, and Debian (and its ports) will have to handle that. Can we please drop this branch of replies? > Do you have any data to undermine that argument? (I think you mean "support that argument"; "undermining" the argument would be attempting to remove support for the argument.) There's plenty of such data readily available, not least of which, summaries of the most common kinds of CVEs; I'm not going to reiterate it here. > > I'm not suggesting the world will get rewritten in Rust overnight. It > > seems a rather safe bet, however, that a non-zero number of additional > > Rust libraries and binaries will show up in the core ecosystem. > > Sure. But also not 95%. Which is also not what I said. Please drop the hyperbole. > >>> Running old versions of a library is not a viable long-term strategy. > >>> Attempting to find alternatives written in C is not a viable long-term > >>> strategy either; that's running in the wrong direction. Ultimately, the > >>> new version will need uploading to Debian, and an architecture that > >>> wants to run a full desktop, or for that matter a server or embedded > >>> environment, will need to have LLVM support and Rust support. > >> > >> I know that. That's why I also criticized the upstream developer, > >> of librsvg, who happens to be a colleague of mine at SUSE, who was > >> responsible > >> for that change. > > > > For attempting to improve beyond C? Hardly a criticism. > > How many CVEs were there on average in librsvg per year that were a result > of the language? Note that by saying "improve beyond C", I'm not just referring to security vulnerabilities. > Again, any data on that beyond assumption? I am seeing > 8 CVEs in 6 years. I haven't looked into the details yet whether they were > a result of the C language or whether they were critical at all: > > > https://www.cvedetails.com/vulnerability-list/vendor_id-283/product_id-23082/Gnome-Librsvg.html >From a *quick* glance, several of them; out of bounds reads, NULL pointer dereferences... > >> Will be interesting to see what will happen in the future > >> when the rustified version of librsvg will try move into the enterprise > >> distributions. > > > > Seems far less likely to encounter issues, given that enterprise > > distributions target mainstream architectures only. > > That's not how enterprise distributions work at all. The main goal is to > not update at all if it's not necessary. It's not related to the architecture. I'm well aware of how enterprise distributions work. My point is that the "regressions" you keep talking about don't apply to a distribution that doesn't *have* architectures less mainstream than x86 and ARM. > >>> I think it's reasonable for the *first* such library being uploaded to > >>> wait a little while to coordinate, which it did. > >> > >> It didn't even wait for Rust to stabilize on the architectures it was > >> recently bootstrapped for. There was no guarantee the Rust compiler will > >> work on arm32 or mips32 in the foreseeable future. > > > > Define "stabilize". And in particular, how were people to know this from > > https://lists.debian.org/debian-devel-announce/2018/11/msg0.html ? > > Given the fact that you're Rust upstream, I think you should be aware of it. > If I know about these issues as an irregular Rust upstream contributor with > just around 20 patches better than you, you're not really making a compelling > argument. I am already well aware that architecture-specific issues exist. I'm also not the person working on fixing them, nor is fixing them something I have any particular mandate to work on,
Re: Uncoordinated upload of the rustified librsvg
Hello! On 11/7/18 8:07 PM, Josh Triplett wrote: >> Well, I wouldn't bet on that. I know that a lot of people have the >> feeling that rewriting everything in Rust will solve all problems >> in software we have nowadays but that's not the case. Rewriting large >> projects is associated with a high cost and not many companies are >> willing to pay for that. Also, there have already been several >> vulnerabilities in Rust and Cargo as well, so the safety is not >> really an argument. > > I really don't feel the need to recreate extensive language arguments > here. I think it safe to say that Rust's small handful of documented > issues in the standard library pales in comparison to the history of > whole classes of bugs in C programs. But the point of this thread is not > advocacy, it's simple observation. I don't think the majority of bugs exist because of C language issues. Do you have any data to undermine that argument? > I'm not suggesting the world will get rewritten in Rust overnight. It > seems a rather safe bet, however, that a non-zero number of additional > Rust libraries and binaries will show up in the core ecosystem. Sure. But also not 95%. >>> Running old versions of a library is not a viable long-term strategy. >>> Attempting to find alternatives written in C is not a viable long-term >>> strategy either; that's running in the wrong direction. Ultimately, the >>> new version will need uploading to Debian, and an architecture that >>> wants to run a full desktop, or for that matter a server or embedded >>> environment, will need to have LLVM support and Rust support. >> >> I know that. That's why I also criticized the upstream developer, >> of librsvg, who happens to be a colleague of mine at SUSE, who was >> responsible >> for that change. > > For attempting to improve beyond C? Hardly a criticism. How many CVEs were there on average in librsvg per year that were a result of the language? Again, any data on that beyond assumption? I am seeing 8 CVEs in 6 years. I haven't looked into the details yet whether they were a result of the C language or whether they were critical at all: > https://www.cvedetails.com/vulnerability-list/vendor_id-283/product_id-23082/Gnome-Librsvg.html >> Will be interesting to see what will happen in the future >> when the rustified version of librsvg will try move into the enterprise >> distributions. > > Seems far less likely to encounter issues, given that enterprise > distributions target mainstream architectures only. That's not how enterprise distributions work at all. The main goal is to not update at all if it's not necessary. It's not related to the architecture. >>> I think it's reasonable for the *first* such library being uploaded to >>> wait a little while to coordinate, which it did. >> >> It didn't even wait for Rust to stabilize on the architectures it was >> recently bootstrapped for. There was no guarantee the Rust compiler will >> work on arm32 or mips32 in the foreseeable future. > > Define "stabilize". And in particular, how were people to know this from > https://lists.debian.org/debian-devel-announce/2018/11/msg0.html ? Given the fact that you're Rust upstream, I think you should be aware of it. If I know about these issues as an irregular Rust upstream contributor with just around 20 patches better than you, you're not really making a compelling argument. >> Given the fact that Rust upstream is always introducing a significant number >> of changes with each release, there is quite a chance of regressions of >> the compiler on these architectures. > > This does not relate. The language has active development, like any > package that isn't dead upstream. What makes it any *more* likely to > have regressions? The release of completely new upstream versions every six weeks. Compare that to OpenJDK, gcc or golang. None of these languages is introducing such huge changes on a regular basis. Are you denying the fact that there isn't a difference between and other languages in this regard? I have worked with the Rust upstream sources well enough to know these issues. You have a regression in Rust 1.25 and you will have a very hard time trying to bisect the issues simply because you cannot even build 1.25 using a 1.19 compiler because the language has changed too much in the mean time. I know this is more a problem with the compiler source itself than with other packages but I think it still shows the current volatility of the language very well. > What makes it likely to have regressions is a lack of direct support > for such architectures upstream. As a random example: where are the bots > that run testsuites on other architectures for PRs? Well, I know that other languages don't have this issue. You cannot blame the lack of these bots on me. I have done as much as I can to help Rust upstream beyond their main target architectures. But there is only so much energy that I can invest without being paid for that work. I have
Re: Uncoordinated upload of the rustified librsvg
On Wed, Nov 07, 2018 at 11:53:06AM +0100, John Paul Adrian Glaubitz wrote: > Hello! > > > librsvg has rewritten substantial fractions of its code upstream in > > Rust. It won't be the last such library or package to do so. > > Well, I wouldn't bet on that. I know that a lot of people have the > feeling that rewriting everything in Rust will solve all problems > in software we have nowadays but that's not the case. Rewriting large > projects is associated with a high cost and not many companies are > willing to pay for that. Also, there have already been several > vulnerabilities in Rust and Cargo as well, so the safety is not > really an argument. I really don't feel the need to recreate extensive language arguments here. I think it safe to say that Rust's small handful of documented issues in the standard library pales in comparison to the history of whole classes of bugs in C programs. But the point of this thread is not advocacy, it's simple observation. I'm not suggesting the world will get rewritten in Rust overnight. It seems a rather safe bet, however, that a non-zero number of additional Rust libraries and binaries will show up in the core ecosystem. > > Running old versions of a library is not a viable long-term strategy. > > Attempting to find alternatives written in C is not a viable long-term > > strategy either; that's running in the wrong direction. Ultimately, the > > new version will need uploading to Debian, and an architecture that > > wants to run a full desktop, or for that matter a server or embedded > > environment, will need to have LLVM support and Rust support. > > I know that. That's why I also criticized the upstream developer, > of librsvg, who happens to be a colleague of mine at SUSE, who was responsible > for that change. For attempting to improve beyond C? Hardly a criticism. > Will be interesting to see what will happen in the future > when the rustified version of librsvg will try move into the enterprise > distributions. Seems far less likely to encounter issues, given that enterprise distributions target mainstream architectures only. > > I think it's reasonable for the *first* such library being uploaded to > > wait a little while to coordinate, which it did. > > It didn't even wait for Rust to stabilize on the architectures it was > recently bootstrapped for. There was no guarantee the Rust compiler will > work on arm32 or mips32 in the foreseeable future. Define "stabilize". And in particular, how were people to know this from https://lists.debian.org/debian-devel-announce/2018/11/msg0.html ? > Given the fact that Rust upstream is always introducing a significant number > of changes with each release, there is quite a chance of regressions of > the compiler on these architectures. This does not relate. The language has active development, like any package that isn't dead upstream. What makes it any *more* likely to have regressions? What makes it likely to have regressions is a lack of direct support for such architectures upstream. As a random example: where are the bots that run testsuites on other architectures for PRs? > > I don't, however, think it's reasonable to wait indefinitely. > > No one was saying that. But I think it's more reasonable to wait for > the Rust compiler to stabilize Rust is stable. Thank you for your contributions helping it work on more architectures, but "does not have first-tier support for every architecture ever" is not a component of "stabilize". > There is still no Rust-stable branch in sight which is > most certainly a requirement for Rust to be part of enterprise distributions. This has certainly been discussed upstream, but in general, it's not obvious what this would gain over simply taking any stable release of Rust and packaging it. > I know the QA processes associated for SLES to update packages in a release > version and I could imagine that it's not anything less involved for > RHEL or other enterprise distributions. It seems that Rust upstream has > not had any of the enterprise and long-term support distributions in > mind yet. They seem to assume that distributions can just always use the > latest upstream versions. No, we assume that distributions can package Rust alongside Rust software and that the packaged software will work with the packaged Rust. There's no need to use "the latest upstream version"; you only need to update to a new upstream version of Rust if you update to a new upstream version of software written in Rust. > > If even more coordination had taken place than what already did, > > what would have been the expected outcome? > > A Rust compiler that doesn't regress every six weeks, maybe? It's not reasonable to block the introduction of software written in Rust on some developer (not yet identified) taking the time to contribute the necessary infrastructure upstream to continually test multiple additional uncommon architectures. And that's what would be necessary. > >
Re: Uncoordinated upload of the rustified librsvg
Hi Josh, I agree with most of you message, specially that we cannot keep using librsvg-in-c forever, but a couple of things: 2018-11-06 06:02 Josh Triplett: librsvg has rewritten substantial fractions of its code upstream in Rust. It won't be the last such library or package to do so. librsvg sat in experimental for months, precisely *because* the maintainer knew that such a change could potentially be disruptive, and wanted to properly integrate it into Debian. But the new upstream version fundamentally depends on Rust. I don't know for sure, but I think that the real reason why it was not uploaded to unstable until less than a week ago was not so much about impact or being disruptive on its rev-deps, but because rustc was not available in a few stable-release architectures [1,2,3], and not be very stable in others [4,5] until a few days ago [6]. So if that interpretation is true, librsvg --in Debian-- could move on to its -rust implementation not because it was sufficiently stable or mature in itself, but thanks in good part to Adrian's effort and people who care "about the 1%" (taking the expression from another message in the thread). [1] https://buildd.debian.org/status/logs.php?pkg=rustc=mips [2] https://buildd.debian.org/status/logs.php?pkg=rustc=mips64el [3] https://buildd.debian.org/status/logs.php?pkg=rustc=mipsel [4] https://buildd.debian.org/status/logs.php?pkg=rustc=ppc64el [5] https://buildd.debian.org/status/logs.php?pkg=rustc=s390x [6] https://lists.debian.org/debian-devel-announce/2018/11/msg0.html Attempting to find alternatives written in C is not a viable long-term strategy either; that's running in the wrong direction. Ultimately, the new version will need uploading to Debian, and an architecture that wants to run a full desktop, or for that matter a server or embedded environment, will need to have LLVM support and Rust support. Perhaps in the future, but that's not really necessary today. I am running systems without LLVM or Rust support and they do their job just fine. Rust(*) is not necessary for anything except Firefox, Thunderbird and now librsvg; and LLVM only for a few things, but the areas where it's needed are not near universal, and not having it available it's less than 10% of the impact of not having librsvg. (*) BTW, I don't dislike Rust per se, in fact I was trying to learn it and started to read the book and create some test programs lately. [...] and that shouldn't impede those architectures too much as long as other packages don't start depending specifically on functionality from the new librsvg. (And if packages do start having such dependencies, they'll get held back too.) That's not really true either, I needed to build a librsvg-in-c to be able to build emacs, so it's already affecting some ports. Cheers. -- Manuel A. Fernandez Montecelo
Re: Uncoordinated upload of the rustified librsvg
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
Re: Uncoordinated upload of the rustified librsvg
Hello! > librsvg has rewritten substantial fractions of its code upstream in > Rust. It won't be the last such library or package to do so. Well, I wouldn't bet on that. I know that a lot of people have the feeling that rewriting everything in Rust will solve all problems in software we have nowadays but that's not the case. Rewriting large projects is associated with a high cost and not many companies are willing to pay for that. Also, there have already been several vulnerabilities in Rust and Cargo as well, so the safety is not really an argument. C++ is also getting safer as a language. Furthermore, Rust is anything but stable. If you check the version in experimental, it already has regressed again on multiple architectures: > https://buildd.debian.org/status/package.php?p=rustc=experimental You'll have fun fixing those regressions again. I will probably stay away for a while focusing on other projects after this experience. > librsvg sat in experimental for months, precisely *because* the maintainer > knew that > such a change could potentially be disruptive, and wanted to properly > integrate it into Debian. But the new upstream version fundamentally > depends on Rust. I'm well aware why it sat in experimental. That's not what I criticized. > Running old versions of a library is not a viable long-term strategy. > Attempting to find alternatives written in C is not a viable long-term > strategy either; that's running in the wrong direction. Ultimately, the > new version will need uploading to Debian, and an architecture that > wants to run a full desktop, or for that matter a server or embedded > environment, will need to have LLVM support and Rust support. I know that. That's why I also criticized the upstream developer, of librsvg, who happens to be a colleague of mine at SUSE, who was responsible for that change. Will be interesting to see what will happen in the future when the rustified version of librsvg will try move into the enterprise distributions. Having just checked, it's not part of SLE-15. You already get an idea of the headache for LTS distributions with the changes necessary for Firefox 60 in Debian Stretch. SLE-16 could be fun. > I think it's reasonable for the *first* such library being uploaded to > wait a little while to coordinate, which it did. It didn't even wait for Rust to stabilize on the architectures it was recently bootstrapped for. There was no guarantee the Rust compiler will work on arm32 or mips32 in the foreseeable future. The rules file already has to make use of workarounds to get the Rust compiler to build natively on these architectures at all: > https://salsa.debian.org/rust-team/rust/blob/debian/sid/debian/rules#L158 Given the fact that Rust upstream is always introducing a significant number of changes with each release, there is quite a chance of regressions of the compiler on these architectures. > I don't, however, think it's reasonable to wait indefinitely. No one was saying that. But I think it's more reasonable to wait for the Rust compiler to stabilize before making half of your distribution dependent on it. There is still no Rust-stable branch in sight which is most certainly a requirement for Rust to be part of enterprise distributions. I know the QA processes associated for SLES to update packages in a release version and I could imagine that it's not anything less involved for RHEL or other enterprise distributions. It seems that Rust upstream has not had any of the enterprise and long-term support distributions in mind yet. They seem to assume that distributions can just always use the latest upstream versions. > If even more coordination had taken place than what already did, > what would have been the expected outcome? A Rust compiler that doesn't regress every six weeks, maybe? > I think the correct answer *was* "it works on the release > architectures", Again, that was a snapshot of the situation. I'm expecting to see more regressions again in the future. > precisely because if non-release architectures need to > keep an outdated version while working on porting efforts, they'll > automatically do so, and that shouldn't impede those architectures too > much as long as other packages don't start depending specifically on > functionality from the new librsvg. (And if packages do start having > such dependencies, they'll get held back too.) Debian Ports doesn't support the cruft mechanism that DAK supports. We're lucky that the librsvg-common package is of arch any, otherwise librsvg would already been uninstallable in Debian Ports. So, this is just pure luck. Please don't make such statements when you're not aware of the differences between Debian's release and ports architectures. > Approaching the problem from a different angle: what help is needed > getting a viable LLVM and Rust development environment for more > architectures? There are open reviews for LLVM, for example: > https://reviews.llvm.org/D50784 >
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 3, 2018 at 5:54 PM John Paul Adrian Glaubitz 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
Re: Uncoordinated upload of the rustified librsvg
On Tue, Nov 06, 2018 at 11:58:57AM +0100, John Paul Adrian Glaubitz wrote: On 11/6/18 11:51 AM, Holger Levsen wrote: Also, you wrote a mail to d-d-a that rust is now running on 14 archs, so I was utterly surprised about your mail a few hours later blaming someone who uploaded a rust library. I am blaming them for an *uncoordinated* upload. I still don't even understand what "coordinated" means to you in this context.
Re: Uncoordinated upload of the rustified librsvg
On Tue, Nov 06, 2018 at 12:37:30PM +, Jonathan Dowland wrote: On Tue, Nov 06, 2018 at 11:58:57AM +0100, John Paul Adrian Glaubitz wrote: Well, if it wasn't for me, we'd probably be shipping the 2.40-version of librsrv in Debian Buster and Firefox would be missing on a couple of release architectures.. But I guess the phrase "Thank you" doesn't exist in Debian anymore. Debian's Dictionary is in a weird order; "Thank You" is right next to the definition of "Entitlement" Sorry this wasn't a helpful message. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Uncoordinated upload of the rustified librsvg
On Sun, Nov 4, 2018 at 2:30 PM Jeremy Bicha wrote: > On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings 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
Re: Uncoordinated upload of the rustified librsvg
Hi, 2018-11-04 17:32 Ben Hutchings: On Sun, 2018-11-04 at 13:15 +0100, Manuel A. Fernandez Montecelo wrote: For example RISC-V / riscv64 will probably not have LLVM ready at least until the LLVM stable released next March. There are enough languages whose implementation depends on LLVM that I think it has to be considered an essential part of a new Debian port. I doubt this is a surprise to the RISC-V porters. Rust was already a build-dependency for our standard desktop installation, since Firefox uses it. A port of LLVM is in the works, and has been for a few years, but it's not complete yet and not upstreamed. The people interested in the RISC-V port for LLVM focused more on the 32-bit and embedded variants, while the support for 64-bit is more mature in GCC, glibc and Linux. From a high level view, Firefox (along with the less critical Thunderbird) is about the only important package that depended on Rust, until librsvg. There are other browsers available based on webkit already working on riscv64. In general, there is a significant difference before and after librsvg-rust, because we go from "Firefox and Thunderbird not available" to "50%(1) of the Debian archive not available [unless other significant extra efforts or suboptimal solutions(2) are taken]". Speaking strictly of riscv64(3) -- having almost all of Debian, including almost everything in the Desktop space and missing only Firefox, is not bad deal at all. If more devices similar to the HiFive Unleashed become available in the next months, with higher volumes and lower prices, Debian users could use them as regular servers, media centres, scientific/imaging applications, even desktops. Which would be nice, because Debian would work right away in RISC-V based hardware, which currently (and hopefully in the future) is significantly more open/free than what we have had in our desktops and phones for a long time. However, if the number of packages available is reduced significantly, due to unavailability of librsvg and things that depend on it, we'd have probably only 50%(1) of the Debian archive available, missing many important areas. Cheers. (1) 50% is made up number, but by precluding most desktop and media players software, we can hopefully agree that it's a big event (2) Let's agree that even if we upload librsvg-c for the use of ports, it's not a particularly good solution (3) The same goes for other ports in which librsvg-rust is not available now, of course; including other free(-ish) hardware based on SH4 now that patents expired, but that effort has gone quiet for a while now. -- Manuel A. Fernandez Montecelo
Re: Uncoordinated upload of the rustified librsvg
On Tue, Nov 06, 2018 at 11:58:57AM +0100, John Paul Adrian Glaubitz wrote: Well, if it wasn't for me, we'd probably be shipping the 2.40-version of librsrv in Debian Buster and Firefox would be missing on a couple of release architectures.. But I guess the phrase "Thank you" doesn't exist in Debian anymore. Debian's Dictionary is in a weird order; "Thank You" is right next to the definition of "Entitlement" -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Uncoordinated upload of the rustified librsvg
On 2018-11-06 11:08, Holger Levsen wrote: > > I also bootstrapped the Rust compiler and helped fixing issues on armel, > > mips, mipsel, mips64el. Those are "strange" ports for you? Ok. > > no (except armel..) I'm running Debian armel on, I don't know, 1000 or 2000 devices. (Not myself, customers of my company are.) Raspberry Pi Zero is compatible only with Debian armel, too. IMHO, it's not strange at all and totally current hardware. So, from my side a big THANK YOU to Adrian! > getting in each others way, I'm not sure you have moral or practical > grounds to demand that we priotize your 1% needs over those of the 99%. Well, to me the main strength of Debian is, that it is the "universal operating system". Means, we might not care about 0.1 % of strange use cases, but 1 % might still be relevant. It it were not for such things as armel support, I get the 99 % much better covered by other distros, maybe. If the 1 % and the 99 % are really not possible to match, we have to go for the 99 %, of course. But, please, Adrian, do not think, that actions by others are directed against you or your work. We are all volunteers, giving their best. In this specific case, a little bit more of communication would have been better, but shit happens and your aggressive tone doesn't help solving issues in a constructive manner.
Re: Uncoordinated upload of the rustified librsvg
> There's no point dancing around the person's identity if you're going to > bring -devel into this. All it does it cost the rest of us a small > amount of effort to bother looking it up. Instead I think it would be > both more polite and more effective to name them directly, AND ensure to > CC them on the mail discussing them. and please don't use public insults like I see on #debian-devel saturday 23:06:34 GMT+1
Re: Uncoordinated upload of the rustified librsvg
Le mardi 06 novembre 2018 à 11:58:57+0100, John Paul Adrian Glaubitz a écrit : > On 11/6/18 11:51 AM, Holger Levsen wrote: > > please get of your high horse. > > > > I'm not sure it is said anywhere that one has to care about ports and/or > > some pet projects. > > This isn't about caring about ports, this is about being respectful to > each other. I find it quite difficult to support you here seeing the piece of respect you shown to each other on this thread. First you complained about the lack of communication to say in 6b4cd362-ae68-aa61-e729-f1b93d1a1...@physik.fu-berlin.de something like > Why would I need to communicate that? You, as the maintainer of librsvg > should know that this package has a large number of reverse dependencies > and that the rustified version would not work on all architectures. Did > you seriously expect me to write "Hey, I fixed Rust on the remaining release > architectures but please don't use this as an excuse to hurt my other work!"? > I rather think that this should be dictated by common sense and mutual > respect for the work of fellow Debian members. Respect and coordination is a two way thing. Expecting the maintainer of a package to do the whole work on his own is not really what I consider as common sense. Especially when you know such package was in experimental for two months. > > Also, you wrote a mail to d-d-a that rust is now running on 14 archs, so > > I was utterly surprised about your mail a few hours later blaming > > someone who uploaded a rust library. > > I am blaming them for an *uncoordinated* upload. As stated before, you didn't seem to consider that poking the maintainers to ensure coordination was needed. It appears it was. The lack of coordination is generally the result of two parts failing to acknowledge each other. > > however, most of us are here to have Debian running > > nicely on hardware used by the 99%, and if those two objectives are > > getting in each others way, I'm not sure you have moral or practical > > grounds to demand that we priotize your 1% needs over those of the 99%. > Well, if it wasn't for me, we'd probably be shipping the 2.40-version of > librsrv in Debian Buster and Firefox would be missing on a couple of > release architectures.. But I guess the phrase "Thank you" doesn't exist > in Debian anymore. We're all working on a lot of things without expecting a "thank you" each and every second. Claiming one just after starting a flamewar doesn't seem really appropriate. That said, thank you for your great work. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 03, 2018 at 10:53:12PM +0100, John Paul Adrian Glaubitz wrote: With this mail, I would like to protest the uncoordinated upload of the rustified version of libsrvg to unstable. The maintainer of the package There's no point dancing around the person's identity if you're going to bring -devel into this. All it does it cost the rest of us a small amount of effort to bother looking it up. Instead I think it would be both more polite and more effective to name them directly, AND ensure to CC them on the mail discussing them. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Uncoordinated upload of the rustified librsvg
On Tue, Nov 06, 2018 at 11:58:57AM +0100, John Paul Adrian Glaubitz wrote: > I also bootstrapped the Rust compiler and helped fixing issues on armel, > mips, mipsel, mips64el. Those are "strange" ports for you? Ok. no (except armel..) but as said, you just wrote a mail to d-d-a that rust has been ported to mips, mipsel, mips64el, so its available on all non strange archs now. (where strange = not a candidate on https://release.debian.org/buster/arch_qualify.html) > Well, if it wasn't for me, we'd probably be shipping the 2.40-version of > librsrv in Debian Buster and Firefox would be missing on a couple of > release architectures.. But I guess the phrase "Thank you" doesn't exist > in Debian anymore. i'm thankful for that, so thank you indeed. (I guess your first mail in this thread wasn't too inviting to reply with 'thank you' to...and certainly the follow ups.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Uncoordinated upload of the rustified librsvg
On 11/6/18 11:51 AM, Holger Levsen wrote: > please get of your high horse. > > I'm not sure it is said anywhere that one has to care about ports and/or > some pet projects. This isn't about caring about ports, this is about being respectful to each other. > Also, you wrote a mail to d-d-a that rust is now running on 14 archs, so > I was utterly surprised about your mail a few hours later blaming > someone who uploaded a rust library. I am blaming them for an *uncoordinated* upload. > That said, I do understand your frustration and I do applause your work > on "strange" ports, I also bootstrapped the Rust compiler and helped fixing issues on armel, mips, mipsel, mips64el. Those are "strange" ports for you? Ok. > however, most of us are here to have Debian running > nicely on hardware used by the 99%, and if those two objectives are > getting in each others way, I'm not sure you have moral or practical > grounds to demand that we priotize your 1% needs over those of the 99%. Well, if it wasn't for me, we'd probably be shipping the 2.40-version of librsrv in Debian Buster and Firefox would be missing on a couple of release architectures.. But I guess the phrase "Thank you" doesn't exist in Debian anymore. 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
Re: Uncoordinated upload of the rustified librsvg
On Tue, Nov 06, 2018 at 02:43:44AM +0100, John Paul Adrian Glaubitz wrote: > >> Why would I need to communicate that? > > Because coordination needs involvement from all > If the maintainer of a package doesn't understand which reverse > dependencies his package has, he shouldn't be the maintainer of > his package. please get of your high horse. I'm not sure it is said anywhere that one has to care about ports and/or some pet projects. Also, you wrote a mail to d-d-a that rust is now running on 14 archs, so I was utterly surprised about your mail a few hours later blaming someone who uploaded a rust library. That said, I do understand your frustration and I do applause your work on "strange" ports, however, most of us are here to have Debian running nicely on hardware used by the 99%, and if those two objectives are getting in each others way, I'm not sure you have moral or practical grounds to demand that we priotize your 1% needs over those of the 99%. sorry. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Uncoordinated upload of the rustified librsvg
John Paul Adrian Glaubitz wrote: > >> Why would I need to communicate that? > > Because coordination needs involvement from all > > If the maintainer of a package doesn't understand which reverse > dependencies his package has, he shouldn't be the maintainer of > his package. This is not a situation that needs such further escalations and hyperbole. The problem here is *not* simply knowing the reverse-dependencies; I feel certain the maintainer of librsvg is well aware of what depends on librsvg. And conversely, I'm sure that the maintainers of packages depending on librsvg are aware of that dependency as well. librsvg has rewritten substantial fractions of its code upstream in Rust. It won't be the last such library or package to do so. librsvg sat in experimental for months, precisely *because* the maintainer knew that such a change could potentially be disruptive, and wanted to properly integrate it into Debian. But the new upstream version fundamentally depends on Rust. Running old versions of a library is not a viable long-term strategy. Attempting to find alternatives written in C is not a viable long-term strategy either; that's running in the wrong direction. Ultimately, the new version will need uploading to Debian, and an architecture that wants to run a full desktop, or for that matter a server or embedded environment, will need to have LLVM support and Rust support. I think it's reasonable for the *first* such library being uploaded to wait a little while to coordinate, which it did. I don't, however, think it's reasonable to wait indefinitely. If even more coordination had taken place than what already did, what would have been the expected outcome? I think the correct answer *was* "it works on the release architectures", precisely because if non-release architectures need to keep an outdated version while working on porting efforts, they'll automatically do so, and that shouldn't impede those architectures too much as long as other packages don't start depending specifically on functionality from the new librsvg. (And if packages do start having such dependencies, they'll get held back too.) Approaching the problem from a different angle: what help is needed getting a viable LLVM and Rust development environment for more architectures? Speaking with an upstream Rust hat on in addition to a Debian hat: what could Rust do to make life easier for porters? And what could Debian's *considerable* expertise in porting do to make that more sustainable upstream? (As an example, it might help if upstream Rust folks had access to machines for more architectures, though that's a side issue for having an LLVM port in the first place.)
Re: Uncoordinated upload of the rustified librsvg
>> Why would I need to communicate that? > Because coordination needs involvement from all If the maintainer of a package doesn't understand which reverse dependencies his package has, he shouldn't be the maintainer of his package. I don't understand why you are defending his behavior. It's simply not nice to pull such a stunt after I put in all these efforts to help others. If you think it is, then the CoCs we have aren't worth the "paper" they are written on. FWIW, I am not subscribed to debian-devel, please keep me CC'ed. Thanks, 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
Re: Uncoordinated upload of the rustified librsvg
> 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." Why would I need to communicate that? You, as the maintainer of librsvg should know that this package has a large number of reverse dependencies and that the rustified version would not work on all architectures. Did you seriously expect me to write "Hey, I fixed Rust on the remaining release architectures but please don't use this as an excuse to hurt my other work!"? I rather think that this should be dictated by common sense and mutual respect for the work of fellow Debian members. Giving other maintainers a heads-up and a chance to coordinate the upload is the least that can be expected in such case. It wouldn't have hurt at all. Just going ahead and willfully causing others trouble is simply not acceptable. There was no immediate time pressure for this upload. > While today's upload was apparently a surprise, I > don't think it should have been a surprise that this upload was > coming. It's the complete lack of communication and coordination, not that the fact the package was updated. You basically told me now not to help other Debian projects in the future because the immediate repayment in Debian seems to be disregard. Why should I pursue such work in the future if that's what I get in return? Why should I keep providing fixes for various packages if I get messages like yours in return? 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
Re: Uncoordinated upload of the rustified librsvg
On Sun, 2018-11-04 at 22:05 +0100, Michael Biebl wrote: > Am 04.11.18 um 20:30 schrieb Jeremy Bicha: > > On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings 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? > > Please make sure to file an RC bug against this package, to ensure this > library never migrates to testing. That shouldn't be necessary - only source packages that build binaries for a release architecture (or "all") are candidates for testing. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: Uncoordinated upload of the rustified librsvg
Am 04.11.18 um 20:30 schrieb Jeremy Bicha: > On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings 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? Please make sure to file an RC bug against this package, to ensure this library never migrates to testing. -- 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
Re: Uncoordinated upload of the rustified librsvg
On Sun, Nov 4, 2018 at 11:33 AM Ben Hutchings 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
Re: Uncoordinated upload of the rustified librsvg
On Sun, 2018-11-04 at 13:15 +0100, Manuel A. Fernandez Montecelo wrote: > Hi, > > 2018-11-04 01:13 Ben Hutchings: > > On Sat, 2018-11-03 at 23:46 +0100, Adam Borowski wrote: [...] > > > A regression of this scale shouldn't be done lightly. So what about > > > reverting it now so things don't degrade, then having a flamewar what to > > > do? > > > > We already know what to do, which is to prioritise our upcoming release > > and the architectures that will be included in it. We do not allow > > Debian ports to hold back changes in unstable. > > I think that this is a reasonable assumption in general if the breakage > is small, but I am not sure if this is the case when in one single blow > a few architectures are completely removed from the table (and new > architectures too, until they get a LLVM and Rust port, along with all > other necessary support in other tools). > > For example RISC-V / riscv64 will probably not have LLVM ready at least > until the LLVM stable released next March. There are enough languages whose implementation depends on LLVM that I think it has to be considered an essential part of a new Debian port. I doubt this is a surprise to the RISC-V porters. Rust was already a build-dependency for our standard desktop installation, since Firefox uses it. > Maybe in this case there are other solutions, like keeping librsvg-rust > and librsvg-c for different architectures. [...] I do like the proposal of adding a librsvg-c for just the architectures that don't have Rust (yet). Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: Uncoordinated upload of the rustified librsvg
Hi,
2018-11-04 01:13 Ben Hutchings:
On Sat, 2018-11-03 at 23:46 +0100, Adam Borowski wrote:
> The maintainer of the package knows very well that
> this particular package has a huge number of reverse dependencies and would
cause
> a lot of problems with non-Rust targets now. He also knows very well that I
am very
> much interested in Debian Ports and a lot of efforts have been invested there.
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.
librsvg doesn't appear to be a hard dependency for fvwm.
In fact, src:fvwm has a Build-Depends on "librsvg2-dev (>= 2.13.92)",
and the binary package a Depends on librsvg2-2, which are provided by
src:librsvg.
If by "hard dependency" you mean that it can be disabled for a bunch of
arches, sure, it is possible if changes in the dependencies are
implemented.
But then that means that a significant percent of the archive, say, even
only 100~200 packages, will have to add dependency exceptions for
several architectures, and we all know how these kind of changes happen
in Debian: from very slow progress to complete stalls for months.
There're always good chances to stumble upon unmaintained packages,
different sorts of entanglements ("cannot be uploaded until this of that
is resolved"), or even --fortunately in a very small handful of cases--
maintainers unwilling to make things happen.
Not to pick specifically on your reply, but to continue with this
example of dependencies... By using "build-rdeps" from devscripts:
Found a total of 145 reverse build-depend(s) for librsvg2-dev.
These include most of the desktops (gnome, mate) and more lenient WMs,
like afterstep and wmaker, but also vlc and ffmpeg and
gst-plugins-bad1.0 (gstreamer). Everyone can imagine that this removes
a big percentage of the packages in the archive.
That's not all, as there are many dependencies of librsvg2-bin:
Found a total of 5832 reverse build-depend(s) for librsvg2-2.
Using only the ones directly build-depending on it (ignoring virtual
deps), with "build-rdeps --old":
Found a total of 72 reverse build-depend(s) for librsvg2-bin.
This includes among others: gnupg2, cups-filters, debian-installer.
I don't want to bore all of you to death with examples, but there's a
big difference between direct (build-)dependencies and all the packages
that need to be working in a given architecture in order to be able to
compile a package, and keep the whole thing up to date as packages get
uploaded to unstable.
By making librsvg unavailable for an architecture, many packages will
not be able to build if rebootstrapped again, in all of those not having
Rust ready. As Adam says, the % of the archive will eventually degrade
to this number in all architectures which cannot use the newer
src:librsvg (due to removal of packages, transitions and so on). All
arches in debian-ports can do more than 75% now, and some almost 90% or
more, but this would be impossible without librsvg:
https://buildd.debian.org/stats/graph-ports-quarter-big.png
A regression of this scale shouldn't be done lightly. So what about
reverting it now so things don't degrade, then having a flamewar what to do?
We already know what to do, which is to prioritise our upcoming release
and the architectures that will be included in it. We do not allow
Debian ports to hold back changes in unstable.
I think that this is a reasonable assumption in general if the breakage
is small, but I am not sure if this is the case when in one single blow
a few architectures are completely removed from the table (and new
architectures too, until they get a LLVM and Rust port, along with all
other necessary support in other tools).
For example RISC-V / riscv64 will probably not have LLVM ready at least
until the LLVM stable released next March.
Maybe in this case there are other solutions, like keeping librsvg-rust
and librsvg-c for different architectures.
But still, it would be nice to have some reassurance for the people
working in ports that the effort spent will not be swept away from one
day to the next just because of a single package, without further
discussion or trying to find acceptable solutions.
Also, that there's a bit of an irony in this case, not specially funny
for Adrian. He just made Rust work in new architectures [1], including
the mips* stable-release-supported architectures. And it's only as a
result of this that a few days later a new src:librsvg implemented in
Rust can be uploaded to unstable, otherwise it couldn't.
So the repayment for him to spend time and make Rust work in many
architectures, is to blow away his work in a lot of other arches. Not
nice.
[1] https://lists.debian.org/debian-devel-announce/2018/11/msg0.html
Cheers.
--
Manuel A. Fernandez Montecelo
Re: Uncoordinated upload of the rustified librsvg
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
Re: Uncoordinated upload of the rustified librsvg
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 Description: PGP signature
Re: Uncoordinated upload of the rustified librsvg
Jeremy Bicha, le sam. 03 nov. 2018 21:04:49 -0400, a ecrit: > On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski 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
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski 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
Re: Uncoordinated upload of the rustified librsvg
On Sat, 2018-11-03 at 23:46 +0100, Adam Borowski wrote: > On Sat, Nov 03, 2018 at 10:53:12PM +0100, John Paul Adrian Glaubitz wrote: > > With this mail, I would like to protest the uncoordinated upload of the > > rustified > > version of libsrvg to unstable. "Uncoordinated upload" is a term normally used for library ABI transitions that aren't coordinated with the release team. That is not what happened here. > > The maintainer of the package knows very well that > > this particular package has a huge number of reverse dependencies and would > > cause > > a lot of problems with non-Rust targets now. He also knows very well that I > > am very > > much interested in Debian Ports and a lot of efforts have been invested > > there. > > 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. librsvg doesn't appear to be a hard dependency for fvwm. > A regression of this scale shouldn't be done lightly. So what about > reverting it now so things don't degrade, then having a flamewar what to do? We already know what to do, which is to prioritise our upcoming release and the architectures that will be included in it. We do not allow Debian ports to hold back changes in unstable. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 03, 2018 at 10:53:12PM +0100, John Paul Adrian Glaubitz wrote: > With this mail, I would like to protest the uncoordinated upload of the > rustified > version of libsrvg to unstable. The maintainer of the package knows very well > that > this particular package has a huge number of reverse dependencies and would > cause > a lot of problems with non-Rust targets now. He also knows very well that I > am very > much interested in Debian Ports and a lot of efforts have been invested there. 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. A regression of this scale shouldn't be done lightly. So what about reverting it now so things don't degrade, then having a flamewar what to do? Meow! -- A true bird-watcher waves his tail while doing so.
