Bug#948745: ksh2020 vs. ksh93
On Tue, Jan 28, 2020 at 07:49:27PM +0100, Thorsten Glaser wrote: > https://ftp-master.debian.org/new.html shows ksh93 ☻ let’s wait for the > ftpmaster review. Some good news this morning, looks like the package got accepted into the archive. -- Regards Anuradha
Bug#948745: ksh2020 vs. ksh93
On Tue, Jan 28, 2020 at 07:49:27PM +0100, Thorsten Glaser wrote: > Thanks for having a look over it (oneself doesn’t find one’s own errors > as good as others). I certainly learnt a thing or two. > Am I correct in assuming you’ll need DM upload privileges on it, once > it’s accepted? Yes, please, if you would be willing to. -- Regards Anuradha
Bug#948745: ksh2020 vs. ksh93
On Mon, 27 Jan 2020, Anuradha Weeraman wrote: > Thanks, looks great. Thanks for having a look over it (oneself doesn’t find one’s own errors as good as others). https://ftp-master.debian.org/new.html shows ksh93 ☻ let’s wait for the ftpmaster review. Am I correct in assuming you’ll need DM upload privileges on it, once it’s accepted? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#948745: ksh2020 vs. ksh93
On Mon, Jan 27, 2020 at 08:00:08PM +0100, Thorsten Glaser wrote: > On Fri, 24 Jan 2020, Anuradha Weeraman wrote: > I had to change some things in src:ksh as well, for better > coïnstallability, and for upgrading. Let’s hope this passes > all tests and ftpmasters… Thanks, looks great. -- Regards Anuradha
Bug#948745: ksh2020 vs. ksh93
On Fri, 24 Jan 2020, Anuradha Weeraman wrote: > If you could team upload as well that would be great! Done! I had to change some things in src:ksh as well, for better coïnstallability, and for upgrading. Let’s hope this passes all tests and ftpmasters… bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#948745: ksh2020 vs. ksh93
On Fri, 24 Jan 2020, Anuradha Weeraman wrote: > If you could team upload as well that would be great! Okay, will do, thanks! bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#948745: ksh2020 vs. ksh93
If you could team upload as well that would be great! On Fri, Jan 24, 2020, 9:53 AM Thorsten Glaser wrote: > On Fri, 24 Jan 2020, Anuradha Weeraman wrote: > > > Thanks for the feedback. > > > > Happy to receive a PR and support with uploading ksh93. Will replicate > > accordingly to ksh2020 as well. > > You’re welcome. > > Just to be clear: > > > > > Thanks. Are you going to package ksh93 as well, or should > > > > I do that (I’m a DD and can do it easily)? > > > You can find a branch on Salsa for ksh93 with the alternatives support > here: > > https://salsa.debian.org/debian/ksh/tree/debian/ksh93 > > > I've done some co-existence testing on it. If you could review and help > > sponsor the package that would be awesome. > > Should I review, possibly fix up, and then team-upload it? > > > > > More questions, from looking at the debdiff: > > > > > > >> * Use alternative system for ksh, shcomp and rksh > > > > > > You’re setting these up as slaves of /bin/ksh, which however > > > does not work if the user chooses /bin/ksh to be mksh but > > > still wants to have shcomp for ksh93 or ksh2020 available. > > > > > > I’d separate at _least_ shcomp into its own alternative, > > > if not rksh (which _can_ be configured separately from ksh, > > > but does not need to; currently, mksh does not provide rksh, > > > but in the future it might). > > > > > > +++ ksh-2020.0.0/debian/gitlab-ci.yml 2020-01-19 07:43:52.0 > +0100 > > > + SALSA_CI_PIUPARTS_ARGS: --ignore=/etc/shells > > > > > > This will not work in practice: piuparts as run by britney > > > (Debian testing migration) doesn’t read this, and so it will > > > never migrate. The cause is easy: > > > > > > +++ ksh-2020.0.0/debian/ksh.postinst2020-01-19 07:43:52.0 > +0100 > > > +add-shell /bin/ksh > > > +add-shell /bin/rksh > > > > > > Please *don’t* add /bin/ksh (and /bin/rksh) to /etc/shells; > > > both ksh before your change and mksh don’t do that, and we > > > decided some time back to let the user only add explicit > > > choices, not things from the alternative system, as shell, > > > so they keep their shell even when the alternative changes. > > > > > > Please also remove the comment referring #790118 there, as > > > it was superceded by the above discussion. > > > > > > Doing this will fix piuparts at the same time ☻ > > > > > > shcomp2020.1 and 0001-List-only-supported-names-for-ksh.patch > > > also need the new names. > > > > > > Do you want me to prepare a pull request with these changes, > > > and, possibly, upload them (to save you effort)? > > Just to be clear: should I only prepare a pull request, or > should I also team-upload the changes? > > bye, > //mirabilos (mksh developer and packager; Debian Developer) > -- > tarent solutions GmbH > Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ > Tel: +49 228 54881-393 • Fax: +49 228 54881-235 > HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 > Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander > Steeg > > ** > > Mit der tarent Academy bieten wir auch Trainings und Schulungen in den > Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. > > Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren > Kontakt. > > ** >
Bug#948745: ksh2020 vs. ksh93
On Fri, 24 Jan 2020, Anuradha Weeraman wrote: > Thanks for the feedback. > > Happy to receive a PR and support with uploading ksh93. Will replicate > accordingly to ksh2020 as well. You’re welcome. Just to be clear: > > > Thanks. Are you going to package ksh93 as well, or should > > > I do that (I’m a DD and can do it easily)? > You can find a branch on Salsa for ksh93 with the alternatives support here: > https://salsa.debian.org/debian/ksh/tree/debian/ksh93 > I've done some co-existence testing on it. If you could review and help > sponsor the package that would be awesome. Should I review, possibly fix up, and then team-upload it? > > More questions, from looking at the debdiff: > > > > >> * Use alternative system for ksh, shcomp and rksh > > > > You’re setting these up as slaves of /bin/ksh, which however > > does not work if the user chooses /bin/ksh to be mksh but > > still wants to have shcomp for ksh93 or ksh2020 available. > > > > I’d separate at _least_ shcomp into its own alternative, > > if not rksh (which _can_ be configured separately from ksh, > > but does not need to; currently, mksh does not provide rksh, > > but in the future it might). > > > > +++ ksh-2020.0.0/debian/gitlab-ci.yml 2020-01-19 07:43:52.0 +0100 > > + SALSA_CI_PIUPARTS_ARGS: --ignore=/etc/shells > > > > This will not work in practice: piuparts as run by britney > > (Debian testing migration) doesn’t read this, and so it will > > never migrate. The cause is easy: > > > > +++ ksh-2020.0.0/debian/ksh.postinst2020-01-19 07:43:52.0 +0100 > > +add-shell /bin/ksh > > +add-shell /bin/rksh > > > > Please *don’t* add /bin/ksh (and /bin/rksh) to /etc/shells; > > both ksh before your change and mksh don’t do that, and we > > decided some time back to let the user only add explicit > > choices, not things from the alternative system, as shell, > > so they keep their shell even when the alternative changes. > > > > Please also remove the comment referring #790118 there, as > > it was superceded by the above discussion. > > > > Doing this will fix piuparts at the same time ☻ > > > > shcomp2020.1 and 0001-List-only-supported-names-for-ksh.patch > > also need the new names. > > > > Do you want me to prepare a pull request with these changes, > > and, possibly, upload them (to save you effort)? Just to be clear: should I only prepare a pull request, or should I also team-upload the changes? bye, //mirabilos (mksh developer and packager; Debian Developer) -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#948745: ksh2020 vs. ksh93
Thanks for the feedback. Happy to receive a PR and support with uploading ksh93. Will replicate accordingly to ksh2020 as well. Regards Anuradha On Fri, Jan 24, 2020, 9:36 AM Thorsten Glaser wrote: > On Fri, 24 Jan 2020, Thorsten Glaser wrote: > > > Thanks. Are you going to package ksh93 as well, or should > > I do that (I’m a DD and can do it easily)? > > More questions, from looking at the debdiff: > > >> * Use alternative system for ksh, shcomp and rksh > > You’re setting these up as slaves of /bin/ksh, which however > does not work if the user chooses /bin/ksh to be mksh but > still wants to have shcomp for ksh93 or ksh2020 available. > > I’d separate at _least_ shcomp into its own alternative, > if not rksh (which _can_ be configured separately from ksh, > but does not need to; currently, mksh does not provide rksh, > but in the future it might). > > +++ ksh-2020.0.0/debian/gitlab-ci.yml 2020-01-19 07:43:52.0 +0100 > + SALSA_CI_PIUPARTS_ARGS: --ignore=/etc/shells > > This will not work in practice: piuparts as run by britney > (Debian testing migration) doesn’t read this, and so it will > never migrate. The cause is easy: > > +++ ksh-2020.0.0/debian/ksh.postinst2020-01-19 07:43:52.0 +0100 > +add-shell /bin/ksh > +add-shell /bin/rksh > > Please *don’t* add /bin/ksh (and /bin/rksh) to /etc/shells; > both ksh before your change and mksh don’t do that, and we > decided some time back to let the user only add explicit > choices, not things from the alternative system, as shell, > so they keep their shell even when the alternative changes. > > Please also remove the comment referring #790118 there, as > it was superceded by the above discussion. > > Doing this will fix piuparts at the same time ☻ > > shcomp2020.1 and 0001-List-only-supported-names-for-ksh.patch > also need the new names. > > Do you want me to prepare a pull request with these changes, > and, possibly, upload them (to save you effort)? > > bye, > //mirabilos (mksh developer) > -- > tarent solutions GmbH > Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ > Tel: +49 228 54881-393 • Fax: +49 228 54881-235 > HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 > Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander > Steeg > > ** > > Mit der tarent Academy bieten wir auch Trainings und Schulungen in den > Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. > > Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren > Kontakt. > > ** >
Bug#948745: ksh2020 vs. ksh93
On Fri, 24 Jan 2020, Thorsten Glaser wrote: > Thanks. Are you going to package ksh93 as well, or should > I do that (I’m a DD and can do it easily)? More questions, from looking at the debdiff: >> * Use alternative system for ksh, shcomp and rksh You’re setting these up as slaves of /bin/ksh, which however does not work if the user chooses /bin/ksh to be mksh but still wants to have shcomp for ksh93 or ksh2020 available. I’d separate at _least_ shcomp into its own alternative, if not rksh (which _can_ be configured separately from ksh, but does not need to; currently, mksh does not provide rksh, but in the future it might). +++ ksh-2020.0.0/debian/gitlab-ci.yml 2020-01-19 07:43:52.0 +0100 + SALSA_CI_PIUPARTS_ARGS: --ignore=/etc/shells This will not work in practice: piuparts as run by britney (Debian testing migration) doesn’t read this, and so it will never migrate. The cause is easy: +++ ksh-2020.0.0/debian/ksh.postinst2020-01-19 07:43:52.0 +0100 +add-shell /bin/ksh +add-shell /bin/rksh Please *don’t* add /bin/ksh (and /bin/rksh) to /etc/shells; both ksh before your change and mksh don’t do that, and we decided some time back to let the user only add explicit choices, not things from the alternative system, as shell, so they keep their shell even when the alternative changes. Please also remove the comment referring #790118 there, as it was superceded by the above discussion. Doing this will fix piuparts at the same time ☻ shcomp2020.1 and 0001-List-only-supported-names-for-ksh.patch also need the new names. Do you want me to prepare a pull request with these changes, and, possibly, upload them (to save you effort)? bye, //mirabilos (mksh developer) -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
