Bug#1001097: ksh93u+m_1.0.0~beta.1-2_all-buildd.changes REJECTED
Hi Aruelien On Sat, Dec 04, 2021 at 10:39:58AM +0100, Aurelien Jarno wrote: > Source: ksh93u+m > Version: 1.0.0~beta.1-2 > Severity: serious > > On 2021-12-03 18:48, Debian FTP Masters wrote: > > Version check failed: > > Your upload included the binary package ksh, version 20210511, for all, > > however unstable already has version 20210511. > > Uploads to unstable must have a higher version than present in unstable. > > > > Mapping sid to unstable. The version 20210511 is a transitional package from the older ksh package over to ksh93u+m [1]. According to this, is the expectation that the the transitional package version is bumped with each release of ksh93u+m, at least until the transition is complete in the next Debian release? Thanks, Anuradha [1] - https://wiki.debian.org/RenamingPackages
Bug#999773: ksh93u+m: missing Breaks+Replaces: ksh (<< 20210511)
On Tue, Nov 16, 2021 at 02:56:26PM +0100, Andreas Beckmann wrote: > Package: ksh93u+m > Version: 1.0.0~beta.1-1 > Severity: serious > Tags: patch > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. > It installed fine in 'sid', then the upgrade to 'experimental' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > This error may also be triggered by having a predecessor package from > 'sid 'installed while installing the package from 'experimental'. Thanks for this observation and report. In this case, the version in experimental needs to be removed as that is no longer a valid upgrade path and has been superceded by the package transition to ksh93u+m. I will request the removal of the package in experimental to address this issue. Regards, Anuradha
Bug#964056: Should ksh93 be removed?
On Wed, Jul 01, 2020 at 12:40:17AM +0300, Adrian Bunk wrote: > Package: ksh93 > Severity: serious > > ksh (2020.0.0+really93u+20120801-6) unstable; urgency=high > > * v2020 of ksh is no longer being maintained and upstream repository has > been reverted back to the last stable version of 93u+. This update > reverts back the ksh2020 changes back to the original ksh93 from AT > ... > -- Anuradha Weeraman Sat, 27 Jun 2020 21:17:32 -0400 > > > The 2020 version of ksh was never part of any Debian distribution > other than unstable, and this seems to make it obsolete. #963858 is open with the ftp-master to have ksh93 removed. -- Regards Anuradha
Bug#950762: ksh,ksh93: both ship /etc/skel/.kshrc with insufficient Conflicts/Breaks/Replaces
On Thu, Feb 06, 2020 at 03:44:51PM +, Thorsten Glaser wrote: > I had considered that, but creating a ksh-common package for just > one file, which in addition to that is a skeleton file that is not > used during normal operation, just adduser, seems overkill. The > sequence of installing both then removing one is also expected to > occur only rarely, most users would either install one, or both, > and then keep that. I had thought that that with the Replaces on > the other packages would be sufficient. > > Is it possible to make an exception here, considering the file in > question and that it is documented? Hi Andreas I would agree on Thorsten's point above that it would be somewhat overkill in this given scenario. Please suggest if you would be okay with an exception in this regard, or if you still feel that this needs to be addressed? thanks, Anuradha
Bug#407405: file conflicts between ncc and nemerle
Hi Sebastian, Any ideas on what we can do about this? Thanks. On May 30, 2007 9:44 PM, Anuradha Weeraman [EMAIL PROTECTED] wrote: Hi Sebastian, Ok, now that etch is release what shall we do about this bug, Anuradha? Does your upstream consider to change the name of the binary? Sorry for the late response, but I've been a bit busy lately and I've not had much time for anything else. But things should change soon, hopefully. The last time I spoke to Stelios, he was not completely for changing the ncc binary name. According to his view, which I tend to agree with, he believes nemerle should rename it's ncc binary to something that's more appropriate for a dot-net application, such as with an .exe suffix. But according to the CLI Policy [1] Never ever install application files (.exe) directly into /usr/bin. Instead create a wrapper script into /usr/bin to allow them to be run without the .exe suffix. So I'm guessing that would not work? Forgive my ignorance on the CLI policy, but do you know if it is an approved policy document? I realize this can be a stale mate situation, and I'm not clear what nemerle's stance on this issue is and whether they would consent to a name change. Any suggestions? [1] - http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html -- Anuradha Weeraman http://www.linux.lk/~anu/ http://anuradha.wordpress.com -- Anuradha Weeraman http://www.linux.lk/~anu/ http://anuradha.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407405: file conflicts between ncc and nemerle
Hi Sebastian, Ok, now that etch is release what shall we do about this bug, Anuradha? Does your upstream consider to change the name of the binary? Sorry for the late response, but I've been a bit busy lately and I've not had much time for anything else. But things should change soon, hopefully. The last time I spoke to Stelios, he was not completely for changing the ncc binary name. According to his view, which I tend to agree with, he believes nemerle should rename it's ncc binary to something that's more appropriate for a dot-net application, such as with an .exe suffix. But according to the CLI Policy [1] Never ever install application files (.exe) directly into /usr/bin. Instead create a wrapper script into /usr/bin to allow them to be run without the .exe suffix. So I'm guessing that would not work? Forgive my ignorance on the CLI policy, but do you know if it is an approved policy document? I realize this can be a stale mate situation, and I'm not clear what nemerle's stance on this issue is and whether they would consent to a name change. Any suggestions? [1] - http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html -- Anuradha Weeraman http://www.linux.lk/~anu/ http://anuradha.wordpress.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
