Bug#919893: package shouldn't exist
So the package that shouldn't have existed made it into buster, there's a ridiculous situation with 3 packages providing essentially the same functionality with minor differences and no practical way for a user to figure out which to install, and no movement on fixing this before the *next* release. On Thu, Feb 07, 2019 at 03:34:31PM +, Thorsten Glaser wrote: Henrique de Moraes Holschuh dixit: On Sun, Jan 20, 2019, at 14:05, Thorsten Glaser wrote: How about starting a sort of transition to the split packages instead?= Looks like a sensible approach to me. It’s a bit too “short” before the release, always has been. My other ideas, both the p-u and the “castling”, rely too much on that all things involved go smooth. I’d like to propose a new plan: * we still intend to do a rng-tools → rng-tools5 transition for bullseye but leave buster alone * we’ll just keep rng-tools (5.x) out of testing, and will later request package removal of src:rng-tools and the binary package (but (new) only AFTER the buster release) * I’ll request removal of rng-tools-debian from testing (and, therefore, buster), but keep it around in sid until we have a new solution (to not break existing users) * said new solution could be to either add all features needed to rng-tools5 or, well, keeping rng-tools-debian (the name’s correct as it’s the former Debian maintainer’s fork of rng-tools, but we can bikeshed that later) around * whatever we do, we’ll do it way after the buster release (so we will have had time to discuss it before implementing) but way before the bullseye release (so it will have had enough time to cook in testing/sid beforehand) * in bullseye, we will need to handle migration from - rng-tools (2.x) [from buster] - rng-tools (5.x) [from sid] - rng-tools5 [from buster/sid] - rng-tools-debian [from sid] but we don’t need to handle all of them the same way; details mostly depend on whether we manage to patch rng-tools5 enough so that we can migrate *all* of them to *one* destination package, handling all use cases; the configuration change needs to be in the release notes of course, but this way, we’ll have actually enough time to do that This most likely means that rng-tools5 people (upstream and packagers) need to consider adding enough rng-tools-debian functionality (more command line switches, and making them actually do what they used to do, and an /etc/default/ file). Is this agreeable? If so, I’ll go ahead requesting removal of rng-tools-debian from testing, and we’ll have to continue blocking rng-tools 5 from entering testing. The downside is that the fixes in rng-tools-debian won’t make it into rng-tools in buster, and that rng-tools-debian will be around for a while longer. But I’ve looked at popcon and *buntu and saw it’s already used by way more people than the two or three systems I installed it on myself, so we’ll do best doing a transition plan including it *anyway*, which won’t get worse if it sticks round for a while. Sorry for taking ~2 weeks for this answer, I’ve had the cold (and now caught conference flu at FOSDEM, no rest for me…), but I believe that even acting 2 weeks ago we would not have managed in time it *anything* went wrong, and the current status quo in testing is “good enough” (that is, not a regres‐ sion from stretch) for us to keep for a release longer. If one step in the transition had failed, we would have been left without rng-tools in buster at all, which had derailed any later transition plans and made users even angrier. bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#919893: package shouldn't exist
Henrique de Moraes Holschuh dixit: >On Sun, Jan 20, 2019, at 14:05, Thorsten Glaser wrote: >> How about starting a sort of transition to the split packages instead?= > >Looks like a sensible approach to me. It’s a bit too “short” before the release, always has been. My other ideas, both the p-u and the “castling”, rely too much on that all things involved go smooth. I’d like to propose a new plan: * we still intend to do a rng-tools → rng-tools5 transition for bullseye but leave buster alone * we’ll just keep rng-tools (5.x) out of testing, and will later request package removal of src:rng-tools and the binary package (but (new) only AFTER the buster release) * I’ll request removal of rng-tools-debian from testing (and, therefore, buster), but keep it around in sid until we have a new solution (to not break existing users) * said new solution could be to either add all features needed to rng-tools5 or, well, keeping rng-tools-debian (the name’s correct as it’s the former Debian maintainer’s fork of rng-tools, but we can bikeshed that later) around * whatever we do, we’ll do it way after the buster release (so we will have had time to discuss it before implementing) but way before the bullseye release (so it will have had enough time to cook in testing/sid beforehand) * in bullseye, we will need to handle migration from - rng-tools (2.x) [from buster] - rng-tools (5.x) [from sid] - rng-tools5 [from buster/sid] - rng-tools-debian [from sid] but we don’t need to handle all of them the same way; details mostly depend on whether we manage to patch rng-tools5 enough so that we can migrate *all* of them to *one* destination package, handling all use cases; the configuration change needs to be in the release notes of course, but this way, we’ll have actually enough time to do that This most likely means that rng-tools5 people (upstream and packagers) need to consider adding enough rng-tools-debian functionality (more command line switches, and making them actually do what they used to do, and an /etc/default/ file). Is this agreeable? If so, I’ll go ahead requesting removal of rng-tools-debian from testing, and we’ll have to continue blocking rng-tools 5 from entering testing. The downside is that the fixes in rng-tools-debian won’t make it into rng-tools in buster, and that rng-tools-debian will be around for a while longer. But I’ve looked at popcon and *buntu and saw it’s already used by way more people than the two or three systems I installed it on myself, so we’ll do best doing a transition plan including it *anyway*, which won’t get worse if it sticks round for a while. Sorry for taking ~2 weeks for this answer, I’ve had the cold (and now caught conference flu at FOSDEM, no rest for me…), but I believe that even acting 2 weeks ago we would not have managed in time it *anything* went wrong, and the current status quo in testing is “good enough” (that is, not a regres‐ sion from stretch) for us to keep for a release longer. If one step in the transition had failed, we would have been left without rng-tools in buster at all, which had derailed any later transition plans and made users even angrier. bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#915689: Bug#919893: Bug#915689: Bug#919893: package shouldn't exist
Michael Stone dixit: > So that's basically just the --rng-entropy argument? If we switch rng-tools5 > to /usr/lib/stunnel/arngc-slrd | runtunnel | \ rngd -f -r /proc/self/fd/0 -H 0.99 -B 2 \ -s 32 -W "$threshold" -t 300 -T 60 I just had the idea of “castling”¹, to avoid going through pu: I’d upload src:rng-tools-debian (to unstable, but with the intention of letting it transition to testing/buster) but providing the rng-tools binary package, with NEWS suggesting a move to rng-tools5. We’ll scrap the rng-tools-debian package for now, and post-buster re-evaluate whether the missing flags can be added to rng-tools5 (in which case we’ll start a tran‐ sition of whole Debian to it) or not (in which case we’ll keep it but, perhaps, under a new name). Sorry still not caught up with all mails yet, but this is the best I think we can do, with the release coming up so soon. The rng-tools-debian source package contains the well-tested code users can, at the moment, expect, plus a massively better initscript, so letting it take over the rng-tools binary package has no cost and minor benefit to users (but allows us to go without p-u, and to RM src:rng-tools entirely). This also allows users some time for the transition (and two years to complain to us if they *do*, for some reason, need the old rng-tools), if it’s announced in buster that we plan to remove it for bullseye. bye, //mirabilos ① inspired from rereading the Launchpad bug discussion
Bug#915689: Bug#919893: Bug#915689: Bug#919893: package shouldn't exist
On Wed, Jan 23, 2019 at 04:12:24PM +, Thorsten Glaser wrote: Yes, exactly: it's definitely better for a certain class of hardware, but I'm honestly just not sure whether any of those are still relevant. (Like, do they work with current kernels, are they in hardware that's otherwise supported, etc.?) I'd love to see reports from people who are still using the older version for functionality that isn't in the newer version to help inform what My MUA just threw this mail to me in an interesting timing attack (I deleted the last new mail just when this one came into my INBOX and before it was sorted under the thread), I didn't read any others in the thread since Monday yet and will see when I have time for this, but since you asked: I use the old rng-tools, with several of the now-unsupported command line options, reading from /dev/stdin which is the stdout of an SSL client, in a scenario where I distribute entropy over the network to multiple boxen. So, software, not hardware. But rng-tools is needed in order to • attribute the new entropy to the pool estimate (even though I use a value of less than 8 bit per byte) • fill the pool up to the watermark • do some plausibility checks on the input as otherwise I could just connect the SSL stdout to /dev/urandom writingly. In general, the missing flags are good to use if you have hardware that produces “some” entropy but not an estimated 8 bit per byte, for example. Also, slow RNGs; I don’t want to have several hundred MiB/s traffic from this… So that's basically just the --rng-entropy argument? If we switch rng-tools5 to the fork at https://github.com/nhorman/rng-tools there's already a new entropy-count option to address that. I don't see any good reason to deploy *new* installs of the rng-tools2 codebase for purely software reasons. I’ll respond to the other mails in the thread in time, when I have the time. Just another data point: rng-tools-debian has an installed user base in testing and in *buntu (they sync’d it), so renaming it is out of the question now. The package description should make it clear that rng-tools5 should be preferred to most, but the -debian is historically true (it’s the one with “all the new options hmh wrote for Debian”, as opposed to the “latest upstream gkernel” one). It's been in testing for a matter of days, so I'm skeptical that this is a real concern. (And it's called *testing* for a reason.) Renaming the package and adding a rng-tools-debian transition package would make the matter moot (though I think it would be silly). Again, calling this rng-tools-debian IMO makes an already confusing set of packages even worse. (And honestly, this is kind of thing that should be sorted out when a package is ITP'd and discussed, not done and then declared a fait accompli.) -- Michael Stone
Bug#915689: Bug#919893: Bug#915689: Bug#919893: package shouldn't exist
Michael Stone dixit: > Yes, exactly: it's definitely better for a certain class of hardware, but I'm > honestly just not sure whether any of those are still relevant. (Like, do they > work with current kernels, are they in hardware that's otherwise supported, > etc.?) I'd love to see reports from people who are still using the older > version for functionality that isn't in the newer version to help inform what My MUA just threw this mail to me in an interesting timing attack (I deleted the last new mail just when this one came into my INBOX and before it was sorted under the thread), I didn't read any others in the thread since Monday yet and will see when I have time for this, but since you asked: I use the old rng-tools, with several of the now-unsupported command line options, reading from /dev/stdin which is the stdout of an SSL client, in a scenario where I distribute entropy over the network to multiple boxen. So, software, not hardware. But rng-tools is needed in order to • attribute the new entropy to the pool estimate (even though I use a value of less than 8 bit per byte) • fill the pool up to the watermark • do some plausibility checks on the input as otherwise I could just connect the SSL stdout to /dev/urandom writingly. In general, the missing flags are good to use if you have hardware that produces “some” entropy but not an estimated 8 bit per byte, for example. Also, slow RNGs; I don’t want to have several hundred MiB/s traffic from this… See https://bugs.launchpad.net/ubuntu/+source/rng-tools/+bug/1333293 for a parameter comparison. I’ll respond to the other mails in the thread in time, when I have the time. Just another data point: rng-tools-debian has an installed user base in testing and in *buntu (they sync’d it), so renaming it is out of the question now. The package description should make it clear that rng-tools5 should be preferred to most, but the -debian is historically true (it’s the one with “all the new options hmh wrote for Debian”, as opposed to the “latest upstream gkernel” one). bye, //mirabilos (still fighting an infection)
Bug#915689: Bug#919893: package shouldn't exist
On Wed, Jan 23, 2019 at 05:19:13AM -0500, Henrique de Moraes Holschuh wrote: On Mon, Jan 21, 2019, at 10:36, Michael Stone wrote: Yes, but most of those features are obsolescent at best. I'm not clear on what functionality is actually being used. (I'm hesitant to remove "old" rng-tools is better for any low-bandwidth RNGs, so I am not sure it is obsolescent: that depends entirely on whether people still design/have low-bandwidth RNGs worth supporting. Yes, exactly: it's definitely better for a certain class of hardware, but I'm honestly just not sure whether any of those are still relevant. (Like, do they work with current kernels, are they in hardware that's otherwise supported, etc.?) I'd love to see reports from people who are still using the older version for functionality that isn't in the newer version to help inform what we should do. I'm conservative enough that I don't want to break existing installs (especially for something that's security-relevant) but it would be nice to know whether I'm being overly cautious on that. -- Michael Stone
Bug#919893: package shouldn't exist
On Sun, Jan 20, 2019, at 14:05, Thorsten Glaser wrote: > How about starting a sort of transition to the split packages instead? Looks like a sensible approach to me. > • upload rng-tools 2-unofficial-mt.14-2 to buster-proposed-updates > (since, due to the version number, it cannot go via unstable), > unchanged from 2-unofficial-mt.14-1 except for a NEWS entry saying: > > “This is the last 2.x version of rng-tools. If you wish to >continue using it, perhaps if you rely on the new command >line options this version has over rng-tools5, please >migrate to the rng-tools-debian package, also available >in buster, instead. If you do so, copy your configuration >settings from /etc/default/rng-tools over to the new file >/etc/default/rng-tools-debian after installing the new package. > > “If you have newer or high-bandwidth HWRNGs or just wish to >follow Debian defaults, migrate to the package rng-tools5, >also available in buster, instead. Please note that it does >not use a file under /etc/defaults/ to configure. > > “If you do nothing, your version of rng-tools will be replaced >with rng-tools5 automatically in bullseye.” > > • keep rng-tools5 and rng-tools-debian in testing > > • after buster, drop src:rng-tools and move the binary package > rng-tools to the rng-tools5 source package as transitional > package, as announced in the above-mentioned NEWS > > ⇒ this will cause the least breakage or surprise to users, > retain version numbers that are actually meaningful, and > start a proper, two-release, transition *and* ensure that > people know about the configuration files Agreed. > I’d be willing to try to coordinate this (also with the release > team since we have to go via p-u). Thank you, please do! > Please do tell me what you think, but *do* refrain from taking > hasty actions (even though we need to get this settled within > ten days or so). Also agreed. Anyone has a better idea for a transition plan? -- Henrique de Moraes Holschuh
Bug#915689: Bug#919893: package shouldn't exist
On Mon, Jan 21, 2019, at 10:36, Michael Stone wrote: > On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote: > >On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote: > >> I’m very much against just saying this package > >> “should not exist” Yeah, what should not exist are NMUs that cause this much of a mess, especially if the one that did it is not going to fix it. Thank you guys very much for pushing a way forward, whichever it might be. And please feel free to adopt the "old rng-tools" package if it is being useful to you... > >I'm inclined to agree with this as the source (+ features/parameters) for > >this > >package is substantially different from rng-tools/rng-tools5. > > Yes, but most of those features are obsolescent at best. I'm not clear > on what functionality is actually being used. (I'm hesitant to remove "old" rng-tools is better for any low-bandwidth RNGs, so I am not sure it is obsolescent: that depends entirely on whether people still design/have low-bandwidth RNGs worth supporting. But yeah, on any stuff with high-bandwidth RNGs (like recent x86 processors, and ARM SoCs with crypto accelerators), I don't think the features "rng-tools-old" implement are really relevant. I'd rather we had it in-kernel, really. -- Henrique de Moraes Holschuh
Bug#915689: Fwd: Re: Bug#919893: package shouldn't exist
On maandag 21 januari 2019 17:13:42 CET Michael Stone wrote: > >Entropy generation for the creation of SSH keys as the netinstaller is > >mostly used in headless situations. > >https://github.com/debian-pi/raspbian-ua-netinst/issues/42 > > That functionality doesn't require the old package; will work fine with > rng-tools5. Great, thanks :) FTR: That *I* don't need it in my particular use case does not mean that no one has a need for the functionality now provided by rng-tools-debian signature.asc Description: This is a digitally signed message part.
Bug#915689: Fwd: Re: Bug#919893: package shouldn't exist
On Mon, Jan 21, 2019 at 04:47:51PM +0100, Diederik de Haas wrote: On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote: On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote: >On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote: >> I’m very much against just saying this package >> “should not exist” > >I'm inclined to agree with this as the source (+ features/parameters) for >this package is substantially different from rng-tools/rng-tools5. Yes, but most of those features are obsolescent at best. I'm not clear on what functionality is actually being used. (I'm hesitant to remove it exactly because I'm not clear on that, but I tend to think that it's functionally obsolete.) I'm not knowledgeable enough to weigh in on that and/or what is best towards the future, so I'll leave that up to you. >coordination/progress. I'm thinking of updating >https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we >use(d) the old rng-tools to get much better/more entropy on the Raspberry >Pi. In what way? Entropy generation for the creation of SSH keys as the netinstaller is mostly used in headless situations. https://github.com/debian-pi/raspbian-ua-netinst/issues/42 That functionality doesn't require the old package; will work fine with rng-tools5.
Bug#915689: Bug#919893: package shouldn't exist
On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote: > On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote: > >On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote: > >> I’m very much against just saying this package > >> “should not exist” > > > >I'm inclined to agree with this as the source (+ features/parameters) for > >this package is substantially different from rng-tools/rng-tools5. > > Yes, but most of those features are obsolescent at best. I'm not clear > on what functionality is actually being used. (I'm hesitant to remove > it exactly because I'm not clear on that, but I tend to think that it's > functionally obsolete.) I'm not knowledgeable enough to weigh in on that and/or what is best towards the future, so I'll leave that up to you. > >coordination/progress. I'm thinking of updating > >https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we > >use(d) the old rng-tools to get much better/more entropy on the Raspberry > >Pi. > > In what way? Entropy generation for the creation of SSH keys as the netinstaller is mostly used in headless situations. https://github.com/debian-pi/raspbian-ua-netinst/issues/42 signature.asc Description: This is a digitally signed message part.
Bug#915689: Bug#919893: package shouldn't exist
On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote: On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote: I’m very much against just saying this package “should not exist” I'm inclined to agree with this as the source (+ features/parameters) for this package is substantially different from rng-tools/rng-tools5. Yes, but most of those features are obsolescent at best. I'm not clear on what functionality is actually being used. (I'm hesitant to remove it exactly because I'm not clear on that, but I tend to think that it's functionally obsolete.) coordination/progress. I'm thinking of updating https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we use(d) the old rng-tools to get much better/more entropy on the Raspberry Pi. In what way?
Bug#915689: Bug#919893: package shouldn't exist
On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote: > I’m very much against just saying this package > “should not exist” I'm inclined to agree with this as the source (+ features/parameters) for this package is substantially different from rng-tools/rng-tools5. AFAICT the problem started when rng-tools changed substantially by the upload which made it (very) similar to rng-tools5 and I think the last line of the long description of rng-tools should've been removed as it only applies to the 'old' implementation (which is now in rng-tools-debian). I bumped into the 'conversation' because I noticed a lack of conversation/ coordination/progress. I'm thinking of updating https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we use(d) the old rng-tools to get much better/more entropy on the Raspberry Pi. (I also want to investigate whether it'll help with other small SBCs like Pine A64) I haven't tried yet whether rng-tools5 will work just as well (raspbian-ua- netinst doesn't use any cmd-line params) And I also think that the current situation shouldn't end up in a stable release. signature.asc Description: This is a digitally signed message part.
Bug#919893: package shouldn't exist
On Sun, Jan 20, 2019 at 03:59:11PM +, Thorsten Glaser wrote: • keep rng-tools5 and rng-tools-debian in testing FWIW, I'd much rather call this rng-tools2 or rng-tools-legacy or something other than rng-tools-debian (which implies that for some reason this version is more "debian" than another version, and that it can't be used anywhere except debian).
Bug#919893: package shouldn't exist
On Sun, Jan 20, 2019 at 03:59:11PM +, Thorsten Glaser wrote: Please don’t understand me wrong, I’m not against a sensible solution out of this mess, but I’m very much against just saying this package “should not exist” without one. Once it's in stable, this mess is a lot harder to fix, so it's not ok to just leave it screwed up for now. I don’t have much time right now (got to go), but I’ve got a better idea than this: that package is in much less health and should perhaps be replaced by a transitional package instead. How about starting a sort of transition to the split packages instead? • upload rng-tools 2-unofficial-mt.14-2 to buster-proposed-updates (since, due to the version number, it cannot go via unstable), unchanged from 2-unofficial-mt.14-1 except for a NEWS entry saying: I don't know if this will work or not. If it will, sounds good.
Bug#919893: package shouldn't exist
Please don’t understand me wrong, I’m not against a sensible solution out of this mess, but I’m very much against just saying this package “should not exist” without one. (I also intend to actually fork the upstream part and hack on it, low pace though and mostly small fixes.) I don’t have much time right now (got to go), but I’ve got a better idea than this: >that package is in much less health and should perhaps be replaced >by a transitional package instead. How about starting a sort of transition to the split packages instead? • upload rng-tools 2-unofficial-mt.14-2 to buster-proposed-updates (since, due to the version number, it cannot go via unstable), unchanged from 2-unofficial-mt.14-1 except for a NEWS entry saying: “This is the last 2.x version of rng-tools. If you wish to continue using it, perhaps if you rely on the new command line options this version has over rng-tools5, please migrate to the rng-tools-debian package, also available in buster, instead. If you do so, copy your configuration settings from /etc/default/rng-tools over to the new file /etc/default/rng-tools-debian after installing the new package. “If you have newer or high-bandwidth HWRNGs or just wish to follow Debian defaults, migrate to the package rng-tools5, also available in buster, instead. Please note that it does not use a file under /etc/defaults/ to configure. “If you do nothing, your version of rng-tools will be replaced with rng-tools5 automatically in bullseye.” • keep rng-tools5 and rng-tools-debian in testing • after buster, drop src:rng-tools and move the binary package rng-tools to the rng-tools5 source package as transitional package, as announced in the above-mentioned NEWS ⇒ this will cause the least breakage or surprise to users, retain version numbers that are actually meaningful, and start a proper, two-release, transition *and* ensure that people know about the configuration files I’d be willing to try to coordinate this (also with the release team since we have to go via p-u). Please do tell me what you think, but *do* refrain from taking hasty actions (even though we need to get this settled within ten days or so). Thanks in advance, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#919893: package shouldn't exist
Michael Stone dixit: > I don't entirely understand why this package was ever uploaded, and > as far as I can tell, with no ITP. An ITP is not necessary, just recommended. There was attempt for discussion in #916147, which was however ignored by *everyone* else for over a month before I took action, so you can take that as the ITP. Before, there was discussion in LP#1333293 in which the rng-tools (5) maintainer recommended me to create this very package, in 2014 (sorry not 2013 as I typo’d earlier). > It should not be included in buster. I disagree: it is necessary to fulfil versioned dependencies on rng-tools (<< 3) | rng-tools-debian (<< 3) (introduced in 2014, incidentally), and some of its contents, such as the new init script, alone are worth it. Given that it’s not possible to update rng-tools back to the 2.x version, nor to update the one in buster except via proposed-updates, that package is in much less health and should perhaps be replaced by a transitional package instead. bye, //mirabilos -- 18:47⎜ well channels… you see, I see everything in the same window anyway 18:48⎜ i know, you have some kind of telnet with automatic pong 18:48⎜ haha, yes :D 18:49⎜ though that's more tinyirc – sirc is more comfy
Bug#919893: package shouldn't exist
Package: rng-tools-debian I don't entirely understand why this package was ever uploaded, and as far as I can tell, with no ITP. It should not be included in buster.
