Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)
On Fri, Feb 1, 2019 at 3:38 AM John Paul Adrian Glaubitz wrote: > > Hello! > > > On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷) wrote: > > > > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in > > task-chinese-t-desktop: > > > > fcitx, > > fcitx-chewing, > > fcitx-table, > > im-config, > > fonts-arphic-ukai, > > fonts-arphic-uming, > > fonts-noto, # this seems to be unnecessary, but not really sure. > > fonts-noto-cjk, > > libreoffice-l10n-zh-tw, > > libreoffice-help-zh-tw, > > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw, > > poppler-data > > I haven’t yet understood why people are moving to fcitx. I have tried it > myself after it was automatically installed on my openSUSE machine to replace > iBus and found it completely unusable. I didn’t even manage to get any input > languages added. > > I am using iBus for writing Japanese and I consider it the superior and > simpler-to-use solution. > > Is there anything that fcitx is supposed to do better than iBus? > > Adrian One of the reasons people moving to fcitx is that the framework has some architectural advantages that gives a lot room of extending the input method which ibus does not have so far. An example for Chinese (China) users is that there are several other alternative implementations of UI and, even further, commercial products with both UI and engines. GNOME's built-in support for ibus is a very old topic that a lot discussions happened on GNOME's mailing list years ago - in short there are two reasons: 1) ibus has slightly better support for those non-CJK languagues whereas GNOME developers are mostly non-CJK native speakers, 2) RedHat has continued investment on it. Cheers, Aron
Металлообрабатывающее-оборудование-Главному Механику
Металлообрабатывающее оборудование 80тр за тонну! круглошлифовальный 3М151В продольно-фрезерный 6642 радиально-сверлильный 2Л554 1987 долбежный 7Д430 1978 радиально-сверлильный 2Н58 токарно-карусельный 1550 вертикально-фрезерный 65А60Ф11-1 1986 токарно-винторезный 16к25 1977 токарно-винторезный 1К625 1969 пресс гидравлический П437 1981 токарно-карусельный 1532Т вертикально-сверлильный 2Н135 1988 вертикально-фрезерный 6Т12 1987 горизонтально-расточной 2Г660Ф2 продольно-фрезерный 6610 токарно-винторезный РТ-21003 1977 продольно-строгальный 7А210 1985 вертикально-фрезерный консольный ВМ127М 1992 вертикально-фрезерный 6Р11 1977 долбежный 7410 фрезерно-расточный 6М608Ф1 1977 токарно-карусельный 1580 токарно-винторезный 1М63 (ДИП 300) 1988 токарно-винторезный 165 (ДИП 500) 1988 плоскошлифовальный 3Б722 горизонтально-расточной 2637ГФ1 плоскошлифовальный 3Л722В токарно-винторезный 16К20 1979 плоскошлифовальный 3Д725 1987 вертикально-фрезерный 6Р12 1984 плоскошлифовальный 3Е711АФ1 вертикально-фрезерный 6Т13Ф3-1 1986 вертикально-фрезерный 6Р13 1981 фрезерный УФ0808 1978 радиально-сверлильный 2М55 1980 пресс гидравлический П6324 1978 продольно-фрезерный 6У612 8..(913)5397.65.4
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
Control: notfound -1 0.57 Raphael Hertzog wrote: > Hi, > > On Wed, 27 Jun 2018, Justin B Rye wrote: > > _Description: Updates management on this system: > > Applying updates on a frequent basis is an important part of keeping the > > system secure. > > . > > By default, security updates are not automatically installed, as security > > advisories should be reviewed before manual installation of the updates > > using standard package management tools. > > . > > Alternatively the unattended-upgrades package can be installed, which will > > install security updates automatically. Note however that automatic > > installation of updates may occasionally cause unexpected downtime of > > services provided by this machine in the rare cases where the update is > > not fully backward-compatible, or where the security advisory requires the > > administrator to perform some other manual operation. > > Thanks for the review. I updated the string in git. I will not upload the > package right away, maybe later once translators had a chance to catchup > (or maybe someone else will decide to upload before me). This has been committed in https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b however this bug was not mentioned in the changelog, and therefore not closed. Tagging this bug as fixed in version 0.57 Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Processed: Re: Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
Processing control commands: > notfound -1 0.57 Bug #875858 [src:pkgsel] Revert default installation of unattended-upgrades Ignoring request to alter found versions of bug #875858 to the same values previously set -- 875858: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875858 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)
Hi, John Paul Adrian Glaubitz wrote: > Hello! > > > On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷) wrote: > > > > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in > > task-chinese-t-desktop: > > > > fcitx, > > fcitx-chewing, > > fcitx-table, > > im-config, > > fonts-arphic-ukai, > > fonts-arphic-uming, > > fonts-noto, # this seems to be unnecessary, but not really sure. > > fonts-noto-cjk, > > libreoffice-l10n-zh-tw, > > libreoffice-help-zh-tw, > > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw, > > poppler-data > > I haven’t yet understood why people are moving to fcitx. I have tried it > myself after it was automatically installed on my openSUSE machine to replace > iBus and found it completely unusable. I didn’t even manage to get any input > languages added. > > I am using iBus for writing Japanese and I consider it the superior and > simpler-to-use solution. > > Is there anything that fcitx is supposed to do better than iBus? I cannot judge on fcitx, but it was stated that GNOME3 has built-in support for iBus, so we have that in any case. The question "fcitx or scim" is just sort of a fallback. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Upcoming stable point release (9.8)
Hi, The next point release for "stretch" (9.8) is scheduled for Saturday, February 16th. Processing of new uploads into stretch-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Bug#919813: recognising devuan
So the remaining problem is that the Debian Buster os-prober did not recognise Devuan ascii. -- hendrik
Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)
Hello! > On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷) wrote: > > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in > task-chinese-t-desktop: > > fcitx, > fcitx-chewing, > fcitx-table, > im-config, > fonts-arphic-ukai, > fonts-arphic-uming, > fonts-noto, # this seems to be unnecessary, but not really sure. > fonts-noto-cjk, > libreoffice-l10n-zh-tw, > libreoffice-help-zh-tw, > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw, > poppler-data I haven’t yet understood why people are moving to fcitx. I have tried it myself after it was automatically installed on my openSUSE machine to replace iBus and found it completely unusable. I didn’t even manage to get any input languages added. I am using iBus for writing Japanese and I consider it the superior and simpler-to-use solution. Is there anything that fcitx is supposed to do better than iBus? Adrian
loop-aes bugreports to be closed (house-cleaning)
Hi, Holger Wansing wrote: > > Hi, > > Am Sonntag, 27. Januar 2019 schrieb Ben Hutchings: > > On Sat, 2019-01-26 at 22:35 +0100, Holger Wansing wrote: > > > Hi, > > > > > > since LUKS is no longer supported by d-i, all LUKS related bugreports > > > against > > > d-i packages can be closed, right? > > > > I don't know what makes you think that. LUKS is precisely what is used > > for disk encryption. > > Uhh, seems I mixed things up here. > At some point in the past the d-i supported two encryption > systems; then one was dropped and now only dm-crypt is > supported. > Somehow I came to the conclusion that LUKS is thus no longer > supported. But it's loop-aes which was dropped. > LUKS is in fact another story (an 'add-on' of dm-crypt). So the goal is now, to close this old, loop-aes related bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381891 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381875 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392221 And renaming this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404261 Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#680668: Fw: Re: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)
Control: tags -1 + pending Holger Wansing wrote: > "Yao Wei (魏銘廷)" wrote: > > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in > > task-chinese-t-desktop: > > > > fcitx, > > fcitx-chewing, > > fcitx-table, > > im-config, > > fonts-arphic-ukai, > > fonts-arphic-uming, > > fonts-noto, # this seems to be unnecessary, but not really sure. > > fonts-noto-cjk, > > libreoffice-l10n-zh-tw, > > libreoffice-help-zh-tw, > > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw, > > poppler-data > > > > Other input methods like gcin and hime are also available, but I seldom > > see people using SCIM. > > So, for the input method question, I would propose to skip SCIM and move to > fcitx as in zh_CN. > > Any objections or advocates? Just committed. Tagging this bug as pending. Holger -- Holger Wansing PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Processed: Re: Fw: Re: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)
Processing control commands: > tags -1 + pending Bug #680668 [tasksel] tasksel: Updating chinese-t-desktop in tasksel for Wheezy. Added tag(s) pending. -- 680668: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680668 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Scheduling 9.8 (was: Re: Scheduling 9.7)
On 1/28/19 8:45 PM, Adam D. Barratt wrote: > On Fri, 2019-01-18 at 18:44 +, Jonathan Wiltshire wrote: >> 9.7 is a bit overdue already (current events being a bit of a time- >> sink). >> >> Please indicate your availablility out of: >> >> - (Feb 2 unlikely, FOSDEM) >> - Feb 9 >> - Feb 16 > > As we had a short-notice 9.7, this is now planning for 9.8. > > Either the 9th or 16th looks like it should work for me, with a > preference for the latter. > 9th or 16th should be ok for me. Cheers, Julien
