글쓴이 보관물: litcoder

Macbook pro 나비 키보드 불량에 따른 보상

메일이 하나 날아들었는데, 내 오래된 맥북 pro의 키보드 불량 때문에 보상을 해주겠다는 내용이었다.

메일에 따르면 보상은 세개의 그룹으로 나누어, 두 번 이상의 키보드 교체를 받고도 문제가 재발한 경우(Group 1), 한번 키보드를 교체 했는데 문제가 재발한 경우(Group 2) 그리고 하나 이상의 키캡 교체를 받고도 문제가 재발한 경우(Group 3) 각각에 대하여 최대 $300-$395, $125, $50을 보상한다고 한다. 아마도 총 5천만 USD에서 제반 비용을 빼고, 나머지를 claim하는 사람 만큼으로 나누어 주기 때문에 최대 한도만 적어 놓은 듯 하다.

다행히 예전에 키보드를 교체한 이력에 대한 영수증을 버리지 않고 있어서 claim해보기로 했다. 나비 키보드는 상판(Top case)와 함께 교체 하기에 수리 명세서에는 “Korean, Top Case”라고 적혀 있다.

Claim page로 들어가면 email로 전달되는 Unique IDPIN을 입력하게 되는데, 이게 Macbook pro의 model 번호와 연결되어 있어서 모델 번호가 잘 못 입력된 경우는 이를 수정 할 수 없다. 만약 모델 번호가 잘 못 입력되어 있거나 case에 해당 함에도 메일을 받지 못했을 경우라면 정보를 직접 입력하는 claim page에서 시작하면 모델번호를 직접 입력할 수 있다.

2023년 3월 6일까지이니 케이스에 해당된다면 서두르시라.

Ubuntu 22.04 Linux kernel 6.1.1로 올리기

Ubuntu 22.04에서 Linux kernel 6.1.1 빌드해서 설정한 내용 정리이다. 굳이 실험정신을 억누르지 못하는게 아니라면 간단히 deb package를 다운로드 받아서 설치해도 된다.

Prerequisites

컴파일에 필요한 tool들을 설치한다.

sudo apt-get install libncurses-dev gawk flex bison openssl libssl-dev dkms libelf-dev libudev-dev libpci-dev libiberty-dev autoconf llvm

Linux kernel code를 다운로드 받고 합축을 해제해 둔다.

wget -c https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.1.tar.xz && tar xvf ./linux-6.1.1.tar.xz

Kernel config 설정 및 build 실행

Linux kernel config를 하나하나 설정하려면 시간이 오래 걸리니 현재 잘 동작하는 있는 kernel 설정 파일을 가져와서 설정하자.

cd ./linux-6.1.1
cp /boot/config-$(uname -r) ./.config

fakeroot debian/rules clean
make olddefconfig

추가로, 다음과 같이 복사된 .config를 열어서 KEY 설정을 주석으로 없애주는게 좋다. 그렇지 않으면 “No rule to make target ‘debian/canonical-certs.pem’, needed by ‘certs/x509_certificate_list’. Stop.” 오류가 발생하면서 빌드가 멈출 것이다.

#                                                                                                   
# Certificates for signature checking                                                               
#                                                                                                   
...                                                              
CONFIG_SYSTEM_TRUSTED_KEYS="" #COMMENT OUT "debian/canonical-certs.pem"                                              
...                                                            
CONFIG_SYSTEM_REVOCATION_KEYS="" #COMMENET OUT "debian/canonical-revoked-certs.pem"   

모든 설정이 완료되면 빌드를 실행한다.

fakeroot debian/rules binary -j$(nproc)

Build된 패키지 설치 및 확인

빌드가 완료되면 다음과 같이 4개의 deb file들이 source code의 상위 디렉토리에 생성되었는지를 확인하고 apt 명령어로 설치 후 system을 reboot한다.

