Bug#915689: prevent from migrating to testing
On Wed, Jan 23, 2019 at 05:46:39AM -0500, Henrique de Moraes Holschuh wrote: On Sun, Jan 20, 2019, at 14:06, Thorsten Glaser wrote: But you’re not in a situation to command either, considering hmh is the ONLY maintainer of rng-tools so we WILL need his input on this (or do an NMU). Anything that does not break things for people in stretch when updating to buster would be excellent. But that is going to be a pain to do, so anything that warns people in stable that they will get broken and must install is IMHO *acceptable*. It shouldn't be difficult to preserve existing configs as long as rng-tools isn't rng-tools5 in buster.
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019, at 14:06, Thorsten Glaser wrote: > But you’re not in a situation to command either, considering > hmh is the ONLY maintainer of rng-tools so we WILL need his > input on this (or do an NMU). Anything that does not break things for people in stretch when updating to buster would be excellent. But that is going to be a pain to do, so anything that warns people in stable that they will get broken and must install is IMHO *acceptable*. But please consider sending in a RELEASE NOTES snippet about it to the team responsible for the Buster RELEASE NOTES, and using NEWS.Debian in the rng-tools family of packages to convey that relevant information as well... IMHO, that would give users a chance to notice they might need to pay attention to rng-tools during the stretch->buster upgrade. Again, thank you guys for pushing a fix for a mess you did not create. And the one responsible for the broken NMU is, as far as I am concerned, owning everyone a pack of beverages, since he is the one that should have cleaned up the breakage he caused. -- Henrique de Moraes Holschuh
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019 at 04:05:09PM +, Thorsten Glaser wrote: Michael Stone dixit: So use the epoch. They're invented for fixing collosal errors like this. Except this time, have the appropriate discussion on -devel instead of just uploading something without coordination. Sounds like an approach, but please see in #919893 my message first for an alternative idea. Coordination with -devel is required for epoch anyway… for p-u only RT IIRC, but we could do either. But you’re not in a situation to command either, considering hmh is the ONLY maintainer of rng-tools so we WILL need his input on this (or do an NMU). I'm not commanding anything, I'm just trying to figure out ways to un-hijack the package. Hence the desire to discuss any solution on -devel to get broader input & consensus.
Bug#915689: prevent from migrating to testing
Michael Stone dixit: > So use the epoch. They're invented for fixing collosal errors like > this. Except this time, have the appropriate discussion on -devel > instead of just uploading something without coordination. Sounds like an approach, but please see in #919893 my message first for an alternative idea. Coordination with -devel is required for epoch anyway… for p-u only RT IIRC, but we could do either. But you’re not in a situation to command either, considering hmh is the ONLY maintainer of rng-tools so we WILL need his input on this (or do an NMU). bye, //m. (really gotta go now)
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019 at 03:41:22PM +, Thorsten Glaser wrote: Michael Stone dixit: Please upload a fixed version of rng-tools instead, reverting the erroneous change. That is impossible because the version changed. In the tool I’m using, I have a hard version requirement on rng-tools (<< 3) | rng-tools-debian (<< 3). Sounds like a self-imposed problem. At best we could do with an epoch, but these are nowadays frowned upon. For two softwares as distinct as these rng-tools implementations, the +really dance is more than just questionable instead. So use the epoch. They're invented for fixing collosal errors like this. Except this time, have the appropriate discussion on -devel instead of just uploading something without coordination.
Bug#915689: prevent from migrating to testing
Michael Stone dixit: > Please upload a fixed version of rng-tools instead, reverting the erroneous > change. That is impossible because the version changed. In the tool I’m using, I have a hard version requirement on rng-tools (<< 3) | rng-tools-debian (<< 3). At best we could do with an epoch, but these are nowadays frowned upon. For two softwares as distinct as these rng-tools implementations, the +really dance is more than just questionable instead. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019 at 03:25:12PM +, Thorsten Glaser wrote: Michael Stone dixit: No, that's something else that shouldn't have happened It’s important to me because the upload of rng-tools (>> 2) broke things on unstable. So that should be fixed--the problem should not be made worse. Please upload a fixed version of rng-tools instead, reverting the erroneous change.
Bug#915689: prevent from migrating to testing
Michael Stone dixit: > No, that's something else that shouldn't have happened It’s important to me because the upload of rng-tools (>> 2) broke things on unstable. Perhaps letting it migrate to testing wasn’t ideal, but it will work for people there, and it won’t affect existing users or those who not explicitly install it. > as it won't preserve an existing configuration. That, it doesn’t. That’s too tricky to get right anyway. But in my scenario, it isn’t even used with the config or the init script, but as the recipient of a stream from a network service — that to not break was more important at that point after rng-tools (>> 2) was uncoordinatedly up‐ loaded into unstable and all attempts to communicate ig‐ nored (we had this discussion in 2013 or so on Launchpad, and, besides suggesting to me to package it separately as rng-tools-debian, nothing happened there, so don’t be of‐ fended if I merely picked up that suggestion and enacted it). I’m open for discussion about things to get users informed correctly, such as a NEWS entry about not retaining the configuration from rng-tools (though I think apt-listchanges does not show NEWS from newly installed packages), or more explicitly pointing out in the documentation that most users will want the 5.x version except perhaps for low-bandwidth RNGs, or something. I do intend to improve rng-tools-debian occasionally but will insist on keeping it. bye, //mirabilos (hat: rng-tools-debian maintainer) -- 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: prevent from migrating to testing
On Sun, Jan 20, 2019 at 03:01:18PM +0100, Diederik de Haas wrote: On Fri, 11 Jan 2019 14:51:05 -0500 Michael Stone wrote: On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote: >There never should have been an NMU simply replacing rng-tools with >rng-tools5. I did not notice that this had happened. Also, the correct fix for buster is an upload to put things back the way they were, which is going to be ugly. You are aware of the rng-tools-debian package containing the 'old' implementation? No, that's something else that shouldn't have happened, as it won't preserve an existing configuration. Why the hell is all this happening with no coordination?
Bug#915689: prevent from migrating to testing
On Fri, 11 Jan 2019 14:51:05 -0500 Michael Stone wrote: > On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote: > >There never should have been an NMU simply replacing rng-tools with > >rng-tools5. I did not notice that this had happened. > > Also, the correct fix for buster is an upload to put things back the way > they were, which is going to be ugly. You are aware of the rng-tools-debian package containing the 'old' implementation? I would really appreciate it if this would be fixed for buster. Right now there are 3 rng-tools packages with nearly identical long/short descriptions (and not very useful VCS/salsa info). signature.asc Description: This is a digitally signed message part.
Bug#915689: prevent from migrating to testing
On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote: There never should have been an NMU simply replacing rng-tools with rng-tools5. I did not notice that this had happened. Also, the correct fix for buster is an upload to put things back the way they were, which is going to be ugly.
Bug#915689: prevent from migrating to testing
There never should have been an NMU simply replacing rng-tools with rng-tools5. I did not notice that this had happened. On Fri, Jan 11, 2019 at 07:21:49PM +0100, Andreas Henriksson wrote: That has apparently failed to materialize well in time for buster. Looking at the contents of the binary packages it seems rng-tools (in unstable) has more contents and likely provides more functionality/integration (but I haven't looked into details, eg. rng-tools5 has no /etc/default file which might be a good thing as those are generally frowed upon in the current systemd service age, but has there been any work on actual migration of current rng-tools users configuration to what rng-tools5 uses?) It's not possible to migrate people from rng-tools to rng-tools5 as the functionality does not entirely overlap. There's no meaningful conversion from one to the other, nor does there need to be. (A user currently running rng-tools has no need to move to rng-tools5.) There's a chance (though increasingly small as the legacy hardware ages) that forcing a migration from rng-tools to rng-tools5 will break an existing setup. The intent of transitioning was entirely to make it easier for people reading non-debian-specific instructions on the internet telling them to install "rng-tools" in order to get certain functionality (specifically RDRAND/RDSEED) would get the package they were expecting. The end result for buster would be rng-tools2 and rng-tools5 packages, with an rng-tools package pulling in rng-tools2 as a replacement. Given that the kernel seems to be moving in the direction of allowing RDRAND/RDSEED to seed /dev/random without blocking (see RANDOM_TRUST_CPU) I'm not sure a package renaming dance is worthwhile as the most common reason for installing rng-tools5 will no longer be as relevant. Another option is to simply remove rng-tools, which eliminates the confusion. But, doing that will mean dropping support for certain (legacy) configurations supported in the current rng-tools package but not rng-tools5.
Bug#915689: prevent from migrating to testing
Hello Aron Xu and everyone else, On Thu, Dec 06, 2018 at 01:25:03PM +0800, Aron Xu wrote: > Package: rng-tools > Version: 5-1 > Severity: serious > Tags: sid > > We need to prevent this version of rng-tools from migrating to testing > before finding a solution of coordinating with the rng-tools5 package. I'm interested in rng-tools and would like to see it in good shape for buster, but the current state makes me uncomfortable. Could you please update me on what the current state is since this bug report was opened? Have any progress been made or attempted that isn't tracked here? The initial changelog entry of rng-tools5 states: "This is part of an intended transition, with this package becoming the default rng-tools post stretch release." That has apparently failed to materialize well in time for buster. Looking at the contents of the binary packages it seems rng-tools (in unstable) has more contents and likely provides more functionality/integration (but I haven't looked into details, eg. rng-tools5 has no /etc/default file which might be a good thing as those are generally frowed upon in the current systemd service age, but has there been any work on actual migration of current rng-tools users configuration to what rng-tools5 uses?) I'd be really interested to hear what people have on their minds for this task and how I can help out. Regards, Andreas Henriksson
Bug#915689: prevent from migrating to testing
Package: rng-tools Version: 5-1 Severity: serious Tags: sid We need to prevent this version of rng-tools from migrating to testing before finding a solution of coordinating with the rng-tools5 package. Aron
