Hi Phil,
Thanks for your reply! That were the pointers I wasn't able to
find previously. There's a lot of helpful information in the
Debian documentation, but sometimes finding the information you
need is like looking for the needle in the haystack - unless you
happen to stumble across a page that points you in the right
direction...
Yes, I already figured that by now it's probably too late to make it into Bullseye.On Tue, Feb 09, 2021 at 06:01:15PM +0100, Eberhard Beilharz wrote:Can someone PLEASE help me getting move this forward? I created #980120 where someone suggested: "Have you contacted with the current maintainer for those packages...? If there's no response, we may also consider other methods." I did, but there's been no response, and then there's been no response on that bug either...Ouch, I can see it'd be annoying to hear mostly silence given that you first tried to get in touch no later than November. I'll try to help just because it came across my inbox, though bear in mind I'm not part of the input method team. Firstly though, a bit of expectation management - it is too late for the latest version to be in Debian 11 bullseye I'm afraid. That doesn't mean you can't work on it in the meantime, and bullseye users could still install the latest if you end up getting it uploaded to backports. https://release.debian.org/bullseye/freeze_policy.html
I'm a member of the Keyman project (https://keyman.com/). We noticed that the Debian package repos still contain Keyman 11 whereas the current stable version is 13, and version 14 is around the corner. What can/need we do to update the packages to a newer version in the Debian package repos?Ok, so it appears to be a simple matter of the initial uploader not having time to work on this package since Jan 2019. Strictly speaking, an RFH is reserved for the maintainer to file - for future reference I would have filed an ordinary bug against ibus-keyman with priority "wishlist" to request a new version. It's great that you've managed to find the packaging repo on salsa, but note that maintainers are not required to monitor its Merge Requests. Just skimming debian/control (not a review) I can see you've done your research, so given you seem to be willing to collaborate on the packaging side, I suggest following the salvaging process: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvagingOpen a bug with the severity "important" against the package in question, expressing the intent to take over maintainership of the package. For this, the title of the bug should start with ITS: package-name. You may alternatively offer to only take co-maintenance of the package. When you file the bug, you must inform all maintainers, uploaders and if applicable the packaging team explicitly by adding them to X-Debbugs-CC.I strongly suggest keeping the team maintenance, just adding yourself to Uploaders.
Ok, thanks! I did that: #982545.
One question: there are several packages that are related, have the same maintainer and have the same upstream source repo, but in Debian have separate source packages. Do I have to create a separate issue for each package?
Thanks again for your help!