Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > Nearly five months later, I'm just pinging in to say that I'm still A: > interested in this, and B: waiting on any possible response as regards > what qualifies as sufficient testing for the drop-the-problematic-file > WIP branch. > > Once we're sufficiently certain that the result is OK as far as what > would go into a package, I plan (as I have for some time now) to make a > release with it, which should also include the new feature which has > been sitting in Limbo for some time now. Moosic is currently very low on my very long TODO list, I can't guarantee any timeframe for getting to it. To remove my timetable as blocker for this work, you could for example join the Python team yourself, do the packaging and look for a sponsor to upload the result. -- Arto Jantunen signature.asc Description: PGP signature
Bug#970635: moosic: new upstream now supports Python 3
Nearly five months later, I'm just pinging in to say that I'm still A: interested in this, and B: waiting on any possible response as regards what qualifies as sufficient testing for the drop-the-problematic-file WIP branch. Once we're sufficiently certain that the result is OK as far as what would go into a package, I plan (as I have for some time now) to make a release with it, which should also include the new feature which has been sitting in Limbo for some time now. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-05-30 at 19:53, The Wanderer wrote: > On 2021-05-30 at 09:33, The Wanderer wrote: > >> There is now a 'wip' branch on the relevant GitHub repository, >> which includes a commit dropping this. I haven't pushed it to the >> primary branch yet, because I'm still not certain how to properly >> test the result; I'm reasonably certain that it is / will be fine, >> but "reasonably certain" shouldn't be enough to move forward on >> when there's an alternative. Now that the new stable release of Debian has been out for a couple of weeks: any status on this? That potential new moosic release (without examples/completion, and with the new play-one command) is still pending testing of the result; I have no reason to expect it to not work, and certainly haven't managed to find anything that does break with it gone, but I don't know what would constitute a valid test of whether there is anything that fails to work without it but did work with it. [Re the bug that manifests when one of the playback commands in the moosic config file would give "No such file or directory":] > Once I've either found and fixed the bug or (much less likely) > assured myself it's not going to manifest in plausibly-real-world > user scenarios, In the somewhat-extensive meantime, I have done the latter of these. I still don't know what causes the buggy behavior, but I've confirmed that it already seems to exist in the previously packaged version, and I don't believe it's going to manifest in real-world usage. As such, I don't consider this a blocker for moving forward. (For reference, the buggy behavior is that even when moosicd is already running, moosic will in some cases fail to detect it - more specifically, the moosic internal client-server command 'no_op' will fail - and will therefore try to start a new instance of the daemon.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-05-30 at 09:33, The Wanderer wrote: > There is now a 'wip' branch on the relevant GitHub repository, which > includes a commit dropping this. I haven't pushed it to the primary > branch yet, because I'm still not certain how to properly test the > result; I'm reasonably certain that it is / will be fine, but > "reasonably certain" shouldn't be enough to move forward on when > there's an alternative. > > Please follow up as you see fit, whether by testing (and letting me > know either about problems, or that it's OK and I can make a new > numbered release) or by letting me know how to test or by whatever > other means you feel appropriate. FYI in case it influences your decision-making, having pushed this WIP branch has inspired me to get back to hacking on moosic, and I've implemented a new feature whose absence I've been working around for some time (and which I know is actively requested by at least one other user of the program): the ability to say "play the next item in the queue, then stop". This can be simulated by e.g. 'moosic adv ; moosic no-adv', but that has a race condition with whether the playback has begun by the time the no-adv takes effect, and I'm fairly sure the in-program version avoids that. Unfortunately, it isn't quite perfect yet. Either it's 99% complete and introduces a bug, or it's 100% complete but exposes a pre-existing bug which I haven't found any other way to trigger; either way, I don't understand yet how the (moderately serious) bug comes about. Thus far, the bug only seems to manifest when ~/.moosic/config (or the equivalent in the directory specified with 'moosic -c') contains a playback command which is not actually available - i.e., trying to run that command would give "No such file or directory". I'm not sure whether that's rare enough in practice to warrant treating the bug as negligible, but I wouldn't be inclined to assume so myself. Once I've either found and fixed the bug or (much less likely) assured myself it's not going to manifest in plausibly-real-world user scenarios, either of which may take me A While, I plan to make another numbered release with that feature included. What effect that information may have on your own plans is up to you. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-03-12 at 06:11, The Wanderer wrote: > On 2021-03-12 at 05:57, Arto Jantunen wrote: > >> The Wanderer writes: > >>> Would this call for an upstream release dropping the file, or >>> are you OK with excluding it from what gets installed as part of >>> the package? >> >> I'd prefer an upstream release if you don't feel strongly about >> it, I think otherwise I need to filter the upstream tarball and >> I'd rather not. > > I'm a little hesitant to drop it, both because it'd be a (very > minor) pain to dig it up to add back later and because I'm not > entirely sure how to test the result for consistency and validity > (given that I currently lack usable VMs for install testing; nearly > all my testing of changes to date has been by running from the source > tree), but I've taken a stab at it locally. > > Any suggestions for how to test the post-drop source tree, or should > I just push 1.5.7.1 to GitHub and let you follow up at leisure? > > (This would probably be a good occasion for me to figure out how to > push secondary branches to GitHub, so that I can make this available > without an irrevocable update to master, but I don't feel like > investing that effort right at the moment. I might feel differently > once the day has gotten underway, but no guarantees.) After an unconscionably long time, for which I have no specific excuse (although I could provide plenty of less-specific ones), I've finally acquired a tuit that is of sufficient circularity. There is now a 'wip' branch on the relevant GitHub repository, which includes a commit dropping this. I haven't pushed it to the primary branch yet, because I'm still not certain how to properly test the result; I'm reasonably certain that it is / will be fine, but "reasonably certain" shouldn't be enough to move forward on when there's an alternative. Please follow up as you see fit, whether by testing (and letting me know either about problems, or that it's OK and I can make a new numbered release) or by letting me know how to test or by whatever other means you feel appropriate. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
On 2021-03-12 at 05:57, Arto Jantunen wrote: > The Wanderer writes: >> Would this call for an upstream release dropping the file, or are >> you OK with excluding it from what gets installed as part of the >> package? > > I'd prefer an upstream release if you don't feel strongly about it, > I think otherwise I need to filter the upstream tarball and I'd > rather not. I'm a little hesitant to drop it, both because it'd be a (very minor) pain to dig it up to add back later and because I'm not entirely sure how to test the result for consistency and validity (given that I currently lack usable VMs for install testing; nearly all my testing of changes to date has been by running from the source tree), but I've taken a stab at it locally. Any suggestions for how to test the post-drop source tree, or should I just push 1.5.7.1 to GitHub and let you follow up at leisure? (This would probably be a good occasion for me to figure out how to push secondary branches to GitHub, so that I can make this available without an irrevocable update to master, but I don't feel like investing that effort right at the moment. I might feel differently once the day has gotten underway, but no guarantees.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > On 2021-03-12 at 05:32, Arto Jantunen wrote: >> We might as well just remove it for now, we can easily bring it back >> if we can come up with a plausible story about the licensing >> situation. > > If you think that's OK for the package (and its users, who may or may > not care about completion), then I'm fine with it for the moment. I don't think we have a massive number of users anyway, and they can still manually install the completion if they need it. In any case, having the package without completion is probably preferable to not having the package at all. > Would this call for an upstream release dropping the file, or are you OK > with excluding it from what gets installed as part of the package? I'd prefer an upstream release if you don't feel strongly about it, I think otherwise I need to filter the upstream tarball and I'd rather not. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
On 2021-03-12 at 05:32, Arto Jantunen wrote: > The Wanderer writes: >> Neither of these things is new; they were true of the last version >> prior to the removal, and possibly of some versions prior to that >> as well. That makes this a bit aggravating. >> >> Still, I suppose that just means they slipped through the cracks of >> the less-stringent copyright review that's applied to packages >> already in the archive, rather than that they shouldn't need to be >> addressed... > > There is no systematic copyright review happening for packages that > are already in the archive (unless they add new binary packages and > end up in the NEW queue that way). I'm personally not a fan of how > this currently works in Debian, but "so there has ever been and ever > will be". Oh, I'm aware. The lack of systematic copyright review just means that what review does get applied is "whatever anyone who happens to be looking at the package happens to notice and cares to point out", which is clearly less stringent than what is applied at NEW time. ^_^ >> For examples/completion, it's not clear whether or not documenting >> the copyright statement would be enough. No specific license is >> stated for that file, so it's not clear what license Etienne PIERRE >> (whom I infer to be its original author, prior to later changes >> introduced by Daniel Pearson) would have intended for it. > > The completion script was actually provided through Debian initially > and then later included upstream: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184633 > > This initial submission includes a copyright statement, but no > license. Not asking for one was clearly my mistake. The advantages of incumbent, institutional-style knowledge! It wouldn't even have occurred to me to check for that sort of thing. > We might as well just remove it for now, we can easily bring it back > if we can come up with a plausible story about the licensing > situation. If you think that's OK for the package (and its users, who may or may not care about completion), then I'm fine with it for the moment. Would this call for an upstream release dropping the file, or are you OK with excluding it from what gets installed as part of the package? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > On 2021-03-10 at 01:30, Arto Jantunen wrote: > >> Indeed the package was rejected after two months in the queue, due to >> things missing from the copyright file: >> >>> +--+ >>> | REJECT reasoning | >>> +--+ >>> >>> examples/completion seems to be copyright Etienne PIERRE and there does not >>> seem to be reason that they too have relinquished copyright. >>> >>> moosic/server/xmlrpc_registry.py has a different license. >>> >>> +--+ >>> | N.B. | >>> +--+ >>> >>> This review may not be exhaustive. Please check your source package >>> against your d/copyright and the ftpmaster REJECT-FAQ, throughly, >>> before uploading to NEW again. > > Neither of these things is new; they were true of the last version prior > to the removal, and possibly of some versions prior to that as well. > That makes this a bit aggravating. > > Still, I suppose that just means they slipped through the cracks of the > less-stringent copyright review that's applied to packages already in > the archive, rather than that they shouldn't need to be addressed... There is no systematic copyright review happening for packages that are already in the archive (unless they add new binary packages and end up in the NEW queue that way). I'm personally not a fan of how this currently works in Debian, but "so there has ever been and ever will be". >> I'll try to find the time to go through the source and update this, >> unless you beat me to it of course. :) > > For moosic/server/xmlrpc_registry.py, I think we just need to document > the license in debian/copyright. I don't have a local copy of the > debian/ directory for this, and have no experience with updating such, > so although I'd kind of like to *get* that experience I think it'd > probably be best if you cover that part. Sure, I'll handle that. > For examples/completion, it's not clear whether or not documenting the > copyright statement would be enough. No specific license is stated for > that file, so it's not clear what license Etienne PIERRE (whom I infer > to be its original author, prior to later changes introduced by Daniel > Pearson) would have intended for it. The completion script was actually provided through Debian initially and then later included upstream: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184633 This initial submission includes a copyright statement, but no license. Not asking for one was clearly my mistake. We might as well just remove it for now, we can easily bring it back if we can come up with a plausible story about the licensing situation. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
On 2021-03-10 at 01:30, Arto Jantunen wrote: > Indeed the package was rejected after two months in the queue, due to > things missing from the copyright file: > >> +--+ >> | REJECT reasoning | >> +--+ >> >> examples/completion seems to be copyright Etienne PIERRE and there does not >> seem to be reason that they too have relinquished copyright. >> >> moosic/server/xmlrpc_registry.py has a different license. >> >> +--+ >> | N.B. | >> +--+ >> >> This review may not be exhaustive. Please check your source package >> against your d/copyright and the ftpmaster REJECT-FAQ, throughly, >> before uploading to NEW again. Neither of these things is new; they were true of the last version prior to the removal, and possibly of some versions prior to that as well. That makes this a bit aggravating. Still, I suppose that just means they slipped through the cracks of the less-stringent copyright review that's applied to packages already in the archive, rather than that they shouldn't need to be addressed... > I'll try to find the time to go through the source and update this, > unless you beat me to it of course. :) For moosic/server/xmlrpc_registry.py, I think we just need to document the license in debian/copyright. I don't have a local copy of the debian/ directory for this, and have no experience with updating such, so although I'd kind of like to *get* that experience I think it'd probably be best if you cover that part. For examples/completion, it's not clear whether or not documenting the copyright statement would be enough. No specific license is stated for that file, so it's not clear what license Etienne PIERRE (whom I infer to be its original author, prior to later changes introduced by Daniel Pearson) would have intended for it. It's possible that the lack of license statement for that file indicates that it's covered by the Unlicense, like the rest of the codebase; however, since the rest of the codebase except for xmlrpc_registry.py seems to have all come from Daniel Pearson, I wouldn't necessarily want to assume that. Based on the copyright statements in that file and their dates, my guess is that moosic originally didn't provide completion, that a user contributed that functionality, and that the maintainer later iterated on the base of that contribution. If that's correct, then the license for this file would probably be whatever license moosic was under at the time of its introduction; we could probably find that out by examining the versions of the package from prior to the relicensing, which I think took place in 2011. We might need to contact Etienne PIERRE, to ask about what license was intended here, and whether the change to the Unlicense would be OK. Fortunately, an E-mail address is provided; unfortunately, it's 18 years old, so could well be out of date. As a third possibility, we could argue that this completion file is simple enough to not be meaningfully copyrightable, but I wouldn't want to try to make and back up that argument in the face of FTP-team copyright review. As a fourth possibility, we could investigate whether this file is even needed anymore. Nothing else in the source seems to reference it, except for setup.py (apparently as part of building the documentation?); the ChangeLog references tab-completion once, a 'debian/completion' file which is no longer part of the upstream source (it's even possible I'm the one who killed it, since I don't think debian/ should be maintained upstream), and tab-completion functionality of a long-dead specialized shell called 'moosh'. It may be notable that the dates of those references are all around 2003, which is the year of Etienne PIERRE's copyright on examples/completion. Given that I don't use completion in a moosic context (or programmable tab-completion at all in my shell), I'm not sure how to effectively test whether this is still needed or not. Suggestions are welcome. (That said, a simple cmp shows that it's identical to /etc/bash_completion.d/moosic from the existing 1.5.6-1 package, so apparently we have been shipping this in Debian.) I've done a cursory glance into every file in the source (in the form I last saw it on GitHub; I didn't bother to re-pull in case someone changed it there under my feet), and other than the above, everything else either states no license or explicitly states the Unlicense. The files that state no license seem to mostly be Python boilerplate, build-system glue (the Makefile, setup.py), or in the doc/ subdirectory; a few of them (instances of __init__.py) are actually empty. I think it's fair to assume that they're all Unlicense'd, and written by Daniel Pearson himself. We could always ask him (including questions about the two files noted above, in relation to the relicensing), but since I already inquired and he indicated that he no longer has interest in moosic, I don't want to
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > (Apologies for breaking threading; I don't seem to have received the > original mail, and my Web browser appears to be treating the mailto: > links as something like file://mailto: links, and reports that it can't > find any file by the given name.) > > On 2021-01-02 at 13:34, Arto Jantunen wrote: > >> The package has been uploaded and is in NEW awaiting processing by >> the FTP team. > > Last night (as far as I can judge), this package disappeared from > https://ftp-master.debian.org/new.html (which I take to be the NEW > queue). > > As of a few minutes ago, it did not seem to be in the archive. A > packages.debian.org search didn't find it in anything newer than stable > (with the old version, of course), and the tracker.debian.org page for > this package showed the last change being the removal this past April. > > I'm not sure whether this is normal (package approved, processing to get > it actually into unstable doesn't happen right away, no visible sign of > package's status in the meantime), or whether it may mean that the > package has been rejected. > > If the former, then all is well. If the latter, I'd be interested to > know the status, both so I know what to expect and in case there's > anything I can do to help the package get in on a subsequent try. > Indeed the package was rejected after two months in the queue, due to things missing from the copyright file: > +--+ > | REJECT reasoning | > +--+ > > examples/completion seems to be copyright Etienne PIERRE and there does not > seem to be reason that they too have relinquished copyright. > > moosic/server/xmlrpc_registry.py has a different license. > > +--+ > | N.B. | > +--+ > > This review may not be exhaustive. Please check your source package > against your d/copyright and the ftpmaster REJECT-FAQ, throughly, > before uploading to NEW again. I'll try to find the time to go through the source and update this, unless you beat me to it of course. :) In any case we have missed the freeze by a mile, so we have a couple of years to get this done before the next round. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
(Apologies for breaking threading; I don't seem to have received the original mail, and my Web browser appears to be treating the mailto: links as something like file://mailto: links, and reports that it can't find any file by the given name.) On 2021-01-02 at 13:34, Arto Jantunen wrote: > The package has been uploaded and is in NEW awaiting processing by > the FTP team. Last night (as far as I can judge), this package disappeared from https://ftp-master.debian.org/new.html (which I take to be the NEW queue). As of a few minutes ago, it did not seem to be in the archive. A packages.debian.org search didn't find it in anything newer than stable (with the old version, of course), and the tracker.debian.org page for this package showed the last change being the removal this past April. I'm not sure whether this is normal (package approved, processing to get it actually into unstable doesn't happen right away, no visible sign of package's status in the meantime), or whether it may mean that the package has been rejected. If the former, then all is well. If the latter, I'd be interested to know the status, both so I know what to expect and in case there's anything I can do to help the package get in on a subsequent try. signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
Control: tags -1 +pending The Wanderer writes: > On 2020-12-23 at 02:08, Arto Jantunen wrote: > >> The Wanderer writes: > >>> I've decided it's worth the effort to become the new upstream for >>> this, and confirmed with the original author that he has no >>> objections, as he is no longer spending any time maintaining it. >>> >>> Version 1.5.7, based on Python 3 rather than Python 2, is now >>> available from: >>> >>> https://github.com/inverseparadox/moosic >>> >>> Please consider packaging this version, if possible in time to meet >>> the release freeze. > >>> Please let me know if there's anything I can do to help move this >>> forward. >> >> You've done the big part of the work already. I'll try to take care >> of updating the package as soon as I can, but due to commitments >> related to the holiday season that will probably take a week or so. >> That should still give us barely enough time before the freeze. > > I am *very* glad to hear that. After sending the above, I discovered > that the package had in fact already been removed from both testing and > unstable; I was starting to be concerned that it might need a full RFP / > ITP / RFS / trip-through-NEW / etc. cycle, which could be more of a > problem and more time-consuming than I'd prefer to engage with at this > stage. > > While obviously making the release freeze would be preferable, don't > worry too much if you can't make that time-frame on your end; I'd still > be happier with the package available in sid (or even experimental) than > with it dropped entirely, even if it doesn't get shipped with the next > release. > >> Thanks a lot for the work you did here. > > Thank *you* for picking this package back up, even with the upstream > side already handled! > > My "if there's anything I can do to help" on this still stands, so long > as I continue to have the time and other capacity to spare. The package has been uploaded and is in NEW awaiting processing by the FTP team. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
First, the bad news. In trying to test the playlist-file compatibility concern, I've discovered that at least on my system as it now exists, the default moosic configuration in the published codebase doesn't play WAV files (or anything else that relies on sox) correctly. IIRC it did work back in September, but I'm guessing something may have changed in the meantime; I've certainly done enough package upgrades for that to be plausible. The moosic configuration from the Python-2-based instance I've been running for all these years, however, does play the files correctly. Trouble is, I don't know whether it's likely to work on a standard Debian install, or whether mine is special in some way. The difference is that the default ~/.moosic/config defines WAV files as being played by invoking 'sox $item -t ossdsp /dev/dsp' (and fails with "no handler for given file type 'ossdsp'"), and the live-environment one defines them to be played by invoking 'play $item'. This can be tested either via moosic, by adjusting the config file, or simply by invoking sox with that syntax on a WAV file which sox knows how to play. If you get a chance to test with either method on a known-baseline Debian system, and it turns out that the observed behavior is indeed not specific to my environment, please let me know; I'll be happy to either spin up a minor (micro?) release which adjusts the default config, or if preferred, just provide a patch without making a new release yet. Second, two pieces of good news. One: although the playlist-queue file doesn't seem to be identical in format to the one from the Python 2 daemon, it does seem to be quite similar, and the code which generates it hasn't changed (except for the exact syntax of catching errors). I was able to take a moosic configuration directory generated with the Python 2 daemon and load it with the Python 3 daemon, and it seems to work without issues. Two: it looks like either I was wrong in remembering that the Py2 daemon and Py3 client don't talk to one another cleanly, or I managed to fix the problem before and forgot about it. I accidentally invoked the Py3 client in a way which seems to have made it interact with the Py2 daemon, and aside from one text-encoding error message which might be cosmetic, it seems to have worked fine - including adding a file to the existing daemon's playlist in a way which the existing daemon was able to parse and handle without issues. So my previously mentioned upgrade-scenario concerns may indeed not be a problem in practice. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#970635: moosic: new upstream now supports Python 3
The Wanderer writes: > On 2020-12-23 at 02:08, Arto Jantunen wrote: > >> The Wanderer writes: > >>> I've decided it's worth the effort to become the new upstream for >>> this, and confirmed with the original author that he has no >>> objections, as he is no longer spending any time maintaining it. >>> >>> Version 1.5.7, based on Python 3 rather than Python 2, is now >>> available from: >>> >>> https://github.com/inverseparadox/moosic >>> >>> Please consider packaging this version, if possible in time to meet >>> the release freeze. > >>> Please let me know if there's anything I can do to help move this >>> forward. >> >> You've done the big part of the work already. I'll try to take care >> of updating the package as soon as I can, but due to commitments >> related to the holiday season that will probably take a week or so. >> That should still give us barely enough time before the freeze. > > I am *very* glad to hear that. After sending the above, I discovered > that the package had in fact already been removed from both testing and > unstable; I was starting to be concerned that it might need a full RFP / > ITP / RFS / trip-through-NEW / etc. cycle, which could be more of a > problem and more time-consuming than I'd prefer to engage with at this > stage. Yeah, apparently so. I thought it had only been removed from testing, but since it has been removed from unstable (removed completely) we do need a trip through NEW. As I can't affect the time that takes we'll see what we can do. -- Arto Jantunen
Bug#970635: moosic: new upstream now supports Python 3
On 2020-12-23 at 02:08, Arto Jantunen wrote: > The Wanderer writes: >> I've decided it's worth the effort to become the new upstream for >> this, and confirmed with the original author that he has no >> objections, as he is no longer spending any time maintaining it. >> >> Version 1.5.7, based on Python 3 rather than Python 2, is now >> available from: >> >> https://github.com/inverseparadox/moosic >> >> Please consider packaging this version, if possible in time to meet >> the release freeze. >> Please let me know if there's anything I can do to help move this >> forward. > > You've done the big part of the work already. I'll try to take care > of updating the package as soon as I can, but due to commitments > related to the holiday season that will probably take a week or so. > That should still give us barely enough time before the freeze. I am *very* glad to hear that. After sending the above, I discovered that the package had in fact already been removed from both testing and unstable; I was starting to be concerned that it might need a full RFP / ITP / RFS / trip-through-NEW / etc. cycle, which could be more of a problem and more time-consuming than I'd prefer to engage with at this stage. While obviously making the release freeze would be preferable, don't worry too much if you can't make that time-frame on your end; I'd still be happier with the package available in sid (or even experimental) than with it dropped entirely, even if it doesn't get shipped with the next release. > Thanks a lot for the work you did here. Thank *you* for picking this package back up, even with the upstream side already handled! My "if there's anything I can do to help" on this still stands, so long as I continue to have the time and other capacity to spare. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