ls ../*.deb
  ../linux-headers-6.1.1_6.1.1-2_amd64.deb
  ../linux-image-6.1.1-dbg_6.1.1-2_amd64.deb
  ../linux-image-6.1.1_6.1.1-2_amd64.deb
  ../linux-libc-dev_6.1.1-2_amd64.deb

sudo apt install ../*.deb
sudo reboot

BIOS로 진입해서 secure boot을 disable하고 GRUB에서 새로 설치한 kernel을 선택해서 부팅한 후 다음과 같이 확인할 수 있다.

uname -a
Linux <machine-name> 6.1.1 #2 SMP PREEMPT_DYNAMIC Thu Dec 29 13:15:23 KST 2022 x86_64 x86_64 x86_64 GNU/Linux

CARLA client를 build해야 하는데 clang-8이 없댄다.

2022년 9월 현재 CARLA simulator의 최신 버전인 0.9.13으로 PythonAPI를 빌드하려고 하면 clang-8 version을 요구하는데 Ubuntu 22.04에서는 clang-8의 repository를 추가하고 설치 시도하면 다음과 같이 의존성 오류가 생긴다.

The following packages have unmet dependencies:
 clang-8 : Depends: libllvm8 (>= 1:8~svn298832-1~) but it is not going to be installed
           Depends: libstdc++-5-dev but it is not installable
           Depends: libgcc-5-dev but it is not installable
           Depends: libobjc-5-dev but it is not installable
           Depends: libclang-common-8-dev (= 1:8.0.1+svn369350-1~exp1~20200112113617.82) but it is not going to be installed
           Depends: libclang1-8 (= 1:8.0.1+svn369350-1~exp1~20200112113617.82) but it is not going to be installed
           Recommends: llvm-8-dev but it is not going to be installed
           Recommends: libomp-8-dev but it is not going to be installed
 lld-8 : Depends: libllvm8 (= 1:8.0.1+svn369350-1~exp1~20200112113617.82) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

그리고 아쉽게도 하위 호환에 문제가 있는 것인지 설치 가능한 최하 버전인 clang-10으로는 CARLA client build가 되지 않는다. 빌드 스크립트에서 버전 점검하는 부분을 건너 뛰도록 수정하고 clang-10으로 강제 빌드를 시도해봤더니 역시나 빌드오류가 나면서 일이 커질것 같다는 느낌이 강하게 든다.

일일이 빌드오류 잡는 삽질을 하고 ‘CARLA client build 삽질기’를 포스팅 할 수도 있었겠지만 이번에는 문명의 이기인 Docker를 한번 누려 보기로했다.

먼저, Docker로 clang-8 설치가 가능한 Ubuntu 18.04에서 빌드를 수행한 다음(참고 CARLA – Linux Build) 빌드가 완료되면 Python client package를 host에 설치한다.

  • Docker로 Ubuntu18.04를 설치하고 CARLA의 소스 코드위치를 /carla로 마운트하여 실행한다.
$ docker pull ubuntu:18.04
$ docker run -ti -v <carla-root-path>:/carla ubuntu:18.04 /bin/bash
  • Clang-8의 repository를 추가하고 관련된 패키지들을 설치한다.
# Clang-8 repository 추가.
DOCKER# apt-get update &&
apt-get install wget software-properties-common &&
add-apt-repository ppa:ubuntu-toolchain-r/test &&
wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key|apt-key add - &&
apt-add-repository "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-8 main" &&
apt-get update

# Install packages.
DOCKER# apt-get install -y build-essential clang-8 lld-8 g++-7 cmake ninja-build libvulkan1 python python-pip python-dev python3-dev python3-pip libpng-dev libtiff5-dev libjpeg-dev tzdata sed curl unzip autoconf libtool rsync libxml2-dev git
  • Clang-8을 default로 설정한다.
# Set clang-8 as a default clang.
DOCKER# update-alternatives --install /usr/bin/clang++ clang++ /usr/lib/llvm-8/bin/clang++ 180 && update-alternatives --install /usr/bin/clang clang /usr/lib/llvm-8/bin/clang 180
  • Host machine의 python과 동일한 버전(3.8)을 docker에도 설치하고 관련된 Python package들을 pip로 설치해준다. 특별히 setuptools package는 버전의 영향을 받으므로 확인된 버전(47.3.1)을 명시해 준다.
DOCKER# apt install -y python3.8 python3.8-dev

# PIP upgrade
DOCKER# pip3 install --upgrade pip && pip install --upgrade pip

# 중요. Python3의 setuptools version이 안맞으면 빌드에 실패할 수 있으니 버전명을 명시해 준다.
DOCKER# pip2 install setuptools &&
pip3 install -Iv setuptools==47.3.1 &&
pip2 install distro &&
pip3 install distro &&
pip2 install wheel &&
pip3 install wheel auditwheel
  • 이제 해당 버전으로 docker에서 build를 시도 한다.
DOCKER# cd /carla
DOCKER# make PythonAPI ARGS="--python-version=3.8"
  • /carla/PythonAPI/carla/dist 아래에 소스에 포함되어 있는 3.6용 package외에 새롭게 빌드한 3.8용 *.whl, *.egg file들이 생성된 것을 확인하고 host system에 설치해 준다.
DOCKER# ls /carla/PythonAPI/carla/dist/
carla-0.9.13-cp36-cp36m-linux_x86_64.whl  carla-0.9.13-py3.6-linux-x86_64.egg
carla-0.9.13-cp38-cp38m-linux_x86_64.whl  carla-0.9.13-py3.8-linux-x86_64.egg

# CARLA client 설치
$ sudo apt install -y <carla-root-path>/PythonAPI/carla/dist/carla-0.9.13-py3.8-linux-x86_64.egg

Mac OSX에서 numpy 설치할 때 빌드 실패 문제

Intel Mac에서 pip로 numpy(ver1.22)를 설치하려고 했더니 설치에 실패하면서 아주 아주 긴 오류가 나오는데 Clang compiler option의 architecture flag가 좀 이상하다.

% python3 -m pip install numpy
...
 clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers -arch arm64 -arch x86_64 ...
  clang: error: the clang compiler does not support '-march=native'
...

“-arch arm64 -arch x86_64” 라는 건 Apple silicon과 Intel architecture를 모두 지원해 보겠다는 뜻인가? 혹시나 해서 환경 변수로 ARCHFLAGS=”-arch x86_64″를 주고 재 실행해 봤더니 이전에 있던 -march=native 플래그가 지원되지 않는다는 에러가 없어지면 잘 설치가 되었다.

% ARCHFLAGS="-arch x86_64" python3 -m pip install numpy

좀 더 일반적으로 적용될 수 있는 다른 방법으로 “–only-binary” 옵션을 주어서 wheel package file build를 안 하도록 하는 방법도 고려해 볼 수 있겠다.

% pip install numpy --only-binary numpy
Collecting numpy
  Downloading numpy-1.22.4-cp38-cp38-macosx_10_15_x86_64.whl (17.6 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 17.6/17.6 MB 30.0 MB/s eta 0:00:00
Installing collected packages: numpy
Successfully installed numpy-1.22.4

Visual Studio Code test explorer에서 explorer로 변경되는 문제

최근 업데이트(1.65.2) 이후 부터 였던 것 같은데 VSCode의 test explorer에서 테스트를 실행하면 자꾸만 explorer로 자동 변경되는 문제가 생겼다.

이 문제는 새롭게 생긴 설정인 testing.openTesting을 neverOpen으로 변경해 주면 해결된다.

{ // settings.json
   ...
    "testing.openTesting": "neverOpen"
}

또는

Setings -> Features -> Testing -> Testing: Open Testing

왜 이런 짓을??

정보의 바다에서 이와 관련해 의견을 나눈 기록을 찾았는데 Switching to test explorer when users clicks ‘run tests’에 따르면 커스터머 인터뷰 중에 IntelliJ에 구현된 이와 관련된 유사한 기능이 요청된 모양이다. 다행히도 이 기능이 VSCode에서는 오히려 불편하기만 할꺼라는 의견을 가진 사람 덕분에 option으로 빠지게 되었는데 default 값은 이 기능이 동작하는 openOnTestStart로 되어 버렸다. 변경 사항에 관련된 ticket은 여기에서 찾을 수 있다.