Am Sun, Nov 26, 2023 at 03:30:18PM +0300 schrieb Igor B. Poretsky: > Hello Tobias, > > Great thanks for your review. I'll try to address all the issues listed, > but several questions by the way below: > > >>>>> "Tobias" == Tobias Frost <t...@debian.org> writes: > > Tobias> d/changelog: - An initial upload to Debian only have one > Tobias> single entry, like "Initial Upload (Closes: > Tobias> #<your-itp-bug>)" (There are by definition no changes to the > Tobias> packaging on initial upload.) - As an consequence, the > Tobias> debian revision must stay at -1 until sponsored. > > Ok, but how can I return to the -1 debian revision now in my upload on > mentors.debian.net? And what should I do further if it will not be the > last iteration?
You should be able to just re-upload to mentors. If it does not allow that, remove the package manually from mentors, then re-upload. In the case a bot auto-close this RFS bug, just manually re-open it (do not file a new one) On further iterations, you keep at -1 until this is sponsored. > Tobias> - A library package needs a development package too. > > But this library is not intended for a third-party development. It just > implements core functionality that is common for two different > frontends. Ok, it seems that this library package could be dropped, if it is solely internal. This will also make the packaging easier, as libraries are always a bit more advanced. I'd either statically link this internal library, or just compile the source files seperately for both flavours of your binary. > Tobias> - the library package must only contain the library, not > Tobias> configuration files nor manpages. (makes them breaking when > Tobias> an SONAME bump is required - see above about your Conflicts) > > But this configuration is common as well and it is parsed by the library > functions. Can you give me some hint what should I do in this situation? The usual approach is here to have a -data package for the library. Is is a possible scenario that users want different configuration for the different frontends? In this case, the frontends should ship (separate) configurations. > Tobias> d/libmultispeech.shlibs - Why do you need this file? > > For the version restriction in dependencies. The Debian build system should be able to calculate dependencies on libraries automatically, so obviously I'm missing some detail why this is not working here. > > Tobias> d/libmultispeech.links - why do you need the link? Is > Tobias> multispeech to be invoked by the user directly or is it only > Tobias> to be invoked by emacs? (as the usr/share/emacs seems to > Tobias> indicate) (Disclaimer: I do not know anything about emacs > Tobias> extension.) > > Generally, it is used just by Emacspeak. This symlink is inherited > historically from the old versions. Now I see no valuable reason for it. > > Tobias> postinst - speech-dispatcher is using a systemd service > Tobias> file, if you really need to reload its configuration, you > Tobias> should use service speech-dispatcher reload and not kill it > Tobias> via kill. (you might overkill) > > Actually, it is not mandatory. Speech Dispatcher can as well be > automatically spawned by a client. The kill command in this case just > sends the SIGHUP signal, that does not kill or restart Speech > Dispatcher, but only notifies it about a configuration change. It is > documented behaviour of Speech Dispatcher. And I should notify every > running instance regardless of the way it was launched by. Additional data point: Looking at speech-dispatcher-espeak-ng, they are not sending SIGHUP. So it seems not to be nedded, also not the service reload (it seems to be discouraged to run it as system service) > Best regards, > Igor. cheers, -- tobi
