Bugzilla/Bug report guide/ko
This article explains how to report bugs on the Gentoo Bugzilla.
See Bugzilla/Guide for the recommended method of reporting bugs for Gentoo.
모범 사례
- 제출 전에 다시 읽어주십시오. 바꾼 내용은 되돌릴 수 없고 제출한 다음에 다시 편집할 수 없습니다. 버그 보고서에 입력한 텍스트는 수많은 사람에게 즉시 전자메일로 발송합니다. 간명한 언어로 기술하고 대화체는 피해주십시오.
요령: 버그 보고서를 쓸 때 삶의 단 한번의 기회가 주어졌음을 생각하는게 중요합니다. 수신자가 영문을 읽을 줄 안다는거 여러분도 압니다만, 주로 사용하는 언어는 아닙니다.
- 버그 보고서를 꾸리기 전 중복 여부를 검색하십시오.
- 항상 주제를 지키십시오 - 버그 추적 시스템은 기술적 보고서를 처리하는데 사용하며 잡담은 배제합니다. 지원 채널(포럼, IRC, 메일링 리스트)en에서 이 점을 지켜주십시오.
- 적어도 한번 문제가 있는지 확인하십시오 - 다른 사람이 또 보고하면 문제를 해결하는데 도움이 안됩니다. 허나 여러분이 보유한 시스템과 확인한 사람의 시스템이 명백히 다르거나 하여 알아야 할 사항이 있다면, 해당 정보를 추가하십시오
- 하나의 주제에 하나의 버그를 다루십시오 - 보통 티켓 하나에 꾸러미 하나와 버그 하나 이상을 다루지 말라는 의미입니다. 보고한 버그 보고서에서 다루는 문제가 아니라면, 해당 문제를 찾거나 새 보고서를 작성하십시오. 다른 버그 내용을 갖아 붙여넣지 마십시오.
- 추적기의 버그에 대해선 말하지 마십시오 - 해당 버그는 통상적인 버그입니다. 쓸만한 정보를 추가하려면 관련 하위 버그 보고서에 추가하든지 새 버그 보고서를 만드십시오.
- 추가: 젠투 자문단 에서 버그와 이빌드에 대한 상업 지원을 제공하기도 합니다.
- 실행 중 또는 설치 과정의 문제를 다루는 티켓일 경우 버그 티켓에 로그를 첨부하십시오.
꾸러미/이빌드
버그에 시스템 설정 정보를 항상 추가해야합니다. 이렇게 하려면 다음 내용을 새 첨부 파일로 만들어 붙여넣으십시오:
user $emerge --info > /tmp/emerge--info.txt빌드 시간 버그 보고(이머지 실패)
- sys-apps/package-2.3-r4와 같이 버그 보고서 제목에 꾸러미 이름과 정확한 버전을 적으십시오.
- 제목에 간단한 설명을 추가하십시오.
- 버그 티켓에 로그를 첨부하십시오
실행 시간 버그 보고
파일 및 관심 정보는 우선 순위에 따라 정렬합니다:
- sys-apps/package-2.3-r4 crashes with error: Cannot proceed...와 같은 버그 보고서의 제목에 해당 꾸러미의 정확한 버전
- 다른 사람이 재현할 수 있도록 하는 문제 설명
- 프로그램 실행 방법(콘솔, 터미널, 데몬, 어떤 런레벨인가 등)
- 오류 출력
- 프로그램이 깨졌을 때, 뭔가가 잘못됐을 때, 시작하지 않았을 때의 원인
- 해결책이 있는가?
- 꾸러미의 최신 동작 버전이 있다면 몇인가?
- 동작하지 않게 하는 (바뀐) 원인이 무엇인가?
- 버그 티켓에 로그 첨부
그 동안 업스트림에서 새 릴리즈가 나와 버전을 올려달라고 요청
- 상위 버전 갱신 요청 전 버그질라를 검색하십시오 - 이미 공개한 버그입니까? 로컬 포티지 트리를 뒤늦게 동기화하여 이미 포티지에 있지 않습니까?
- 당일 상위 버전 업데이트 요청을 피하십시오(최소한 출시 발표 후 48 시간을 기다려주십시오)
- 실제로 업스트림 소스를 출시 했는지, 아니면 소스트리에 단지 상위 버전으로 표시했을 뿐인지? 일부 프로젝트는 공식 출시 훨씬 이전에 소스트리 상에 출시로 표시할 수도 있습니다.
- 보유중인 아키텍처에서의 컴파일 및 실행 여부를 확인하십시오. 다른 참고 사항을 제공해주시면 더욱 좋습니다.
- 업스트림 웹사이트 링크를 추가하십시오
- 수정 버그 목록 또는 새 기능 목록 링크를 제공하십시오(changelog라고도 합니다)
- app-editors/vim-12.3.5 version bump와 같은 식으로 summary 항목을 작성하십시오
추가 고려사항
- 간단한 복사 작업이나 이빌드 변경 (의존성 바뀜, 오래된 패치 파일)이 필요합니까?
- 첨부 파일을 제출하기 전에 로컬 오버레이에서 이빌드를 테스트하십시오
- 바뀐 내용에 대한 설명을 곁들여 제안한 이빌드 편집의 패치를 제공하십시오(파일 이름은 이전 버전이 아닌 새 버전 번호에 맞춰야 합니다)
- 추가 파일(initd, unit 파일)을 별도로 첨부(필요한 대로)로 제공하십시오
- 답글에 이빌드 또는 이빌드 관련 내용을 직접 붙여넣지 마십시오. 첨부 기능을 활용하십시오.
새 꾸러미에 대한 이빌드 요청
포티지 트리에 추가할 프로그램의 새 이빌드를 요청하려면 꾸러미의 관리자를 찾거나 자신이 직접 꾸러미 관리자가 돼야합니다:
If no bug report exists for the package, you can file a bug report under the Gentoo Linux project and the component New package.
The Summary of your bug report should list a (preliminary) package atom category/package, perhaps with a -VERSION suffix, followed by a canonical short description of the package (the DESCRIPTION variable in an ebuild). It is important to disambiguate the name of the new package: if upstream uses different names for the same software, perhaps an abbreviation as well as the full name, you should mention both (all) of these in the Summary so that other people can find bug reports about the same software. If several (groups of) people track different bug reports about virtually the same ebuild request, this will duplicate the effort of ebuild research and development, and will divide people who have a common interest.
You should link to the upstream website (the HOMEPAGE variable in an ebuild) using the URL field. You should provide a list of features in the Description of the bug report. This may well be taken directly from the upstream website or from a manual or other documentation, and could be used later for the longdescription tag in metadata.xml.
You can attach an ebuild and related files that should go into the portage tree directly to the bug report, or you can use the See also field to refer to a git pull request.
You can help develop the package by setting up a local overlay with your ebuilds, metadata, patches and other auxiliary files. If you need technical support with your ebuild development, many people would be glad to help.
XY 꾸러미를 안정 버전으로 간주해야 함
For developers, the devmanual has more extensive information on stable requests.
시스템에 빌드, 설치 후 30일 이상이 흘러 어떤 문제도 없지만 여전히 안정판이 아닐 경우 안정판 지정을 요청할 수 있습니다.
Everybody can request a stabilization. Users do not need to worry about filling all fields or details in the bug. The maintainer (or Proxied Maintainer) will CC the arches.
To request stabilization of a package, file a new bug under the Stabilization component taking care to complete two special bug fields:
Package list- a fully qualified package per line, optionally followed by a space-delimited list of architectures to target. If no architecture list is provided, all architectures inCCare assumed. Formerly, this field was calledAtoms to stabilizeand contained fully qualified atoms, which is also still supported.Runtime testing required- indicates if additional runtime testing should be performed beyond build and tests passing. If undefined the arch tester should use their best judgement
Examples:
| Summary | foo-libs/libbar-1.2.3 stabilization request |
|---|---|
| CC | amd64 x86 |
| Runtime testing required | No |
| Package list | foo-libs/libbar-1.2.3 (old syntax, still supported: =foo-libs/libbar-1.2.3) |
| Explanation |
|
| Summary | app-foo/bar-1.2.3 and app-foo/baz-4.5.6 stabilization request |
|---|---|
| CC | amd64 arm x86 |
| Runtime testing required | Yes |
| Package list | app-foo/bar-1.2.3 |
| app-foo/baz-4.5.6 amd64 x86 | |
| Explanation |
|
커널
커널 버그 보고서의 파일과 관심 정보는 우선 순위에 따라 정렬합니다:
- x86_64의 gentoo-sources-3.4.2-r2와 같이 사용중인 커널 및 버전, 아키텍처 명시.
- 커널 설정 파일 (/usr/src/linux/.config)을 버그 보고서에 첨부할 것
- 시스템의 모든 장치 목록을 lspci -k로 가져올 수 있습니다
- 커널 초기화시에 나오는 로그 파일 (/var/log/dmesg 또는 /var/log/messages)을 첨부해야합니다
kernel git-bisect 요청은 잘못된 패치 여부를 증명해낼 수 있습니다.
Supplemental information for bug reports
| Information | when needed | How to collect |
|---|---|---|
| SRC_URI reachable? | download failed | GENTOO_MIRRORS="" ebuild foo-1.2.ebuild fetch
|
| OpenGL version | Games with OpenGL | glxinfo -B
|
| linked libraries | Dependency is missing | Add missing dependency, compile, check with lddtree |
Trackers
Tracker-Bugs are virtual bugs to cluster bugs with the same topic.
추가 참조
- Bugzilla/Guide — covers the recommended method of forensically reporting specific details of bugs within Gentoo.en
- Contributing to Gentoo — explains how users can contribute to the development of Gentooen
- GitHub Pull Requests — how to contribute to Gentoo by creating pull requests on GitHub.en
- 젠투 버그질라 사이트en