/usr/share/doc/ubuntu-packaging-guide-html-ru/singlehtml/index.html is in ubuntu-packaging-guide-html-ru 0.3.7.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Ubuntu Packaging Guide</title>
<link rel="shortcut icon" href="./_static/images/favicon.ico" type="image/x-icon" />
<link rel="stylesheet" href="./_static/reset.css" type="text/css" />
<link rel="stylesheet" href="./_static/960.css" type="text/css" />
<link rel="stylesheet" href="./_static/base.css" type="text/css" />
<link rel="stylesheet" href="./_static/home.css" type="text/css" />
<link rel="stylesheet" href="./_static/pygments.css" type="text/css" />
<link rel="stylesheet" href="./_static/guide.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '0.3.7',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="./_static/jquery.js"></script>
<script type="text/javascript" src="./_static/underscore.js"></script>
<script type="text/javascript" src="./_static/doctools.js"></script>
<script type="text/javascript" src="./_static/translations.js"></script>
<script type="text/javascript" src="./_static/main.js"></script>
<link rel="top" title="None" href="./index.html" />
</head>
<body class="home">
<a name="top"></a>
<div class="header-navigation">
<div>
<nav role="navigation">
<ul>
<li class="page_item current_page_item"><a title="Содержание" href="index.html">Содержание</a>
<li>
<form id="form-search" method="get" action="search.html">
<fieldset>
<input id="input-search" type="text" name="q" value="Search" />
</fieldset>
</form>
</li>
</ul>
</nav>
<a class="logo-ubuntu" href="http://packaging.ubuntu.com/">
<img src="./_static/images/logo-ubuntu.png" width="119" height="27" alt="Ubuntu logo" />
</a>
<a href="http://packaging.ubuntu.com/"><h2>Packaging Guide</h2></a>
</div>
</div>
<div class="header-content">
<div class="clearfix">
<div class="header-navigation-secondary">
<div>
<nav role="navigation">
<ul class="clearfix">
<li class="page_item"><a class="sub-nav-item" href="index.html#document-index">Ubuntu Packaging Guide »</a></li>
</ul>
</nav>
</div>
</div>
</div>
</div>
<div id="content" class="body container_12">
<div class="grid_12">
<!--<section id="main-section">-->
<div class="grid_9 alpha">
<div class="section" id="ubuntu-packaging-guide">
<h1>Руководство разработчика Ubuntu<a class="headerlink" href="#ubuntu-packaging-guide" title="Ссылка на этот заголовок">¶</a></h1>
<p>Добро пожаловать в руководство разработчика Ubuntu! Это официальная документация по всем темам, связанных с разработкой Ubuntu и сборкой пакетов для этой операционной системы. После прочтения этого руководства вы:</p>
<ul class="simple">
<li><p class="first">будете знать о самых важных утилитах, процессах и командах в разработке Ubuntu,</p>
</li>
<li><p class="first">сможете правильно настроить вашу среду разработки,</p>
</li>
<li><p class="first">узнаете, как присоединиться к нашему сообществу,</p>
</li>
<li><p class="first">исправите настоящую ошибку в Ubuntu в процессе изучения руководства.</p>
</li>
</ul>
<p>Ubuntu — не только свободная операционная система с открытым исходным кодом, её платформа также является открытой и обеспечивает прозрачность разработки. Можно легко получить исходный код для каждого отдельного компонента, и каждое отдельное изменение в платформе Ubuntu можно проверить.</p>
<p>Это означает, что вы можете принять активное участие в её улучшении, и сообщество разработчиков платформы Ubuntu всегда заинтересовано в привлечении новых участников.</p>
<p>Ubuntu также является сообществом замечательных людей, верящих в то, что программное обеспечение должно быть свободным и доступным для всех. Участники сообщества приветствуют вас и хотят, чтобы вы тоже к ним присоединились. Мы хотим, чтобы вы принимали участие в нашей работе, задавали вопросы, делали Ubuntu лучше вместе с нами.</p>
<p>Если у вас возникнут трудности: не волнуйтесь! Прочтите <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/communication"><em>раздел о коммуникации</em></a>, и вы узнаете, как легко связаться с остальными разработчиками.</p>
<p>Это руководство состоит из двух разделов:</p>
<ul class="simple">
<li><p class="first">Список статей, основанных на определённых задачах, которые вам может понадобиться выполнить.</p>
</li>
<li><p class="first">Набор статей базы знаний, в которых подробнее рассматриваются используемые нами инструменты и рабочие процессы.</p>
</li>
</ul>
<p>Это руководство фокусируется на методе создания пакетов Ubuntu Distributed Development. Это новый способ работы с пакетами, который использует ветки распределённой системы управления версиями. В настоящее время он имеет некоторые ограничения, поэтому многие команды Ubuntu по-прежнему пользуются <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/traditional-packaging"><em>традиционными</em></a> методами создания пакетов. Чтобы узнать о различиях, смотрите страницу <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro"><em>Введение в UDD</em></a>.</p>
<div class="section" id="articles">
<h2>Статьи<a class="headerlink" href="#articles" title="Ссылка на этот заголовок">¶</a></h2>
<div class="toctree-wrapper compound">
<span id="document-ubuntu-packaging-guide/introduction-to-ubuntu-development"></span><div class="section" id="introduction-to-ubuntu-development">
<h3>Введение в разработку Ubuntu<a class="headerlink" href="#introduction-to-ubuntu-development" title="Ссылка на этот заголовок">¶</a></h3>
<p>Ubuntu состоит из тысяч различных компонентов, написанных на множестве языков программирования. Каждый компонент — библиотека, утилита или графическое приложение — доступен в виде пакета исходного кода. Пакты исходных кодов в большинстве случаев состоят из двух частей: сам исходный код и метаданные. Метаданные включают в себя зависимости пакета, информацию об авторском праве и лицензии, а также инструкции по сборке пакета. После того, как пакет исходных кодов скомпилирован, в процессе сборки мы получим двоичные пакеты, являющиеся .deb файлами, которые пользователи могут установить.</p>
<p>Каждый раз, когда выходит новая версия приложения, или когда кто-то вносит изменения в исходный код пакета, входящего в состав Ubuntu, пакет с исходным кодом должен быть загружен на сборочные компьютеры Launchpad для компиляции. Готовые бинарные пакеты затем попадают в репозиторий и его зеркала в разных странах. URL в <tt class="docutils literal"><span class="pre">/etc/apt/sources.list</span></tt> являются ссылками на репозиторий или его зеркал. Каждый день собираются образы для различных версий Ubuntu. Они могут быть использованы в различных условиях. Есть образы, которые можно записать на USB-носители или на DVD-диски, образы, которые можно использовать для сетевой загрузки и есть образы, предназначенные для установки на телефон или планшет. Ubuntu, серверная версия Ubuntu, Kubuntu и другие ветки имеют специфичный список необходимых пакетов, которые попадают в образ. Эти образы, которые затем используются для проверки установки и обеспечивают обратную связь для дальнейшего планирования выпуска.</p>
<p>Разработка Ubuntu сильно зависит от текущей фазы цикла выпуска. Мы выпускаем новую версию Ubuntu каждые шесть месяцев, что возможно только благодаря тому, что мы устанавливаем точные даты «заморозки». По достижении каждой даты заморозки ожидается, что разработчики будут вносить более редкие и менее значительные изменения. Заморозка новых функций (feature freeze) — это первая крупная дата заморозки, наступающая после прохождения первой половины цикла разработки. На этом этапе новые функции должны в основном быть реализованы. В оставшуюся часть цикла предполагается сфокусироваться на исправлении ошибок. После этого «замораживается» пользовательский интерфейс, затем документация, ядро и т.п., после чего выпускается бета-версия (beta release), которая подвергается интенсивному тестированию. После того, как выпущена бета-версия, исправляются только критические ошибки, и выпускается release candidate, который, если он не содержит серьёзных ошибок, становится в дальнейшем финальным выпуском.</p>
<img alt="./_images/cycle-items.png" src="./_images/cycle-items.png" />
<p>Тысячи пакетов исходного кода, миллиарды строк кода, сотни разработчиков требуют больше общения и планирования для поддержания высоких стандартов качества. В начале и в середине каждого цикла выпуска организуется Ubuntu Developer Summit, где разработчики и участники собираются вместе, чтобы планировать новые функции в следующих выпусках. Каждая функция обсуждается заинтересованными сторонами, и составляется спецификация, содержащая подробную информацию об исходных предположениях, реализации, внесении необходимых изменений в другие пакеты, о тестировании и так далее. Всё это делается прозрачным и открытым образом, так что вы можете поучаствовать удалённо, посмотреть видеотрансляцию, пообщаться с участниками и подписаться на спецификации, чтобы всегда быть в курсе происходящего.</p>
<p>Однако на совещании могут быть обсуждены не все изменения, так как Ubuntu зависит от изменений, вносимых в другие проекты. Поэтому участники разработки Ubuntu остаются постоянно на связи. Большинство команд или проектов используют отдельные списки рассылки, чтобы избежать большого потока не связанных с их специализацией писем. Для более непосредственной координации разработчики и добровольные участники используют Internet Relay Chat (IRC). Все обсуждения являются открытыми и публичными.</p>
<p>Ещё одним важным инструментом связи являются отчёты об ошибках. Если в пакете или части инфраструктуры обнаружена ошибка, отчёт о ней отправляется на Launchpad. В этом отчёте собрана вся информация, и при необходимости сведения о важности, статусе ошибки и лице, назначенном для её устранения, обновляются. Это делает отчёт об ошибке эффективным средством отслеживания ошибок в пакетах или проектах и оптимизации рабочей нагрузки.</p>
<p>Большая часть доступных в Ubuntu программ создана не самими разработчиками Ubuntu. Многие из программ написаны разработчиками из других проектов с открытым исходным кодом, а затем интегрированы в Ubuntu. Такие проекты принято называть «апстримом» (от англ. upstream — вверх по течению), так как их исходный код вливается в Ubuntu, где мы «просто» интегрируем его в систему. Связь с апстримом очень важна для Ubuntu. Не только Ubuntu получает программный код из апстрима, но и апстрим получает от пользователей отчёты об ошибках и патчи от Ubuntu (и других дистрибутивов).</p>
<p>Наиболее важным апстримом для Ubuntu является Debian. Debian — это дистрибутив, на котором основана Ubuntu, и именно там созданы многие инженерные решения, касающиеся инфраструктуры пакетов. По традиции, в Debian для каждого отдельного пакета всегда имеется сопровождающий (мэйнтейнер) или отдельная группа сопровождения. В Ubuntu тоже есть команды, заинтересованные в работе над подмножеством пакетов и, разумеется, каждый разработчик имеет собственную область компетенции, но участие (и права загрузки изменений) обычно доступны любому, кто продемонстрирует способность и желание работать.</p>
<p>Внести изменение в Ubuntu новому участнику не так трудно, как кажется, и это может быть весьма полезным опытом. Это позволяет не только научиться чему-то новому и увлекательному, но и поделиться своим решением проблемы с миллионами других пользователей.</p>
<p>Разработка открытого программного обеспечения происходит в распределённом мире, в котором у разработчиков могут быть различные цели и различные области интересов. Например, может быть так, что отдельный апстрим заинтересован в работе над крупным нововведением, в то время как Ubuntu, вследствие тесного расписания релизов, более заинтересована в выпуске стабильной версии, в которой лишь исправлены некоторые ошибки. Поэтому мы используем «Ubuntu Distributed Development», где работа над кодом ведётся в различных ветках, которые затем сливаются друг с другом после проверки кода и достаточного количества обсуждений.</p>
<img alt="./_images/cycle-branching.png" src="./_images/cycle-branching.png" />
<p>В приведённом выше примере имеет смысл включить в Ubuntu существующую версию проекта, сделать исправления ошибок, добавить их в апстрим для следующего выпуска проекта и включить его (если он к этому пригоден) в следующий выпуск Ubuntu. Это будет наилучшим компромиссом и ситуацией, в которой выигрывают обе стороны.</p>
<p>Чтобы исправить ошибку в Ubuntu, нужно сначала получить исходный код пакета, поработать над его исправлением, снабдить свою работу документацией, чтобы другим разработчикам и пользователям было легко понять, что именно вы сделали, а затем собрать пакет и протестировать его. После того, как вы протестировали изменённый пакет, можно предложить включить его в текущий разрабатываемый релиз Ubuntu. Разработчик с правом загрузки проверит ваш пакет и затем интегрирует его в Ubuntu.</p>
<img alt="./_images/cycle-process.png" src="./_images/cycle-process.png" />
<p>При попытке найти решение полезно проверить, известно ли о проблеме, над которой вы работаете, в апстриме и не найдено ли там уже её возможное решение. Если нет, сделайте всё возможное, чтобы решить проблему совместными усилиями.</p>
<p>Дополнительные шаги, которые вы можете предпринять, — это адаптирование вашего изменения для предыдущих поддерживаемых выпусков Ubuntu и отправление его в апстрим.</p>
<p>Наиболее важные требования для успешной разработки в Ubuntu: уметь «заставлять вещи снова работать», не бояться читать документацию и задавать вопросы, быть командным игроком и иметь некоторую склонность к работе детектива.</p>
<p>Подходящими местами для получения ответов на ваши вопросы являются <tt class="docutils literal"><span class="pre">ubuntu-motu@lists.ubuntu.com</span></tt> и <tt class="docutils literal"><span class="pre">#ubuntu-motu</span></tt> на <tt class="docutils literal"><span class="pre">irc.freenode.net</span></tt>. Там вы легко найдёте множество новых друзей и людей, разделяющих вашу страсть: делать мир лучше, улучшая открытое программное обеспечение.</p>
</div>
<span id="document-ubuntu-packaging-guide/getting-set-up"></span><div class="section" id="getting-set-up">
<h3>Подготовка<a class="headerlink" href="#getting-set-up" title="Ссылка на этот заголовок">¶</a></h3>
<p>Существует несколько вещей, которые нужно сделать перед началом разработки в Ubuntu. Эта статья поможет вам подготовить компьютер к работе с пакетами и отправке ваших пакетов на платформу хостинга Ubuntu — Launchpad. Вот что здесь описано:</p>
<ul class="simple">
<li><p class="first">Установка программ для работы с пакетами. Они включают в себя:</p>
<ul>
<li><p class="first">специфичные для Ubuntu утилиты создания пакетов</p>
</li>
<li><p class="first">криптографическую программу, которая позволит другим удостовериться, что работа выполнена именно вами</p>
</li>
<li><p class="first">дополнительные программы шифрования, обеспечивающие безопасную передачу файлов</p>
</li>
</ul>
</li>
<li><p class="first">Создание и настройка учётной записи на Launchpad</p>
</li>
<li><p class="first">Настройка вашей среды разработки для облегчения локальной сборки пакетов, взаимодействия с другими разработчиками и отправки ваших изменений на Launchpad.</p>
</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Примечание</p>
<p>Рекомендуется выполнять работу по созданию пакетов в текущей разрабатываемой версии Ubuntu. Это позволит вам тестировать изменения в той же среде, в которую они в действительности затем будут внесены.</p>
<p class="last">Не беспокойтесь, вы можете воспользоваться <a class="reference external" href="https://wiki.ubuntu.com/QATeam/Testdrive">Testdrive</a> или <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/chroots"><em>chroots</em></a> для безопасного использования разрабатываемой версии (релиза)</p>
</div>
<div class="section" id="install-basic-packaging-software">
<h4>Установка базового программного обеспечения для создания пакетов<a class="headerlink" href="#install-basic-packaging-software" title="Ссылка на этот заголовок">¶</a></h4>
<p>Существует множество инструментов, которые могут значительно упростить жизнь разработчику Ubuntu. Вы познакомитесь с ними далее в этом руководстве. Чтобы установить большинство инструментов, нужно выполнить следующую команду:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo apt-get install gnupg pbuilder ubuntu-dev-tools bzr-builddeb apt-file
</pre></div>
</div>
<p>Примечание: Начиная с Ubuntu 11.10 «Oneiric Ocelot» (или если включен репозиторий Backports в текущем поддерживаемом выпуске), следующая команда устанавливает всё вышеупомянутое и другие инструменты, часто используемые в разработке Ubuntu:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo apt-get install packaging-dev
</pre></div>
</div>
<p>Эта команда установит следующие программы:</p>
<ul class="simple">
<li><p class="first"><tt class="docutils literal"><span class="pre">gnupg</span></tt> – <a class="reference external" href="https://www.gnupg.org/">GNU Privacy Guard</a> содержит инструменты, которые понадобятся для создания криптографического ключа, с помощью которого вы будете подписывать файлы, которые хотите загрузить на Launchpad</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">pbuilder</span></tt> – инструмент для создания готовых к дальнейшему распространению сборок пакетов в чистой и изолированной среде.</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt> (и его непосредственная зависимость <tt class="docutils literal"><span class="pre">devscripts</span></tt>) – набор инструментов, упрощающих многие задачи по созданию пакетов.</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> (и его зависимость – <tt class="docutils literal"><span class="pre">bzr</span></tt>) – управление распределёнными версиями с помощью Bazaar (новый способ работы с пакетами для Ubuntu), упрощающий совместную работу многих людей над одним и тем же кодом и позволяющий с лёгкостью объединять результаты их труда друг с другом.</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">apt-file</span></tt> предоставляет простой способ найти двоичный пакет, содержащий заданный файл.</p>
</li>
</ul>
<div class="section" id="create-your-gpg-key">
<h5>Создание ключа GPG<a class="headerlink" href="#create-your-gpg-key" title="Ссылка на этот заголовок">¶</a></h5>
<p>GPG — аббревиатура для <a class="reference external" href="https://www.gnupg.org/">GNU Privacy Guard</a>, реализующего стандарт OpenPGP, который позволяет подписывать и шифровать сообщения и файлы. Это полезно в ряде ситуаций. В нашем случае важно, что вы можете использовать свой ключ для подписывания файлов, чтобы можно было удостовериться, что именно вы с ними работали. Если вы загрузите пакет исходного кода на Launchpad, он будет принят только в том случае, если можно точно определить, кто именно отправил пакет.</p>
<p>Чтобы сгенерировать новый ключ GPG, наберите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --gen-key
</pre></div>
</div>
<p>GPG сначала спросит, какой тип ключа вы хотите создать. Выбор по умолчанию (RSA и DSA) вполне подойдёт. Далее он попросит указать размер ключа. Размер по умолчанию (в настоящее время 2048) подойдёт, но 4096 надёжнее. Далее, программа спросит, хотите ли вы, чтобы срок действия ключа истёк через какое-то время. Безопаснее ответить “0”, что означает, что срок действия не истечёт никогда. Последний вопрос будет о вашем имени и адресе электронной почты. Просто выберите адрес, которым вы пользуетесь при разработке Ubuntu, дополнительные адреса можно будет добавить позже. Добавлять комментарий не обязательно. После этого нужно указать надёжную парольную фразу (парольная фраза — это просто пароль, в котором допускается использовать пробелы).</p>
<p>Теперь GPG создаст для вас ключ, что может занять некоторое время. Для его создания понадобятся случайные байты, поэтому будет просто замечательно, если вы зададите своей системе какую-нибудь работу. Подвигайте указатель мыши, наберите несколько абзацев случайного текста, загрузите любую веб-страницу.</p>
<p>Когда процесс будет завершён, вы получите сообщение наподобие следующего:</p>
<div class="highlight-python"><div class="highlight"><pre>pub 4096R/43CDE61D 2010-12-06
Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D
uid Daniel Holbach <dh@mailempfang.de>
sub 4096R/51FBE68C 2010-12-06
</pre></div>
</div>
<p>В данном случае, <tt class="docutils literal"><span class="pre">43CDE61D</span></tt> — это идентификатор ключа (<em>key ID</em>).</p>
<p>Затем нужно загрузить открытую (public) часть вашего ключа на сервер ключей, чтобы все могли идентифицировать сообщения и файлы, как отправленные вами. Для этого введите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --send-keys --keyserver keyserver.ubuntu.com <KEY ID>
</pre></div>
</div>
<p>Эта команда отправит ваш ключ на сервер ключей Ubuntu, а сеть серверов ключей автоматически синхронизирует ключ между собой. После того, как эта синхронизация завершится, ваш подписанный открытый ключ будет готов для удостоверения сделанного вами вклада во всём мире.</p>
</div>
<div class="section" id="create-your-ssh-key">
<h5>Создание ключа SSH<a class="headerlink" href="#create-your-ssh-key" title="Ссылка на этот заголовок">¶</a></h5>
<p><a class="reference external" href="http://www.openssh.com/">SSH</a> или <em>Secure Shell</em> — это протокол, позволяющий безопасно обмениваться данными по сети. Обычной практикой является использование SSH для доступа и открытия командной оболочки на другом компьютере и для безопасной пересылки файлов. В наших целях мы в основном будем использовать SSH для безопасной отправки пакетов исходного кода на Launchpad.</p>
<p>Чтобы сгенерировать ключ SSH, введите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ ssh-keygen -t rsa
</pre></div>
</div>
<p>Имя файла по умолчанию обычно вполне годится, так что можете оставить его как есть. Для целей безопасности настоятельно рекомендуется задать парольную фразу.</p>
</div>
<div class="section" id="set-up-pbuilder">
<h5>Настройка pbuilder<a class="headerlink" href="#set-up-pbuilder" title="Ссылка на этот заголовок">¶</a></h5>
<p><tt class="docutils literal"><span class="pre">pbuilder</span></tt> позволяет локально собирать пакеты на вашем компьютере. Он служит нескольким целям:</p>
<ul class="simple">
<li><p class="first">Сборка будет выполнена в минимальной и чистой среде. Это даст возможность убедиться, что сборку удастся успешно воспроизвести и на других компьютерах, но при этом поможет избежать изменений в вашей локальной системе</p>
</li>
<li><p class="first">Отпадает необходимость в локальной установке всех <em>сборочных зависимостей</em></p>
</li>
<li><p class="first">Можно настроить несколько экземпляров для различных выпусков Ubuntu и Debian</p>
</li>
</ul>
<p>Настроить <tt class="docutils literal"><span class="pre">pbuilder</span></tt> очень просто. Наберите</p>
<div class="highlight-python"><div class="highlight"><pre>$ pbuilder-dist <release> create
</pre></div>
</div>
<p>где <release> — это, например <cite>raring</cite>, <cite>saucy</cite>, <cite>trusty</cite> или, в случае Debian, <cite>sid</cite>. Выполнение команды займёт некоторое время, поскольку будут загружены все пакеты, необходимые для “минимальной установки”. Впрочем, при этом используется кэширование.</p>
</div>
</div>
<div class="section" id="get-set-up-to-work-with-launchpad">
<h4>Подготовка к работе с Launchpad<a class="headerlink" href="#get-set-up-to-work-with-launchpad" title="Ссылка на этот заголовок">¶</a></h4>
<p>После того, как базовая локальная конфигурация создана, следующим шагом будет настройка системы для работы с Launchpad. В этом разделе мы сфокусируемся на следующих вопросах:</p>
<blockquote>
<div><ul class="simple">
<li><p class="first">Что такое Launchpad и как создать учётную запись на Launchpad</p>
</li>
<li><p class="first">Загрузка ваших ключей GPG и SSH на Launchpad</p>
</li>
<li><p class="first">Настройка Bazaar для работы с Launchpad</p>
</li>
<li><p class="first">Настройка Bash для работы с Bazaar</p>
</li>
</ul>
</div></blockquote>
<div class="section" id="about-launchpad">
<h5>Сведения о Launchpad<a class="headerlink" href="#about-launchpad" title="Ссылка на этот заголовок">¶</a></h5>
<p>Launchpad является центральным элементом инфраструктуры, используемой нами в Ubuntu. Он хранит не только наши пакеты и наш код, но и такие вещи, как переводы, отчёты об ошибках, а также информацию о людях, работающих над Ubuntu и их принадлежности к различным командам. Вы можете также использовать Launchpad, чтобы опубликовать предлагаемые вами исправления и попросить других разработчиков Ubuntu проверить и поддержать их.</p>
<p>Вам понадобится зарегистрироваться на Launchpad и предоставить некоторое минимальное количество информации о себе. Это позволит вам скачивать или отправлять исходный код, отправлять отчёты об ошибках и т.п.</p>
<p>Кроме хостинга Ubuntu, Launchpad может предоставлять место для любого свободного программного проекта. Дополнительную информацию смотрите на <a class="reference external" href="https://help.launchpad.net/">Справочных вики-страницах Launchpad</a>.</p>
</div>
<div class="section" id="get-a-launchpad-account">
<h5>Создание учётной записи на Launchpad<a class="headerlink" href="#get-a-launchpad-account" title="Ссылка на этот заголовок">¶</a></h5>
<p>Если у вас ещё нет учётной записи на Launchpad, вы легко можете <a class="reference external" href="https://launchpad.net/+login">создать её</a>. Если учётная запись есть, но вы не помните свой Launchpad ID, его можно узнать, зайдя на <a class="reference external" href="https://launchpad.net/~">https://launchpad.net/~</a> и взглянув на часть после <cite>~</cite> в URL.</p>
<p>При регистрации на Launchpad вас попросят выбрать отображаемое имя. Рекомендуется указать здесь ваше настоящее имя, чтобы ваши коллеги - разработчики Ubuntu могли лучше с вами познакомиться.</p>
<p>При регистрации новой учётной записи Launchpad отправит вам письмо со ссылкой, которую нужно открыть в веб-браузере, чтобы подтвердить указанный вами адрес электронной почты. Если вы не получили письмо, проверьте папку нежелательной почты (спама).</p>
<p><a class="reference external" href="https://help.launchpad.net/YourAccount/NewAccount">Справочная страница новой учётной записи</a> на Launchpad содержит дополнительную информацию о процессе и дополнительных настройках, которые можно сделать.</p>
</div>
<div class="section" id="upload-your-gpg-key-to-launchpad">
<h5>Загрузка вашего ключа GPG на Launchpad<a class="headerlink" href="#upload-your-gpg-key-to-launchpad" title="Ссылка на этот заголовок">¶</a></h5>
<p>Сначала нужно получить отпечаток и идентификатор ключа.</p>
<p>Чтобы узнать свой отпечаток ключа GPG (fingerprint), наберите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --fingerprint email@address.com
</pre></div>
</div>
<p>и вы увидите что-то наподобие:</p>
<div class="highlight-python"><div class="highlight"><pre>pub 4096R/43CDE61D 2010-12-06
Key fingerprint = 5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D
uid Daniel Holbach <dh@mailempfang.de>
sub 4096R/51FBE68C 2010-12-06
</pre></div>
</div>
<p>Затем выполните эту команду для отправки вашего ключа на сервер ключей Ubuntu:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --keyserver keyserver.ubuntu.com --send-keys 43CDE61D
</pre></div>
</div>
<p>где <tt class="docutils literal"><span class="pre">43CDE61D</span></tt> следует заменить на ваш идентификатор ключа (он в первой строке вывода предыдущей команды). Теперь можно импортировать свой ключ на Launchpad.</p>
<p>Зайдите на <a class="reference external" href="https://launchpad.net/~/+editpgpkeys">https://launchpad.net/~/+editpgpkeys</a> и скопируйте данные из строки «Key fingerprint» в текстовое поле. В приведённом выше примере это будет <tt class="docutils literal"><span class="pre">5C28</span> <span class="pre">0144</span> <span class="pre">FB08</span> <span class="pre">91C0</span> <span class="pre">2CF3</span> <span class="pre">37AC</span> <span class="pre">6F0B</span> <span class="pre">F90F</span> <span class="pre">43CD</span> <span class="pre">E61D</span></tt>. Затем щёлкните «Import Key».</p>
<p>Launchpad воспользуется отпечатком ключа для проверки наличия вашего ключа на сервере ключей Ubuntu и, в случае успеха, отправит вам зашифрованное сообщение электронной почты, предлагающее подтвердить импорт ключа. Проверьте свою почту и прочтите письмо, полученное с Launchpad. <cite>Если ваш клиент электронной почты поддерживает шифрование OpenPGP, он предложит ввести пароль, который вы выбрали при создании ключа GPG. Введите пароль, затем щёлкните на ссылке, чтобы подтвердить, что этот ключ принадлежит вам.</cite></p>
<p>Launchpad шифрует почту, используя ваш публичный ключ, так что вы сможете убедиться, что ключ ваш. Если вы пользуетесь почтовым клиентом Thunderbird, использующимся в Ubuntu по умолчанию, для дешифровки сообщения можете установить <a class="reference external" href="https://apps.ubuntu.com/cat/applications/enigmail/">дополнение Enigmail</a>. Если ваша почтовая программа не поддерживает шифрование OpenPGP, скопируйте зашифрованное содержимое письма в буфер обмена, наберите в терминале <tt class="docutils literal"><span class="pre">gpg</span></tt> и вставьте содержимое письма в окно терминала.</p>
<p>Вернувшись на сайт Launchpad, воспользуйтесь кнопкой «Confirm», чтобы Launchpad завершил импорт вашего ключа OpenPGP.</p>
<p>Дополнительную информацию можно найти на <a class="reference external" href="https://help.launchpad.net/YourAccount/ImportingYourPGPKey">https://help.launchpad.net/YourAccount/ImportingYourPGPKey</a></p>
</div>
<div class="section" id="upload-your-ssh-key-to-launchpad">
<h5>Загрузка вашего ключа SSH на Launchpad<a class="headerlink" href="#upload-your-ssh-key-to-launchpad" title="Ссылка на этот заголовок">¶</a></h5>
<p>Откройте в веб-браузере <a class="reference external" href="https://launchpad.net/~/+editsshkeys">https://launchpad.net/~/+editsshkeys</a>, а в текстовом редакторе файл <tt class="docutils literal"><span class="pre">~/.ssh/id_rsa.pub</span></tt>. Это открытая часть вашего ключа SSH, поэтому можно без опасений предоставить к ней общий доступ на Launchpad. Скопируйте содержимое файла и вставьте его в текстовое поле на веб-странице с меткой «Add an SSH key». Затем щёлкните «Import Public Key».</p>
<p>Для дополнительной информации об этом процессе посетите страницу о <a class="reference external" href="https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair">создании ключевой пары SSH</a> на Launchpad.</p>
</div>
<div class="section" id="configure-bazaar">
<h5>Настройка Bazaar<a class="headerlink" href="#configure-bazaar" title="Ссылка на этот заголовок">¶</a></h5>
<p>Bazaar — это инструмент, который мы используем для хранения изменений в коде логичным и предсказуемым способом, а также обмена предлагаемыми изменениями и их слияния, даже в том случае, если разработка ведётся параллельно несколькими людьми. Он используется в новом методе работы с пакетами Ubuntu — Ubuntu Distributed Development.</p>
<p>Что сообщить Bazaar о том, кто вы, просто наберите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr whoami "Bob Dobbs <subgenius@example.com>"
$ bzr launchpad-login subgenius
</pre></div>
</div>
<p><cite>whoami</cite> сообщит Bazaar, какое имя и адрес электронной почты он должен использовать для ваших коммитов. С помощью <cite>launchpad-login</cite> вы указываете свой Launchpad ID. Это код, который идентифицирует вашу учётную запись на Launchpad.</p>
<p>Примечание: если вы не помните свой идентификатор, перейдите на <a class="reference external" href="https://launchpad.net/~">https://launchpad.net/~</a> и посмотрите, куда вас перенаправляет эта страница. Часть URL после символа «~» — это и есть ваш Launchpad ID.</p>
</div>
<div class="section" id="configure-your-shell">
<h5>Настройка командной оболочки<a class="headerlink" href="#configure-your-shell" title="Ссылка на этот заголовок">¶</a></h5>
<p>Как и Bazaar, инструментам создания пакетов Debian/Ubuntu понадобится некоторая информация о вас. Просто откройте <cite>~/.bashrc</cite> в текстовом редакторе и добавьте внизу что-то вроде этого:</p>
<div class="highlight-python"><div class="highlight"><pre>export DEBFULLNAME="Bob Dobbs"
export DEBEMAIL="subgenius@example.com"
</pre></div>
</div>
<p>Затем сохраните файл и перезапустите терминал или наберите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ source ~/.bashrc
</pre></div>
</div>
<p>(Если вы не пользуетесь стандартной командной оболочкой <cite>bash</cite>, отредактируйте конфигурационный файл той оболочки, которую вы предпочитаете использовать.)</p>
</div>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-intro"></span><div class="section" id="ubuntu-distributed-development-introduction">
<h3>Распределенная разработка Ubuntu — введение<a class="headerlink" href="#ubuntu-distributed-development-introduction" title="Ссылка на этот заголовок">¶</a></h3>
<p>Это руководство фокусируется на работе с пакетами с использованием метода <em>Ubuntu Distributed Development</em> (UDD).</p>
<p><em>Ubuntu Distributed Development</em> (UDD) — это новая технология разработки пакетов Ubuntu, использующая инструменты, процессы и последовательности действий, характерные для типичной схемы разработки программ, основанной на распределённой системе управления версиями (DVCS). DVCS, используемая в UDD — это <a class="reference internal" href="#bazaar">Bazaar</a>.</p>
<div class="section" id="traditional-packaging-limitations">
<h4>Ограничения традиционных методов создания пакетов<a class="headerlink" href="#traditional-packaging-limitations" title="Ссылка на этот заголовок">¶</a></h4>
<p>Традиционно пакеты Ubuntu хранятся в архивных tar-файлах. Традиционный пакет исходного кода состоит из tar-файла с исходным кодом из апстрима, “debian” tar-файла (или сжатого diff-файл для более старых пакетов), содержащего набор входных файлов для создания пакета, и файла .dsc с метаданными. Чтобы посмотреть на традиционный пакет, выполните команду:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-get source kdetoys
</pre></div>
</div>
<p>Она загрузит исходники из апстрима <tt class="docutils literal"><span class="pre">kdetoys_4.6.5.orig.tar.bz2</span></tt>, набор входных файлов <tt class="docutils literal"><span class="pre">kdetoys_4.6.5-0ubuntu1.debian.tar.gz</span></tt> и метаданные <tt class="docutils literal"><span class="pre">kdetoys_4.6.5-0ubuntu1~ppa1.dsc</span></tt>. Если у вас установлен dpkg-dev, она извлечёт их содержимое и предоставит вам пакет исходного кода.</p>
<p>Традиционные методы создания пакетов отредактируют и загрузят эти файлы. Однако это дает ограниченные возможности для сотрудничества с другими разработчиками, изменения должны передаваться через файлы diff без центрального способ отслеживания них, плюс два разработчики не могут вносить изменения одновременно. Поэтому большинство команд разработчиков перешли от традиционного метода создания пакетов к системе контроля версий. Это позволяет нескольким разработчикам работать над пакетом сообща. Однако нет прямой связи между системы контроля версий и архивом пакетов, поэтому их необходимо будет вручную синхронизировать. Поскольку каждая команда работает в собственной системе контроля версий перспективный разработчик должен сначала разобраться где, что и как получить пакет, прежде чем они смогут работать с этим пакетом.</p>
</div>
<div class="section" id="ubuntu-distributed-development">
<h4>Распределенная разработка Ubuntu<a class="headerlink" href="#ubuntu-distributed-development" title="Ссылка на этот заголовок">¶</a></h4>
<p>С Ubuntu Distributed Development все пакеты в архиве Ubuntu (и Debian) автоматически импортируются в ветки Bazaar на нашем сайте хостинга кода Launchpad. Изменения можно вносить напрямую в эти ветки шагами увеличения любым пользователем, у которого есть доступ. Изменения также можно вносить в раздвоенные ветки и соединять из обратно при помощи Предложений и Слиянии (Merge Proposals), когда они станут достаточно большими для рассмотрения, либо если созданы кем-либо без прямого доступа.</p>
<p>UDD ветки все находятся в стандартном местоположении, поэтому отладка будет легкой:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:kdetoys
</pre></div>
</div>
<p>История объединений включает две отдельные ветки, одну для источника апстрима и другую, которая добавит директорию пакета <tt class="docutils literal"><span class="pre">debian/</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd kdetoys
$ bzr qlog
</pre></div>
</div>
<p>(Эта команда использует в качестве графического интерфейса <em>qbzr</em>. Для вывода в консоль, запустите <tt class="docutils literal"><span class="pre">log</span></tt> вместо <tt class="docutils literal"><span class="pre">qlog</span></tt>.)</p>
<img alt="./_images/kdetoys-udd-branch.png" src="./_images/kdetoys-udd-branch.png" />
<p>UDD ветка <em>kdetoys</em> помечает полный пакет для каждой версии, загруженной в Ubuntu серыми кругами и версии источника апстрима - зелеными. Версии помечаются либо версиями Ubuntu (например, <tt class="docutils literal"><span class="pre">4:4.2.29-0ubuntu1</span></tt>) или для веток апстрима - версией апстрима (<tt class="docutils literal"><span class="pre">upstream-4.2.96</span></tt>).</p>
<p>Многие пакеты Ubuntu основаны на пакетах в Debian, UDD также импортирует и пакет Debian в наши ветки. В ветке <em>kdetoys</em> выше версии Debian из <em>unstable</em> после объединения помечены синими кружочками, в то время как из <em>Debian experimental</em> после объединения помечены желтыми. Релизы Debian помечены номерами своих версий, например, <tt class="docutils literal"><span class="pre">4:4.2.2-1</span></tt>.</p>
<p>Таким образом из UDD-ветки вы можете увидеть полную историю изменений пакета и сравнить любые две версии. Например, чтобы увидеть различия между версией 4.2.2 в Debian и 4.2.2 в Ubuntu, используйте:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr qdiff -r tag:4:4.2.2-1..tag:4:4.2.2-1ubuntu1
</pre></div>
</div>
<p>(Эта команда использует графический интерфейс <em>qbzr</em>. Запустите <tt class="docutils literal"><span class="pre">diff</span></tt> вместо <tt class="docutils literal"><span class="pre">qdiff</span></tt> для вывода в консоль.)</p>
<img alt="./_images/kdetoys-udd-diff.png" src="./_images/kdetoys-udd-diff.png" />
<p>Здесь мы можем ясно увидеть, что было изменено в Ubuntu по сравнению с Debian-версией. Очень удобно.</p>
</div>
<div class="section" id="bazaar">
<h4>Bazaar<a class="headerlink" href="#bazaar" title="Ссылка на этот заголовок">¶</a></h4>
<p>Ветки UDD используют Bazaar — распределённую систему управления версиями, которая проста в использовании для тех, кто знаком с такими популярными системами, как Subversion, и в то же время предоставляет всю мощь Git.</p>
<p>Чтобы сделать пакет с UDD Вам нужно знать основы использования Bazaar для управления файлами. Для получения базовых навыков работы с Bazaar смотрите <a class="reference external" href="http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html">Пятиминутное обучение Bazaar</a> и <a class="reference external" href="http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html">Руководство по использованию Bazaar</a>.</p>
</div>
<div class="section" id="limitations-of-udd">
<h4>Ограничения UDD<a class="headerlink" href="#limitations-of-udd" title="Ссылка на этот заголовок">¶</a></h4>
<p>Ubuntu Distributed Development — новый метод работы с пакетами Ubuntu. В настоящее время он имеет некоторые существенных ограничения:</p>
<ul class="simple">
<li><p class="first">Создание полной ветки с историей может отнять много времени и сетевых ресурсов. Возможно Вам быстрее будет сделать легкую отладку <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">checkout</span> <span class="pre">--lightweight</span> <span class="pre">ubuntu:kdetoys</span></tt>, но тогда потребуется сетевой доступ для любых дальнейших операций bzr.</p>
</li>
<li><p class="first">Работа над патчами очень кропотливая. Патчи можно рассматривать как разветвленную переработку системы управления, таки образом мы получаем RCS поверх RCS.</p>
</li>
<li><p class="first">Нет способа создавать билды напрямую из веток. Нужно создавать исходный пакет и загружать его.</p>
</li>
<li><p class="first">Некоторые пакеты не были успешно импортированы в ветки UDD. Последние версии Bazaar автоматически будут уведомлять вас в случае возникновения подобной ситуации. Перед началом работы с веткой Вы можете вручную поставить отметку <a class="reference external" href="http://package-import.ubuntu.com/status">status of the package importer</a>.</p>
</li>
</ul>
<p>Над всем вышеперечисленным сейчас ведется работа и ожидается, что UDD вскоре станет основным способом работы над пакетами Ubuntu. Тем не менее, сейчас большинство команд Ubuntu еще не работали с ветками UDD. Но так как UDD ветки являются тем же самым, как и пакеты в архиве, любой команде не составит труда с ними работать.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/fixing-a-bug"></span><div class="section" id="fixing-a-bug-in-ubuntu">
<h3>Исправление ошибок в Ubuntu<a class="headerlink" href="#fixing-a-bug-in-ubuntu" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="introduction">
<h4>Вступление<a class="headerlink" href="#introduction" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если вы следовали инструкциям по <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>подготовке к разработке Ubuntu</em></a>, всё должно быть уже готово к работе.</p>
<img alt="./_images/fixing-a-bug.png" src="./_images/fixing-a-bug.png" />
<p>Как вы можете видеть на картинке выше, в процессе исправления ошибок в Ubuntu нет никаких сюрпризов: вы находите проблему, получаете код, исправляете его, тестируете, отправляете на Launchpad и просите, чтобы его проверили и объединили с основным кодом. В этом руководстве мы пройдем через все необходимые шаги, один за другим.</p>
</div>
<div class="section" id="finding-the-problem">
<h4>Поиск проблемы<a class="headerlink" href="#finding-the-problem" title="Ссылка на этот заголовок">¶</a></h4>
<p>Существуют различные способы найти, над чем можно поработать. Это может быть ошибка, которую вы обнаружили сами (что даёт вам отличную возможность проверить своё исправление) или проблема, которую вы заметили где-то ещё, например в отчёте об ошибке.</p>
<p><a class="reference external" href="http://harvest.ubuntu.com/">Harvest</a> хранит различные списки TODO, касающиеся разработки Ubuntu. Это списки ошибок, которые были уже исправлены в апстриме или в Debian, списки небольших ошибок (мы называем их «bitesize») и так далее. Просмотрите их и найдите ошибку, исправлением которой вы хотите заняться.</p>
</div>
<div class="section" id="figuring-out-what-to-fix">
<span id="what-to-fix"></span><h4>Выяснение того, что нужно исправить<a class="headerlink" href="#figuring-out-what-to-fix" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если вы не знаете, в каком пакете исходного кода содержится ошибка, но знаете путь к этому приложению в вашей системе, то вы сможете найти пакет исходного кода, над которым требуется поработать.</p>
<p>Предположим, вы обнаружили ошибку в Tomboy, приложении для создания заметок на рабочем столе. Приложение Tomboy можно запустить, выполнив <tt class="docutils literal"><span class="pre">/usr/bin/tomboy</span></tt> в командной строке. Чтобы найти двоичный пакет, содержащий это приложение, используйте следующую команду:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-file find /usr/bin/tomboy
</pre></div>
</div>
<p>Команда выведет следующую информацию:</p>
<div class="highlight-python"><div class="highlight"><pre>tomboy: /usr/bin/tomboy
</pre></div>
</div>
<p>Обратите внимание на то, что часть, предшествующая двоеточию, является именем двоичного пакета. Часто бывает так, что у пакета исходного кода и двоичного пакета различные имена. Чаще всего это происходит, когда один пакет исходного кода используется, чтобы создать несколько различных двоичных пакетов. Чтобы найти исходный пакет для определенного двоичного пакета, введите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-cache showsrc tomboy | grep ^Package:
Package: tomboy
$ apt-cache showsrc python-vigra | grep ^Package:
Package: libvigraimpex
</pre></div>
</div>
<p>Команда <tt class="docutils literal"><span class="pre">apt-cache</span></tt> установлена в Ubuntu по умолчанию.</p>
</div>
<div class="section" id="getting-the-code">
<h4>Получение кода<a class="headerlink" href="#getting-the-code" title="Ссылка на этот заголовок">¶</a></h4>
<p>Когда вы знаете, над каким пакетом исходного кода работать, вы можете загрузить копию этого пакета, и заняться отладкой. При распределённой разработке Ubuntu это делается при помощи <a class="reference internal" href="index.html#branching"><em>клонирования bzr-репозитория</em></a> этого пакета. Launchpad поддерживает Bazaar-ветки для всех пакетов в Ubuntu.</p>
<p>Как только вы получили локальную копию исходного кода, вы можете исследовать ошибку, исправить её, и отправить своё исправление на Launchpad, в виде Bazaar-ветки. Как только вы станете достаточно уверены в своём исправлении, вы можете отправить <a class="reference internal" href="index.html#merge-proposal"><em>заявку на слияние</em></a>, то есть попросить других разработчиков просмотреть и одобрить ваше изменение. В случае согласия с вашими изменениями они загрузят ваши изменения в репозиторий. От вашего изменения получать пользу все — в том числе и вы, чьё имя будет стоять в списке изменений. Вы теперь на пути становления разработчиком Ubuntu!</p>
<p>Мы опишем специфику загрузки кода, отправки изменений, и создания заявки на просмотр в следующимх разделах.</p>
</div>
<div class="section" id="work-on-a-fix">
<span id="working-on-a-fix"></span><h4>Исправление ошибки<a class="headerlink" href="#work-on-a-fix" title="Ссылка на этот заголовок">¶</a></h4>
<p>Есть целые книги о нахождении ошибок, их исправлении, тестировании и так далее. Если вы новичок в программировании, попробуйте исправлять лёгкие ошибки, такие как опечатки. Пытайтесь делать ваши изменения минимальными и чётко документировать ваши изменения и предположения.</p>
<p>Перед тем, как работать над ошибкой, убедитесь, что она не исправлена уже кем-то другим, и никто не занимается в данный момент её исправлением. Не помешает проверить следующие источники:</p>
<ul class="simple">
<li><p class="first">Система отслеживания ошибок апстрима (и Debian) — открытые и закрытые ошибки,</p>
</li>
<li><p class="first">История версий в апстриме (или в новой версии) может содержать сведения об исправлении ошибки,</p>
</li>
<li><p class="first">отчёты об ошибках и новые версии пакетов в Debian и других дистрибутивах.</p>
</li>
</ul>
<p>Теперь можно создать патч, содержащий исправление ошибки. Команда <tt class="docutils literal"><span class="pre">edit-patch</span></tt> — самый простой способ добавить патч к пакету. Выполните:</p>
<div class="highlight-python"><div class="highlight"><pre>$ edit-patch 99-new-patch
</pre></div>
</div>
<p>Эта команда скопирует файлы, необходимые для сборки пакета, во временную директорию. Вы можете изменять эти файлы в текстовом редакторе или применять патчи из upstream, например:</p>
<div class="highlight-python"><div class="highlight"><pre>$ patch -p1 < ../bugfix.patch
</pre></div>
</div>
<p>После редактирования файла наберите <tt class="docutils literal"><span class="pre">exit</span></tt> или нажмите <tt class="docutils literal"><span class="pre">control-d</span></tt>, чтобы выйти из временной командной оболочки. Новый патч будет добавлен в <tt class="docutils literal"><span class="pre">debian/patches</span></tt>.</p>
</div>
<div class="section" id="testing-the-fix">
<h4>Тестирование исправления<a class="headerlink" href="#testing-the-fix" title="Ссылка на этот заголовок">¶</a></h4>
<p>Чтобы собрать тестовый пакет с вашими изменениями, выполните следующие команды:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -- -S -us -uc
$ pbuilder-dist <release> build ../<package>_<version>.dsc
</pre></div>
</div>
<p>Это создаст пакет исходного кода из содержимого ветки (<tt class="docutils literal"><span class="pre">-us</span> <span class="pre">-uc</span></tt> просто позволяет пропустить этап подписывания пакета исходного кода), а <tt class="docutils literal"><span class="pre">pbuilder-dist</span></tt> соберёт пакет из исходного кода для любого выбранного вами <tt class="docutils literal"><span class="pre">релиза</span></tt>.</p>
<p>После успешного завершения сборки установите пакет из <tt class="docutils literal"><span class="pre">~/pbuilder/<release>_result/</span></tt> (с помощью <tt class="docutils literal"><span class="pre">sudo</span> <span class="pre">dpkg</span> <span class="pre">-i</span> <span class="pre"><пакет>_<версия>.deb</span></tt>). Затем проверьте, удалось ли устранить ошибку.</p>
<div class="section" id="documenting-the-fix">
<h5>Документирование исправления<a class="headerlink" href="#documenting-the-fix" title="Ссылка на этот заголовок">¶</a></h5>
<p>Очень важно документировать свои изменения в достаточной степени, чтобы разработчикам впоследствии не пришлось гадать, какими были основания и предпосылки сделанных вами изменений. Каждый пакет исходного кода Debian и Ubuntu включает в себя файл <tt class="docutils literal"><span class="pre">debian/changelog</span></tt>, в котором отслеживаются вносимые в пакет изменения.</p>
<p>Самый простой способ обновить его — это выполнить:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dch -i
</pre></div>
</div>
<p>Эта команда добавит в файл шаблон записи и запустит редактор, в котором вы сможете добавить недостающую информацию. Вот пример этой записи:</p>
<div class="highlight-python"><div class="highlight"><pre>specialpackage (1.2-3ubuntu4) trusty; urgency=low
* debian/control: updated description to include frobnicator (LP: #123456)
-- Emma Adams <emma.adams@isp.com> Sat, 17 Jul 2010 02:53:39 +0200
</pre></div>
</div>
<p>Команда <tt class="docutils literal"><span class="pre">dch</span></tt> должна заполнить первую и последнюю строку этой записи в файле changelog. Первая строка содержит имя пакета исходного кода, номер его версии, в какой релиз Ubuntu он загружен, срочность (почти всегда низкая — ‘low’). Последняя строка всегда содержит имя, адрес электронной почты и метку времени изменения (в формате <span class="target" id="index-2"></span><a class="rfc reference external" href="http://tools.ietf.org/html/rfc5322.html"><strong>RFC 5322</strong></a>).</p>
<p>Теперь давайте сфокусируемся на том, что должно содержаться в самой записи файла changelog. Очень важно задокументировать:</p>
<blockquote>
<div><ol class="arabic simple">
<li><p class="first">где сделано изменение</p>
</li>
<li><p class="first">что было изменено</p>
</li>
<li><p class="first">где происходило обсуждение этого изменения</p>
</li>
</ol>
</div></blockquote>
<p>В нашем (довольно редком) примере последнему пункту соответствует <tt class="docutils literal"><span class="pre">(LP:</span> <span class="pre">#123456)</span></tt>, то есть сслыка на ошибку на Launchpad с номером 123456. Отчёты об ошибках, темы списков рассылки или спецификации обычно являются хорошими источниками информации для обоснования изменений. В качестве дополнительного приза, если вы используете нотацию <tt class="docutils literal"><span class="pre">LP:</span> <span class="pre">#<номер></span></tt> для ошибок на Launchpad, то ошибка автоматически получит статус закрытой при отправке пакета в Ubuntu.</p>
</div>
<div class="section" id="committing-the-fix">
<h5>Закрепление изменения<a class="headerlink" href="#committing-the-fix" title="Ссылка на этот заголовок">¶</a></h5>
<p>Написав и сохранив запись в changelog, мы можем просто запустить:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">debcommit</span>
</pre></div>
</div>
<p>и изменение будет залито (локально) с вашей записью changelog в качестве сообщения коммита.</p>
<p>Для Launchpad-репозитория, в который отправлять ваши изменения, используйте cледующее имя:</p>
<div class="highlight-python"><div class="highlight"><pre>lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>
</pre></div>
</div>
<p>Это может быть, например:</p>
<div class="highlight-python"><div class="highlight"><pre>lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
</pre></div>
</div>
<p>Так что, если вы просто выполните:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr push lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
bzr lp-propose
</pre></div>
</div>
<p>всё должно быть готово. Команда push выполнит отправку на Launchpad, а вторая команда откроет страницу удалённой ветки на Launchpad в вашем браузере. Найдите там ссылку «(+) Propose for merging» и щёлкните на ней, чтобы кто-нибудь проверил изменение и включил его в Ubuntu.</p>
<p>Наша статья о <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-sponsorship"><em>поиске поручительства</em></a> предоставляет дополнительные подробности о получении обратной связи для предложенных вами изменений.</p>
<p>Если ваша ветка исправляет ошибку в стабильном выпуске или это исправление безопасности, прочтите нашу статью <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/security-and-stable-release-updates"><em>Обновления безопасности и стабильных выпусков</em></a>.</p>
</div>
</div>
</div>
<span id="document-ubuntu-packaging-guide/fixing-a-bug-example"></span><div class="section" id="tutorial-fixing-a-bug-in-ubuntu">
<h3>Демонстрация: исправление ошибки в Ubuntu<a class="headerlink" href="#tutorial-fixing-a-bug-in-ubuntu" title="Ссылка на этот заголовок">¶</a></h3>
<p>Хотя техника <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>исправления ошибки</em></a> одинакова для любых ошибок, каждая ошибка всё же в чём то отличается от других. Данный пример исправления конкретной ошибки может помочь вам понять, что обычно следует принять во внимание.</p>
<div class="admonition note">
<p class="first admonition-title">Примечание</p>
<p class="last">Во время написания данной статьи эта ошибка ещё не была исправлена. Возможно, у тому времени, когда вы будете читать статью, ошибку уже исправят. Считайте это просто примером и постарайте адаптировать его к конкретной проблеме, с которой вы столкнётесь.</p>
</div>
<div class="section" id="confirming-the-problem">
<h4>Подтверждение проблемы<a class="headerlink" href="#confirming-the-problem" title="Ссылка на этот заголовок">¶</a></h4>
<p>Предположим, в описании пакета <tt class="docutils literal"><span class="pre">bumprace</span></tt> отсутствует информация о его домашней странице. В качестве первого шага, следует проверить, не исправлена ли уже эта ошибка. Сделать это просто: посмотрите в Центре приложений или запустите:</p>
<div class="highlight-python"><div class="highlight"><pre>apt-cache show bumprace
</pre></div>
</div>
<p>Вывод команды должен быть примерно следующим:</p>
<div class="highlight-python"><div class="highlight"><pre>Package: bumprace
Priority: optional
Section: universe/games
Installed-Size: 136
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Christian T. Steigies <cts@debian.org>
Architecture: amd64
Version: 1.5.4-1
Depends: bumprace-data, libc6 (>= 2.4), libsdl-image1.2 (>= 1.2.10),
libsdl-mixer1.2, libsdl1.2debian (>= 1.2.10-1)
Filename: pool/universe/b/bumprace/bumprace_1.5.4-1_amd64.deb
Size: 38122
MD5sum: 48c943863b4207930d4a2228cedc4a5b
SHA1: 73bad0892be471bbc471c7a99d0b72f0d0a4babc
SHA256: 64ef9a45b75651f57dc76aff5b05dd7069db0c942b479c8ab09494e762ae69fc
Description-en: 1 or 2 players race through a multi-level maze
In BumpRacer, 1 player or 2 players (team or competitive) choose among 4
vehicles and race through a multi-level maze. The players must acquire
bonuses and avoid traps and enemy fire in a race against the clock.
For more info, see the homepage at http://www.linux-games.com/bumprace/
Description-md5: 3225199d614fba85ba2bc66d5578ff15
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
</pre></div>
</div>
<p>В качестве контрпримера можно привести <tt class="docutils literal"><span class="pre">gedit</span></tt>, где домашняя страница указана:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-cache show gedit | grep ^Homepage
Homepage: http://www.gnome.org/projects/gedit/
$
</pre></div>
</div>
<p>В некоторых случаях вы можете столкнуться с тем, что проблема, решение которой вы ищете, уже кем-то устранена. Чтобы избежать напрасной траты времени и труда, имеет смысл проделать кое-какую детективную работу.</p>
</div>
<div class="section" id="research-bug-situation">
<h4>Изучение ситуации с ошибкой<a class="headerlink" href="#research-bug-situation" title="Ссылка на этот заголовок">¶</a></h4>
<p>Сначала нужно проверить, не существует ли уже сообщения об этой ошибке в Ubuntu. Возможно, кто-то уже работает над её исправлением, или мы можем как-то внести свой вклад в решение этой проблемы. Для Ubuntu мы взглянем на <a class="reference external" href="https://bugs.launchpad.net/ubuntu/+source/bumprace">https://bugs.launchpad.net/ubuntu/+source/bumprace</a> и увидим, что открытого отчёта о нашей ошибке там нет.</p>
<div class="admonition note">
<p class="first admonition-title">Примечание</p>
<p class="last">Для Ubuntu URL <tt class="docutils literal"><span class="pre">https://bugs.launchpad.net/ubuntu/+source/<пакет></span></tt> всегда приводит на страницу ошибок в указанном пакете исходного кода.</p>
</div>
<p>В Debian, который является основным источником пакетов Ubuntu мы взглянем на <a class="reference external" href="http://bugs.debian.org/src:bumprace">http://bugs.debian.org/src:bumprace</a> и также не найдём там сообщения о нашей ошибке.</p>
<div class="admonition note">
<p class="first admonition-title">Примечание</p>
<p class="last">Для Debian URL <tt class="docutils literal"><span class="pre">http://bugs.debian.org/src:<пакет></span></tt> всегда приводит на страницу ошибок в указанном пакете исходного кода.</p>
</div>
<p>Ошибка, над которой мы работаем, необычна в том смысле, что она касается только пакетирования <tt class="docutils literal"><span class="pre">bumprace</span></tt>. Если бы это была ошибка в исходном коде, полезно было бы также проверить систему отслеживания ошибок апстрима. К сожалению, эта процедура часто различается для каждого отдельного пакета, но всегда можно воспользоваться поиском в интернете, и в большинстве случаев вы обнаружите, что она окажется не такой уж сложной.</p>
</div>
<div class="section" id="offering-help">
<h4>Предложение помощи<a class="headerlink" href="#offering-help" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если вы обнаружили открытую ошибку, которая ещё никому не назначена, и вы готовы взяться за её устранение, следует написать комментарий с вашим решением. Включите в него как можно больше информации: При каких обстоятельствах появляется ошибка? Как вы её исправили? Тестировали ли вы свой способ устранения ошибки?</p>
<p>Если сообщение об ошибке не было зарегистрировано, вы можете его создать. Подумайте над двумя вещами: Может быть, изменение настолько мало, что достаточно просто попросить кого-нибудь применить его? Может быть, у вас получилось только частично исправить ошибку, и вы хотите поделиться вашей частью?</p>
<p>Будет замечательно, если вы можете предложить свою помощь, и она, несомненно, будет с готовностью принята.</p>
</div>
<div class="section" id="fixing-the-issue">
<h4>Исправление ошибки<a class="headerlink" href="#fixing-the-issue" title="Ссылка на этот заголовок">¶</a></h4>
<p>В данном конкретном примере недостаточно просто найти веб-сайт <tt class="docutils literal"><span class="pre">bumprace</span></tt> и определить адрес его домашней страницы. Нужно убедиться, что сайт работает, и он не является просто каталогом различных программ. <a class="reference external" href="http://www.linux-games.com/bumprace/">http://www.linux-games.com/bumprace/</a> выглядит подходящим местом.</p>
<p>Чтобы взяться за ошибку в пакете исходного кода, нам понадобится этот исходный код, и мы легко можем получить его, набрав:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr branch ubuntu:bumprace
</pre></div>
</div>
<p>Если вы прочитали <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/debian-dir-overview"><em>обзор каталога Debian</em></a>, то помните, вероятно, что домашняя страница указывается в первой части <tt class="docutils literal"><span class="pre">debian/control</span></tt>, в секции, начинающейся с <tt class="docutils literal"><span class="pre">Source:</span></tt>.</p>
<p>Так что теперь мы должны выполнить команду:</p>
<div class="highlight-python"><div class="highlight"><pre>cd bumprace
</pre></div>
</div>
<p>и отредактировать <tt class="docutils literal"><span class="pre">debian/control</span></tt>, добавив <tt class="docutils literal"><span class="pre">Homepage:</span> <span class="pre">http://www.linux-games.com/bumprace/</span></tt>. В конце первой секции должно быть подходящее место для этого. После внесения изменений сохраните файл.</p>
<p>Если теперь вы выполните:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr diff
</pre></div>
</div>
<p>вы должны увидеть что-то вроде этого:</p>
<div class="highlight-diff"><div class="highlight"><pre><span class="gh">=== modified file 'debian/control'</span>
<span class="gd">--- debian/control 2012-05-14 23:38:14 +0000</span>
<span class="gi">+++ debian/control 2012-09-03 15:45:30 +0000</span>
<span class="gu">@@ -12,6 +12,7 @@</span>
libtool,
zlib1g-dev
Standards-Version: 3.9.3
<span class="gi">+Homepage: http://www.linux-games.com/bumprace/</span>
Package: bumprace
Architecture: any
</pre></div>
</div>
<p>Синтаксис diff очень прост для понимания. <tt class="docutils literal"><span class="pre">+</span></tt> указывает строку, которая была добавлена. В нашем случае она была добавлена непосредственно перед второй секцией, начинающейся с <tt class="docutils literal"><span class="pre">Package</span></tt>, которая указывает на готовый двоичный пакет.</p>
</div>
<div class="section" id="documenting-the-fix">
<h4>Документирование исправления<a class="headerlink" href="#documenting-the-fix" title="Ссылка на этот заголовок">¶</a></h4>
<p>Важно пояснить своим коллегам - разработчикам, что именно вы сделали. Если вы наберёте:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">dch</span> <span class="o">-</span><span class="n">i</span>
</pre></div>
</div>
<p>это запустит редактор, с шаблоном записи в changelog, которую вам остаётся лишь дозаполнить. В нашем случае должно подойти что-то наподобие <tt class="docutils literal"><span class="pre">debian/control:</span> <span class="pre">Added</span> <span class="pre">project's</span> <span class="pre">homepage.</span></tt> Затем сохраните файл. Чтобы ещё раз проверить, что всё работает, наберите:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr diff debian/changelog
</pre></div>
</div>
<p>и вы увидите что-то вроде этого:</p>
<div class="highlight-diff"><div class="highlight"><pre><span class="gh">=== modified file 'debian/changelog'</span>
<span class="gd">--- debian/changelog 2012-05-14 23:38:14 +0000</span>
<span class="gi">+++ debian/changelog 2012-09-03 15:53:52 +0000</span>
<span class="gu">@@ -1,3 +1,9 @@</span>
<span class="gi">+bumprace (1.5.4-1ubuntu1) UNRELEASED; urgency=low</span>
<span class="gi">+</span>
<span class="gi">+ * debian/control: Added project's homepage.</span>
<span class="gi">+</span>
<span class="gi">+ -- Peggy Sue <peggy.sue@example.com> Mon, 03 Sep 2012 17:53:12 +0200</span>
<span class="gi">+</span>
bumprace (1.5.4-1) unstable; urgency=low
* new upstream version, sound and music have been removed (closes: #613344)
</pre></div>
</div>
<p>Несколько дополнительных соображений:</p>
<blockquote>
<div><ul class="simple">
<li><p class="first">Если у вас есть ссылка на ошибку на Launchpad, которую исправляет ваше изменение, добавьте (<tt class="docutils literal"><span class="pre">LP:</span> <span class="pre">#<номер</span> <span class="pre">ошибки></span></tt>) в запись changelog, например: <tt class="docutils literal"><span class="pre">(LP:</span> <span class="pre">#123456)</span></tt>.</p>
</li>
<li><p class="first">Если вы хотите, чтобы ваше исправление было включено в Debian, синтаксис для ошибки в Debian будет <tt class="docutils literal"><span class="pre">(Closes:</span> <span class="pre">#<номер</span> <span class="pre">ошибки>)</span></tt>, например: <tt class="docutils literal"><span class="pre">(Closes:</span> <span class="pre">#123456)</span></tt>.</p>
</li>
<li><p class="first">Если это ссылка на сообщение об ошибке в апстриме или в Debian, или на обсуждение в почтовой рассылке, также укажите её.</p>
</li>
<li><p class="first">Старайтесь делать перенос строк после 80 символов.</p>
</li>
<li><p class="first">Старайтесь излагать подробно: не стоит писать целое эссе, но укажите достаточно информации, чтобы понять мог любой человек (даже если он не вникал глубоко в эту проблему).</p>
</li>
<li><p class="first">Укажите, как и где вы исправили ошибку.</p>
</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="testing-the-fix">
<h4>Тестирование исправления<a class="headerlink" href="#testing-the-fix" title="Ссылка на этот заголовок">¶</a></h4>
<p>Чтобы проверить исправление, вам понадобится <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>настроить свою среду разработки</em></a>, затем собрать пакет, установить его и проверить, что проблема устранена. В нашем случае это будут следующие действия:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr bd -- -S
pbuilder-dist <current Ubuntu release> build ../bumprace_*.dsc
dpkg -I ~/pbuilder/*_result/bumprace_*.deb
</pre></div>
</div>
<p>Первой командой мы создаём пакет исходного кода из ветки, затем собираем его с помощью <tt class="docutils literal"><span class="pre">pbuilder</span></tt>, после чего проверяем, правильно ли добавлено поле домашней страницы в получившемся пакете.</p>
<div class="admonition note">
<p class="first admonition-title">Примечание</p>
<p class="last">В большинстве случаев вам придётся действительно установить пакет, чтобы проверить правильность его работы. Наш случай намного проще. Если сборка завершилась успешно, готовые двоичные пакеты можно будет найти в <tt class="docutils literal"><span class="pre">~/pbuilder/<выпуск>_result</span></tt>. Установите их с помощью <tt class="docutils literal"><span class="pre">sudo</span> <span class="pre">dpkg</span> <span class="pre">-i</span> <span class="pre"><пакет>.deb</span></tt> или двойного щелчка на них в файловом менеджере.</p>
</div>
<p>После того, как мы убедились, что проблема решена, следующим шагом будет поделиться своим решением со всем миром.</p>
</div>
<div class="section" id="getting-the-fix-included">
<h4>Применение исправления<a class="headerlink" href="#getting-the-fix-included" title="Ссылка на этот заголовок">¶</a></h4>
<p>It makes sense to get the fix included as Upstream as possible. Doing that you
can guarantee that everybody can take the Upstream source as-is and don’t need
to have local modifications to fix it.</p>
<p>В нашем случае мы установили, что ошибка относится только к пакетам Ubuntu и Debian. Так как Ubuntu основана на Debian, мы должны отправить исправление в Debian. После того, как в Debian появится исправленный пакет, он попадёт также и в Ubuntu. Наша ошибка не критична, поэтому можно так сделать. Если же важно применить исправление как можно скорее, то необходимо отправить исправление в несколько баг-трекеров (если оно затрагивает соотвествующие проекты).</p>
<p>Чтобы отправить патч в Debian, просто наберите:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">submittodebian</span>
</pre></div>
</div>
<p>Эта команда проведёт вас через несколько шагов, необходимых для оформления отчёта об ошибке и отправки его в правильное место. Обязательно просмотрите ваши изменения, чтобы убедиться, что там нет ничего постороннего.</p>
<p>Коммуникация имеет очень большое значение, поэтому при добавлении описания предоставьте хорошее и дружественное объяснение.</p>
<p>Если всё прошло нормально, то вы должны получить почтовое сообщение от системы отслеживания ошибок Debian с дополнительной информацией. Иногда это может занять несколько минут.</p>
<div class="admonition note">
<p class="first admonition-title">Примечание</p>
<p class="last">Если проблема наблюдается только в Ubuntu, вы можете воспользоваться <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-sponsorship"><em>инструкцией по поиску спонсора</em></a>.</p>
</div>
</div>
<div class="section" id="additional-considerations">
<h4>Дополнительные замечания<a class="headerlink" href="#additional-considerations" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если вы можете внести в пакет несколько тривиальных исправлений сразу, сделайте это. Это позволит разработчикам быстрее рассмотреть и применить эти изменения.</p>
<p>Если вы хотите внести несколько больших изменений, лучше посылать патчи или запросы на слияние отдельно для каждого изменения. Это проще, если уже созданы индивидуальные сообщения об ошибках.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/packaging-new-software"></span><div class="section" id="packaging-new-software">
<h3>Создание пакетов для новых программ<a class="headerlink" href="#packaging-new-software" title="Ссылка на этот заголовок">¶</a></h3>
<p>Хотя в архиве Ubuntu имеются тысячи пакетов, есть ещё много программ, которыми никто не занимается. Если вы знаете о какой-то замечательной программе, о которой, по вашему мнению, стоит узнать более широкому кругу пользователей, вы можете попробовать приложить свою руку к созданию пакета для Ubuntu или <a class="reference external" href="https://help.launchpad.net/Packaging/PPA">PPA</a>. Это руководство проведёт вас через этапы создания пакета для новой программы.</p>
<p>Сначала вам следует прочитать статью <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>Подготовка</em></a>, чтобы подготовить свою среду разработки.</p>
<div class="section" id="checking-the-program">
<h4>Проверка программы<a class="headerlink" href="#checking-the-program" title="Ссылка на этот заголовок">¶</a></h4>
<p>Первым этапом создания пакета является получение tar-файла из апстрима («апстримом» мы называем авторов приложений) и проверка того, что он нормально компилируется и запускается.</p>
<p>Это руководство проведёт вас через процесс создания пакета для небольшого приложения GNU Hello, доступного на <a class="reference external" href="http://www.gnu.org/software/hello/">GNU.org</a>.</p>
<p>Если у вас ещё нет инструментов сборки, установите их. Также установите все необходимые зависимости.</p>
<p>Установим инструменты сборки:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo apt-get install build-essential
</pre></div>
</div>
<p>Скачаем основной пакет:</p>
<div class="highlight-python"><div class="highlight"><pre>$ wget -O hello-2.7.tar.gz "http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz"
</pre></div>
</div>
<p>Теперь распакуем основной пакет:</p>
<div class="highlight-python"><div class="highlight"><pre>$ tar xf hello-2.7.tar.gz
$ cd hello-2.7
</pre></div>
</div>
<p>Это приложение использует систему сборки autoconf, так что нам нужно запустить <tt class="docutils literal"><span class="pre">./configure</span></tt> для подготовки к компиляции.</p>
<p>При этом будет проверено наличие необходимых для сборки зависимостей. Поскольку <tt class="docutils literal"><span class="pre">hello</span></tt> — простой пример, <tt class="docutils literal"><span class="pre">build-essential</span></tt> обеспечит нас всем, что нужно. Для более сложных программ, команда завершится ошибкой, если у нас нет необходимых библиотек и файлов для разработки. Установите требуемые пакеты и повторите процесс, пока команда не завершится успешно.:</p>
<div class="highlight-python"><div class="highlight"><pre>$ ./configure
</pre></div>
</div>
<p>Теперь нужно скомпилировать исходный код:</p>
<div class="highlight-python"><div class="highlight"><pre>$ make
</pre></div>
</div>
<p>Если компиляция завершилась успешно, можно установить и запустить программу:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo make install
$ hello
</pre></div>
</div>
</div>
<div class="section" id="starting-a-package">
<h4>Создание пакета<a class="headerlink" href="#starting-a-package" title="Ссылка на этот заголовок">¶</a></h4>
<p><tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> содержит модуль для создания нового пакета из шаблона. Этот модуль является обёрткой вокруг команды <tt class="docutils literal"><span class="pre">dh_make</span></tt> . Он уже должен быть у вас, если вы установили <tt class="docutils literal"><span class="pre">packaging-dev</span></tt>. Запустите команду, указав имя пакета, номер версии и путь к tar-архиву из апстрима:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo apt-get install dh-make bzr-builddeb
$ cd ..
$ bzr dh-make hello 2.7 hello-2.7.tar.gz
</pre></div>
</div>
<p>Когда он спросит тип пакета, выберите <tt class="docutils literal"><span class="pre">s</span></tt>: одиночный бинарник. Это импортирует код в ветку и создаст папку <tt class="docutils literal"><span class="pre">debian/</span></tt>. Взгляните на её содержимое: большинство автоматически созданных файлов требуются лишь для специализированных пакетов (например, модули Emacs), так что можно начать с удаления лишних файлов:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd hello/debian
$ rm *ex *EX
</pre></div>
</div>
<p>Теперь нужно внести изменения в каждый из файлов.</p>
<p>В <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> измените номер версии на версию Ubuntu: <tt class="docutils literal"><span class="pre">2.7-0ubuntu1</span></tt> (апстрим-версия 2.7, версия в Debian 0, версия в Ubuntu 1). Также смените <tt class="docutils literal"><span class="pre">unstable</span></tt> на текущий разрабатываемый выпуск Ubuntu, например, <tt class="docutils literal"><span class="pre">trusty</span></tt>.</p>
<p>Большая часть процесса компиляции пакета совершается скриптами из <tt class="docutils literal"><span class="pre">debhelper</span></tt>. Так как поведение <tt class="docutils literal"><span class="pre">debhelper</span></tt> меняется при выходе старшей версии, файл compat сообщает <tt class="docutils literal"><span class="pre">debhelper</span></tt>‘у какую именно версию использовать. Имеет смысл использовать наиболее свежую версию: <tt class="docutils literal"><span class="pre">9</span></tt>.</p>
<p>Файл <tt class="docutils literal"><span class="pre">control</span></tt> содержит все метаданные пакета. Первый абзац описывает пакет исходных кодов. Второй и следующие абзацы описывают двоичные пакеты, которые должны быть собраны. Нам понадобится добавить пакеты, необходимые для компиляции приложения в <tt class="docutils literal"><span class="pre">Build-Depends:</span></tt>. Для <tt class="docutils literal"><span class="pre">hello</span></tt> он должен включать, как минимум:</p>
<div class="highlight-python"><div class="highlight"><pre>Build-Depends: debhelper (>= 9)
</pre></div>
</div>
<p>Также нужно заполнить описание программы в поле <tt class="docutils literal"><span class="pre">Description:</span></tt>.</p>
<p><tt class="docutils literal"><span class="pre">copyright</span></tt> нужно заполнить в соответствии с лицензией на источник из апстрима. Согласно файлу hello/COPYING, это лицензия GNU GPL 3 или более поздняя её версия.</p>
<p><tt class="docutils literal"><span class="pre">docs</span></tt> должен содержать любые файлы документации из апстрима, которые, по вашему мнению, должны быть включены в готовый пакет.</p>
<p><tt class="docutils literal"><span class="pre">README.source</span></tt> и <tt class="docutils literal"><span class="pre">README.Debian</span></tt> необходимы, лишь если ваш пакет имеет какие-то нестандартные функции. У нас таких нет, так что можно удалить эти файлы.</p>
<p><tt class="docutils literal"><span class="pre">source/format</span></tt> можно оставить как есть, он описывает формат версии пакета исходного кода, который должен быть <tt class="docutils literal"><span class="pre">3.0</span> <span class="pre">(quilt)</span></tt>.</p>
<p><tt class="docutils literal"><span class="pre">rules</span></tt> — самый сложный файл. Это Makefile, который компилирует код и превращает его в двоичный пакет. К счастью, основную часть работы в наши дни автоматически выполняет <tt class="docutils literal"><span class="pre">debhelper</span> <span class="pre">7</span></tt>, так что универсальная цель <tt class="docutils literal"><span class="pre">%</span></tt> просто запускает сценарий <tt class="docutils literal"><span class="pre">dh</span></tt>, который делает всё, что необходимо.</p>
<p>Все эти файлы подробнее описаны в статье <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/debian-dir-overview"><em>обзор каталога debian</em></a>.</p>
<p>Наконец, закоммитьте код в ветку для пакетов:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr add debian/source/format
$ bzr commit -m "Initial commit of Debian packaging."
</pre></div>
</div>
</div>
<div class="section" id="building-the-package">
<h4>Сборка пакета<a class="headerlink" href="#building-the-package" title="Ссылка на этот заголовок">¶</a></h4>
<p>Теперь нам нужно проверить, что наши исходные файлы для пакета успешно компилируются и собираются в двоичный .deb-пакет:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -- -us -uc
$ cd ../../
</pre></div>
</div>
<p><tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">builddeb</span></tt> — это команда для сборки пакета в его текущем местоположении. <tt class="docutils literal"><span class="pre">-us</span> <span class="pre">-uc</span></tt> сообщает что подписывать пакет с помощью GPG не требуется. Результат будет помещён в каталог «..».</p>
<p>Просмотреть содержимое пакета можно с помощью:</p>
<div class="highlight-python"><div class="highlight"><pre>$ lesspipe hello_2.7-0ubuntu1_amd64.deb
</pre></div>
</div>
<p>Установите пакет и проверьте, что он работает (позднее при желании вы сможете удалить его командой <tt class="docutils literal"><span class="pre">sudo</span> <span class="pre">apt-get</span> <span class="pre">remove</span> <span class="pre">hello</span></tt>):</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo dpkg --install hello_2.7-0ubuntu1_amd64.deb
</pre></div>
</div>
<p>Можете также установить все пакеты сразу с помощью:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo debi
</pre></div>
</div>
</div>
<div class="section" id="next-steps">
<h4>Дальнейшие шаги<a class="headerlink" href="#next-steps" title="Ссылка на этот заголовок">¶</a></h4>
<p>Даже если двоичный .deb-пакет успешно собирается, ваши исходные файлы для пакета могут содержать ошибки. Многие ошибки могут автоматически обнаруживаться нашим инструментом <tt class="docutils literal"><span class="pre">lintian</span></tt>, который можно применить к файлу метаданных .dsc, двоичным пакетам .deb или файлу .changes:</p>
<div class="highlight-python"><div class="highlight"><pre>$ lintian hello_2.7-0ubuntu1.dsc
$ lintian hello_2.7-0ubuntu1_amd64.deb
</pre></div>
</div>
<p>Чтобы увидеть подробное описание ошибок, используйте флаг lintian <tt class="docutils literal"><span class="pre">--info</span></tt> или команду <tt class="docutils literal"><span class="pre">lintian-info</span></tt>.</p>
<p>Результаты проверок архива Ubuntu можно найти в Интернете на <a class="reference external" href="http://lintian.ubuntuwire.org">http://lintian.ubuntuwire.org</a>.</p>
<p>Для пакетов Python имеется также инструмент <tt class="docutils literal"><span class="pre">lintian4python</span></tt>, осуществляющий некоторые дополнительные проверки lintian.</p>
<p>После создания исправления для файлов пакета можно пересобрать его с параметром <tt class="docutils literal"><span class="pre">-nc</span></tt> (“no clean”), чтобы не начинать сборку с самого начала:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -- -nc -us -uc
</pre></div>
</div>
<p>Убедившись, что пакет успешно собирается локально, вы должны проверить, правильно ли его сборка будет проходить в чистой системе, с помощью <tt class="docutils literal"><span class="pre">pbuilder</span></tt>. Поскольку вскоре мы собираемся загрузить его в PPA (персональный архив пакетов), эту загрузку нужно снабдить <em>цифровой подписью</em>, чтобы Launchpad мог удостовериться, что загрузку сделали вы (узнать о том, что загрузка будет подписана, можно по отсутствию передаваемых <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">builddeb</span></tt> флагов <tt class="docutils literal"><span class="pre">-us</span></tt> и <tt class="docutils literal"><span class="pre">-uc</span></tt>, которые мы использовали ранее). Для подписывания своей работы вам понадобится настроить GPG. Если вы ещё не настроили <tt class="docutils literal"><span class="pre">pbuilder-dist</span></tt> или GPG, <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>сделайте это сейчас</em></a>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -S
$ cd ../build-area
$ pbuilder-dist trusty build hello_2.7-0ubuntu1.dsc
</pre></div>
</div>
<p>После того как вы останетесь довольны получившимся пакетом, нужно, чтобы его проверили другие люди. Вы можете выгрузить ветку на Launchpad для проверки:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push lp:~<lp-username>/+junk/hello-package
</pre></div>
</div>
<p>Выгрузка в PPA позволит удостовериться, что пакет собирается нормально, а также позволит вам и остальным тестировать бинарные пакеты. Вам потребуется создать PPA на Launchpad, после чего выгрузить пакет с помощью <tt class="docutils literal"><span class="pre">dput</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dput ppa:<lp-username>/<ppa-name> hello_2.7-0ubuntu1.changes
</pre></div>
</div>
<p>Смотрите раздел «<a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-uploading"><em>Загрузка</em></a>» для дополнительной информации.</p>
<p>Попросить провести review можно на канале IRC <tt class="docutils literal"><span class="pre">#ubuntu-motu</span></tt>, или в <a class="reference external" href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu">списке рассылки MOTU</a>. В некоторых случаях может потребоваться участие конкретной команды: в подобных случаях команда GNU поможет разобраться.</p>
</div>
<div class="section" id="submitting-for-inclusion">
<h4>Отправка на включение<a class="headerlink" href="#submitting-for-inclusion" title="Ссылка на этот заголовок">¶</a></h4>
<p>Существует несколько путей, которыми пакет может попасть в Ubuntu. В большинстве случаев лучшим путём может быть прохождение сначала через Debian. Это позволит вашему пакету стать доступным для наибольшего количества пользователей, так как он будет доступен не только в Debian и Ubuntu, но и во всех дистрибутивах, созданных на их основе. Вот несколько полезных ссылок по отправке новых пакетов в Debian:</p>
<blockquote>
<div><ul class="simple">
<li><p class="first"><a class="reference external" href="https://wiki.debian.org/DebianMentorsFaq">Debian Mentors FAQ</a> - debian-mentors создан для менторства новых и перспективных разработчиков Debian. Это то место, где можно найти спонсора для загрузки Вашего пакета в архив.</p>
</li>
<li><p class="first"><a class="reference external" href="http://www.debian.org/devel/wnpp/">Work-Needing and Prospective Packages</a> - информация о том как отправлять баги “Intent to Package” (Назначение пакету) и “Request for Package” (Запрос пакета), а также списки открытых ITP и RFP.</p>
</li>
<li><p class="first"><a class="reference external" href="http://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage">Руководство Разработчика Debian, 5.1. Создание пакетов</a> - бесценный документ для создателей пакетов как под Ubuntu, так и под Debian. Данная глава описывает процесс отправки новых пакетов.</p>
</li>
</ul>
</div></blockquote>
<p>В некоторых случаях имеет смысл отправляться прямо в Ubuntu. Например, если Debian находится в состоянии “freeze”: тогда ваш пакет врядли успеет войти в Ubuntu к ближайшему релизу. Этот процесс описан на странице <a class="reference external" href="https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages">“Новые Пакеты”</a> Ubuntu Wiki.</p>
</div>
<div class="section" id="screenshots">
<h4>Снимки экрана<a class="headerlink" href="#screenshots" title="Ссылка на этот заголовок">¶</a></h4>
<p>Загрузив пакет в Debian, вам следует добавить снимки экрана, чтобы будущие пользователи смогли получить представление о том, как выглядит интерфейс программы. Снимки нужно отправлять на <a class="reference external" href="http://screenshots.debian.net/upload">http://screenshots.debian.net/upload</a> .</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/security-and-stable-release-updates"></span><div class="section" id="security-and-stable-release-updates">
<h3>Обновления безопасности и обновления стабильных релизов<a class="headerlink" href="#security-and-stable-release-updates" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="fixing-a-security-bug-in-ubuntu">
<h4>Исправление ошибок безопасности в Ubuntu<a class="headerlink" href="#fixing-a-security-bug-in-ubuntu" title="Ссылка на этот заголовок">¶</a></h4>
<div class="section" id="introduction">
<h5>Вступление<a class="headerlink" href="#introduction" title="Ссылка на этот заголовок">¶</a></h5>
<p>Исправление дыр в безопасности в Ubuntu фактически не отличается от <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>исправления обычного бага</em></a>, и предполагается, что Вы знакомы с исправлением обычных багов. Для демонстрации отличий мы будем добавлять в пакет dbus в Ubuntu 12.04 LTS (Precise Pangolin) обновления для системы безопасности.</p>
</div>
<div class="section" id="obtaining-the-source">
<h5>Получение исходного кода<a class="headerlink" href="#obtaining-the-source" title="Ссылка на этот заголовок">¶</a></h5>
<p>В данном примере мы уже знаем, что хотим исправить пакет dbus в Ubuntu 12.04 LTS (Precise Pangolin). Поэтому сначала нужно определить версию пакета, который хотите скачать. Мы можем использовать <tt class="docutils literal"><span class="pre">rmadison</span></tt> в качестве помощи в данной ситуации.</p>
<div class="highlight-python"><div class="highlight"><pre>$ rmadison dbus | grep precise
dbus | 1.4.18-1ubuntu1 | precise | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-security | source, amd64, armel, armhf, i386, powerpc
dbus | 1.4.18-1ubuntu1.4 | precise-updates | source, amd64, armel, armhf, i386, powerpc
</pre></div>
</div>
<p>Обычно выбирают самую последнюю версию для релиза, который Вы хотите пропатчить, который не в -proposed или -backports. Так как мы обновляем dbus Precise, Вы скачаете 1.4.18-1ubuntu1.4 с precise-updates:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:precise-updates/dbus
</pre></div>
</div>
</div>
<div class="section" id="patching-the-source">
<h5>Создание патча<a class="headerlink" href="#patching-the-source" title="Ссылка на этот заголовок">¶</a></h5>
<p>Теперь, когда мы имеем исходный пакет, мы должны сделать патч для исправления уязвимости. Вы можете использовать любой метод, подходящий для данного пакета, в том числе <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro"><em>методы UDD</em></a>, но в этом примере будем использовать <tt class="docutils literal"><span class="pre">edit-patch</span></tt> (из пакета ubuntu-dev-tools). <tt class="docutils literal"><span class="pre">edit-patch</span></tt> — это самый простой способ для исправления пакетов, работающий с любой системой патчей, которую вы можете себе представить.</p>
<p>Чтобы создать патч с помощью <tt class="docutils literal"><span class="pre">edit-patch</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd dbus
$ edit-patch 99-fix-a-vulnerability
</pre></div>
</div>
<p>Это применит все существующие патчи и поместит пакет во временный каталог. Теперь отредактируйте файлы для исправления уязвимостей. Обычно в апстриме лежит и патч, поэтому Вы сразу можете его применить:</p>
<div class="highlight-python"><div class="highlight"><pre>$ patch -p1 < /home/user/dbus-vulnerability.diff
</pre></div>
</div>
<p>После внесения необходимых изменений просто нажмите Ctrl-D или наберите exit, чтобы покинуть временную командную оболочку.</p>
</div>
<div class="section" id="formatting-the-changelog-and-patches">
<h5>Форматирование файла changelog и патчей<a class="headerlink" href="#formatting-the-changelog-and-patches" title="Ссылка на этот заголовок">¶</a></h5>
<p>После применения патчей вам потребуется внести изменения в лог. Команда <tt class="docutils literal"><span class="pre">dch</span></tt> используется для редактирования файла <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> и <tt class="docutils literal"><span class="pre">edit-patch</span></tt> автоматически запустит <tt class="docutils literal"><span class="pre">dch</span></tt> после отката всех патчей. Если Вы не пользуетесь <tt class="docutils literal"><span class="pre">edit-patch</span></tt>, то можете запустить <tt class="docutils literal"><span class="pre">dch</span> <span class="pre">-i</span></tt> вручную. В отличии от обычных патчей, Вам следует использовать следующий формат (обратите внимание, что в имени дитрибутива используется precise-security, так как это обновление безопасности для Precise) для обновлений безопасности:</p>
<div class="highlight-python"><div class="highlight"><pre>dbus (1.4.18-2ubuntu1.5) precise-security; urgency=low
* SECURITY UPDATE: [DESCRIBE VULNERABILITY HERE]
- debian/patches/99-fix-a-vulnerability.patch: [DESCRIBE CHANGES HERE]
- [CVE IDENTIFIER]
- [LINK TO UPSTREAM BUG OR SECURITY NOTICE]
- LP: #[BUG NUMBER]
...
</pre></div>
</div>
<p>Обновите свой патч для использования соответствующих тегов. Ваш патч должен содержать как минимум теги Origin, Description и Bug-Ubuntu. Например, отредактируйте <tt class="docutils literal"><span class="pre">debian/patches/99-fix-a-vulnerability.patch</span></tt>, чтобы он имел приблизительно следующие строки:</p>
<div class="highlight-python"><div class="highlight"><pre>## Description: [DESCRIBE VULNERABILITY HERE]
## Origin/Author: [COMMIT ID, URL OR EMAIL ADDRESS OF AUTHOR]
## Bug: [UPSTREAM BUG URL]
## Bug-Ubuntu: https://launchpad.net/bugs/[BUG NUMBER]
Index: dbus-1.4.18/dbus/dbus-marshal-validate.c
...
</pre></div>
</div>
<p>Множественные уязвимости можно исправить одной загрузкой безопасности, просто убедитесь что используете разные патчи для разных уязвимостей.</p>
</div>
<div class="section" id="test-and-submit-your-work">
<h5>Проверка и отправка вашей работы<a class="headerlink" href="#test-and-submit-your-work" title="Ссылка на этот заголовок">¶</a></h5>
<p>На этом этапе процесс такой же, как при <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>исправлении обычных ошибок в Ubuntu</em></a>. А именно, вам нужно:</p>
<blockquote>
<div><ol class="arabic simple">
<li><p class="first">Выполнить сборку пакета и проверить, что он компилируется без ошибок и компилятор не выдаёт никаких дополнительных предупреждений</p>
</li>
<li><p class="first">Выполнить обновление с предыдущей версии пакета до новой версии</p>
</li>
<li><p class="first">Убедиться, что новый пакет закрывает уязвимость и не вносит никаких ухудшений</p>
</li>
<li><p class="first">Отправляйте свою работу через предложение об объединении Launchpad и отправляйте баг в Launchpad, убедившись что пометили баг как ошибку безопасности, и для подписки <tt class="docutils literal"><span class="pre">ubuntu-security-sponsors</span></tt></p>
</li>
</ol>
</div></blockquote>
<p>Если это уязвимость в безопасности, о которой ещё не объявлено публично, то не отправляйте предложение слияния и убедитесь, что вы пометили свою ошибку, как приватную (private).</p>
<p>Отправленный баг должен содержать Тестовый Пример, т.е. комментарий, который четко показывает как воссоздать баг, запустив старую версию, также показывая как убедиться, что баг больше не существует в новой версии.</p>
<p>Отчет по багу также должен подтверждать, что ошибка исправлена в новых версиях Ubuntu при помощи предложенного фикса (в вышеуказанном примере выше чем в Precise). Если проблема не исправлена в новых версиях Ubuntu, вы должны подготовить обновлениях и для новых версий.</p>
</div>
</div>
<div class="section" id="stable-release-updates">
<h4>Обновления стабильного релиза<a class="headerlink" href="#stable-release-updates" title="Ссылка на этот заголовок">¶</a></h4>
<p>Мы также разрешаем вносить обновления в выпуски, в которых пакет содержит серьёзную ошибку, такую как значительная регрессия по сравнению с предыдущим выпуском или ошибка, которая может привести к потере данных. Из-за того, что такие изменения сами потенциально могут привести к появлению дополнительных ошибок, мы позволяем делать это только там, где изменения легко можно понять и проверить.</p>
<p>Процесс обновлений стабильного выпуска (Stable Release Updates или SRU) такой же, как и для исправлений ошибок безопасности, за исключением того, что нужно подписать на отчёт об ошибке команду <tt class="docutils literal"><span class="pre">ubuntu-sru</span></tt>.</p>
<p>Обновление попадет в архив <tt class="docutils literal"><span class="pre">proposed``(к</span> <span class="pre">примеру</span> <span class="pre">``precise-proposed</span></tt>), где его проверяют на способность исправить проблему и подтверждают, что оно не является следствием новых проблем. После недели работы без заявленных проблем, обновление попадает в раздел <tt class="docutils literal"><span class="pre">updates</span></tt>.</p>
<p>Смотрите ‘Вики страницу Обновлений Стабильного Релиза <<a class="reference external" href="https://wiki.ubuntu.com/StableReleaseUpdates">SRUWiki</a>>`_ для получения дополнительной информации.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/patches-to-packages"></span><div class="section" id="patches-to-packages">
<h3>Патчи для пакетов<a class="headerlink" href="#patches-to-packages" title="Ссылка на этот заголовок">¶</a></h3>
<p>Иногда разработчикам пакета Ubuntu надо изменить исходный код апстрима, чтобы заставить его работать в Ubuntu должным образом. Примеры включают патчи для апстримов, которые еще не попали в версию релиза, либо изменения к системам билдов апстрима, необходимые только для их сборки на Ubuntu. Мы будем менять исходный код апстрима напрямую, но такой метод делает более сложным дальнейшее удаление патчей, когда апстрим уже применил их, также усложняя извлечение изменений для их отправки в проект апстрима. Вместо этого, мы будем хранить эти изменения как отдельные патчи в форме diff файлов.</p>
<p>Существуют различные способы работы с патчами для пакетов Debian. К счастью, мы остановимся на одной системе, <a class="reference external" href="https://wiki.debian.org/UsingQuilt">Quilt</a>, которая сейчас используется большинством пакетов.</p>
<p>Давайте возьмём в качестве примера пакет <tt class="docutils literal"><span class="pre">kamoso</span></tt> в Trusty:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:trusty/kamoso
</pre></div>
</div>
<p>Патчи хранятся в <tt class="docutils literal"><span class="pre">debian/patches</span></tt>. Для этого пакета имеется один патч <tt class="docutils literal"><span class="pre">kubuntu_01_fix_qmax_on_armel.diff</span></tt> для исправления ошибки компиляции на платформе ARM. Этому патчу присвоено имя, описывающее, что он делает, номер патча по порядку (чтобы избежать путаницы, если два патча имеют одинаковое имя) и, в данном случае, команда Kubuntu добавила свой собственный префикс, чтобы показать, что патч исходит от них, а не от Debian.</p>
<p>Порядок применения патчей хранится в <tt class="docutils literal"><span class="pre">debian/patches/series</span></tt>.</p>
<div class="section" id="patches-with-quilt">
<h4>Патчи с помощью Quilt<a class="headerlink" href="#patches-with-quilt" title="Ссылка на этот заголовок">¶</a></h4>
<p>Перед работой с Quilt нужно указать этой системе, где искать патчи. Добавьте в <tt class="docutils literal"><span class="pre">~/.bashrc</span></tt> следующее:</p>
<div class="highlight-python"><div class="highlight"><pre>export QUILT_PATCHES=debian/patches
</pre></div>
</div>
<p>И источник файла для применения нового экспорта:</p>
<div class="highlight-python"><div class="highlight"><pre>$ . ~/.bashrc
</pre></div>
</div>
<p>По умолчанию все патчи применяются уже с UDD извлечений или загружаемых пакетов. Вы можете проверить это с помощью:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt applied
kubuntu_01_fix_qmax_on_armel.diff
</pre></div>
</div>
<p>Если вы хотите удалить патч, нужно выполнить <tt class="docutils literal"><span class="pre">pop</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt pop
Removing patch kubuntu_01_fix_qmax_on_armel.diff
Restoring src/kamoso.cpp
No patches applied
</pre></div>
</div>
<p>А чтобы применить патч, используйте <tt class="docutils literal"><span class="pre">push</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp
Now at patch kubuntu_01_fix_qmax_on_armel.diff
</pre></div>
</div>
</div>
<div class="section" id="adding-a-new-patch">
<h4>Добавление нового патча<a class="headerlink" href="#adding-a-new-patch" title="Ссылка на этот заголовок">¶</a></h4>
<p>Для добавления нового патча нужно указать Quilt создать новый патч, сообщить ему, какие файлы этот патч должен изменить, отредактировать файлы, а затем обновить патч:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt new kubuntu_02_program_description.diff
Patch kubuntu_02_program_description.diff is now on top
$ quilt add src/main.cpp
File src/main.cpp added to patch kubuntu_02_program_description.diff
$ sed -i "s,Webcam picture retriever,Webcam snapshot program,"
src/main.cpp
$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff
</pre></div>
</div>
<p>Шаг <tt class="docutils literal"><span class="pre">quilt</span> <span class="pre">add</span></tt> важен: если вы забудете его сделать, файлы не попадут в патч.</p>
<p>Теперь изменения будут в <tt class="docutils literal"><span class="pre">debian/patches/kubuntu_02_program_description.diff</span></tt>, а в файл <tt class="docutils literal"><span class="pre">series</span></tt> будет добавлена информация о новом патче. Вы должны добавить новый файл в исходные файлы для пакета:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr add debian/patches/kubuntu_02_program_description.diff
$ bzr add .pc/*
$ dch -i "Add patch kubuntu_02_program_description.diff to improve the program description"
$ bzr commit
</pre></div>
</div>
<p>Quilt содержит свои мета-данные в директории <a href="#id1"><span class="problematic" id="id2">``</span></a>.pc/<a href="#id3"><span class="problematic" id="id4">`</span></a>‘, поэтому сейчас вам нужно добавить в пакет и ее. Это должно быть улучшено в будущем.</p>
<p>Как правило, следует проявлять осторожность при добавлении патчей к программам, если они исходят не из апстрима. Часто имеется веская причина, по которой изменения ещё не были сделаны. В рассмотренном выше примере изменяется строка в пользовательском интерфейсе, так что это может поломать все переводы. Если сомневаетесь, спросите автора из апстрима перед тем, как добавить патч.</p>
</div>
<div class="section" id="patch-headers">
<h4>Заголовки патчей<a class="headerlink" href="#patch-headers" title="Ссылка на этот заголовок">¶</a></h4>
<p>Мы рекомендуем добавлять к каждому патчу заголовки <a class="reference external" href="http://dep.debian.net/deps/dep3/">DEP-3</a>, помещая их в самом верху файла патча. Вот некоторые заголовки, которые можно использовать:</p>
<table class="docutils field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field-odd field"><th class="field-name">Description:</th><td class="field-body"><p class="first last">Описание того, что делает патч. Имеет формат, аналогичный полю <tt class="docutils literal"><span class="pre">Description</span></tt> в <tt class="docutils literal"><span class="pre">debian/control</span></tt>: первая строка содержит краткое описание, начинающееся со строчной буквы, остальные строки содержат более длинное описание с пробелом в качестве отступа.</p>
</td>
</tr>
<tr class="field-even field"><th class="field-name">Author:</th><td class="field-body"><p class="first last">Кто написал патч (например, “Jane Doe <<a class="reference external" href="mailto:packager%40example.com">packager<span>@</span>example<span>.</span>com</a>>”).</p>
</td>
</tr>
<tr class="field-odd field"><th class="field-name">Origin:</th><td class="field-body"><p class="first last">Откуда пришёл этот патч (например, “upstream”), если заголовок <em>Author</em> отсутствует.</p>
</td>
</tr>
<tr class="field-even field"><th class="field-name">Bug-Ubuntu:</th><td class="field-body"><p class="first last">Ссылка на информацию об ошибке на Launchpad, предпочтительно, в краткой форме (наподобие <em>https://bugs.launchpad.net/bugs/XXXXXXX</em>). Если также имеются отчёты об ошибках в апстриме или системах отслеживания ошибок Debian, добавьте заголовки <em>Bug</em> или <em>Bug-Debian</em>.</p>
</td>
</tr>
<tr class="field-odd field"><th class="field-name">Forwarded:</th><td class="field-body"><p class="first last">Был ли патч передан в апстрим. Значения: “yes”, “no” или “not-needed”.</p>
</td>
</tr>
<tr class="field-even field"><th class="field-name">Last-Update:</th><td class="field-body"><p class="first last">Дата последней ревизии (в форме “ГГГГ-ММ-ДД”).</p>
</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="upgrading-to-new-upstream-versions">
<h4>Обновление до новых версий из апстрима<a class="headerlink" href="#upgrading-to-new-upstream-versions" title="Ссылка на этот заголовок">¶</a></h4>
<p>Чтобы выполнить обновление до последней версии, вы можете использовать команду <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-upstream</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge-upstream --version 2.0.2 https://launchpad.net/ubuntu/+archive/primary/+files/kamoso_2.0.2.orig.tar.bz2
</pre></div>
</div>
<p>При запуске этой команды произойдет откат всех патчей, так как они могут стать устаревшими. Возможно потребуется их обновить для соответствия новому источнику апстрима, либо потребуется удалить их все вместе. Для облегчения проверки проблем применяйте патчи по одному.</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt push
Applying patch kubuntu_01_fix_qmax_on_armel.diff
patching file src/kamoso.cpp
Hunk #1 FAILED at 398.
1 out of 1 hunk FAILED -- rejects in file src/kamoso.cpp
Patch kubuntu_01_fix_qmax_on_armel.diff can be reverse-applied
</pre></div>
</div>
<p>Если для патча указано <tt class="docutils literal"><span class="pre">it</span> <span class="pre">can</span> <span class="pre">be</span> <span class="pre">reverse-applied</span></tt>, значит патч уже был применён апстримом, так что мы можем удалить этот патч:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt delete kubuntu_01_fix_qmax_on_armel
Removed patch kubuntu_01_fix_qmax_on_armel.diff
</pre></div>
</div>
<p>Затем продолжайте:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt push
Applied kubuntu_02_program_description.diff
</pre></div>
</div>
<p>Неплохой мыслью будет выполнить refresh, это обновит патч относительно изменений исходного кода в апстриме:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff
</pre></div>
</div>
<p>Затем выполните фиксацию, как обычно:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr commit -m "new upstream version"
</pre></div>
</div>
</div>
<div class="section" id="making-a-package-use-quilt">
<h4>Создание пакета с использованием Quilt<a class="headerlink" href="#making-a-package-use-quilt" title="Ссылка на этот заголовок">¶</a></h4>
<p>Современные пакеты используют Quilt по умолчанию, это встроено в формат исходных файлов пакета. Проверьте, что в <tt class="docutils literal"><span class="pre">debian/source/format</span></tt> указано <tt class="docutils literal"><span class="pre">3.0</span> <span class="pre">(quilt)</span></tt>.</p>
<p>Для более старых пакетов, использующих формат 1.0, необходимо использовать Quilt явно, обычно с помощью включения make-фала в <tt class="docutils literal"><span class="pre">debian/rules</span></tt>.</p>
</div>
<div class="section" id="configuring-quilt">
<h4>Конфигурирование Quilt<a class="headerlink" href="#configuring-quilt" title="Ссылка на этот заголовок">¶</a></h4>
<p>Вы можете воспользоваться файлом <tt class="docutils literal"><span class="pre">~/.quiltrc</span></tt> для конфигурирования quilt. Вот несколько опций, которые могут быть полезны при использовании quilt с пакетами Debian:</p>
<div class="highlight-sh"><div class="highlight"><pre><span class="c"># Set the patches directory</span>
<span class="nv">QUILT_PATCHES</span><span class="o">=</span><span class="s2">"debian/patches"</span>
<span class="c"># Remove all useless formatting from the patches</span>
<span class="nv">QUILT_REFRESH_ARGS</span><span class="o">=</span><span class="s2">"-p ab --no-timestamps --no-index"</span>
<span class="c"># The same for quilt diff command, and use colored output</span>
<span class="nv">QUILT_DIFF_ARGS</span><span class="o">=</span><span class="s2">"-p ab --no-timestamps --no-index --color=auto"</span>
</pre></div>
</div>
</div>
<div class="section" id="other-patch-systems">
<h4>Другие системы управления патчами<a class="headerlink" href="#other-patch-systems" title="Ссылка на этот заголовок">¶</a></h4>
<p>Другие системы патчинга, используемые в пакетах, включают <tt class="docutils literal"><span class="pre">dpatch</span></tt> и <tt class="docutils literal"><span class="pre">cdbs</span> <span class="pre">simple-patchsys</span></tt>, принцип работы которых похож на Quilt - патчи хранятся в <tt class="docutils literal"><span class="pre">debian/patches</span></tt>, но для их применения, отмены или создания требуются другие команды. Вы можете узнать какая система патчинга используется в пакете при помощи команды <tt class="docutils literal"><span class="pre">what-patch``(в</span> <span class="pre">пакете</span> <span class="pre">``ubuntu-dev-tools</span></tt>). Вы можете использовать <tt class="docutils literal"><span class="pre">edit-patch</span></tt>, показанный в <a class="reference internal" href="index.html#working-on-a-fix"><em>предыдущих главах</em></a>, в качестве надежного способа для работы со всеми системами.</p>
<p>В более старых пакетах изменения будут включены напрямую в источники и храниться в исходном файле <tt class="docutils literal"><span class="pre">diff.gz</span></tt>. Это делает сложнее процесс обновления до новых версий апстрима или различия между патчами - лучше избегать.</p>
<p>Не изменяйте систему патчей, не обсудив это с сопровождающим Debian или имеющей отношение к делу командой Ubuntu. Если существующей системы патчей нет, можете добавить Quilt.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/fixing-ftbfs"></span><div class="section" id="fixing-ftbfs-packages">
<h3>Исправление пакетов FTBFS (Fails To Build From Source)<a class="headerlink" href="#fixing-ftbfs-packages" title="Ссылка на этот заголовок">¶</a></h3>
<p>Перед тем, как пакет можно будет использовать в Ubuntu, он должен быть собран из исходного кода. Если это не удаётся, пакет, вероятно, будет ожидать в -proposed и не будет доступен в архивах Ubuntu. Полный список пакетов, которые не удалось собрать из исходного кода, можно найти на <a class="reference external" href="http://qa.ubuntuwire.org/ftbfs/">http://qa.ubuntuwire.org/ftbfs/</a>. На этой странице показано 5 основных категорий:</p>
<blockquote>
<div><ul class="simple">
<li><p class="first">Package failed to build (F): Что-то действительно пошло не так в процессе сборки.</p>
</li>
<li><p class="first">Отменённая сборка (X): сборка была отменена по некоторой причине. Для начала, с ними лучше не связываться.</p>
</li>
<li><p class="first">Package is waiting on another package (M): Этот пакет ожидает сборки или обновления другого пакета, или (если это пакет в main) одна из его зависимостей находится не в той части архива.</p>
</li>
<li><p class="first">Проблема в chroot (C): Некоторая операция над chroot-окружением столкнулась с ошибкой. Чаще всего исправляется повторной сборкой. Попросите разработчика запустить пересборку.</p>
</li>
<li><p class="first">Ошибка при загрузке (U): Пакет не может быть загружен на сервер. Обычно в этом случае нужно сделать пересборку, но перед этим – проверьте логи сборки.</p>
</li>
</ul>
</div></blockquote>
<div class="section" id="first-steps">
<h4>Первые шаги<a class="headerlink" href="#first-steps" title="Ссылка на этот заголовок">¶</a></h4>
<p>Первым делом необходимо повторить FTBFS самостоятельно. Скачайте код с помощью <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">branch</span> <span class="pre">lp:ubuntu/PACKAGE</span></tt> и получите tar-архив, или запустите <tt class="docutils literal"><span class="pre">dget</span> <span class="pre">PACKAGE_DSC</span></tt> над .dsc-файлом со страницы проекта на Launchpad. После этого, создайте chroot-окружение.</p>
<p>У вас должно получиться воспроизвести ошибку FTBFS. Если же нет – проверьте, не качает ли сборка отсутствующую зависимость: в таком случае необходимо в файле debian/control объявить её как build-depends. Другой вариант – попробовать собрать пакет локально, что позволит проверить отсутствующие или не указанные зависимости (в таком случае локальная сборка должна быть успешна, а в schroot – нет)</p>
</div>
<div class="section" id="checking-debian">
<h4>Проверка Debian<a class="headerlink" href="#checking-debian" title="Ссылка на этот заголовок">¶</a></h4>
<p>В случае, если проблему удалось воспроизвести – необходимо приступить к поиску решения. Если пакет также находится в Debian, – проверьте, возможно у них пакет собирается нормально: <a class="reference external" href="http://packages.qa.debian.org/PACKAGE">http://packages.qa.debian.org/PACKAGE</a>. Если в Debian есть более новая версия пакета, его нужно объединить (merge). Если же нет – проверьте логи сборки и ссылки на известные проблемы: там можеет быть дополнительная информация о FTBFS или патчи. Debian также поддерживает список команд разных FTBFS, в котором также есть варианты решения разнообразных проблем: <a class="reference external" href="https://wiki.debian.org/qa.debian.org/FTBFS">https://wiki.debian.org/qa.debian.org/FTBFS</a>.</p>
</div>
<div class="section" id="arm64">
<h4>ARM64<a class="headerlink" href="#arm64" title="Ссылка на этот заголовок">¶</a></h4>
<p>Недавно Ubuntu добавили поддержку архитектуры arm64, но множество пакетов сбоят при сборке. Полный список таких пакетов можно найти на странице qa.ubuntuwire.org/ftbfs/arm64.html. Множество проблем вызвано использованием устаревших вспомогательных файлов autotools. Эта проблема обязательно возникает с пакетами, для которых утилита lintian выдаёт предупреждение ancient-autotools-helper-file или outdated-autotools-helper-file. Обычно исправление заключается в добавлении autotools-dev или dh-autoreconf к процессу сборки.</p>
</div>
<div class="section" id="other-causes-of-a-package-to-ftbfs">
<h4>Другие причины возникновения FTBFS<a class="headerlink" href="#other-causes-of-a-package-to-ftbfs" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если пакет находится в main, но для него отсутствует зависимость не из main, то необходимо отправить MIR-баг: страница <a class="reference external" href="https://wiki.ubuntu.com/MainInclusionProcess">https://wiki.ubuntu.com/MainInclusionProcess</a> описывает эту процедуру.</p>
</div>
<div class="section" id="fixing-the-issue">
<h4>Исправление ошибки<a class="headerlink" href="#fixing-the-issue" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если удалось исправить проблему, следуйте такой же процедуре как и при любых других проблемах: создайте патч, добавьте его в ветку или баг bzr, подпишите ubuntu-sponsors, а потом попробуйте добиться его добавления в исходный пакет и/или в Debian.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/libraries"></span><div class="section" id="shared-libraries">
<h3>Общие библиотеки<a class="headerlink" href="#shared-libraries" title="Ссылка на этот заголовок">¶</a></h3>
<p>Общие библиотеки — это скомпилированный код, предназначенный для совместного использования несколькими различными программами. Они распространяются в виде файлов <tt class="docutils literal"><span class="pre">.so</span></tt> в <tt class="docutils literal"><span class="pre">/usr/lib/</span></tt>.</p>
<p>Библиотеки экспортируют символы в скомпилированном виде: функции, классы и переменные. У каждой библиотеки также есть название SONAME, включающее номер её версии, но который не обязательно совпадает с официальным номером релиза. Программы компилируются с конкретным SONAME библиотеки. Так, если какой-либо из символов библиотеки был удалён или изменён – небходимо изменить версию с тем, чтобы все зависящие от библиотеки пакеты были перекомпилированы с использованием новой версии. Обычно версии устанавливаются в источнике, и мы используем те же номера версий для двоичных пакетов, называемые “номер ABI”, но в случае, если источник не использует вменяемой версионности, создатели пакетов могут использовать отличную, более традиционную нумерацию.</p>
<p>Библиотеки обычно распространяются апстримом в виде отдельных выпусков. Иногда они распространяются, как часть программы. В последнем случае они могут быть включены в двоичный пакет вместе с программой (это называется bundling), если вы не предполагаете использование этих библиотек другими программами, но чаще их всё же следует выделять в отдельные двоичные пакеты.</p>
<p>Сами библиотеки помещаются в двоичный пакет с именем <tt class="docutils literal"><span class="pre">libfoo1</span></tt>, где <tt class="docutils literal"><span class="pre">foo</span></tt> — имя библиотеки, а <tt class="docutils literal"><span class="pre">1</span></tt> — версия из SONAME. Файлы разработки из пакета, такие как заголовочные файлы, необходимые для компиляции программ с библиотекой, помещаются в пакет с именем <tt class="docutils literal"><span class="pre">libfoo-dev</span></tt>.</p>
<div class="section" id="an-example">
<h4>Пример<a class="headerlink" href="#an-example" title="Ссылка на этот заголовок">¶</a></h4>
<p>В качестве примера мы используем libnova:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:trusty/libnova
$ sudo apt-get install libnova-dev
</pre></div>
</div>
<p>Чтобы найти SONAME библиотеки, выполните:</p>
<div class="highlight-python"><div class="highlight"><pre>$ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME
</pre></div>
</div>
<p>SONAME в данном случае <tt class="docutils literal"><span class="pre">libnova-0.12.so.2</span></tt>, что соответствует имени файла (как правило, но не всегда). Здесь апстрим поместил номер версии из апстрима, как часть SONAME, и задал ABI-версию <tt class="docutils literal"><span class="pre">2</span></tt>. Имена библиотечных пакетов должны следовать SONAME библиотеки, которую они содержат. Двоичный библиотечный пакет называется <tt class="docutils literal"><span class="pre">libnova-0.12-2</span></tt>, где <tt class="docutils literal"><span class="pre">libnova-0.12</span></tt> — имя библиотеки, а <tt class="docutils literal"><span class="pre">2</span></tt> — наш ABI-номер.</p>
<p>Если авторы из апстрима внесли несовместимые изменения в свою библиотеку, они должны изменить номер версии SONAME, а мы должны переименовать нашу библиотеку. Любые другие пакеты, использующие наш библиотечный пакет, нужно будет перекомпилировать с новой весрией, это называется переходом (transition) и требует некоторых усилий. Надо надеяться, наш ABI-номер продолжит соответствовать SONAME апстрима, но иногда они вносят несовместимости без изменения их номера версии, а нам нужно изменить наш.</p>
<p>Взглянув на debian/libnova-0.12-2.instal, мы увидим, что он включает в себя два файла:</p>
<div class="highlight-python"><div class="highlight"><pre>usr/lib/libnova-0.12.so.2
usr/lib/libnova-0.12.so.2.0.0
</pre></div>
</div>
<p>Вторая строчка — настоящая библиотека, с полным номером версии. Первая — символическая ссылка, указывающая на настоящую библиотеку. Программы, использующие библиотеку, как правило, будут пользоваться символической ссылкой.</p>
<p><tt class="docutils literal"><span class="pre">libnova-dev.install</span></tt> содержит все файлы, необходимые для компиляции программы с данной библиотекой. Заголовочные файлы, бинарник конфигурации, файл libtool’a <tt class="docutils literal"><span class="pre">.la</span></tt>, а также <tt class="docutils literal"><span class="pre">libnova.so</span></tt> – ещё один симлинк на библиотеку, создаваемый с тем, чтобы программы могли компилироваться вне зависимости от старшего номера версии (при этом, скомпилированное приложение всё равно будет зависеть от версии).</p>
<p><tt class="docutils literal"><span class="pre">.la</span></tt>-файлы libtool’а требуются на некоторых не-Linux системах с ограниченной поддержкой библиотек, но на системах Debian зачастую создают больше проблем, чем решают. <a class="reference external" href="https://wiki.debian.org/ReleaseGoals/LAFileRemoval">Цель Debian отказаться от .la-файлов</a> сегодня весьма актуальна, и вы можете помочь с решением этой задачи.</p>
</div>
<div class="section" id="static-libraries">
<h4>Статические библиотеки<a class="headerlink" href="#static-libraries" title="Ссылка на этот заголовок">¶</a></h4>
<p>Пакет -dev также содержит <tt class="docutils literal"><span class="pre">usr/lib/libnova.a</span></tt>. Это статическая библиотека, альтернатива общей библиотеке. Любая программа, скомпилированная со статической библиотекой, содержит её код непосредственно в себе. Это позволяет не беспокоиться о двоичной совместимости библиотеки. Однако это также означает, что любые ошибки, в том числе уязвимости в безопасности, не будут исправлены за счёт обновления библиотеки, пока программа не будет перекомпилирована. По этой причине использовать программы со статическими библиотеками не рекомендуется.</p>
</div>
<div class="section" id="symbol-files">
<h4>Символьные файлы<a class="headerlink" href="#symbol-files" title="Ссылка на этот заголовок">¶</a></h4>
<p>Когда приложение компилируется с библиотекой, механизм <tt class="docutils literal"><span class="pre">shlibs</span></tt> добавит к пакету зависимость от этой библиотеки. Именно поэтому большинство программ содержат <tt class="docutils literal"><span class="pre">Depends:</span> <span class="pre">${shlibs:Depends}</span></tt> в файле <tt class="docutils literal"><span class="pre">debian/control</span></tt>. Этот максов заменяется списком зависимых библиотек при билде. Однако shlibs может только указывать зависимость от старшей ABI-версии , <tt class="docutils literal"><span class="pre">2</span></tt> в нашем примере с libnova, так что если новые символы будут добавлены в будущей libnova 2.1 – приложение будет запускаться и с более старой версией libnova ABI 2.0, что приведёт к аварианому завершению.</p>
<p>Чтобы точнее указывать зависимости от библиотек, мы создали файл <tt class="docutils literal"><span class="pre">.symbols</span></tt>, который перечисляет все символы библиотеки и версии, в которых они появились.</p>
<p>libnova не имеет символьного файла, так что мы можем создать его. Начните с компиляции пакета:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -- -nc
</pre></div>
</div>
<p>Опция <tt class="docutils literal"><span class="pre">-nc</span></tt> указывает не удалять сборочные файлы после завершения компиляции. Перейдите в каталог сборки и выполните <tt class="docutils literal"><span class="pre">dpkg-gensymbols</span></tt> для пакета библиотеки:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd ../build-area/libnova-0.12.2/
$ dpkg-gensymbols -plibnova-0.12-2 > symbols.diff
</pre></div>
</div>
<p>Это создаст diff-файл, который вы сможете применить самостоятельно:</p>
<div class="highlight-python"><div class="highlight"><pre>$ patch -p0 < symbols.diff
</pre></div>
</div>
<p>Это создаст файл с именем вида <tt class="docutils literal"><span class="pre">dpkg-gensymbolsnY_WWI</span></tt>, в котором будут перечислены все символы. Он также указывает текущую версию пакета. Версию пакета можно убрать из файла, так как новые символы обычно добавляются не с новой версией пакета, а разработчиками исходной библиотеки.</p>
<div class="highlight-python"><div class="highlight"><pre>$ sed -i s,-0ubuntu2,, dpkg-gensymbolsnY_WWI
</pre></div>
</div>
<p>Теперь переместите файл туда, где он должен находиться, зафиксируйте изменения и выполните тестовую сборку:</p>
<div class="highlight-python"><div class="highlight"><pre>$ mv dpkg-gensymbolsnY_WWI ../../libnova/debian/libnova-0.12-2.symbols
$ cd ../../libnova
$ bzr add debian/libnova-0.12-2.symbols
$ bzr commit -m "add symbols file"
$ bzr builddeb
</pre></div>
</div>
<p>Если компиляция выполняется успешно, значит символьный файл не содержит ошибок. С выходом следующей апстрим-версии libnova вам придётся снова запустить dpkg-gensymbols, чтобы создать diff для обновления символьного файла.</p>
</div>
<div class="section" id="c-library-symbols-files">
<h4>Символьные файлы библиотек C++<a class="headerlink" href="#c-library-symbols-files" title="Ссылка на этот заголовок">¶</a></h4>
<p>У языка C++ более строгие стандарты на двоичную совместимость, чем у C. Команда Debian Qt/KDE поддерживает некоторые скрипты, которые помогут справиться с этим: страница <a class="reference external" href="http://pkg-kde.alioth.debian.org/symbolfiles.html">Работа с файлами symbols</a> описывает принципы их использования.</p>
</div>
<div class="section" id="further-reading">
<h4>Информация для дальнейшего чтения<a class="headerlink" href="#further-reading" title="Ссылка на этот заголовок">¶</a></h4>
<p>Статья Junichi Uekawa <a class="reference external" href="http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html">Пакетирование библиотек для Debian</a> рассматривает этот вопрос более детально.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/backports"></span><div class="section" id="backporting-software-updates">
<h3>Бэкпортирование обновлений программ<a class="headerlink" href="#backporting-software-updates" title="Ссылка на этот заголовок">¶</a></h3>
<p>Порой может потребоваться добавить функционал в стабильный релиз, который не связан с исправлением критических проблем. В подобных случаях, есть два варианта: либо вы <a class="reference external" href="https://help.launchpad.net/Packaging/PPA">загрузите его в PPA</a>, или подготовите бэкпорт (backport).</p>
<div class="section" id="personal-package-archive-ppa">
<h4>Персональные архивы пакетов (PPA)<a class="headerlink" href="#personal-package-archive-ppa" title="Ссылка на этот заголовок">¶</a></h4>
<p>Использование PPA имеет ряд преимуществ. Это достаточно просто, вам не понадобится одобрение от кого бы то ни было, но недостаток в том, что пользователям придётся вручную подключать PPA. Это нестандартный источник приложений.</p>
<p><a class="reference external" href="https://help.launchpad.net/Packaging/PPA">Документация к PPA на Launchpad</a> достаточно исчерпывающая и поможет вам быстро начать работу с ним.</p>
</div>
<div class="section" id="official-ubuntu-backports">
<h4>Официальные бэкпорты Ubuntu<a class="headerlink" href="#official-ubuntu-backports" title="Ссылка на этот заголовок">¶</a></h4>
<p>Целью проекта Backports является предоставление пользователям новой функциональности. Из-за рисков уменьшения стабильности при портировании новшеств, бэкпорты недоступны пользователям, пока они не включат их. Поэтому бэкпорты не являются местом для исправления ошибок. Если в пакете Ubuntu обнаружена ошибка, она должна быть исправлена через <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/security-and-stable-release-updates"><em>обновления безопасности и стабильности</em></a>.</p>
<p>Когда вы определите, требуется ли вам адаптировать ваши изменения для стабильного релиза, вам будет необходимо собрать и протестировать ваш пакет на данном релизе. Команда <tt class="docutils literal"><span class="pre">pbuilder-dist</span></tt> (из пакета <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt>) поможет вам сделать это.</p>
<p>Чтобы подать заявку на бэкпорт, можно использовать утилиту <tt class="docutils literal"><span class="pre">requestbackport</span></tt> (также из пакета <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt>). Она определит все промежуточные выпуски, для которых пакет также придётся бэкпортировать, покажет, какие пакеты зависят от данного, и создаст заявку. Она также включит список требуемых тестов в заявку.</p>
</div>
</div>
</div>
</div>
<div class="section" id="knowledge-base">
<h2>База знаний<a class="headerlink" href="#knowledge-base" title="Ссылка на этот заголовок">¶</a></h2>
<div class="toctree-wrapper compound">
<span id="document-ubuntu-packaging-guide/communication"></span><div class="section" id="communication-in-ubuntu-development">
<h3>Коммуникация при Разработке в Ubuntu<a class="headerlink" href="#communication-in-ubuntu-development" title="Ссылка на этот заголовок">¶</a></h3>
<p>В проекте, где подвергаются изменениям тысячи строк кода, принимается множество решений, и где сотни людей должны взаимодействовать каждый день, важно иметь эффективную связь.</p>
<div class="section" id="mailing-lists">
<h4>Почтовые рассылки<a class="headerlink" href="#mailing-lists" title="Ссылка на этот заголовок">¶</a></h4>
<p>Почтовые рассылки — это достаточно эффективный инструмент, если вы хотите обсудить идеи в команде и убедиться что вы оповестили всех, несмотря на различия в часовых поясах.</p>
<p>С точки зрения разработки, это наиболее важные из рассылок:</p>
<ul class="simple">
<li><p class="first"><a class="reference external" href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce</a> (только анонсы, самые важные объявления разработки попадают сюда)</p>
</li>
<li><p class="first"><a class="reference external" href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a> (главная дискуссия разработчиков Ubuntu )</p>
</li>
<li><p class="first"><a class="reference external" href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu">https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu</a> (обсуждения команды MOTU, получение справки по созданию пакетов)</p>
</li>
</ul>
</div>
<div class="section" id="irc-channels">
<h4>Каналы IRC<a class="headerlink" href="#irc-channels" title="Ссылка на этот заголовок">¶</a></h4>
<p>Для онлайн-дискуссии подключитесь к irc.freenode.net и присоединяйтесь к любому из каналов:</p>
<ul class="simple">
<li><p class="first">#ubuntu-devel (для главной дискуссии разработчиков)</p>
</li>
<li><p class="first">#ubuntu-motu (для обсуждений команды MOTU и получения помощи)</p>
</li>
</ul>
</div>
</div>
<span id="document-ubuntu-packaging-guide/debian-dir-overview"></span><div class="section" id="basic-overview-of-the-debian-directory">
<h3>Общий обзор каталога <tt class="docutils literal"><span class="pre">debian/</span></tt><a class="headerlink" href="#basic-overview-of-the-debian-directory" title="Ссылка на этот заголовок">¶</a></h3>
<p>Эта статья даёт краткие пояснения к различным файлам, важным для создания пакетов Ubuntu, которые содержатся в каталоге <tt class="docutils literal"><span class="pre">debian/</span></tt>. Самыми важными из них являются <tt class="docutils literal"><span class="pre">changelog</span></tt>, <tt class="docutils literal"><span class="pre">control</span></tt>, <tt class="docutils literal"><span class="pre">copyright</span></tt>, and <tt class="docutils literal"><span class="pre">rules</span></tt>. Они требуются для всех пакетов. Многие дополнительные файлы в <tt class="docutils literal"><span class="pre">debian/</span></tt> могут использоваться для настройки и изменения поведения пакета. Некоторые из этих файлов обсуждаются в этой статье, но это далеко не полный список.</p>
<div class="section" id="the-changelog">
<h4>Файл changelog<a class="headerlink" href="#the-changelog" title="Ссылка на этот заголовок">¶</a></h4>
<p>Этот файл, как следует из его названия — это список изменений, внесённых в каждую версию. Он имеет особый формат, который показывает имя пакета, версию, дистрибутив, изменения, и кто вносил изменения в данное время. Если у вас есть ключ GPG (смотрите: <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>Подготовка</em></a>), убедитесь, что вы используете в <tt class="docutils literal"><span class="pre">changelog</span></tt> те же имя и адрес электронной почты, что и в вашем ключе. Ниже приведен шаблон <tt class="docutils literal"><span class="pre">changelog</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>package (version) distribution; urgency=urgency
* change details
- more change details
* even more change details
-- maintainer name <email address>[two spaces] date
</pre></div>
</div>
<p>Формат (особенно даты) важен. Дата должна быть в формате <span class="target" id="index-2"></span><a class="rfc reference external" href="http://tools.ietf.org/html/rfc5322.html"><strong>RFC 5322</strong></a>, который можно увидеть при выполнении команды <tt class="docutils literal"><span class="pre">date</span> <span class="pre">-R</span></tt>. Для удобства, можно использовать для редактирования changelog команду <tt class="docutils literal"><span class="pre">dch</span></tt>. Она обновит дату автоматически.</p>
<p>Пункты с незначительными изменениями отмечаются дефисом «-», в то время как в важных пунктах используется звездочка «*».</p>
<p>Если вы создаёте пакет «с нуля», <tt class="docutils literal"><span class="pre">dch</span> <span class="pre">--create</span></tt> (<tt class="docutils literal"><span class="pre">dch</span></tt> находится в пакете <tt class="docutils literal"><span class="pre">devscripts</span></tt>) создаст для вас стандартный файл <tt class="docutils literal"><span class="pre">debian/changelog</span></tt>.</p>
<p>Вот пример файла <tt class="docutils literal"><span class="pre">changelog</span></tt> для hello:</p>
<div class="highlight-python"><div class="highlight"><pre>hello (2.8-0ubuntu1) trusty; urgency=low
* New upstream release with lots of bug fixes and feature improvements.
-- Jane Doe <packager@example.com> Thu, 21 Oct 2013 11:12:00 -0400
</pre></div>
</div>
<p>Обратите внимание, что версия имеет <tt class="docutils literal"><span class="pre">-0ubuntu1</span></tt> добавленный к нему, это - distro версия, используемая так, чтобы упаковка могла быть обновлена (чтобы исправить ошибки, например) с новыми закачками в той же исходной версии выпуска.</p>
<p>Ubuntu и Debian используют немного различающиеся схемы нумерации версий пакетов, чтобы избежать конфликта пакетов с одной и той же исходной версией. Если пакет Debian был изменён в Ubuntu, к концу Debian-версии добавляется <tt class="docutils literal"><span class="pre">ubuntuX</span></tt> (где <tt class="docutils literal"><span class="pre">X</span></tt> — номер редакции в Ubuntu). Таким образом, если пакет Debian hello <tt class="docutils literal"><span class="pre">2.6-1</span></tt> был изменён в Ubuntu, номер версии будет <tt class="docutils literal"><span class="pre">2.6-1ubuntu1</span></tt>. Если пакет приложения в Debian не существует, то редакция Debian равна <tt class="docutils literal"><span class="pre">0</span></tt> (например, <tt class="docutils literal"><span class="pre">2.6-0ubuntu1</span></tt>).</p>
<p>Более подробную информацию можно найти на странице <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog">changelog (Глава 4.4)</a> документа Debian Policy Manual.</p>
</div>
<div class="section" id="the-control-file">
<h4>Файл control<a class="headerlink" href="#the-control-file" title="Ссылка на этот заголовок">¶</a></h4>
<p>Файл <tt class="docutils literal"><span class="pre">control</span></tt> содержит информацию, которую использует менеджер пакетов (такой, как <tt class="docutils literal"><span class="pre">apt-get</span></tt>, <tt class="docutils literal"><span class="pre">synaptic</span></tt> или <tt class="docutils literal"><span class="pre">adept</span></tt>), сборочные зависимости, информацию мэйнтейнера и многое другое.</p>
<p>Для пакета Ubuntu <tt class="docutils literal"><span class="pre">hello</span></tt> файл <tt class="docutils literal"><span class="pre">control</span></tt> выглядит следующим образом:</p>
<div class="highlight-control"><div class="highlight"><pre><span class="k">Source</span><span class="w">: </span><span class="s">hello</span>
<span class="k">Section</span><span class="w">: </span><span class="s">devel</span>
<span class="k">Priority</span><span class="w">: </span><span class="s">optional</span>
<span class="k">Maintainer</span>: Ubuntu Developers <span class="gs"><ubuntu-devel-discuss@lists.ubuntu.com></span>
<span class="k">XSBC-Original-Maintainer</span><span class="w">: </span><span class="s">Jane Doe <packager@example.com></span>
<span class="k">Standards-Version</span><span class="w">: </span><span class="s">3.9.5</span>
<span class="k">Build-Depends</span>: <span class="nf">debhelper</span> (<span class="o">>=</span> <span class="m">7</span>)
<span class="k">Vcs-Bzr</span><span class="w">: </span><span class="s">lp:ubuntu/hello</span>
<span class="k">Homepage</span><span class="w">: </span><span class="s">http://www.gnu.org/software/hello/</span>
<span class="k">Package</span><span class="w">: </span><span class="s">hello</span>
<span class="k">Architecture</span><span class="w">: </span><span class="s">any</span>
<span class="k">Depends</span>: <span class="o">$</span>{<span class="ni">shlibs:Depends</span>}
<span class="k">Description</span><span class="gs">: The classic greeting, and a good example</span>
The GNU hello program produces a familiar, friendly greeting. It
allows non-programmers to use a classic computer science tool which
would otherwise be unavailable to them. Seriously, though: this is
an example of how to do a Debian package. It is the Debian version of
the GNU Project's `hello world' program (which is itself an example
for the GNU Project).
</pre></div>
</div>
<p>Первый абзац описывает исходный пакет, включая список пакетов, требуемых для сборки данного пакета из исходного кода, в поле <tt class="docutils literal"><span class="pre">Build-Depends</span></tt>. Он также содержит некоторую метаинформацию, такую как имя мэйнтейнера, версию Debian Policy, с которой компилируется пакет, местоположение репозитория управления версиями и домашнюю страницу апстрима.</p>
<p>Заметьте, что в Ubuntu мы указываем в поле <tt class="docutils literal"><span class="pre">Maintainer</span></tt> общий адрес, так как любой человек может изменить любой пакет (в отличие от Debian, где правом изменения пакетов обладают лишь отдельные люди или команда). Пакеты в Ubuntu, как правило, должны в поле <tt class="docutils literal"><span class="pre">Maintainer</span></tt> содержать <tt class="docutils literal"><span class="pre">Ubuntu</span> <span class="pre">Developers</span> <span class="pre"><ubuntu-devel-discuss@lists.ubuntu.com></span></tt>. Если поле Maintainer изменено, старое значение должно быть сохранено в поле <tt class="docutils literal"><span class="pre">XSBC-Original-Maintainer</span></tt>. Это можно сделать автоматически сценарием <tt class="docutils literal"><span class="pre">update-maintainer</span></tt> из пакета <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt>. Для дальнейшей информации смотрите <a class="reference external" href="https://wiki.ubuntu.com/DebianMaintainerField">Debian Maintainer Field spec</a> в Ubuntu wiki.</p>
<p>Каждый дополнительный абзац описывает бинарный пакет, который будет создан.</p>
<p>Более подробную информацию можно найти на странице <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-controlfields.html">секции control-файла (Глава 5)</a> документа Debian Policy Manual.</p>
</div>
<div class="section" id="the-copyright-file">
<h4>Файл copyright<a class="headerlink" href="#the-copyright-file" title="Ссылка на этот заголовок">¶</a></h4>
<p>Файл содержит информацию о копирайтах исходных кодов и самого пакета. Ubuntu и <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile">Debian Policy (Глава 12.5)</a> требуют, чтобы каждый пакет устанавливал неизменную копию копирайта и информации по лицензированию в папку <tt class="docutils literal"><span class="pre">/usr/share/doc/$(имя_пакета)/copyright</span></tt></p>
<p>Как правило, информацию об авторских правах можно найти в файле <tt class="docutils literal"><span class="pre">COPYING</span></tt> в каталоге с исходным кодом программы. Этот файл должен включать такую информацию, как имена автора и упаковщика, URL, из которого получен источник, строку со значком копирайта с указанием года и владельца авторских прав, а также сам текст авторского права. Шаблон для примера:</p>
<div class="highlight-python"><div class="highlight"><pre>Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Hello
Source: ftp://ftp.example.com/pub/games
Files: *
Copyright: Copyright 1998 John Doe <jdoe@example.com>
License: GPL-2+
Files: debian/*
Copyright: Copyright 1998 Jane Doe <packager@example.com>
License: GPL-2+
License: GPL-2+
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more
details.
.
You should have received a copy of the GNU General Public
License along with this package; if not, write to the Free
Software Foundation, Inc., 51 Franklin St, Fifth Floor,
Boston, MA 02110-1301 USA
.
On Debian systems, the full text of the GNU General Public
License version 2 can be found in the file
`/usr/share/common-licenses/GPL-2'.
</pre></div>
</div>
<p>Пример испольует <a class="reference external" href="http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/">машино-понятный формат debian/copyright</a>, и авторам пакетов также рекомендуется следовать этому формату.</p>
</div>
<div class="section" id="the-rules-file">
<h4>Файл rules<a class="headerlink" href="#the-rules-file" title="Ссылка на этот заголовок">¶</a></h4>
<p>Последний файл, который мы рассмотрим, это <tt class="docutils literal"><span class="pre">rules</span></tt>. Он выполняет всю работу по сборке нашего пакета. Это Makefile, в котором есть функции компиляции программы, её установки и создания <tt class="docutils literal"><span class="pre">.deb</span></tt>-пакета из установленных файлов. В нём есть также функция очистки файлов сборки, которая удаляет всё, кроме собственно пакета исходного кода.</p>
<p>Вот упрощённый пример файла rules, созданного <tt class="docutils literal"><span class="pre">dh_make</span></tt> (который можно найти в пакете <tt class="docutils literal"><span class="pre">dh-make</span></tt>):</p>
<div class="highlight-makefile"><div class="highlight"><pre><span class="c">#!/usr/bin/make -f</span>
<span class="c"># -*- makefile -*-</span>
<span class="c"># Uncomment this to turn on verbose mode.</span>
<span class="c">#export DH_VERBOSE=1</span>
<span class="nf">%</span><span class="o">:</span>
dh <span class="nv">$@</span>
</pre></div>
</div>
<p>Давайте рассмотрим этот файл внимательнее. На каждом этапе сборки <tt class="docutils literal"><span class="pre">debian/rules</span></tt> вызывается с аргументом, который передаётся <tt class="docutils literal"><span class="pre">/usr/bin/dh</span></tt>, который, в свою очередь, вызывает необходимые команды <tt class="docutils literal"><span class="pre">dh_*</span></tt>.</p>
<p><tt class="docutils literal"><span class="pre">dh</span></tt> запускает последовательность команд debhelper. Поддерживаемые последовательности соответствуют целям файла <tt class="docutils literal"><span class="pre">debian/rules</span></tt>: «build», «clean», «install», «binary-arch», «binary-indep» и «binary». Чтобы увидеть, какие команды выполняются в каждой цели, наберите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dh binary-arch --no-act
</pre></div>
</div>
<p>Командам из последовательности <tt class="docutils literal"><span class="pre">binary-indep</span></tt> передаётся аргумент <tt class="docutils literal"><span class="pre">-i</span></tt>, чтобы они затрагивали только архитектурно-независимые пакеты, а командам из последовательности <tt class="docutils literal"><span class="pre">binary-arch</span></tt> — аргумент <tt class="docutils literal"><span class="pre">-a</span></tt>, чтобы онм затрагивали только архитектурно-зависимые пакеты.</p>
<p>Каждая команда debhelper при её успешном выполненении делает запись в журнале <tt class="docutils literal"><span class="pre">debian/package.debhelper.log</span></tt> (который затем удаляет dh_clean.) Таким образом dh может определить, какие команды уже были выполнены и для каких пакетов, что помогает избежать повторного выполнения этих команд.</p>
<p>При каждом запуске <tt class="docutils literal"><span class="pre">dh</span></tt> он изучает журнал, находит добавленные последними команды, которые относятся к указанной последовательности. Затем он продолжает выполнение со следующей команды в этой последовательности. Опции <tt class="docutils literal"><span class="pre">--until</span></tt>, <tt class="docutils literal"><span class="pre">--before</span></tt>, <tt class="docutils literal"><span class="pre">--after</span></tt> и <tt class="docutils literal"><span class="pre">--remaining</span></tt> могут изменить это поведение.</p>
<p>Если в <tt class="docutils literal"><span class="pre">debian/rules</span></tt> есть функция с именем, похожим на <tt class="docutils literal"><span class="pre">override_dh_команда</span></tt>, то вместо данной команды <tt class="docutils literal"><span class="pre">dh</span></tt> выполнит данную функцию. Эта функция может запустить ту же команду с другими аргументами, или же совершенно другую команду. (Замечание: для использования этой функциональности при сборке требуется пакет debhelper версии не менее 7.0.50).</p>
<p>За дополнительными примерами обратитесь к <tt class="docutils literal"><span class="pre">/usr/share/doc/debhelper/examples/</span></tt> и <tt class="docutils literal"><span class="pre">man</span> <span class="pre">dh</span></tt>. Смотрите также <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules">раздел о файле rules (Раздел 4.9)</a> в «Debian Policy Manual».</p>
</div>
<div class="section" id="additional-files">
<h4>Дополнительные файлы<a class="headerlink" href="#additional-files" title="Ссылка на этот заголовок">¶</a></h4>
<div class="section" id="the-install-file">
<h5>Файл install<a class="headerlink" href="#the-install-file" title="Ссылка на этот заголовок">¶</a></h5>
<p>Файл <tt class="docutils literal"><span class="pre">install</span></tt> используется <tt class="docutils literal"><span class="pre">dh_install</span></tt> для установки файлов в двоичный пакет. Он имеет два стандартных варианта использования:</p>
<ul class="simple">
<li><p class="first">Для установки в ваш пакет файлов, не установленных оригинальной системой сборки.</p>
</li>
<li><p class="first">Разделение одного большого пакета источника на несколько бинарных пакетов.</p>
</li>
</ul>
<p>В первом случае файл <tt class="docutils literal"><span class="pre">install</span></tt> должен содержать одну строку для каждого устанавливаемого файла, указывающую как файл, так и установочный каталог. Например, следующий файл <tt class="docutils literal"><span class="pre">install</span></tt> установит сценарий <tt class="docutils literal"><span class="pre">foo</span></tt> из корневого каталога пакета исходного кода в <tt class="docutils literal"><span class="pre">usr/bin</span></tt> и desktop-файл из каталога <tt class="docutils literal"><span class="pre">debian</span></tt> в <tt class="docutils literal"><span class="pre">usr/share/applications</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>foo usr/bin
debian/bar.desktop usr/share/applications
</pre></div>
</div>
<p>Если пакет исходного кода производит несколько двоичных пакетов, <tt class="docutils literal"><span class="pre">dh</span></tt> установит файлы в <tt class="docutils literal"><span class="pre">debian/tmp</span></tt> вместо установки непосредственно в <tt class="docutils literal"><span class="pre">debian/<пакет></span></tt>. Файлы, установленные в <tt class="docutils literal"><span class="pre">debian/tmp</span></tt> затем можно переместить в отдельные двоичные пакеты с помощью нескольких файлов <tt class="docutils literal"><span class="pre">$имя_пакета.install</span></tt>. Это часто делается, чтобы разбить большое количество не зависящих от архитектуры данных из зависящих от архитектуры пакетов в пакеты <tt class="docutils literal"><span class="pre">Architecture:</span> <span class="pre">all</span></tt>. В этом случае нужно указать только имена устанавливаемых файлов (или каталогов), без установочного каталога. Например, <tt class="docutils literal"><span class="pre">foo.install</span></tt>, содерщащий только зависящие от архитектуры файлы, может выглядеть наподобие:</p>
<div class="highlight-python"><div class="highlight"><pre>usr/bin/
usr/lib/foo/*.so
</pre></div>
</div>
<p>В то время как <tt class="docutils literal"><span class="pre">foo-common.install</span></tt>, содержащий только не зависящие от архитектуры файлы, может выглядеть так:</p>
<div class="highlight-python"><div class="highlight"><pre>/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/
</pre></div>
</div>
<p>Будут созданы два двоичных пакета: <tt class="docutils literal"><span class="pre">foo</span></tt> и <tt class="docutils literal"><span class="pre">foo-common</span></tt>. Для обоих требуется их собственный абзац в <tt class="docutils literal"><span class="pre">debian/control</span></tt>.</p>
<p>Для дополнительных подробностей смотрите <tt class="docutils literal"><span class="pre">man</span> <span class="pre">dh_install</span></tt> и <a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install">раздел о файле install (Раздел 5.11)</a> в «Debian New Maintainers’ Guide».</p>
</div>
<div class="section" id="the-watch-file">
<h5>Файл watch<a class="headerlink" href="#the-watch-file" title="Ссылка на этот заголовок">¶</a></h5>
<p>Файл <tt class="docutils literal"><span class="pre">debian/watch</span></tt> позволяет автоматически проверять наличие новых версий в апстриме с помощью инструмента <tt class="docutils literal"><span class="pre">uscan</span></tt> из пакета <tt class="docutils literal"><span class="pre">devscripts</span></tt>. Первой строкой файла watch должна быть версия формата (3 на момент написания этого руководства), а следующий строки содержат любые URL для анализа. Например:</p>
<div class="highlight-python"><div class="highlight"><pre>version=3
http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz
</pre></div>
</div>
<p>Запуск <tt class="docutils literal"><span class="pre">uscan</span></tt> в корневом каталоге исходников сравнит номер апстрим-версии в <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> с последней доступной в апстриме версией. Если в апстриме найдена новая версия, она будет автоматически загружена. Например:</p>
<div class="highlight-python"><div class="highlight"><pre>$ uscan
hello: Newer version (2.7) available on remote site:
http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz
(local version is 2.6)
hello: Successfully downloaded updated package hello-2.7.tar.gz
and symlinked hello_2.7.orig.tar.gz to it
</pre></div>
</div>
<p>Если ваши tarball-файлы обитают на Launchpad, файл <tt class="docutils literal"><span class="pre">debian/watch</span></tt> имеет немного более сложный вид (о том, почему это так, смотрите <a class="reference external" href="https://answers.launchpad.net/launchpad/+question/21146">Question 21146</a> и <a class="reference external" href="https://launchpad.net/launchpad/+bug/231797">Bug 231797</a>). В этому случае используйте нечто вроде:</p>
<div class="highlight-python"><div class="highlight"><pre>version=3
https://launchpad.net/flufl.enum/+download http://launchpad.net/flufl.enum/.*/flufl.enum-(.+).tar.gz
</pre></div>
</div>
<p>Дополнительные сведения смотрите в <tt class="docutils literal"><span class="pre">man</span> <span class="pre">uscan</span></tt> и в <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch">разделе о файле watch (Раздел 4.11)</a> «Debian Policy Manual».</p>
<p>Список пакетов, для которых файл <tt class="docutils literal"><span class="pre">watch</span></tt> сообщает о том, что они не синхронизированы с апстримом, смотрите <a class="reference external" href="http://qa.ubuntuwire.org/uehs/no_updated.html">Ubuntu External Health Status</a>.</p>
</div>
<div class="section" id="the-source-format-file">
<h5>Файл source/format<a class="headerlink" href="#the-source-format-file" title="Ссылка на этот заголовок">¶</a></h5>
<p>Этот файл указывает формат пакета исходного кода. Он должен содержать одну строку, показывающую выбранный формат:</p>
<ul class="simple">
<li><p class="first"><tt class="docutils literal"><span class="pre">3.0</span> <span class="pre">(native)</span></tt> для «родных» пакетов Debian (апстрим-версия отсутствует)</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">3.0</span> <span class="pre">(quilt)</span></tt> для пакетов с отдельным тарболом из апстрима</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">1.0</span></tt> для пакетов, желающих явно указать формат по умолчанию</p>
</li>
</ul>
<p>В настоящее время по умолчанию выбирается формат пакета исходного кода 1.0, если этот файл отсутствует. В файле source/format можно указать его явно. Если вы не используете этот файл для указания формата исходного кода, Lintian выдаст предупреждение об отстутствии файла. Это чисто информационное предупреждение и его можно без опасений проигнорировать.</p>
<p>Рекомендуется использовать более новый формат 3.0. Он предоставляет некоторые новые возможности:</p>
<ul class="simple">
<li><p class="first">Поддержка дополнительных форматов сжатия: bzip2, lzma и xz</p>
</li>
<li><p class="first">Поддержка нескольких архивов с оригинальным исходным кодом</p>
</li>
<li><p class="first">Необязательно перепаковывать архив с оригинальным исходным кодом, чтобы удалить директорию <tt class="docutils literal"><span class="pre">debian</span></tt>.</p>
</li>
<li><p class="first">Специфичные для Debian изменения теперь хранятся не в одном файле .diff.gz, а в виде нескольких патчей, совместимых с quilt, в каталоге <tt class="docutils literal"><span class="pre">debian/patches/</span></tt></p>
</li>
</ul>
<p><a class="reference external" href="https://wiki.debian.org/Projects/DebSrc3.0">https://wiki.debian.org/Projects/DebSrc3.0</a> содержит дополнительную информацию касательно перехода на версию 3.0 формата исходных пакетов.</p>
<p>Дополнительную информацию можно найти в <tt class="docutils literal"><span class="pre">man</span> <span class="pre">dpkg-source</span></tt> и в <a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcef">Главе source/format (Глава 5.21)</a> руководства Debian New Maintainers.</p>
</div>
</div>
<div class="section" id="additional-resources">
<h4>Дополнительные ресурсы<a class="headerlink" href="#additional-resources" title="Ссылка на этот заголовок">¶</a></h4>
<p>Кроме Debian Policy Manual, на который ссылается статья, руководство Debian New Maintainers’ Guide содержит более детальное описание для каждого файла. <a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dreq.en.html">Глава 4, “Необходимые файлы в папке debian”</a> описывает файлы control, changelog, copyright и rules. <a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dother.en.html">Глава 5, “Прочие файлы в папке debian”</a> описывает дополнительные файлы, которые можно использовать.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/auto-pkg-test"></span><div class="section" id="autopkgtest-automatic-testing-for-packages">
<h3>autopkgtest: Автоматическое тестирование пакетов<a class="headerlink" href="#autopkgtest-automatic-testing-for-packages" title="Ссылка на этот заголовок">¶</a></h3>
<p><a class="reference external" href="http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst">Спецификация DEP 8</a> определяет, как можно легко интегрировать автоматическое тестирование в ваши пакеты. Для этого, необходимо:</p>
<ul>
<li><p class="first">добавить следующую строчку к разделу Source в <tt class="docutils literal"><span class="pre">debian/control</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>XS-Testsuite: autopkgtest
</pre></div>
</div>
</li>
<li><p class="first">добавить файл <tt class="docutils literal"><span class="pre">debian/tests/control</span></tt>, который определяет требования к тестовому окружению,</p>
</li>
<li><p class="first">добавить тесты в <tt class="docutils literal"><span class="pre">debian/tests</span></tt>.</p>
</li>
</ul>
<div class="section" id="testbed-requirements">
<h4>Требования к тестовому окружению<a class="headerlink" href="#testbed-requirements" title="Ссылка на этот заголовок">¶</a></h4>
<p>В файле <tt class="docutils literal"><span class="pre">debian/tests/control</span></tt> вы можете определить требования к тестовому окружению. Например, если тесты не проходят при сборке, или требуются права <tt class="docutils literal"><span class="pre">root</span></tt> – вы перечисляете необходимые для тестов пакеты. В <a class="reference external" href="http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst">Спецификации DEP 8</a> вы найдёте все доступные опции.</p>
<p>Ниже мы рассмотрим пакет исходного кода <tt class="docutils literal"><span class="pre">glib2.0</span></tt>. В очень простом случае он будет выглядеть так:</p>
<div class="highlight-python"><div class="highlight"><pre>Tests: build
Depends: libglib2.0-dev, build-essential
</pre></div>
</div>
<p>Это будет означать, что для теста <tt class="docutils literal"><span class="pre">debian/tests/build</span></tt> требуются пакеты <tt class="docutils literal"><span class="pre">libglib2.0-dev</span></tt> и <tt class="docutils literal"><span class="pre">build-essential</span></tt>.</p>
<div class="admonition note">
<p class="first admonition-title">Примечание</p>
<p class="last">В поле <tt class="docutils literal"><span class="pre">Depends</span></tt> можно указать <tt class="docutils literal"><span class="pre">@</span></tt>, если вы хотите установки всех бинарных пакетов, собранных из рассматриваемого пакета исходного кода.</p>
</div>
</div>
<div class="section" id="the-actual-tests">
<h4>Настоящие тесты<a class="headerlink" href="#the-actual-tests" title="Ссылка на этот заголовок">¶</a></h4>
<p>Тест, соответствующий рассмотренному выше примеру, будет выглядеть так:</p>
<div class="highlight-sh"><div class="highlight"><pre><span class="c">#!/bin/sh</span>
<span class="c"># autopkgtest check: Build and run a program against glib, to verify that the</span>
<span class="c"># headers and pkg-config file are installed correctly</span>
<span class="c"># (C) 2012 Canonical Ltd.</span>
<span class="c"># Author: Martin Pitt <martin.pitt@ubuntu.com></span>
<span class="nb">set</span> -e
<span class="nv">WORKDIR</span><span class="o">=</span><span class="k">$(</span>mktemp -d<span class="k">)</span>
<span class="nb">trap</span> <span class="s2">"rm -rf </span><span class="nv">$WORKDIR</span><span class="s2">"</span> <span class="m">0</span> INT QUIT ABRT PIPE TERM
<span class="nb">cd</span> <span class="nv">$WORKDIR</span>
cat <span class="s"><<EOF > glibtest.c</span>
<span class="s">#include <glib.h></span>
<span class="s">int main()</span>
<span class="s">{</span>
<span class="s"> g_assert_cmpint (g_strcmp0 (NULL, "hello"), ==, -1);</span>
<span class="s"> g_assert_cmpstr (g_find_program_in_path ("bash"), ==, "/bin/bash");</span>
<span class="s"> return 0;</span>
<span class="s">}</span>
<span class="s">EOF</span>
gcc -o glibtest glibtest.c <span class="sb">`</span>pkg-config --cflags --libs glib-2.0<span class="sb">`</span>
<span class="nb">echo</span> <span class="s2">"build: OK"</span>
<span class="o">[</span> -x glibtest <span class="o">]</span>
./glibtest
<span class="nb">echo</span> <span class="s2">"run: OK"</span>
</pre></div>
</div>
<p>Здесь небольшая программа на языке C копируется во временную директорию, затем компилируется с использованием системных библиотек (с использованием флагов и путей к библиотекам, определённых через <tt class="docutils literal"><span class="pre">pkg-config</span></tt>). Затем запускается скомпилированный файл, который запускает несколько основных функций glib.</p>
<p>Хотя этот тест очень маленький и простой, он проверяет многое: что ваш -dev пакет имеет все необходимые зависимости, что ваш пакет устанавливает рабочие файлы pkg-config, заголовочные файлы и библиотеки помещаются в нужное место, или что компилятор и компоновщик работают. Это помогает обнаружить критические ошибки на ранней стадии.</p>
</div>
<div class="section" id="executing-the-test">
<h4>Выполнение теста<a class="headerlink" href="#executing-the-test" title="Ссылка на этот заголовок">¶</a></h4>
<p>Несмотря на то, что скрипт тестирования может быть запущен напрямую, всё же рекомендуется использовать <tt class="docutils literal"><span class="pre">adt-run</span></tt> из пакета <tt class="docutils literal"><span class="pre">autopkgtest</span></tt> для проверки прохождения тестов; в противном случае, если тест покажет ошибку в системе Ubuntu Continuous Integration (CI) – пакет не пройдёт в Ubuntu. Заодно можно избежать “замусоривания” Вашей рабочей станции тестовыми пакетами и конфигурациями в случае, если тест совершает нечто более серьёзное в отношении системы, чем в примере выше.</p>
<p>В документации <a class="reference external" href="file:///usr/share/doc/autopkgtest/RREADME.running-tests.html">README.running-tests</a> (<a class="reference external" href="http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst">онлайн-версия:</a>) объясняются все доступные тестовые окружения (schroot, LXC, QEMU, etc) и приводятся наиболее популярные способы запуска тестов через <tt class="docutils literal"><span class="pre">adt-run</span></tt>. Например, с локальной сборкой бинарников, локально модифицируемыми тестами, и т.д.</p>
<p>Система непрерывной интеграции Ubuntu CI использует эмулятор QEMU и запускает тесты из пакетов в архиве, с включённом флагом <tt class="docutils literal"><span class="pre">-proposed</span></tt>. Чтобы вручную получить то же окружение, сначала необходимо установить следующие пакеты:</p>
<div class="highlight-python"><div class="highlight"><pre>sudo apt-get install autopkgtest qemu-system qemu-utils
</pre></div>
</div>
<p>Теперь выполните сборку тестового окружения, выполнив следующее:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">adt</span><span class="o">-</span><span class="n">buildvm</span><span class="o">-</span><span class="n">ubuntu</span><span class="o">-</span><span class="n">cloud</span> <span class="o">-</span><span class="n">v</span>
</pre></div>
</div>
<p>(Более подробно о выборе других релизов, архитектур, целевых директорий, и об использовании прокси – в manpage и в выводе опции <tt class="docutils literal"><span class="pre">--help</span></tt>). Эта команда выполнит сборку, например <tt class="docutils literal"><span class="pre">adt-trusty-amd64-cloud.img</span></tt>.</p>
<p>Теперь запустите тесты исходного пакета, например <tt class="docutils literal"><span class="pre">libpng</span></tt>, в образе QEMU:</p>
<div class="highlight-python"><div class="highlight"><pre>adt-run libpng --- qemu adt-trusty-amd64-cloud.img
</pre></div>
</div>
<p>Система Ubuntu CI запускает пакеты с включённым флагом <tt class="docutils literal"><span class="pre">-proposed</span></tt>; чтобы включить это, запустите:</p>
<div class="highlight-python"><div class="highlight"><pre>adt-run libpng -U --apt-pocket=proposed --- qemu adt-trusty-amd64-cloud.img
</pre></div>
</div>
<p>Man-страница <tt class="docutils literal"><span class="pre">adt-run</span></tt> содержит много ценной информации по другим параметрам тестирования.</p>
</div>
<div class="section" id="further-examples">
<h4>Дальнейшие примеры<a class="headerlink" href="#further-examples" title="Ссылка на этот заголовок">¶</a></h4>
<p>Этот список не полон, но может помочь вам получить представление о том, как автоматические тесты реализованы, и как они используются в Ubuntu.</p>
<ul class="simple">
<li><p class="first">Для библиотеки <a class="reference external" href="https://bazaar.launchpad.net/+branch/ubuntu/libxml2/files/head:/debian/tests/">libxml2</a> , тесты очень похожи. Они так же запускают тестовую сборку простого кода на C и выполняют его.</p>
</li>
<li><p class="first">Пакет <cite>gtk+3.0 tests <gtk3_></cite> также компилирует/линкует/запускает проверку в тесте “build”. Также есть дополнительный тест “python3-gi”, проверяющий что библиотека GTK может быть использована во время теста.</p>
</li>
<li><p class="first">В пакете <a class="reference external" href="https://bazaar.launchpad.net/+branch/ubiquity/files/head:/debian/tests/">ubiquity tests</a> используется набор тестов родительского пакета</p>
</li>
<li><p class="first">Пакет <a class="reference external" href="https://bazaar.launchpad.net/+branch/ubuntu/gvfs/files/head:/debian/tests/">gvfs tests</a> – очень интересный пример: он тестирует свой функционал “по полной”, включая эмуляцию CD, Samba, DAV и прочих компонентов.</p>
</li>
</ul>
</div>
<div class="section" id="ubuntu-infrastructure">
<h4>Инфраструктура Ubuntu<a class="headerlink" href="#ubuntu-infrastructure" title="Ссылка на этот заголовок">¶</a></h4>
<p>Пакеты с включённым <tt class="docutils literal"><span class="pre">autopkgtest</span></tt> будут тестироваться при выгрузке, или если обновятся какие-либо зависимости. Результат работы <a class="reference external" href="https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/">автоматический запуск тестов autopkgtest</a> может быть просмотрет на сайте, и он регулярно обновляется.</p>
<p>Debian также использует <tt class="docutils literal"><span class="pre">adt-run</span></tt> для запуска тестов пакета, но на данный момент – только в окружении schroot, так что результаты могут отличаться. Результаты и логи можно посмотреть по ссылке <a class="reference external" href="http://ci.debian.net">http://ci.debian.net</a>. Пожалуйста, также отправляйте исправления для тестов или новые тесты в Debian.</p>
</div>
<div class="section" id="getting-the-test-into-ubuntu">
<h4>Добавление теста в Ubuntu<a class="headerlink" href="#getting-the-test-into-ubuntu" title="Ссылка на этот заголовок">¶</a></h4>
<p>Процесс добавления и отправки autopkgtest-теста для пакетов очень похож на <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>процесс исправления ошибок в Ubuntu</em></a>. Достаточно лишь:</p>
<ul class="simple">
<li><p class="first">выполните <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">branch</span> <span class="pre">ubuntu:<имя_пакета></span></tt>,</p>
</li>
<li><p class="first">включите тесты в <tt class="docutils literal"><span class="pre">debian/control</span></tt>,</p>
</li>
<li><p class="first">создайте директорию <tt class="docutils literal"><span class="pre">debian/tests</span></tt>,</p>
</li>
<li><p class="first">создайте <tt class="docutils literal"><span class="pre">debian/tests/control</span></tt>, основываясь на <a class="reference external" href="http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst">Спецификации DEP 8</a>,</p>
</li>
<li><p class="first">добавьте ваши тесты в <tt class="docutils literal"><span class="pre">debian/tests</span></tt>,</p>
</li>
<li><p class="first">закоммитьте ваши изменения, отправьте их на Launchpad, предложите merge и дождитесь его рассмотрения и дождаться, – в точности как с любыми другими улучшениями в исходных пакетах.</p>
</li>
</ul>
</div>
<div class="section" id="what-you-can-do">
<h4>Чем вы можете помочь<a class="headerlink" href="#what-you-can-do" title="Ссылка на этот заголовок">¶</a></h4>
<p>Команда Ubuntu Engineering собрала <a class="reference external" href="https://wiki.ubuntu.com/QATeam/RequiredTests">список необходимых тестов</a>, в котором пакеты, нуждающиеся в тестировании, распределены по категориям. Там можно найти примеры таких тестов и взять их на себя.</p>
<p>Если вы столкнётесь с проблемами, присоединяйтесь к IRC на канал <a class="reference external" href="http://webchat.freenode.net/?channels=ubuntu-quality">#ubuntu-quality IRC channel</a>: разработчики наверняка вам помогут.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-getting-the-source"></span><div class="section" id="getting-the-source">
<h3>Получение исходного кода<a class="headerlink" href="#getting-the-source" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="source-package-urls">
<h4>URL пакетов исходного кода<a class="headerlink" href="#source-package-urls" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar предоставляет несколько очень удобных сокращений для доступа к веткам исходного кода с Launchpad для пакетов как Ubuntu, так и Debian.</p>
<p>Чтобы сослаться на ветки исходного кода, используйте:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:package
</pre></div>
</div>
<p>где <em>package</em> — имя пакета, который вам нужен. Этот URL ссылается на пакеты в текущей разрабатываемой версии Ubuntu. Чтобы сослаться на ветку Tomboy в разрабатываемой версии, нужно использовать:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:tomboy
</pre></div>
</div>
<p>Чтобы сделать отсылку к версии исходного пакета в более старом релизе Ubuntu просто добавьте пакету префикс с кодовым именем релиза. Например, для отсылки к исходному пакету Tomboy в <a class="reference external" href="https://wiki.ubuntu.com/SaucySalamander">Saucy</a> используйте:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:saucy/tomboy
</pre></div>
</div>
<p>Поскольку первые буквы кодовых имён не повторяются, можно сократить имя выпуска:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:s/tomboy
</pre></div>
</div>
<p>Похожую схему можно использовать для доступа к веткам исходного кода в Debian, хотя здесь нет сокращений для имён выпусков Debian. Чтобы получить доступ к ветке Tomboy в текущем разрабатываемом выпуске Debian, используйте:</p>
<div class="highlight-python"><div class="highlight"><pre>debianlp:tomboy
</pre></div>
</div>
<p>также для доступа к Tomboy в Debian <a class="reference external" href="http://www.debian.org/releases/stable/">Wheezy</a> используйте:</p>
<div class="highlight-python"><div class="highlight"><pre>debianlp:wheezy/tomboy
</pre></div>
</div>
</div>
<div class="section" id="id1">
<h4>Получение исходного кода<a class="headerlink" href="#id1" title="Ссылка на этот заголовок">¶</a></h4>
<p>Каждый пакет исходного кода в Ubuntu связан с веткой исходного кода на Launchpad. Launchpad автоматически обновляет эти ветки исходного кода, хотя процесс не полностью «защищён от дурака».</p>
<p>Есть несколько вещей, которые мы сделаем в первую очередь, чтобы сделать рабочий процесс более эффективным впоследствии. После того, как вы освоите процесс, вы узнаете, когда имеет смысл пропускать эти этапы.</p>
<div class="section" id="creating-a-shared-repository">
<span id="branching"></span><h5>Создание общедоступного хранилища<a class="headerlink" href="#creating-a-shared-repository" title="Ссылка на этот заголовок">¶</a></h5>
<p>К примеру, Вы хотите работать над пакетом Tomboy, и Вы уже проверили, что исходный пакет называется <tt class="docutils literal"><span class="pre">tomboy</span></tt>. Перед фактическим ветвлением кода для Tomboy создайте общедоступный репозиторий для хранения ветвей этого пакета. Общедоступный репозиторий сделает будущую работу более эффективной.</p>
<p>Воспользуйтесь для этого командой <cite>bzr init-repo</cite>, передав ей имя каталога, который вы хотите использовать:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr init-repo tomboy
</pre></div>
</div>
<p>Вы увидите, что в вашей текущей рабочей области создан каталог <cite>tomboy</cite>. Перейдите в него для продолжения работы:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy
</pre></div>
</div>
</div>
<div class="section" id="getting-the-trunk-branch">
<h5>Получение ветки trunk<a class="headerlink" href="#getting-the-trunk-branch" title="Ссылка на этот заголовок">¶</a></h5>
<p>Мы используем команду <cite>bzr branch</cite> для создания локальной ветки пакета. Целевой каталог назовём <cite>tomboy.dev</cite>, просто потому, что так легче запомнить:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:tomboy tomboy.dev
</pre></div>
</div>
<p>Каталог tomboy.dev представляет собой версию Tomboy в разрабатываемой версии Ubuntu, и вы всегда можете перейти в этот каталог и выполнить <cite>bzr pull</cite> для получения любых будущих обновлений.</p>
</div>
<div class="section" id="ensuring-the-version-is-up-to-date">
<span id="up-to-date"></span><h5>Проверка актуальности версии<a class="headerlink" href="#ensuring-the-version-is-up-to-date" title="Ссылка на этот заголовок">¶</a></h5>
<p>Когда Вы делаете свою <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">branch</span></tt>, то получите сообщение о том является ли ветвь пакетов актуальной. К примеру:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:tomboy
Most recent Ubuntu version: 1.8.0-1ubuntu1.2
Packaging branch status: CURRENT
Branched 86 revisions.
</pre></div>
</div>
<p>Иногда импорт не проходит успешно и ветви пакета не совпадают с теми, что находятся в архиве. Сообщение:</p>
<div class="highlight-python"><div class="highlight"><pre>Packaging branch status: OUT-OF-DATE
</pre></div>
</div>
<p>означает, что импорт не удался. Вы можете узнать причину по ссылке: <a class="reference external" href="http://package-import.ubuntu.com/status/">http://package-import.ubuntu.com/status/</a> и <a class="reference external" href="https://bugs.launchpad.net/udd">отправить баг в UDD</a> для разрешение проблемы.</p>
</div>
<div class="section" id="upstream-tar">
<h5>Tar-файл из апстрима<a class="headerlink" href="#upstream-tar" title="Ссылка на этот заголовок">¶</a></h5>
<p>Получить tar из апстрима можно с помощью:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr get-orig-source
</pre></div>
</div>
<p>Таким образом пробуются несколько методов для попадания в tar апстрима, сначала воссоздавая его из тега <tt class="docutils literal"><span class="pre">upstream-x.y</span></tt> в архиве bzr, затем скачивая из архива Ubuntu, а потом запуская <tt class="docutils literal"><span class="pre">debian/rules</span> <span class="pre">get-orig-source</span></tt>. Tar апстрима также будет воссоздан при использовании bzr для построения пакета:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr builddeb
</pre></div>
</div>
<p>У плагина <cite>builddeb</cite> есть несколько <a class="reference external" href="http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/view/head:/doc/user_manual/configuration.rst">опций конфигурации</a>.</p>
</div>
<div class="section" id="getting-a-branch-for-a-particular-release">
<h5>Получение ветки для определённого выпуска<a class="headerlink" href="#getting-a-branch-for-a-particular-release" title="Ссылка на этот заголовок">¶</a></h5>
<p>Если Вы хотите сделать что-то вроде <a class="reference external" href="https://wiki.ubuntu.com/StableReleaseUpdates">обновления стабильного релиза</a> (SRU), либо просто хотите изучить код в старом релизе, Вам нужно выбрать ветвь, соответствующую определенному релизу Ubuntu. К примеру, чтобы получить пакет Tomboy для Quantal:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:m/tomboy quantal
</pre></div>
</div>
</div>
<div class="section" id="importing-a-debian-source-package">
<h5>Импорт пакета исходного кода Debian<a class="headerlink" href="#importing-a-debian-source-package" title="Ссылка на этот заголовок">¶</a></h5>
<p>Если пакет, над которым Вы хотите работать, доступен в Debian, но не в Ubuntu - код легко импортировать в локальную ветку bzr для разработки. К примеру, Вы хотите импортировать исходный пакет <cite>newpackage</cite>. Мы начнем с создания общедоступного репозитория в качестве обычного, но нам также надо создать рабочее дерево, в которое будет импортирован исходный пакет (не забудьте выполнить cd out директории <cite>tomboy</cite>, созданной выше):</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr init-repo newpackage
$ cd newpackage
$ bzr init debian
$ cd debian
$ bzr import-dsc http://ftp.de.debian.org/debian/pool/main/n/newpackage/newpackage_1.0-1.dsc
</pre></div>
</div>
<p>Как Вы видите - нужно просто указать удаленное расположение файла dsc, а Bazaar сделает все остальное. Теперь у Вас есть исходная ветка Bazaar.</p>
</div>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-working"></span><div class="section" id="working-on-a-package">
<h3>Работа с пакетом<a class="headerlink" href="#working-on-a-package" title="Ссылка на этот заголовок">¶</a></h3>
<p>Как только у Вас есть ветка с исходным пакетом в общедоступном репозитории, Вы захотите создать дополнительные ветки для фиксов или другой запланированной работы. Вы захотите, чтобы Ваша ветка основывалась на пакете исходной ветки релиза distro, куда Вы планируете загружать. Обычно это текущий релиз разработки, но это могут быть и более старые релизы, если Вы, к примеру, выполняете обратный порт на SRU.</p>
<div class="section" id="branching-for-a-change">
<h4>Ветвление для изменений<a class="headerlink" href="#branching-for-a-change" title="Ссылка на этот заголовок">¶</a></h4>
<p>Первым делом убедитесь, что ветка исходного пакета актуальна. Если Вы ее только что проверили, то она будет актуальной, если же нет, то сделайте следующее:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy.dev
$ bzr pull
</pre></div>
</div>
<p>Будут показаны любые обновления касательно пакета, которые были загружены с момента отладки. Вы не хотите вносить изменения в эту ветку. Вместо этого создайте ветку, которая будет содержать только те изменения, которые Вы собираетесь внести. Предположим, Вы хотите исправить баг 12345 для проекта Tomboy. Когда Вы находитесь в общедоступном репозитории, ранее созданном для Tomboy, Вы можете создать ветку для исправления багов следующим образом:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch tomboy.dev bug-12345
$ cd bug-12345
</pre></div>
</div>
<p>Теперь Вы можете выполнять всю работу в директории <tt class="docutils literal"><span class="pre">bug-12345</span></tt>. Делайте там все необходимые изменения, не забывая по ходу дела отправлять свою работу. Этот процесс схож с разработкой любых приложений при помощи Bazaar. Можно делать промежуточные отправки так часто, как захотите, а когда Вы закончили работу над изменениями, используйте стандартную команду <tt class="docutils literal"><span class="pre">dch</span></tt> (из пакета <tt class="docutils literal"><span class="pre">devscripts</span></tt>):</p>
<div class="highlight-python"><div class="highlight"><pre>$ dch -i
</pre></div>
</div>
<p>Эта команда откроет редактор и добавит запись в файл <cite>debian/changelog</cite>.</p>
<p id="link-via-changelog">При добавлении записи в <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> вы должны включить тег исправления ошибки, который указывает, для какого сообщения об ошибке на Launchpad вы создали исправление. Этот текстовый тег имеет вполне определённый формат: <tt class="docutils literal"><span class="pre">LP:</span> <span class="pre">#12345</span></tt>. Пробел между <tt class="docutils literal"><span class="pre">:</span></tt> и <tt class="docutils literal"><span class="pre">#</span></tt> обязателен и, разумеется, вы должны указать номер реально существующей ошибке, которую вы исправляете. Ваш <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> может выглядеть примерно так:</p>
<div class="highlight-python"><div class="highlight"><pre>tomboy (1.12.0-1ubuntu3) trusty; urgency=low
* Don't fubar the frobnicator. (LP: #12345)
-- Bob Dobbs <subgenius@example.com> Mon, 10 Sep 2013 16:10:01 -0500
</pre></div>
</div>
<p>Подтвердить с нормальным:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr commit
</pre></div>
</div>
<p>Хук в bzr-builddeb будет использовать текст debian/changelog как сообщение о завершении отправки и установит тег для отметки бага #12345 в качестве фиксированного.</p>
<p>Это работает только с bzr-builddeb 2.7.5 и bzr 2.4, для более старых версий используйте <tt class="docutils literal"><span class="pre">debcommit</span></tt>.</p>
</div>
<div class="section" id="building-the-package">
<h4>Сборка пакета<a class="headerlink" href="#building-the-package" title="Ссылка на этот заголовок">¶</a></h4>
<p>По ходу дела Вы захотите создать свою ветку, чтобы Вы могли проверить ее и убедиться, что она действительно исправляет баг.</p>
<p>Чтобы создать пакет, Вы можете использовать команду <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">builddeb</span></tt> из пакета <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt>. Вы можете создать исходный пакет при помощи:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -S
</pre></div>
</div>
<p>(<tt class="docutils literal"><span class="pre">bd</span></tt> — это псевдоним для <tt class="docutils literal"><span class="pre">builddeb</span></tt>.) Вы можете оставить пакет неподписанным, добавив к команде <tt class="docutils literal"><span class="pre">--</span> <span class="pre">-uc</span> <span class="pre">-us</span></tt>.</p>
<p>Вы можете также использовать свои обычные инструменты, если они способны убирать каталоги <tt class="docutils literal"><span class="pre">.bzr</span></tt> из пакета, например:</p>
<div class="highlight-python"><div class="highlight"><pre>$ debuild -i -I
</pre></div>
</div>
<p>Если Вы когда-либо столкнетесь с ошибкой, связанной с попыткой составить родной пакет без tar-архива, убедитесь что там есть файл <tt class="docutils literal"><span class="pre">.bzr-builddeb/default.conf</span></tt>, ошибочно выдающий пакет за родной. Если в версии лога изменений есть тире, то это не родной пакет, поэтому файл конфигурации следует убрать. Обратите внимание, если у <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">builddeb</span></tt> есть оператор <tt class="docutils literal"><span class="pre">--native</span></tt>, то у него нет оператора <tt class="docutils literal"><span class="pre">--no-native</span></tt>.</p>
<p>После того, как вы получили пакет исходного кода, можно собрать его как обычно, с помощью <tt class="docutils literal"><span class="pre">pbuilder-dist</span></tt> (или <tt class="docutils literal"><span class="pre">pbuilder</span></tt>, или <a class="reference external" href="https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment">sbuild</a>).</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-sponsorship"></span><div class="section" id="seeking-review-and-sponsorship">
<h3>Поиск Обзоров и Спонсорства<a class="headerlink" href="#seeking-review-and-sponsorship" title="Ссылка на этот заголовок">¶</a></h3>
<p>Один из больших плюсов использования рабочего процесса UDD - улучшение качества путем отзывов об изменениях от Ваших друзей и коллег. Это работает вне зависимости от того есть ли у Вас права на загрузку. Конечно, если у Вас нет прав на загрузку, то Вам нужно найти спонсора.</p>
<p>Как только Вы довольны своим фиксом и Ваша ветка готова к работе, следует предпринять следующие шаги для публикации своей ветки на Launchpad, привязки ее к багу, а затем создать предложение о слиянии (<em>merge proposal</em>) для рассмотрения другими пользователями и возможностью загрузки его спонсорами.</p>
<div class="section" id="pushing-to-launchpad">
<span id="merge-proposal"></span><h4>Выгрузка на Launchpad<a class="headerlink" href="#pushing-to-launchpad" title="Ссылка на этот заголовок">¶</a></h4>
<p>Ранее мы показали вам, как <a class="reference internal" href="index.html#link-via-changelog"><em>связать вашу ветку с ошибкой</em></a>, используя команды <tt class="docutils literal"><span class="pre">dch</span></tt> и <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">commit</span></tt>. Однако ветка и ошибка в действительности не будут связаны, пока вы не выгрузите ветку на Launchpad командой push.</p>
<p>Создавать ссылку на ошибку для каждого вашего изменения не обязательно, но если вы исправляете ошибки, для которых имеется отчёт об ошибке, то ссылки на этот отчёт могут быть полезны.</p>
<p>Общий формат URL, на который вы должны выгрузить свою ветку, имеет следующий вид:</p>
<div class="highlight-python"><div class="highlight"><pre>lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name>
</pre></div>
</div>
<p>Например, чтобы продвинуть свой фикс для бага 12345 в пакете Tomboy для Trusty, используйте:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
</pre></div>
</div>
<p>Последний компонент пути в этом примере выбран произвольно, укажите вместо него реально существующую ошибку.</p>
<p>Но обычно этого недостаточно, чтобы разработчики Ubuntu проверили ваше изменение и взяли на себя поручительство над ним. Вам нужно отправить <em>предложение слияния</em> (merge proposal).</p>
<p>Для этого откройте страницу ошибки в браузере, например:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr lp-open
</pre></div>
</div>
<p>Если сделать это не удалось, вы можете использовать:</p>
<div class="highlight-python"><div class="highlight"><pre>$ xdg-open https://code.launchpad.net/~subgenius/ubuntu/trusty/tomboy/bug-12345
</pre></div>
</div>
<p>где большая часть URL совпадает с тем URL, который вы указывали в команде <cite>bzr push</cite>. На этой странице вы увидите ссылку <em>Propose for merging into another branch</em>. Наберите описание вашего изменения в поле <em>Initial Comment</em>. Затем щёлкните <em>Propose Merge</em>, чтобы завершить процесс.</p>
<p>Предложения о слиянии для исходных веток автоматически подпишут команду <cite>~ubuntu-branches</cite>, что должно быть достаточно для того, чтобы привлечь внимание разработчика Ubuntu, который сможет дать отзыв Вашим изменениям и стать спонсором.</p>
</div>
<div class="section" id="generating-a-debdiff">
<h4>Создание debdiff<a class="headerlink" href="#generating-a-debdiff" title="Ссылка на этот заголовок">¶</a></h4>
<p>Как было указано выше, некоторые поручители предпочитают проверять <em>debdiff</em>, прикреплённый к отчёту об ошибке, вместо предложения слияния. Если вас попросили включить debdiff, вы можете создать его следующим образом (из вашей ветки <cite>bug-12345</cite>):</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr diff -rbranch:../tomboy.dev
</pre></div>
</div>
<p>Другой способ — открыть предложение слияния и загрузить diff.</p>
<p>Вы должны убедиться, что diff-файл содержит ожидаемые вами изменения, не больше и не меньше. Дайте ему подходящее имя, например, <tt class="docutils literal"><span class="pre">foobar-12345.debdiff</span></tt> и прикрепите к отчёту об ошибке.</p>
</div>
<div class="section" id="dealing-with-feedback-from-sponsors">
<h4>Работа с обратной связью от поручителей<a class="headerlink" href="#dealing-with-feedback-from-sponsors" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если поручитель проверяет вашу ветку и просит вас что-то изменить, то сделать это очень легко. Просто перейдите в ветку, над которой вы работали, сделайте требуемые изменения и выполните фиксацию:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr commit
</pre></div>
</div>
<p>Теперь когда Вы продвинули свою ветку в Launchpad, Bazaar обновит ветку на Launchpad Вашими последними изменениями. Все, что Вам нужно сделать:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push
</pre></div>
</div>
<p>Вы можете ответить на email с обзором предложения о слиянии объяснение того, какие изменения Вы внесли, а также можете попросить провести повторный обзор; или же Вы можете отправить свой ответ через Launchpad.</p>
<p>Обратите внимание - Вас спонсируют через debdiff, прикрепленный к отчету о баге - Вам следует обновлять его вручную, генерируя новый diff и прикрепляя его у отчету о баге.</p>
</div>
<div class="section" id="expectations">
<h4>Ожидание<a class="headerlink" href="#expectations" title="Ссылка на этот заголовок">¶</a></h4>
<p>Разработчики Ubuntu составили расписание людей (так называемых “patch pilots”), которые регулярно проверяют очередь поручительства и предоставляют обратную связь по вопросам работы с ветками и патчами. Но, даже несмотря на это, может пройти несколько дней, пока вы получите ответ. Это зависит от их занятости, от состояния заморозки текущей версии и других факторов.</p>
<p>Если вы не получаете ответа в течение долгого времени, подключитесь к каналу <cite>#ubuntu-devel</cite> на <cite>irc.freenode.net</cite> и найдите кого-нибудь, кто может вам помочь.</p>
<p>Чтобы узнать больше о процессе поручительства, прочтите также нашу вики-документацию: <a class="reference external" href="https://wiki.ubuntu.com/SponsorshipProcess">https://wiki.ubuntu.com/SponsorshipProcess</a></p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-uploading"></span><div class="section" id="uploading-a-package">
<h3>Загрузка пакета<a class="headerlink" href="#uploading-a-package" title="Ссылка на этот заголовок">¶</a></h3>
<p>Как только Ваше предложение о слиянии рассмотрено и подтверждено, Вы захотите загрузить свой пакет либо в архив (если у Вас есть права), либо в свой Персональный Архив Пакетов <a class="reference external" href="https://help.launchpad.net/Packaging/PPA">Personal Package Archive</a> (PPA). Также возможно Вы захотите выполнить загрузку, если спонсируете изменения, внесенные другим пользователем.</p>
<div class="section" id="uploading-a-change-made-by-you">
<h4>Выгрузка изменений, сделанных вами<a class="headerlink" href="#uploading-a-change-made-by-you" title="Ссылка на этот заголовок">¶</a></h4>
<p>Когда у Вас есть ветка с изменениями, которые Вы хотите загрузить, то нужно отправить это изменение обратно на исходную ветку, создать исходный пакет, а затем загрузить его.</p>
<p>Сначала Вам нужно убедиться, что у Вас самая последняя версия пакета в отладке древа пакета разработки:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy/tomboy.dev
$ bzr pull
</pre></div>
</div>
<p>Это применит любые изменения, которые были внесены за время Вашей работы над фиксом. Начиная с этого момента у Вас есть несколько вариантов. Если Ваши изменения большие и Вы чувствуете, что их следует протестировать вместе с Вашими изменениями - то можно объединить их в ветке исправления багов и провести тестирование там. Если нет, то Вы можете продолжить процесс слияния в Вашей ветке исправления бага. Касательно bzr 2.5 и bzr-builddeb 2.8.1, это работает так же как и стандартная команда <tt class="docutils literal"><span class="pre">merge</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge ../bug-12345
</pre></div>
</div>
<p>Для более старых версий bzr можно использовать взамен команду <tt class="docutils literal"><span class="pre">merge-package</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge-package ../bug-12345
</pre></div>
</div>
<p>Эта команда сольёт два дерева и, возможно, сообщит о конфликтах, которые вам надо будет разрешить вручную.</p>
<p>Далее следует убедиться в правильности содержимого <tt class="docutils literal"><span class="pre">debian/changelog</span></tt>, то есть, что там правильно указан дистрибутив, номер версии и т.п.</p>
<p>Как только это сделано, Вы должны еще раз перепроверить изменения, которые хотите отправить, при помощи <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span></tt>. Это должно показать те же изменения, как показал бы debdiff до загрузки исходного пакета.</p>
<p>Следующий шаг — собрать и протестировать изменённый пакет исходного кода, как вы это обычно делаете:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -S
</pre></div>
</div>
<p>Когда Вы наконец довольны своей веткой, убедитесь что отправили все изменения, а затем пометьте ветку номером версии лога изменений. Команда <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">tag</span></tt> сделает это автоматически, если не указано ни одного аргумента:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr tag
</pre></div>
</div>
<p>Этот тег сообщит импортирующему пакет, что содержимое ветка Bazaar идентично содержимому архива.</p>
<p>Теперь вы можете выгрузить командой push изменения обратно на Launchpad:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push ubuntu:tomboy
</pre></div>
</div>
<p>(Измените место назначения, если вы выгружаете SRU или что-то подобное.)</p>
<p>Вам нужен один последний шаг, чтобы отправить свои изменения в Ubuntu или ваш PPA: вам нужно загрузить с помощью <tt class="docutils literal"><span class="pre">dput</span></tt> пакет исходного кода в соответствующее место. Например, чтобы загрузить изменения в PPA, сделайте следующее:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes
</pre></div>
</div>
<p>или, если у вас есть права загрузки в основной архив:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dput tomboy_1.5.2-1ubuntu5_source.changes
</pre></div>
</div>
<p>Теперь Вы можете спокойно удалить ветвь, так как она уже объединена, и при необходимости ее можно заново скачать с Launchpad.</p>
</div>
<div class="section" id="sponsoring-a-change">
<h4>Поручительство над изменением<a class="headerlink" href="#sponsoring-a-change" title="Ссылка на этот заголовок">¶</a></h4>
<p>Поручительство над чьим-нибудь изменением похоже на вышеописанную процедуру, но вместо слияния из созданной вами ветки вы выполняете слияние из ветки, имеющейся в предложении слияния:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
</pre></div>
</div>
<p>Если при слиянии возникает множество конфликтов, возможно Вы захотите попросить разработчика их исправить. Смотрите в следующем разделе как отменить запланированное слияние.</p>
<p>Но если с изменениями все в порядке - подтвердите, а затем пройдите оставшуюся часть процесса загрузки:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr commit --author "Bob Dobbs <subgenius@example.com>"
</pre></div>
</div>
</div>
<div class="section" id="canceling-an-upload">
<h4>Отмена выгрузки<a class="headerlink" href="#canceling-an-upload" title="Ссылка на этот заголовок">¶</a></h4>
<p>В любое время до выполнения действия <cite>dput</cite> с исходным пакетом Вы можете отменить загрузку и откатить все изменения:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr revert
</pre></div>
</div>
<p>Вы можете сделать это если заметите, что требуется еще немного работы, либо если хотите попросить разработчика исправить конфликты (если выступаете его спонсором).</p>
</div>
<div class="section" id="sponsoring-something-and-making-your-own-changes">
<h4>Поручительство над чем-нибудь и внесение своих собственных изменений<a class="headerlink" href="#sponsoring-something-and-making-your-own-changes" title="Ссылка на этот заголовок">¶</a></h4>
<p>Если вы являетесь поручителем над чьей-нибудь работой, но хотите дополнить её несколькими собственными изменениями, то вы можете сначала выполнить слияние их работы в отдельную ветку.</p>
<p>Если у Вас уже есть ветка, в которой Вы работаете над пакетом и Вы хотите включить все изменения - просто запустите <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt> из этой ветки, вместо отладки пакета разработки. Затем Вы можете внести изменения и отправить, а затем продолжить работу с изменениями к пакету.</p>
<p>Если у Вас нет существующей ветки, но Вы знаете, что хотели бы внести изменения, основываюсь на данных разработчика, то Вы должны первым делом должны спарсить их ветку:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
</pre></div>
</div>
<p>затем работайте в этой новой ветке, а после этого выполните ее слияние с главной и загрузите таким образом, как если бы загружали собственную работу. Разработчик-участник все еще будет упомянут в логах изменений, и Bazaar должным образом назначит им внесенные ими изменения.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-latest"></span><div class="section" id="getting-the-latest">
<h3>Получение последних изменений<a class="headerlink" href="#getting-the-latest" title="Ссылка на этот заголовок">¶</a></h3>
<p>Если кто-нибудь ещё внёс изменения в пакет, вам может понадобиться получить эти изменения в ваши копии веток пакета.</p>
<div class="section" id="updating-your-main-branch">
<h4>Обновление вашей основной ветки<a class="headerlink" href="#updating-your-main-branch" title="Ссылка на этот заголовок">¶</a></h4>
<p>Обновить вашу копию ветки, соответствующей пакету в определённом выпуске, очень просто: выполните <cite>bzr pull</cite> из соответствующего каталога:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy/tomboy.dev
$ bzr pull
</pre></div>
</div>
<p>Это работает если у Вас есть отладка ветки, поэтому его можно применить для таких вещей как ветки <cite>saucy</cite>, <cite>trusty-proposed</cite>, итп.</p>
</div>
<div class="section" id="getting-the-latest-in-to-your-working-branches">
<h4>Получение последних изменений в ваши рабочие ветки<a class="headerlink" href="#getting-the-latest-in-to-your-working-branches" title="Ссылка на этот заголовок">¶</a></h4>
<p>Как только Вы обновили свою копию ветки distroseries, то возможно захотите также объединить ее со своими рабочими ветками, чтобы они работали на самом последнем коде.</p>
<p>Тем не менее, Вам не нужно делать это каждый раз. Вы можете без проблем работать и со слегка старым кодом. Недостатки могут всплыть если Вы работали над кодом, который изменил кто-то еще. Если Вы работаете не с самой последней версией, Ваши изменения могут быть некорректными, и даже могут стать причиной конфликта.</p>
<p>Слияние следует выполнять в определенный момент. Чем дольше Вы работаете - тем сложнее может быть процесс в дальнейшем. Выполняйте слияние регулярно, чтобы максимально упростить процесс. Если даже слияний много, в итоге нужно применять меньше общих усилий.</p>
<p>Чтобы выполнить слияние изменений, Вам нужно использовать <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt>, но сначала Вы должны отправить свою текущую работу:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy/bug-12345
$ bzr merge ../tomboy.dev
</pre></div>
</div>
<p>О любых конфликтах будет сообщаться. так что Вы сможете их исправить в дальнейшем. Чтобы рассмотреть изменения, используйте <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span></tt>. Как только Вы закончили работу - используйте <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">commit</span></tt>.</p>
</div>
<div class="section" id="referring-to-versions-of-a-package">
<h4>Относительно версий пакета<a class="headerlink" href="#referring-to-versions-of-a-package" title="Ссылка на этот заголовок">¶</a></h4>
<p>Вы часто будете думать относительно версий пакета, а не просто о цифрах предыдущих поправок в Bazaar. <cite>bzr-builddeb</cite> для удобства предоставляет спецификатор поправок. Любая команда, использующая аргумент <tt class="docutils literal"><span class="pre">-r</span></tt> для указаний поправки или диапазона поправок. будет работать с этим спецификатором, к примеру, <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">log</span></tt>, <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff``итд.</span> <span class="pre">Чтобы</span> <span class="pre">просмотреть</span> <span class="pre">версии</span> <span class="pre">пакета,</span> <span class="pre">используйте</span> <span class="pre">спецификатор</span> <span class="pre">``package:</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr diff -r package:0.1-1..package:0.1-2
</pre></div>
</div>
<p>Эта команда покажет вам различия между версиями пакета 0.1-1 и 0.1-2.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-merging"></span><div class="section" id="merging-updating-from-debian-and-upstream">
<h3>Слияние — обновления из Debian и апстрима<a class="headerlink" href="#merging-updating-from-debian-and-upstream" title="Ссылка на этот заголовок">¶</a></h3>
<p>Слияние — это одна из сильнейших сторон Bazaar, и мы часто выполняем его в процессе разработки Ubuntu. Слияние может быть выполнено с обновлениями из Debian, из нового выпуска в апстриме и от других разработчиков Ubuntu. Сделать это в Bazaar очень просто, всё основано на команде <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt> <a class="footnote-reference" href="#id3" id="id1">[1]</a>.</p>
<p>Находясь в рабочем каталоге любой ветки, вы можете выполнить слияние изменений из ветки в другом месте. Сначала проверьте, что у вас нет незафиксированных изменений:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr status
</pre></div>
</div>
<p>Если появится отчет, то Вам нужно либо применить изменения, откатить их, либо отложить решения (и возвратиться к их решению позже).</p>
<div class="section" id="merging-from-debian">
<h4>Слияние из Debian<a class="headerlink" href="#merging-from-debian" title="Ссылка на этот заголовок">¶</a></h4>
<p>Затем запустите <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt>, передавай URL ветки для слияния. К примеру, чтобы выполнить слияние версий пакета в Debian Unstable запустите <a class="footnote-reference" href="#id4" id="id2">[2]</a>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge lp:debian/tomboy
</pre></div>
</div>
<p>Это добавит изменения, внесенные с момента последнего слияния и даст Вам все изменения для обзора. Это может повлечь конфликты. Вы можете увидеть все действия, выполненные командой <tt class="docutils literal"><span class="pre">merge</span></tt>, запустив:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr status
$ bzr diff
</pre></div>
</div>
<p>Если появится отчет о конфликтах, Вам нужно отредактировать соответствующие файлы, чтобы привести их к должному виду, убрав конфликтующие маркеры (<em>conflict markers</em>). Как только Вы это сделали, выполните:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr resolve
$ bzr conflicts
</pre></div>
</div>
<p>Это решит проблему с конфликтующими файлами, которые Вы исправляли, и сообщит что еще Вам нужно сделать.</p>
<p>После того, как все конфликты разрешены, и вы внесли все другие необходимые изменения, нужно добавить новую запись в changelog и выполнить фиксацию:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dch -i
$ bzr commit
</pre></div>
</div>
<p>как было описано выше.</p>
<p>Однако перед фиксацией всегда желательно проверить все изменения, сделанные в Ubuntu, выполнив:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr diff -r tag:0.6.10-5
</pre></div>
</div>
<p>Эта команда покажет различия между версиями в Debian (0.6.10-5) и Ubuntu (0.6.10-5ubuntu1). Подобным же способом вы можете выполнить сравнение с любыми другими версиями. Чтобы увидеть все доступные версии, выполните:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr tags
</pre></div>
</div>
<p>После проверки и фиксации слияния, вам нужно найти попечителя или выгрузить пакет в архив обычным способом.</p>
<p>Если Вы собираетесь создать исходный пакет из этой объединенной ветки, то нужно использовать опцию <tt class="docutils literal"><span class="pre">-S</span></tt> команды <tt class="docutils literal"><span class="pre">bd</span></tt>. Также Вам захочется рассмотреть использование опции <tt class="docutils literal"><span class="pre">--package-merge</span></tt>. Это добавит соответствующие опции <tt class="docutils literal"><span class="pre">-v</span></tt> и <tt class="docutils literal"><span class="pre">-sa</span></tt> к исходному пакету, чтобы все записи в логе изменений после последних изменений в Ubuntu были включены в Ваш файл <tt class="docutils literal"><span class="pre">_source.changes</span></tt>. Например:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -S --package-merge
</pre></div>
</div>
</div>
<div class="section" id="merging-a-new-upstream-version">
<h4>Слияние с новой версией из апстрима<a class="headerlink" href="#merging-a-new-upstream-version" title="Ссылка на этот заголовок">¶</a></h4>
<p>Когда в апстриме выпускается новая версия (или Вы хотите запаковать скриншот), Вам нужно выполнить слияние tar-архива и Вашей ветки.</p>
<p>Это делается командой <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-upstream</span></tt>. Если в вашем пакете имеется файл <tt class="docutils literal"><span class="pre">debian/watch</span></tt> с правильным содержимым, то из каталога ветки, в которую вы собираетесь слить изменения, просто наберите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge-upstream
</pre></div>
</div>
<p>Команда загрузит тарбол и сольёт его в вашу ветку, автоматически добавив запись в <tt class="docutils literal"><span class="pre">debian/changelog</span></tt>. <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> просматривает файл <tt class="docutils literal"><span class="pre">debian/watch</span></tt>, чтобы определить местоположение тарбола из апстрима.</p>
<p>Если у вас <em>отсутствует</em> файл <tt class="docutils literal"><span class="pre">debian/watch</span></tt>, то вам нужно вручную указать местоположение тарбола из апстрима и версию:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge-upstream --version 1.2 http://example.org/releases/foo-1.2.tar.gz
</pre></div>
</div>
<p>Опция <tt class="docutils literal"><span class="pre">--version</span></tt> используется для указания версии апстрима, из которой выполняется слияние, поскольку команда не способна (пока) узнать её самостоятельно.</p>
<p>Последний параметр — это местоположение тарбола, на который выполняется обновление: это может быть путь в локальной файловой системе, http, ftp, sftp или другой URI, как показано в примере. Команда автоматически загрузит тарбол для вас, переименует его соответствующим образом и, если требуется, преобразует в <tt class="docutils literal"><span class="pre">.gz</span></tt>.</p>
<p>Команда <tt class="docutils literal"><span class="pre">merge-upstream</span></tt> сообщит либо о своём удачном завершении, либо о том, что имеются конфликты. В любом случае у вас будет возможность проверить изменения перед их фиксацией обычным способом.</p>
<p>Если Вы объединяете релиз апстрима с существующей веткой Bazaar, в которой еще не использовалась разметка UDD, <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-upstream</span></tt> пройдет неудачно и с ошибкой, что тег предыдущих версий апстрима недоступен. Слияние нельзя выполнить без знания базовой версии для слияния. Для работы с этим, создайте тег в своем существующем репозитории для последней имеющейся там версии апстрима; например, если последний релиз Ubuntu был <em>1.1-0ubuntu3</em>, создайте тег <em>upstream-1.1</em>, указывая на изменение bzr, которое Вы хотите использовать как подсказку для ветки апстрима.</p>
<table class="docutils footnote" frame="void" id="id3" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td><p class="first last">Для работы с командой <tt class="docutils literal"><span class="pre">merge</span></tt> вам понадобятся более новые версии <tt class="docutils literal"><span class="pre">bzr</span></tt> и <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt>. Используйте версии из Ubuntu 12.04 (Precise) или разрабатываемые версии из PPA <tt class="docutils literal"><span class="pre">bzr</span></tt>. Точнее говоря, вам понадобится <tt class="docutils literal"><span class="pre">bzr</span></tt> версии 2.5 beta 5 или более новой, а также <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> версии 2.8.1 или более новой. Для старых версий используйте взамен команду <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-package</span></tt>.</p>
</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td><td><p class="first last">Чтобы проверить наличие других веток пакета в Debian, см. страницу кода пакета. Например: <a class="reference external" href="https://code.launchpad.net/debian/+source/tomboy">https://code.launchpad.net/debian/+source/tomboy</a></p>
</td></tr>
</tbody>
</table>
</div>
</div>
<span id="document-ubuntu-packaging-guide/chroots"></span><div class="section" id="using-chroots">
<h3>Использование chroot-окружений<a class="headerlink" href="#using-chroots" title="Ссылка на этот заголовок">¶</a></h3>
<p>Если вы пользуетесь одной из версий Ubuntu, но работаете над пакетами для другой версии, вы можете создать среду другой версии с помощью <tt class="docutils literal"><span class="pre">chroot</span></tt>.</p>
<p>Использование <tt class="docutils literal"><span class="pre">chroot</span></tt> позволит вам иметь в распоряжении полную файловую систему другого дистрибутива для удобства работы. Это позволяет избежать затрат, связанных с установкой виртуальной машины.</p>
<div class="section" id="creating-a-chroot">
<h4>Создание chroot<a class="headerlink" href="#creating-a-chroot" title="Ссылка на этот заголовок">¶</a></h4>
<p>Используйте команду <tt class="docutils literal"><span class="pre">debootstrap</span></tt>, чтобы создать новый chroot:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo debootstrap trusty trusty/
</pre></div>
</div>
<p>Это создаст папку <tt class="docutils literal"><span class="pre">trusty</span></tt> и установит минимальный образ trusty в неё.</p>
<p>Если ваша версия <tt class="docutils literal"><span class="pre">debootstrap</span></tt> не определит Trusty, попробуйте обновиться до версии в <tt class="docutils literal"><span class="pre">backports</span></tt>.</p>
<p>После этого вы можете работать внутри chroot:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo chroot trusty
</pre></div>
</div>
<p>Где можно установить или удалить любой пакет, который вы хотите, без ущерба для основной системы.</p>
<p>Вы можете скопировать свои ключи GPG и SSH, а также конфигурацию Bazaar в chroot, чтобы получать доступ и подписывать пакеты непосредственно оттуда:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo mkdir trusty/home/<username>
$ sudo cp -r ~/.gnupg ~/.ssh ~/.bazaar trusty/home/<username>
</pre></div>
</div>
<p>Чтобы apt и другие программы не жаловались на отсутствующие локали, можно установить соответствующий языковой пакет:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-get install language-pack-en
</pre></div>
</div>
<p>Если вам нужно запускать программы, использующие X-сервер, вам нужно добавить в chroot директорию /tmp, для этого снаружи chroot запустите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo mount -t none -o bind /tmp trusty/tmp
$ xhost +
</pre></div>
</div>
<p>Для некоторых программ, возможно, понадобится привязать /dev или /proc.</p>
<p>На странице <a class="reference external" href="https://wiki.ubuntu.com/DebootstrapChroot">Debootstrap Chroot вики</a> вы найдёте более подробную информацию о chroot-окружении.</p>
</div>
<div class="section" id="alternatives">
<h4>Альтернативы<a class="headerlink" href="#alternatives" title="Ссылка на этот заголовок">¶</a></h4>
<p>SBuild – система, похожая на PBuilder, используемая для создания окружения, в котором выполняются тестовые сборки пакета. Она близка к той, которую использует Launchpad для сборки пакетов, но её установка несколько сложнее, чем PBuilder. Более полную информацию можно найти на викистранице <a class="reference external" href="https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment">Система Сборки Security Team</a>.</p>
<p>Полные виртуальные машины могут быть полезны для создания пакетов и тестирования программ. TestDrive — это программа, позволяющая автоматизировать синхронизацию и запуск ежедневных ISO-образов. Подробнее смотрите <a class="reference external" href="https://wiki.ubuntu.com/QATeam/Testdrive">wiki-страницу TestDrive</a>.</p>
<p>Можно также настроить pbuilder так, чтобы он приостанавливался при обнаружении ошибки сборки. Скопируйте C10shell из /usr/share/doc/pbuilder/examples в каталог и используйте аргумент <tt class="docutils literal"><span class="pre">--hookdir=</span></tt>, чтобы указать на него.</p>
<p>Облачный сервис <a class="reference external" href="https://help.ubuntu.com/community/EC2StartersGuide">Amazon EC2</a> позволит вам приобрести компьютер в облаке, цена за который – всего несколько центов в час. Там вы можете установить Ubuntu любой поддерживаемой версии и работать с пакетами удалённо, что очень удобно, если требуется сборка множества пакетов одновременно, или если нужно преодолеть медленную скорость Интернет-подключения.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/traditional-packaging"></span><div class="section" id="traditional-packaging">
<h3>Традиционные методы создания пакетов<a class="headerlink" href="#traditional-packaging" title="Ссылка на этот заголовок">¶</a></h3>
<p>Большая часть данного руководства относится к <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro"><em>Ubuntu Distributed Development</em></a> (UDD), которое использует распространяемую версию системы управления (DVCS) Bazaar для <a class="reference internal" href="index.html#branching"><em>получения источников пакетов</em></a> и отправки фиксов через <a class="reference internal" href="index.html#merge-proposal"><em>предложения о слияниях.</em></a> В этой статье мы обсудим так называемые “традиционные” методы создания пакетов. До того как Bazaar стали применять в разработках Ubuntu, помочь Ubuntu можно было стандартными способами.</p>
<p>В некоторых случаях вам может понадобиться использовать эти инструменты вместо UDD. Поэтому не помешает познакомиться с ними. Перед тем, как продолжить, вам следует прочитать статью <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>Подготовка.</em></a></p>
<div class="section" id="getting-the-source">
<h4>Получение исходного кода<a class="headerlink" href="#getting-the-source" title="Ссылка на этот заголовок">¶</a></h4>
<p>Чтобы получить пакет исходного кода, можно просто набрать:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-get source <package_name>
</pre></div>
</div>
<p>Но у этого метода есть некоторые недостатки. Он скачивает версию исходного кода, которая доступна в <strong>вашей системе.</strong> Скорее всего, у вас установлен текущий стабильный выпуск, а вы собираетесь внести изменения в пакет в разрабатываемом выпуске. К счастью, пакет <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt> предоставляет вспомогательный сценарий:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source <package_name>
</pre></div>
</div>
<p>По умолчанию будет загружена самая свежая версия из разрабатываемого выпуска. Можно также указать версию выпуска Ubuntu следующим образом:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source <package_name> trusty
</pre></div>
</div>
<p>чтобы вытащить источник из релиза <tt class="docutils literal"><span class="pre">trusty</span></tt>, либо:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source <package_name> 1.0-1ubuntu1
</pre></div>
</div>
<p>чтобы скачать версию пакета <tt class="docutils literal"><span class="pre">1.0-1ubuntu1</span></tt>. Для получения дополнительной информации о команде воспользуйтесь <tt class="docutils literal"><span class="pre">man</span> <span class="pre">pull-lp-source</span></tt>.</p>
<p>Для примера, давайте представим, что мы получили отчёт об ошибке, в котором говорится, что вместо “colour” в описании <tt class="docutils literal"><span class="pre">xicc</span></tt> должно быть “color,” и мы хотим это исправить. <em>(Примечание: это просто пример чего-то, что можно изменить, а не реальная ошибка.)</em> Чтобы получить исходный код, введите:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source xicc 0.2-3
</pre></div>
</div>
</div>
<div class="section" id="creating-a-debdiff">
<h4>Создание Debdiff<a class="headerlink" href="#creating-a-debdiff" title="Ссылка на этот заголовок">¶</a></h4>
<p>Файл <tt class="docutils literal"><span class="pre">debdiff</span></tt> показывает различия между двумя пакетами Debian. Имя команды, используемой для его создания, тоже <tt class="docutils literal"><span class="pre">debdiff</span></tt>. Она является частью пакета <tt class="docutils literal"><span class="pre">devscripts</span></tt>. Смотрите <tt class="docutils literal"><span class="pre">man</span> <span class="pre">debdiff</span></tt> для подробной информации о ней. Чтобы сравнить два пакета исходного кода, передайте команде в качестве аргумента два файла <tt class="docutils literal"><span class="pre">dsc</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ debdiff <package_name>_1.0-1.dsc <package_name>_1.0-1ubuntu1.dsc
</pre></div>
</div>
<p>Чтобы продолжить наш пример, давайте отредактируем <tt class="docutils literal"><span class="pre">debian/control</span></tt> и «исправим» нашу «ошибку»:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd xicc-0.2
$ sed -i 's/colour/color/g' debian/control
</pre></div>
</div>
<p>Мы также должны соблюдать <a class="reference external" href="https://wiki.ubuntu.com/DebianMaintainerField">Спецификации Обслуживания Debian<MaintFieldSpec_></a> и редактировать <tt class="docutils literal"><span class="pre">debian/control</span></tt> для замены:</p>
<div class="highlight-python"><div class="highlight"><pre>Maintainer: Ross Burton <ross@debian.org>
</pre></div>
</div>
<p>на:</p>
<div class="highlight-python"><div class="highlight"><pre>Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
XSBC-Original-Maintainer: Ross Burton <ross@debian.org>
</pre></div>
</div>
<p>Для этого можно воспользоваться инструментом <tt class="docutils literal"><span class="pre">update-maintainer</span></tt> (из пакета <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt>).</p>
<p>Не забудьте задокументировать ваши изменения в <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> с помощью <tt class="docutils literal"><span class="pre">dch</span> <span class="pre">-i</span></tt>, после чего мы можем сгенерировать новый пакет исходного кода:</p>
<div class="highlight-python"><div class="highlight"><pre>$ debuild -S
</pre></div>
</div>
<p>Теперь можно проверить наши изменения с помощью <tt class="docutils literal"><span class="pre">debdiff</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd ..
$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc | less
</pre></div>
</div>
<p>Чтобы создать файл патча, который можно отправить другим или приложить к отчёту об ошибке для одобрения, выполните:</p>
<div class="highlight-python"><div class="highlight"><pre>$ debdiff xicc_0.2-3.dsc xicc_0.2-3ubuntu1.dsc > xicc_0.2-3ubuntu1.debdiff
</pre></div>
</div>
</div>
<div class="section" id="applying-a-debdiff">
<h4>Применение Debdiff<a class="headerlink" href="#applying-a-debdiff" title="Ссылка на этот заголовок">¶</a></h4>
<p>Чтобы применить debdiff, нужно иметь исходный код версии, на основе которой он был создан:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source xicc 0.2-3
</pre></div>
</div>
<p>Затем в терминале измените на директорию, куда был распакован исходник:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd xicc-0.2
</pre></div>
</div>
<p>Фактически, debdiff похож на обычный файл патча. Примените его, как обычно, с помощью:</p>
<div class="highlight-python"><div class="highlight"><pre>$ patch -p1 < ../xicc_0.2.2ubuntu1.debdiff
</pre></div>
</div>
</div>
</div>
<span id="document-ubuntu-packaging-guide/kde"></span><div class="section" id="kde-packaging">
<h3>Работа с пакетами KDE<a class="headerlink" href="#kde-packaging" title="Ссылка на этот заголовок">¶</a></h3>
<p>Созданием пакетов программ KDE в Ubuntu занимаются команды Kubuntu и MOTU. Связаться с командой Kubuntu можно через <a class="reference external" href="https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel">почтовую рассылку Kubuntu</a> и канал Freenode IRC <tt class="docutils literal"><span class="pre">#kubuntu-devel</span></tt>. Дополнительная информация о разработке Kubuntu доступна на <a class="reference external" href="https://wiki.kubuntu.org/Kubuntu">wiki-странице Kubuntu</a>.</p>
<p>При создании пакетов мы учитываем практику команд <a class="reference external" href="http://pkg-kde.alioth.debian.org/">Debian Qt/KDE</a> и Debian KDE Extras. Большинство наших пакетов являются производными от пакетов, созданных этими командами Debian.</p>
<div class="section" id="patching-policy">
<h4>Политика создания патчей<a class="headerlink" href="#patching-policy" title="Ссылка на этот заголовок">¶</a></h4>
<p>Kubuntu добавляет патчи в приложения KDE, только если они исходят от оригинальных авторов, либо если они были отправлены в upstream и есть уверенность в их скором принятии, либо если мы обсудили проблемы с разработчиками KDE.</p>
<p>Kubuntu не меняет фирменного оформления пакетов, кроме случаев, когда этого требует апстрим (например, логотип в верхнем левом углу меню Kickoff) или для упрощения (например, удаление показываемых при запуске заставок).</p>
</div>
<div class="section" id="debian-rules">
<h4>debian/rules<a class="headerlink" href="#debian-rules" title="Ссылка на этот заголовок">¶</a></h4>
<p>Пакеты Debian включают некоторые дополнения к обычному использованию Debhelper. Они хранятся в пакете <tt class="docutils literal"><span class="pre">pkg-kde-tools</span></tt>.</p>
<p>Пакеты, использующие Debhelper 7, должны добавить опцию <tt class="docutils literal"><span class="pre">--with=kde</span></tt>. Это позволит убедиться в использовании правильных флагов сборки и опций, таких как обработка заданий kdeinit и файлов перевода.</p>
<div class="highlight-python"><div class="highlight"><pre>%:
dh $@ --with=kde
</pre></div>
</div>
<p>Некоторые новые пакеты KDE используют систему <tt class="docutils literal"><span class="pre">dhmk</span></tt>, альтернативу <tt class="docutils literal"><span class="pre">dh</span></tt>, созданную командой Debian Qt/KDE. Прочесть о ней можно в /usr/share/pkg-kde-tools/qt-kde-team/2/README. Использующие её пакеты будут <tt class="docutils literal"><span class="pre">включать</span> <span class="pre">/usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk</span></tt> вместо запуска <tt class="docutils literal"><span class="pre">dh</span></tt>.</p>
</div>
<div class="section" id="translations">
<h4>Переводы<a class="headerlink" href="#translations" title="Ссылка на этот заголовок">¶</a></h4>
<p>Переводы пакетов из репозитория main импортируются на Launchpad и экспортируются с Launchpad в языковые пакеты Ubuntu.</p>
<p>Итак, каждый KDE-пакет в main должен создавать шаблоны переводов, включать оригинальные переводы и обрабатывать переводимые строки в <tt class="docutils literal"><span class="pre">.desktop</span></tt>-файлах.</p>
<p>Для генерации шаблонов переводов пакет должен содержать файл <tt class="docutils literal"><span class="pre">Messages.sh</span></tt>; если его там нет, обратитесь в апстрим. Проверить его работу можно, выполнив сценарий <tt class="docutils literal"><span class="pre">extract-messages.sh</span></tt>, который должен создать один или несколько файлов <tt class="docutils literal"><span class="pre">.pot</span></tt> в каталоге <tt class="docutils literal"><span class="pre">po/</span></tt>. В процессе сборки это будет сделано автоматически, если вы используете опцию <tt class="docutils literal"><span class="pre">--with=kde</span></tt> для <tt class="docutils literal"><span class="pre">dh</span></tt>.</p>
<p>Апстрим обычно также помещает файлы переводов <tt class="docutils literal"><span class="pre">.po</span></tt> в каталог <tt class="docutils literal"><span class="pre">po/</span></tt>. Если их там нет, проверьте, не выделены ли они в один из отдельных языковых пакетов апстрима, например, в языковые пакеты KDE SC. Если они в отдельном языковом пакете, на Launchpad необходимо собирать их вместе вручную. Проконсультируйтесь по этому поводу с <a class="reference external" href="https://launchpad.net/~dpm">Дэвидом Планеллой (David Planella)</a>.</p>
<p>Если пакет перемещён из universe в main, его следует перевыгрузить перед импортом переводов на Launchpad.</p>
<p>Файлы <tt class="docutils literal"><span class="pre">.desktop</span></tt> также требуют перевода. Мы добавили патч к KDELibs для чтения переводов из <tt class="docutils literal"><span class="pre">.po</span></tt>-файлов, указывающих на строку <tt class="docutils literal"><span class="pre">X-Ubuntu-Gettext-Domain=</span></tt>, добавляемую к файлам <tt class="docutils literal"><span class="pre">.desktop</span></tt> во время сборки пакета. Файл .pot для каждого пакета генерируется во время сборки и .po-файлы необходимо скачать из апстрима и включить в пакет или в наши языковые пакеты. Список .po-файлов, которые нужно скачать из репозиториев KDE, находится в <tt class="docutils literal"><span class="pre">/usr/lib/kubuntu-desktop-i18n/desktop-template-list</span></tt>.</p>
</div>
<div class="section" id="library-symbols">
<h4>Библиотечные символы<a class="headerlink" href="#library-symbols" title="Ссылка на этот заголовок">¶</a></h4>
<p>Библиотечные символы отслеживаются при помощи файлов <tt class="docutils literal"><span class="pre">.symbols</span></tt>, которые позволяют убедиться, что всё на месте. KDE использует библиотеки C++, которые действуют несколько иначе, чем библиотеки C. Для Debian команда Qt/KDE создала скрипты, которые позволяют справиться с этим. Документ <a class="reference external" href="http://pkg-kde.alioth.debian.org/symbolfiles.html">Работа с файлами symbols</a> описывает, как создавать и обновлять такие файлы.</p>
</div>
</div>
</div>
</div>
<div class="section" id="further-reading">
<h2>Информация для дальнейшего чтения<a class="headerlink" href="#further-reading" title="Ссылка на этот заголовок">¶</a></h2>
<p>Вы можете прочитать оффлайн-версию этого руководства в различных форматах, если установите один из <a class="reference external" href="https://launchpad.net/ubuntu/+source/ubuntu-packaging-guide">двоичных пакетов</a>.</p>
<p>Если вы желаете узнать больше о сборке пакетов Debian, вот несколько ресурсов Debian, которые могут быть вам полезны:</p>
<ul class="simple">
<li><p class="first"><a class="reference external" href="https://wiki.debian.org/HowToPackageForDebian">Как создавать пакеты для Debian</a>;</p>
</li>
<li><p class="first"><a class="reference external" href="http://www.debian.org/doc/debian-policy/">Руководство по политике Debian</a>;</p>
</li>
<li><p class="first"><a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/">Руководство начинающего разработчика Debian</a> — доступно на различных языках;</p>
</li>
<li><p class="first"><a class="reference external" href="http://www.debian.org/doc/manuals/packaging-tutorial/">Руководство по созданию пакетов</a> (также доступно в виде <a class="reference external" href="https://launchpad.net/ubuntu/+source/packaging-tutorial">пакета</a>);</p>
</li>
<li><p class="first"><a class="reference external" href="https://wiki.debian.org/Python/LibraryStyleGuide">Руководство по созданию пакетов для модулей Python</a>.</p>
</li>
</ul>
<p>Мы всегда стремимся улучшить это руководство. Если вы найдёте какую-либо ошибку, или хотите что-либо предложить, пожалуйста, <a class="reference external" href="https://bugs.launchpad.net/ubuntu-packaging-guide">создайте отчёт об ошибке на Launchpad</a>. Если вы хотели бы помочь в работе над руководством, его <a class="reference external" href="https://code.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk">исходный код</a> также доступен на Launchpad.</p>
</div>
</div>
<div class="divide"></div>
</div>
<div id="sidebar" class="grid_3 omega">
<div class="container-tweet">
<h3>Оглавление</h3>
<div class="toc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/introduction-to-ubuntu-development">1. Введение в разработку Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up">2. Подготовка</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro">3. Распределенная разработка Ubuntu — введение</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug">4. Исправление ошибок в Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug-example">5. Демонстрация: исправление ошибки в Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/packaging-new-software">6. Создание пакетов для новых программ</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/security-and-stable-release-updates">7. Обновления безопасности и обновления стабильных релизов</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/patches-to-packages">8. Патчи для пакетов</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-ftbfs">9. Исправление пакетов FTBFS (Fails To Build From Source)</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/libraries">10. Общие библиотеки</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/backports">11. Бэкпортирование обновлений программ</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/communication">1. Коммуникация при Разработке в Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/debian-dir-overview">2. Общий обзор каталога <tt class="docutils literal"><span class="pre">debian/</span></tt></a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/auto-pkg-test">3. autopkgtest: Автоматическое тестирование пакетов</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-getting-the-source">4. Получение исходного кода</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-working">5. Работа с пакетом</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-sponsorship">6. Поиск Обзоров и Спонсорства</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-uploading">7. Загрузка пакета</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-latest">8. Получение последних изменений</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-merging">9. Слияние — обновления из Debian и апстрима</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/chroots">10. Использование chroot-окружений</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/traditional-packaging">11. Традиционные методы создания пакетов</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/kde">12. Работа с пакетами KDE</a></li>
</ul>
</div>
<div class="browse-guide">
<h3>Browse The Guide:</h3>
<ul>
<li class="prev disabled">
</li>
<li class="center">
<a title="Back to Index" href="index.html#document-index">Index Guide</a>
</li>
<li class="next disabled">
</li>
</ul>
</div>
</div>
<div id="back_top"><a href="#top">Back to Top</a></div>
</div>
<!--</section>-->
</div>
</div>
<div class="shadow"></div>
<footer>
<div>
Version: 0.3.7.
<a href="https://bugs.launchpad.net/ubuntu-packaging-guide">Report bugs</a> or
<a href="https://code.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk">grab the source code</a> from Launchpad.
Создано с помощью <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.3.
<br />
© Copyright 2010-2015, Ubuntu Developers, Creative Commons Attribution-ShareAlike 3.0.
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">
Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.
<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">
<img alt="Creative Commons License" style="border-width:0"
src="./_static/images/cc-by-sa.png" /></a>
<br />
<a href="http://people.ubuntu.com/~mitya57/ubuntu-packaging-guide-readme.html#translating">Help translate</a> or
<a href="./_static/translators.html">view the list of translators</a>.
</div>
</footer>
</body>
</html>
|