Update requests for packages imported from Arch Linux

lynis 3.0.7-1 is available in arch repo. We have in manjaro unstable.

So just wait for the next sync?

Yes, of course. However, since this is a security auditing tool, I would like to ask for it to be fast tracked directly to stable, if possible.

2 posts were split to a new topic: Libspeechd: signature is unknown trust

2 posts were split to a new topic: Is there anywhere to track the progress of a package?

Hey guys, could someone please update fcitx5-mozc if possible? I tried to do it myself but I’m stuck and I think my approach is not the best one anyway (I tried to force building using python 3.7).

# Maintainer: Jiachen Yang <farseerfc@archlinux.org>
# Contributor: Felix Yan <felixonmars@archlinux.org>
# Contributor: ponsfoot <cabezon dot hashimoto at gmail dot com>
# Contributor: UTUMI Hirosi <utuhiro78 at yahoo dot co dot jp>

## Mozc compile option

## follow the submodule commits in https://github.com/fcitx/mozc/tree/fcitx/src/third_party

## the latest release from https://osdn.net/projects/ponsfoot-aur/storage/mozc/

pkgdesc="Fcitx5 Module of A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source Edition of Google Japanese Input)"
depends=('qt5-base' 'fcitx5')
makedepends=('pkg-config' 'python' 'curl' 'gtk2' 'mesa' 'subversion' 'ninja' 'git' 'clang' 'python-six')
conflicts=('mozc' 'mozc-server' 'mozc-utils-gui' 'mozc-fcitx' 'fcitx-mozc')
validpgpkeys=('2CC8A0609AD2A479C65B6D5C8E8B898CBF2412F9')  # Weng Xuetian

  cd mozc
  # change pkgver is OK because we fixed commit
  # parse major.minor.buildid from version template, revision is fixed to 102 for Linux
  _bzr_ver=$(sed 's/ //g;$ a echo $MAJOR.$MINOR.$BUILD.102' src/data/version/mozc_version_template.bzl | source /dev/stdin)
  printf "%s.g%s" "${_bzr_ver}" "${_mozc_commit}"

prepare() {
  cd "$srcdir/mozc"
  git submodule init
  git config submodule.src/third_party/breakpad.url "$srcdir/breakpad"
  git config submodule.src/third_party/gtest.url "$srcdir/googletest"
  git config submodule.src/third_party/gyp.url "$srcdir/gyp"
  git config submodule.src/third_party/japanese_usage_dictionary.url "$srcdir/japanese-usage-dictionary"
  git config submodule.src/third_party/jsoncpp.url "$srcdir/jsoncpp"
  git config submodule.src/third_party/protobuf.url "$srcdir/protobuf"
  git config submodule.src/third_party/abseil-cpp.url "$srcdir/abseil-cpp"
  git submodule update

  cd src
  # Generate zip code seed
  echo "Generating zip code seed..."
  PYTHONPATH="$PWD:$PYTHONPATH" python dictionary/gen_zip_code_seed.py --zip_code="${srcdir}/x-ken-all.csv" --jigyosyo="${srcdir}/JIGYOSYO.CSV" >> data/dictionary_oss/dictionary09.txt
  echo "Done."

  # disable fcitx4 target
  #rm unix/fcitx/fcitx.gyp
  ## use libstdc++ instead of libc++
  sed "/stdlib=libc++/d;/-lc++/d" -i gyp/common.gypi

build() {
  # Fix compatibility with google-glog 0.3.3 (symbol conflict)
  CFLAGS="${CFLAGS} -fvisibility=hidden"
  CXXFLAGS="${CXXFLAGS} -fvisibility=hidden"

  cd mozc/src

  _targets="server/server.gyp:mozc_server gui/gui.gyp:mozc_tool unix/fcitx5/fcitx5.gyp:fcitx5-mozc"

  QTDIR=/usr GYP_DEFINES="document_dir=/usr/share/licenses/$pkgname use_libzinnia=1" python3.7 build_mozc.py gyp
  python3.7 build_mozc.py build -c $_bldtype $_targets

  # Extract license part of mozc
  head -n 29 server/mozc_server.cc > LICENSE

package() {
  cd mozc/src
  export PREFIX="${pkgdir}/usr"
  export _bldtype

  install -d "${pkgdir}/usr/share/licenses/$pkgname/"
  install -m 644 LICENSE data/installer/*.html "${pkgdir}/usr/share/licenses/${pkgname}/"

  install -d "${PREFIX}/share/fcitx5/addon"
  install -d "${PREFIX}/share/fcitx5/inputmethod"
  install -d "${PREFIX}/lib/fcitx5"

there is new version for wlroots (0.15.0). They have migrated to GitLab (gitlab-wlroots), so maybe this is the reason manjaro team haven’t been able to pick up on this version release.

wlroots is an Arch community package. 0.15 is currently in Arch Community-Staging.

fcitx5-mozc is on the Task Todo List GTK 2 EOL so Arch may be waiting to be able to build it with Gtk 3.

1 Like

stable : 3.0.10-6 → cannot be installed due to invalid PGP signature
testing : 3.0.10-7 → works
Please update ?

A few packages including shntool were missed when rebuilding the maintainer’s packages when the key was revoked.

For now just download shntool 3.0.10-7 and mcomix 1.3.0.dev0-6 from one of our mirrors like this one: Index of /testing/community/x86_64/

Thanks for the explanation and solution.

intel-ucode should be updated to 20220207-1. Should be fasttracked as it is a security update. spectre-meltdown-checker shows that my intel CPU is vulernerable and it can be mitigated by updating microcode.

It is currently in Unstable branch.

1 Like

It’s a false positive. The script does not seem to detect microcode properly. There are numerous reports about it.

1 Like

if you are running an old chip like me (ivy-bridge/3rd-gen) you can forget getting microcode updates from intel, last time i got updates relevant to mine was in 02/2019

1 Like

I have 5th gen i5-5200U. How do I know if the intel-ucode package has microcode for my CPU or not?

run this;

$ journalctl -b | head -1l

the date at the end of result is the last time intel released an update for your processor in the current intel-ucode


python-installer is at 0.2.3-2 but upstream is at 0.5.0

➤  pacman -Ss python-installer
community/python-installer 0.2.3-2 [Installiert]
    Low-level library for installing a Python package from a wheel distribution

The Python package guidelines in the Arch Wiki recommend building Python packages via python -m installer ..., which is a feature introduced in python-installer>=0.5.0. It is also strictly necessary for Python packages that don’t provide a setup.py anymore. In Arch the package is up to date.

Is there a reason for this very old python-installer version in the Manjaro repos?

@nobodyinperson It is at 0.5.0-2 in testing and unstable. See Manjaro - Branch Compare