/usr/share/doc/ubuntu-packaging-guide-html-pt-br/singlehtml/index.html is in ubuntu-packaging-guide-html-pt-br 0.3.6.
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 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 | <!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.6',
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="Conteúdo" href="index.html">Conteúdo</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>Guia de Empacotamento do Ubuntu<a class="headerlink" href="#ubuntu-packaging-guide" title="Link permanente para este título">¶</a></h1>
<p>Bem-vindo ao Guia de Desenvolvimento e Empacotamento do Ubuntu! Este é o local oficial para aprender tudo sobre o desenvolvimento e empacotamento do Ubuntu. Após ler este guia, você terá:</p>
<ul class="simple">
<li><p class="first">ouvido sobre as coisas mais importantes, processos e ferramentas no desenvolvimento do Ubuntu,</p>
</li>
<li><p class="first">seu ambiente de desenvolvimento configurado corretamente,</p>
</li>
<li><p class="first">uma ideia melhor de como se juntar à nossa comunidade,</p>
</li>
<li><p class="first">corrigido um erro real do Ubuntu como parte dos tutoriais.</p>
</li>
</ul>
<p>O Ubuntu não é somente um sistema operacional livre e de código-aberto, sua plataforma também é aberta e desenvolvida de maneira transparente. O código-fonte de cada um dos componentes pode ser obtido facilmente e toda mudança na plataforma do Ubuntu pode ser revisada.</p>
<p>Isto significa que você pode se envolver ativamente na melhoria dele e a comunidade de desenvolvedores da plataforma Ubuntu está sempre disposta a auxiliar seus pares a iniciar.</p>
<p>O Ubuntu também é uma comunidade de boas pessoas que acreditam no software livre e que este deve estar acessível a todos. Seus membro são amistosos e querem que você se envolva também. Queremos que você se envolva, faça perguntas, para fazer o Ubuntu melhor junto conosco.</p>
<p>Se você encontrar problemas, não entre em pânico! Confira o <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/communication"><em>artigo sobre comunicação</em></a> e você irá descobrir a maneira mais fácil de entrar em contato com outros desenvolvedores.</p>
<p>O guia é dividido em duas seções:</p>
<ul class="simple">
<li><p class="first">Um lista de artigos baseada em tarefas, coisas que você quer fazer.</p>
</li>
<li><p class="first">Um conjunto de artigos de base de conhecimento que se aprofunda em partes específicas de nossas ferramentas e fluxos de trabalho.</p>
</li>
</ul>
<p>This guide focuses on the Ubuntu Distributed Development packaging method.
This is a new way of packaging which uses Distributed Revision Control
branches. It currently has some limitations which mean many teams in Ubuntu
use <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/traditional-packaging"><em>traditional packaging</em></a> methods. See the
<a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro"><em>UDD Introduction</em></a> page for an introduction to the differences.</p>
<div class="section" id="articles">
<h2>Artigos<a class="headerlink" href="#articles" title="Link permanente para este título">¶</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>Introdução ao desenvolvimento Ubuntu<a class="headerlink" href="#introduction-to-ubuntu-development" title="Link permanente para este título">¶</a></h3>
<p>Ubuntu is made up of thousands of different components, written in many
different programming languages. Every component - be it a software library,
a tool or a graphical application - is available as a source package. Source
packages in most cases consist of two parts: the actual source code and
metadata. Metadata includes the dependencies of the package, copyright and
licensing information, and instructions on how to build the package. Once
this source package is compiled, the build process provides binary packages,
which are the .deb files users can install.</p>
<p>Every time a new version of an application is released, or when someone makes
a change to the source code that goes into Ubuntu, the source package must be
uploaded to Launchpad’s build machines to be compiled. The resulting binary
packages then are distributed to the archive and its mirrors in different
countries. The URLs in <tt class="docutils literal"><span class="pre">/etc/apt/sources.list</span></tt> point to an archive or mirror.
Every day images are built for a selection of different Ubuntu flavours. They
can be used in various circumstances. There are images you can put on a USB
key, you can burn them on DVDs, you can use netboot images and there are
images suitable for your phone and tablet. Ubuntu Desktop, Ubuntu Server,
Kubuntu and others specify a list of required packages that get on the image.
These images are then used for installation tests and provide the feedback
for further release planning.</p>
<p>Ubuntu’s development is very much dependent on the current stage of the
release cycle. We release a new version of Ubuntu every six months, which is
only possible because we have established strict freeze dates. With every
freeze date that is reached developers are expected to make fewer, less
intrusive changes. Feature Freeze is the first big freeze date after the
first half of the cycle has passed. At this stage features must be largely
implemented. The rest of the cycle is supposed to be focused on fixing bugs.
After that the user interface, then the documentation, the kernel, etc. are
frozen, then the beta release is put out which receives a lot of testing.
From the beta release onwards, only critical bugs get fixed and a release
candidate release is made and if it does not contain any serious problems, it
becomes the final release.</p>
<img alt="./_images/cycle-items.png" src="./_images/cycle-items.png" />
<p>Thousands of source packages, billions of lines of code, hundreds of
contributors require a lot of communication and planning to maintain
high standards of quality. At the beginning and in the middle of each release
cycle we have the Ubuntu Developer Summit where developers and contributors
come together to plan the features of the next releases. Every feature is
discussed by its stakeholders and a specification is written that contains
detailed information about its assumptions, implementation, the necessary
changes in other places, how to test it and so on. This is all done in an
open and transparent fashion, so you can participate remotely and listen to
a videocast, chat with attendants and subscribe to changes of specifications,
so you are always up to date.</p>
<p>Not every single change can be discussed in a meeting though, particularly
because Ubuntu relies on changes that are done in other projects. That is why
contributors to Ubuntu constantly stay in touch. Most teams or projects use
dedicated mailing lists to avoid too much unrelated noise. For more immediate
coordination, developers and contributors use Internet Relay Chat (IRC). All
discussions are open and public.</p>
<p>Uma outra importante ferramenta de comunicação são os relatórios de erros. Sempre que um defeito é encontrado em um pacote ou parte da infraestrutura, um relatório de erro deve ser registrado no Launchpad. Todas as informações são coletadas nesse relatório, a sua importância, o status e atualização de para quem foi atribuído, quando necessário. Isto faz com que seja uma ferramenta efetiva para ficar em cima dos erros em um pacote ou projeto e organizar a carga de trabalho.</p>
<p>Most of the software available through Ubuntu is not written by Ubuntu
developers themselves. Most of it is written by developers of other Open
Source projects and then integrated into Ubuntu. These projects are called
“Upstreams”, because their source code flows into Ubuntu, where we “just”
integrate it. The relationship to Upstreams is critically important to Ubuntu.
It is not just code that Ubuntu gets from Upstreams, but it is also that
Upstreams get users, bug reports and patches from Ubuntu (and other
distributions).</p>
<p>The most important Upstream for Ubuntu is Debian. Debian is the distribution
that Ubuntu is based on and many of the design decisions regarding the
packaging infrastructure are made there. Traditionally, Debian has always had
dedicated maintainers for every single package or dedicated maintenance teams.
In Ubuntu there are teams that have an interest in a subset of packages too,
and naturally every developer has a special area of expertise, but
participation (and upload rights) generally is open to everyone who
demonstrates ability and willingness.</p>
<p>Ser um novo colaborador do Ubuntu não é tão intimidador como parece e pode ser uma experiência bastante compensadora. Não é apenas aprender algo novo e excitante, mas também sobre compartilhar a solução e resolver um problema para milhões de usuários.</p>
<p>Open Source Development happens in a distributed world with different goals
and different areas of focus. For example there might be the case that a
particular Upstream is interested in working on a new big feature while
Ubuntu, because of the tight release schedule, is interested in shipping a
solid version with just an additional bug fix. That is why we make use of
“Distributed Development”, where code is being worked on in various branches
that are merged with each other after code reviews and sufficient discussion.</p>
<img alt="./_images/cycle-branching.png" src="./_images/cycle-branching.png" />
<p>No exemplo mencionado acima faria sentido incluir a versão existente do projeto no Ubuntu, adicionar uma correção de erro, colocá-lo no upstream para o seu próximo lançamento (se for possível) e inclui-lo na próxima versão do Ubuntu. Seria a melhor solução, uma situação onde todos saem ganhando.</p>
<p>To fix a bug in Ubuntu, you would first get the source code for the package,
then work on the fix, document it so it is easy to understand for other
developers and users, then build the package to test it. After you have
tested it, you can easily propose the change to be included in the current
Ubuntu development release. A developer with upload rights will review it for
you and then get it integrated into Ubuntu.</p>
<img alt="./_images/cycle-process.png" src="./_images/cycle-process.png" />
<p>Quando estiver tentando encontrar uma solução, normalmente é uma boa ideia verificar como o uspstream se o problema (ou uma possível solução) já é conhecida e, se não, fazer de tudo para que a solução seja um esforço coordenado.</p>
<p>Passos adicionais podem envolver fazer o backport da alteração para uma versão mais velha ainda suportada ou repassá-la ao upstream.</p>
<p>Os requisitos mais importantes para o sucesso no desenvolvimento do Ubuntu são: ter a habilidade de “fazer as coisas voltarem a funcionar”, não ter medo de ler documentação e fazer perguntas, jogar em equipe e gostar de trabalhar como detetive.</p>
<p>Bons lugares para você fazer perguntas são “<a class="reference external" href="mailto:ubuntu-motu%40lists.ubuntu.com">ubuntu-motu<span>@</span>lists<span>.</span>ubuntu<span>.</span>com</a>” e “#ubuntu-motu” em “irc.freenode.net”. Você irá encontrar vários novos amigos e pessoas com a mesma paixão que você tem: fazer do mundo um lugar melhor ao fazer software de código aberto melhor.</p>
</div>
<span id="document-ubuntu-packaging-guide/getting-set-up"></span><div class="section" id="getting-set-up">
<h3>Guia de configuração<a class="headerlink" href="#getting-set-up" title="Link permanente para este título">¶</a></h3>
<p>Há várias coisas que você precisa saber para começar a desenvolver para o Ubuntu. Esta artigo foi desenvolvido para deixar o seu computador preparado para que você possa começar a trabalhar com pacotes e enviá-los para a plataforma que hospeda o Ubuntu, o Launchpad. Eis o que vamos cobrir:</p>
<ul class="simple">
<li><p class="first">Instalando pacotes de programas relacionados. Isto inclui:</p>
<ul>
<li><p class="first">Utilitários de empacotamento específicos do Ubuntu</p>
</li>
<li><p class="first">Programas de criptografia para que seu trabalho possa ser verificado se foi feito por você</p>
</li>
<li><p class="first">Programas adicionais de criptografia para que você possa transferir seus arquivos com segurança</p>
</li>
</ul>
</li>
<li><p class="first">Criando e configurando sua conta no Launchpad</p>
</li>
<li><p class="first">Configurando o seu ambiente de desenvolvimento para ajudá-lo a fazer compilações de pacotes locais, interagir com outros desenvolvedores, e propor as alterações no Launchpad.</p>
</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Nota</p>
<p>É recomendado fazer o trabalho de empacotamento utilizando a versão do Ubuntu que atualmente estiver em desenvolvimento. Isto irá permitir que você teste as alterações no mesmo ambiente em que elas serão aplicadas e utilizadas.</p>
<p class="last">Don’t worry though, you can use <a class="reference external" href="https://wiki.ubuntu.com/QATeam/Testdrive">Testdrive</a>
or <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/chroots"><em>chroots</em></a> to safely use the development release.</p>
</div>
<div class="section" id="install-basic-packaging-software">
<h4>Instalar os programas de empacotamento básico<a class="headerlink" href="#install-basic-packaging-software" title="Link permanente para este título">¶</a></h4>
<p>Há várias ferramentas que irão fazer a sua vida como desenvolvedor do Ubuntu muito mais fácil. Você irá encontrar essas ferramentas mais adiante neste guia. Para instalar a maioria dessas ferramentas você precisará executar este comando:</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>Nota: Desde o Ubuntu 11.10 “Oneiric Ocelot” (ou se você tiver backports habilitados em uma versão atualmente suportada), o seguinte comando irá instalar as ferramentas acima e outras que são bem comuns no desenvolvimento do Ubuntu:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo apt-get install packaging-dev
</pre></div>
</div>
<p>Este comando instalará os seguintes programas:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">gnupg</span></tt> – <a class="reference external" href="https://www.gnupg.org/">GNU Privacy Guard</a> contains tools you will need to create a
cryptographic key with which you will sign files you want to upload to
Launchpad.</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">pbuilder</span></tt> – uma ferramenta para fazer a reprodução da construção dos pacotes em um ambiente limpo e isolado.</p>
</li>
<li><p class="first">“ubuntu-dev-tools” (e “devscripts”, uma dependência direta) – uma coleção de ferramentas para tornar mais fácil muitas tarefas de empacotamento.</p>
</li>
<li><tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> (and <tt class="docutils literal"><span class="pre">bzr</span></tt>, a dependency) – distributed version control
with Bazaar, a new way of working with packages for Ubuntu that will make it
easy for many developers to collaborate and work on the same code while
keeping it trivial to merge each other’s work.</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">apt-file</span></tt> fornece um caminho fácil para pesquisar um pacote binário que contém o determinado arquivo.</p>
</li>
</ul>
<div class="section" id="create-your-gpg-key">
<h5>Criar sua chave GPG<a class="headerlink" href="#create-your-gpg-key" title="Link permanente para este título">¶</a></h5>
<p>GPG stands for <a class="reference external" href="https://www.gnupg.org/">GNU Privacy Guard</a> and it implements the OpenPGP standard
which allows you to sign and encrypt messages and files. This is useful for a
number of purposes. In our case it is important that you can sign files with
your key so they can be identified as something that you worked on. If you
upload a source package to Launchpad, it will only accept the package if it
can absolutely determine who uploaded the package.</p>
<p>Para gerar uma nova chave GPG, execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --gen-key
</pre></div>
</div>
<p>GPG will first ask you which kind of key you want to generate. Choosing the
default (RSA and DSA) is fine. Next it will ask you about the keysize. The
default (currently 2048) is fine, but 4096 is more secure. Afterwards, it will
ask you if you want it to expire the key at some stage. It is safe to say “0”,
which means the key will never expire. The last questions will be about your
name and email address. Just pick the ones you are going to use for Ubuntu
development here, you can add additional email addresses later on. Adding a
comment is not necessary. Then you will have to set a passphrase, choose a
safe one (a passphrase is just a password which is allowed to include spaces).</p>
<p>Agora o GPG irá criar uma chave para você, o que pode levar uma pouco de tempo. Ele precisa de bytes aleatórios, então será bom se você fornecer ao sistema algum trabalho para fazer. Mova o cursor pela tela, digite alguns parágrafos de texto aleatório, carregue uma página da Internet.</p>
<p>uma vez feito isso, você receberá uma mensagem semelhante a esta:</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>Neste caso, <tt class="docutils literal"><span class="pre">43CDE61D</span></tt> é o <em>ID da chave</em>.</p>
<p>A seguir, você deve enviar a parte pública de sua chave para um servidor de chaves para que o mundo possa identificar mensagens e arquivos como sendo seus. Para fazer isso, digite:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --send-keys --keyserver keyserver.ubuntu.com <KEY ID>
</pre></div>
</div>
<p>This will send your key to the Ubuntu keyserver, but a network of keyservers
will automatically sync the key between themselves. Once this syncing is
complete, your signed public key will be ready to verify your contributions
around the world.</p>
</div>
<div class="section" id="create-your-ssh-key">
<h5>Criar sua chave SSH<a class="headerlink" href="#create-your-ssh-key" title="Link permanente para este título">¶</a></h5>
<p><a class="reference external" href="http://www.openssh.com/">SSH</a> stands for <em>Secure Shell</em>, and it is a protocol that allows you to
exchange data in a secure way over a network. It is common to use SSH to access
and open a shell on another computer, and to use it to securely transfer files.
For our purposes, we will mainly be using SSH to securely upload source packages
to Launchpad.</p>
<p>Para gerar uma chave SSH, digite:</p>
<div class="highlight-python"><div class="highlight"><pre>$ ssh-keygen -t rsa
</pre></div>
</div>
<p>O nome de arquivo padrão geralmente faz sentido, então você pode deixar como está. Por motivo de segurança, é altamente recomendado que você utilize uma frase secreta.</p>
</div>
<div class="section" id="set-up-pbuilder">
<h5>Configurando o pbuilder<a class="headerlink" href="#set-up-pbuilder" title="Link permanente para este título">¶</a></h5>
<p><tt class="docutils literal"><span class="pre">pbuilder</span></tt> permite você construir pacotes localmente em sua máquina. Ele serve para vários propósitos:</p>
<ul class="simple">
<li><p class="first">A construção será feita em um sistema mínimo e limpo. Isto ajuda a assegurar que suas construções sejam feitas com sucesso de uma maneira reprodutível, sem modificar seu sistema local</p>
</li>
<li><p class="first">Não há necessidade de instalar todas as <em>dependências de construção</em> localmente</p>
</li>
<li><p class="first">Você pode configurar múltiplas instâncias de várias versões do Ubuntu e do Debian</p>
</li>
</ul>
<p>Configurar o <tt class="docutils literal"><span class="pre">pbuilder</span></tt> é muito fácil, execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pbuilder-dist <release> create
</pre></div>
</div>
<p>where <release> is for example <cite>raring</cite>, <cite>saucy</cite>, <cite>trusty</cite> or in the case of
Debian maybe <cite>sid</cite>. This will take a while as it will download all the
necessary packages for a “minimal installation”. These will be cached though.</p>
</div>
</div>
<div class="section" id="get-set-up-to-work-with-launchpad">
<h4>Prepare-se para trabalhar com o Launchpad<a class="headerlink" href="#get-set-up-to-work-with-launchpad" title="Link permanente para este título">¶</a></h4>
<p>Com uma configuração local básica estabelecida, seu próximo passo será configurar o seu sistema para trabalhar com o Launchpad. Esta seção irá se concentrar nos seguintes tópicos:</p>
<blockquote>
<div><ul class="simple">
<li><p class="first">O que o Launchpad é e criando uma conta nele</p>
</li>
<li><p class="first">Enviando suas chaves GPG e SSH para o Launchpad</p>
</li>
<li><p class="first">Configurando o Bazaar para trabalhar com o Launchpad</p>
</li>
<li><p class="first">Configurando o Bash para trabalhar com o Bazaar</p>
</li>
</ul>
</div></blockquote>
<div class="section" id="about-launchpad">
<h5>Sobre o Launchpad<a class="headerlink" href="#about-launchpad" title="Link permanente para este título">¶</a></h5>
<p>O Launchpad é uma peça central da infraestrutura que usamos no Ubuntu. Ela não só armazena nossos pacotes e nossos códigos, mas também coisas como traduções, relatórios de erros, e informações sobre as pessoas que trabalham no Ubuntu e os seus grupos de membros. Você também irá usar o Launchpad para publicar propostas de correções, e conseguir outros desenvolvedores para revisão e orientação.</p>
<p>Você irá precisar se registrar no Launchpad e fornecer algumas informações mínimas. Isto irá permitir que você baixe e envie códigos, envie relatórios de erros e mais.</p>
<p>Além de hospedar o Ubuntu, o Launchpad pode hospedar qualquer projeto de Software Livre. Para mais informações, veja a <a class="reference external" href="https://help.launchpad.net/">wiki de ajuda do Launchpad</a>.</p>
</div>
<div class="section" id="get-a-launchpad-account">
<h5>Obter uma conta do Launchpad<a class="headerlink" href="#get-a-launchpad-account" title="Link permanente para este título">¶</a></h5>
<p>If you don’t already have a Launchpad account, you can easily <a class="reference external" href="https://launchpad.net/+login">create one</a>.
If you have a Launchpad account but cannot remember your Launchpad id, you can
find this out by going to <a class="reference external" href="https://launchpad.net/~">https://launchpad.net/~</a> and looking for the
part after the <cite>~</cite> in the URL.</p>
<p>O processo de registro do Launchpad irá pedir que você escolha um nome de exibição. O uso do nome real é encorajado aqui, de modo que seus colegas desenvolvedores do Ubuntu sejam capazes de lhe conhecer melhor.</p>
<p>Quando você registrar uma nova conta, o Launchpad enviará um email com um link que precisa ser aberto no seu navegador para verificar o seu endereço de email. Se você não recebê-lo, verifique na sua pasta de spam.</p>
<p><a class="reference external" href="https://help.launchpad.net/YourAccount/NewAccount">The new account help page</a> on Launchpad has more information
about the process and additional settings you can change.</p>
</div>
<div class="section" id="upload-your-gpg-key-to-launchpad">
<h5>Enviar sua chave GPG para o Launchpad<a class="headerlink" href="#upload-your-gpg-key-to-launchpad" title="Link permanente para este título">¶</a></h5>
<p>First, you will need to get your fingerprint and key ID.</p>
<p>Para pesquisar sobre sua impressão digital GPG, execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --fingerprint email@address.com
</pre></div>
</div>
<p>e será exibido alguma coisa como:</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>Then run this command to submit your key to Ubuntu keyserver:</p>
<div class="highlight-python"><div class="highlight"><pre>$ gpg --keyserver keyserver.ubuntu.com --send-keys 43CDE61D
</pre></div>
</div>
<p>where <tt class="docutils literal"><span class="pre">43CDE61D</span></tt> should be replaced by your key ID (which is in the
first line of output of the previous command). Now you can import your
key to Launchpad.</p>
<p>Vá para <a class="reference external" href="https://launchpad.net/~/+editpgpkeys">https://launchpad.net/~/+editpgpkeys</a> e copie a “Key fingerprint” na caixa de texto. No caso acima seria “5C28 0144 FB08 91C0 2CF3 37AC 6F0B F90F 43CD E61D”. Agora clique em “Import Key”.</p>
<p>O Launchpad irá usar a impressão digital para verificar a sua chave no servidor de chaves do Ubuntu e, se tudo ocorrer bem, enviar para você um e-mail criptografado pedindo para confirmar a importação da chave. Verifique a sua conta de e-mail e leia a mensagem que o Launchpad lhe enviou. “Se o seu cliente de e-mail tiver suporte a criptografia OpenPGP, ele irá pedir a senha que você escolheu para a chave quando o GPG a gerou. Digite a senha, e então clique no link para confirmar que a chave é sua”.</p>
<p>Launchpad encrypts the email, using your public key, so that it can be sure
that the key is yours. If you are using Thunderbird, the default Ubuntu email
client, you can install the <a class="reference external" href="https://apps.ubuntu.com/cat/applications/enigmail/">Enigmail plugin</a>
to easily decrypt the message.
If your email software does not support OpenPGP
encryption, copy the encrypted email’s contents, type <tt class="docutils literal"><span class="pre">gpg</span></tt> in your
terminal, then paste the email contents into your terminal window.</p>
<p>De volta ao site do Launchpad, clique no botão Confirm e o Launchpad irá completar a importação da sua chave OpenPGP.</p>
<p>Encontre mais informações em <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>Enviar sua chave SSH para o Launchpad<a class="headerlink" href="#upload-your-ssh-key-to-launchpad" title="Link permanente para este título">¶</a></h5>
<p>Open <a class="reference external" href="https://launchpad.net/~/+editsshkeys">https://launchpad.net/~/+editsshkeys</a> in a web browser, also open
<tt class="docutils literal"><span class="pre">~/.ssh/id_rsa.pub</span></tt> in a text editor. This is the public part of your SSH key,
so it is safe to share it with Launchpad. Copy the contents of the file and
paste them into the text box on the web page that says “Add an SSH key”. Now
click “Import Public Key”.</p>
<p>For more information on this process, visit the <a class="reference external" href="https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair">creating an SSH keypair</a>
page on Launchpad.</p>
</div>
<div class="section" id="configure-bazaar">
<h5>Configurar o Bazaar<a class="headerlink" href="#configure-bazaar" title="Link permanente para este título">¶</a></h5>
<p>O Bazaar é a ferramenta que usamos para armazenar as alterações de código de maneira lógica, para trocar alterações propostas e mesclá-las, mesmo se o desenvolvimento já estiver atualmente terminado. Ele é usado pelo novo método de Desenvolvimento Distribuído do Ubuntu de trabalho com pacotes do Ubuntu.</p>
<p>Para dizer ao Bazaar quem você é, simplesmente execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr whoami "Bob Dobbs <subgenius@example.com>"
$ bzr launchpad-login subgenius
</pre></div>
</div>
<p>“whoami” irá dizer ao Bazaar que nome e endereço de e-mail você deve usar para submeter mensagens. Com “launchpad-login”, você define a sua ID no Launchpad. Assim, o código que você publicar no Launchpad será associado a você.</p>
<p>Nota: se você não lembra do seu ID, vá para <a class="reference external" href="https://launchpad.net/~">https://launchpad.net/~</a> e veja onde ele redireciona você. A parte depois do “~” na URL é seu ID do Launchpad.)</p>
</div>
<div class="section" id="configure-your-shell">
<h5>Configurar seu shell<a class="headerlink" href="#configure-your-shell" title="Link permanente para este título">¶</a></h5>
<p>De maneira similar ao Bazaar, as ferramentas de empacotamento do Debian/Ubuntu precisam aprender sobre você também. Abra o seu “~/.bashrc” em um editor de texto e adicione algo parecido com isso ao final:</p>
<div class="highlight-python"><div class="highlight"><pre>export DEBFULLNAME="Bob Dobbs"
export DEBEMAIL="subgenius@example.com"
</pre></div>
</div>
<p>Agora salve o arquivo e reinicie o seu terminal ou execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ source ~/.bashrc
</pre></div>
</div>
<p>(se você não usa o shell padrão, que o é “bash”, favor editar devidamente o arquivo de configuração para o seu shell.)</p>
</div>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-intro"></span><div class="section" id="ubuntu-distributed-development-introduction">
<h3>Desenvolvimento distribuído do Ubuntu — Introdução<a class="headerlink" href="#ubuntu-distributed-development-introduction" title="Link permanente para este título">¶</a></h3>
<p>Este guia foca o empacotamento usando o método de <em>Desenvolvimento distribuído do Ubuntu</em> (UDD).</p>
<p>O <em>Desenvolvimento Distribuído Ubuntu</em> (sigla em inglês UDD) é uma nova técnica para o desenvolvimento dos pacotes do Ubuntu que usa ferramentas, processos e fluxos de trabalho similares ao desenvolvimento de programas baseados no sistema de controle de versão distribuído (sigla em inglês DVCS) genérico. O DVCS usado pelo UDD é o <a class="reference internal" href="#bazaar">Bazaar</a>.</p>
<div class="section" id="traditional-packaging-limitations">
<h4>Limitações do empacotamento tradicional<a class="headerlink" href="#traditional-packaging-limitations" title="Link permanente para este título">¶</a></h4>
<p>Tradicionalmente, os pacotes do Ubuntu são mantidos em arquivos tar. Um pacote fonte tradicional é composto pelo tar fonte do upstream, um tar “debian” (ou arquivo diff compactado nos pacotes mais antigos) contendo o empacotamento e um arquivo de metadados .dsc. Para ver um pacote tradicional, execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-get source kdetoys
</pre></div>
</div>
<p>Isto irá baixar o fonte do upstream “kdetoys_4.6.5.orig.tar.bz2”, o empacotamento “kdetoys_4.6.5-0ubuntu1.debian.tar.gz” e os metadados “kdetoys_4.6.5-0ubuntu1~ppa1.dsc”. Pressupondo que você possua o dpkg-dev instalado, ele irá extrair esses pacotes e lhe dar o pacote fonte.</p>
<p>O empacotamento tradicional consistiria em editar esses arquivos e então enviá-los de volta. Entretanto, isto daria pouca oportunidade de colaborar com outros desenvolvedores, alterações teriam que ser passadas através de arquivos diff sem uma maneira centralizada de rastreá-los, e dois desenvolvedores não poderiam fazer alterações ao mesmo tempo. Então a maioria dos times passaram a colocar os seus empacotamentos em um sistema de controle de revisão. Isto torna mais fácil para diversos desenvolvedores trabalharem em um pacote juntos. Entretanto, não há conexão direta entre o sistema de controle de revisão e os pacotes do arquivo, então os dois devem ser mantidos em sincronia manualmente. Como cada time trabalha em seu próprio sistema de controle de revisão, um desenvolvedor em potencial deve antes descobrir onde está e como obter o empacotamento antes que possa trabalhar no pacote.</p>
</div>
<div class="section" id="ubuntu-distributed-development">
<h4>Desenvolvimento distribuído do Ubuntu<a class="headerlink" href="#ubuntu-distributed-development" title="Link permanente para este título">¶</a></h4>
<p>With Ubuntu Distributed Development all packages in the Ubuntu (and Debian)
archive are automatically imported into Bazaar branches on our code hosting
site Launchpad. Changes can be made directly to these branches in
incremental steps and by anyone with commit access. Changes can also be made
in forked branches and merged back in with Merge Proposals when they are large
enough to need review or if they are by someone without direct commit access.</p>
<p>Os ramos UDD estão todos em uma localização padrão, então fazer um checkout é fácil:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:kdetoys
</pre></div>
</div>
<p>O histórico de mesclagens inclui dois ramos separados, um para a fonte upstream e outro que adiciona o diretório de empacotamento “debian/”:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd kdetoys
$ bzr qlog
</pre></div>
</div>
<p>(Este comando utiliza <em>qbzr</em> para uma interface gráfica, execute <tt class="docutils literal"><span class="pre">log</span></tt> em vez de <tt class="docutils literal"><span class="pre">qlog</span></tt> para saída de console.)</p>
<img alt="./_images/kdetoys-udd-branch.png" src="./_images/kdetoys-udd-branch.png" />
<p>This UDD branch of <em>kdetoys</em> shows the full packaging for each version
uploaded to Ubuntu with grey circles and the upstream source versions with
green circles. Versions are tagged with either the version in Ubuntu such as
<tt class="docutils literal"><span class="pre">4:4.2.29-0ubuntu1</span></tt> or for the upstream branch with the upstream version
<tt class="docutils literal"><span class="pre">upstream-4.2.96</span></tt>.</p>
<p>Many Ubuntu packages are based on the packages in Debian, UDD also imports the
Debian package into our branches. In the <em>kdetoys</em> branch above the Debian
versions from <em>unstable</em> are from the merge with blue circles while those from
<em>Debian experimental</em> are from the merge with yellow circles. Debian
releases are tagged with their version number, e.g., <tt class="docutils literal"><span class="pre">4:4.2.2-1</span></tt>.</p>
<p>So from a UDD branch you can see the complete history of changes to the package
and compare any two versions. For example, to see the changes between version
4.2.2 in Debian and the 4.2.2 in Ubuntu use:</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>(Esse comando usa <em>qbzr</em> para uma GUI, execute <tt class="docutils literal"><span class="pre">diff</span></tt> ao invés de <tt class="docutils literal"><span class="pre">qdiff</span></tt> para saída no terminal.)</p>
<img alt="./_images/kdetoys-udd-diff.png" src="./_images/kdetoys-udd-diff.png" />
<p>A partir disto, podemos observar claramente o que foi alterado no Ubuntu em comparação com o Debian, muito útil.</p>
</div>
<div class="section" id="bazaar">
<h4>Bazaar<a class="headerlink" href="#bazaar" title="Link permanente para este título">¶</a></h4>
<p>Os ramos UDD utilizam o Bazaar, um sistema de controle de revisão distribuída que visa ser fácil de usar àqueles familiarizados com sistemas famosos como o Subversion, oferencendo, ao mesmo tempo, os recursos do Git.</p>
<p>To do packaging with UDD you will need to know the basics of how to use
Bazaar to manage files. For an introduction to Bazaar see the <a class="reference external" href="http://doc.bazaar.canonical.com/bzr.dev/en/mini-tutorial/index.html">Bazaar Five
Minute Tutorial</a> and the <a class="reference external" href="http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html">Bazaar Users Guide</a>.</p>
</div>
<div class="section" id="limitations-of-udd">
<h4>Limitações do DDU<a class="headerlink" href="#limitations-of-udd" title="Link permanente para este título">¶</a></h4>
<p>O desenvolvimento distribuído do Ubuntu é um novo método para trabalhar com pacotes Ubuntu. Ele atualmente tem algumas limitações notáveis:</p>
<ul class="simple">
<li>Doing a full branch with history can take a lot of time and network
resources. You may find it quicker to do a lightweight checkout <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> but this will need a network access
for any further bzr operations.</li>
<li><p class="first">Trabalhar com patches é difícil. Patches podem ser vistos como um sistema de controle de revisão ramificado, então nós acabamos com um RCS em cima de um RCS.</p>
</li>
<li><p class="first">Não há como compilar diretamente a partir dos ramos. Você precisa criar um pacote fonte e enviá-lo.</p>
</li>
<li>Some packages have not been successfully imported into UDD branches. Recent
versions of Bazaar will automatically notify you when this is the case.
You can also check the <a class="reference external" href="http://package-import.ubuntu.com/status">status of the package importer</a>
manually before working on a branch.</li>
</ul>
<p>All of the above are being worked on and UDD is expected to become the main way
to work on Ubuntu packages soon. However currently most teams within Ubuntu do
not yet work with UDD branches for their development. However because UDD
branches are the same as the packages in the archive any team should be able to
accept merges against them.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/fixing-a-bug"></span><div class="section" id="fixing-a-bug-in-ubuntu">
<h3>Corrigindo um erro no Ubuntu<a class="headerlink" href="#fixing-a-bug-in-ubuntu" title="Link permanente para este título">¶</a></h3>
<div class="section" id="introduction">
<h4>Introdução<a class="headerlink" href="#introduction" title="Link permanente para este título">¶</a></h4>
<p>Se você seguiu as instruções do <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>prepare-se para o Desenvolvimento do Ubuntu</em></a>, você deve estar pronto para começar.</p>
<img alt="./_images/fixing-a-bug.png" src="./_images/fixing-a-bug.png" />
<p>Como você pode observar na imagem acima, não há surpresas no processo de correção de erros no Ubuntu: você encontra um problema, obtém o código, trabalha para corrigi-lo, testa, envia as alterações para o Launchpad e pede para que sejam revisadas e incorporadas. Neste guia nós passaremos por todas as etapas necessárias, uma por uma.</p>
</div>
<div class="section" id="finding-the-problem">
<h4>Encontrando o problema<a class="headerlink" href="#finding-the-problem" title="Link permanente para este título">¶</a></h4>
<p>Há várias maneiras diferentes de encontrar coisas nas quais trabalhar. Pode ser um relatório de erro que você mesmo encontrou (o que lhe dá uma boa oportunidade para testar a correção), ou um problema que você encontrou em outro lugar, talvez num relatório de erro.</p>
<p><a class="reference external" href="http://harvest.ubuntu.com/">Harvest</a> é onde podemos seguir as várias listas de afazeres relacionadas ao desenvolvimento do Ubuntu. Ele lista erros que já foram corrigidos no upstream ou no Debian, lista pequenos erros (que chamamos de “bitezise”), e assim por diante. Confira o site e encontre o seu primeiro bug para trabalhar.</p>
</div>
<div class="section" id="figuring-out-what-to-fix">
<span id="what-to-fix"></span><h4>Descobrindo o que corrigir<a class="headerlink" href="#figuring-out-what-to-fix" title="Link permanente para este título">¶</a></h4>
<p>Se você não sabe qual o pacote fonte que contém o código que tem o problema, mas você sabe o caminho para o programa afetado no seu sistema, você pode descobrir o pacote fonte no qual você precisa trabalhar.</p>
<p>Digamos que você tenha encontrado um erro no Tomboy, um aplicativo para tomar notas na área de trabalho. O Tomboy pode ser iniciado executando “/usr/bin/tomboy” na linha de comando. Para encontrar o pacote binário que contém esse aplicativo, use este comando:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-file find /usr/bin/tomboy
</pre></div>
</div>
<p>Isso deverá imprimir:</p>
<div class="highlight-python"><div class="highlight"><pre>tomboy: /usr/bin/tomboy
</pre></div>
</div>
<p>Note que a parte que precede o ponto-e-vírgula é o nome do pacote binário. Frequentemente, o pacote fonte e o pacote binário terão nomes diferentes. Isto é mais comum quando um único pacote fonte é utilizado para construir diferentes pacotes binários. Para encontrar o pacote fonte de um pacote binário em particular, digite:</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> é parte da instalação padrão do Ubuntu.</p>
</div>
<div class="section" id="getting-the-code">
<h4>Obtendo o código<a class="headerlink" href="#getting-the-code" title="Link permanente para este título">¶</a></h4>
<p>Uma vez que você saiba em qual pacote fonte trabalhar, você deverá obter uma cópia do código para o seu sistema, para que você possa depurá-lo. No Desenvovimento distribuído do Ubuntu, isto é feito <a class="reference internal" href="index.html#branching"><em>ramificando o ramo do pacote fonte</em></a> correspondente ao pacote fonte. O Launchpad mantém ramos de pacotes fontes para todos os pacotes do Ubuntu.</p>
<p>Once you’ve got a local branch of the source package, you can investigate the
bug, create a fix, and upload your proposed fix to Launchpad, in the form of a
Bazaar branch. When you are happy with your fix, you can <a class="reference internal" href="index.html#merge-proposal"><em>submit a
merge proposal</em></a>, which asks other Ubuntu developers to
review and approve your change. If they agree with your changes, an Ubuntu
developer will upload the new version of the package to Ubuntu so that
everyone gets the benefit of your excellent fix - and you get a little bit of
credit. You’re now on your way to becoming an Ubuntu developer!</p>
<p>Nós vamos descrever especificações sobre como ramificar um código, enviar sua correção e solicitar uma revisão nas próximas seções.</p>
</div>
<div class="section" id="work-on-a-fix">
<span id="working-on-a-fix"></span><h4>trabalhar em uma correção<a class="headerlink" href="#work-on-a-fix" title="Link permanente para este título">¶</a></h4>
<p>Há livros inteiros escritos sobre encontrar erros, corrigi-los, testá-los, etc. Se você for um programador novato, tente corrigir erros fáceis primeiro, como erros de digitação óbvios. Tente alterar o mínimo possível, e documente sua alteração e suposições com clareza.</p>
<p>Antes de trabalhar na correção você mesmo, tenha certeza de investigar se ninguém já corrigiu ou está trabalhando na correção para a falha. Boas fontes para verificar são:</p>
<ul class="simple">
<li><p class="first">Rastreamento de erros upstream (e Debian) de erros abertos e fechados,</p>
</li>
<li><p class="first">Histórico de revisão do upstream (ou lançamento recente) poderia ter corrigido o problema,</p>
</li>
<li><p class="first">bugs ou envio de pacotes do Debian ou outras distribuições.</p>
</li>
</ul>
<p>Você agora quer criar um patch que inclui a correção. O comando <tt class="docutils literal"><span class="pre">edit-patch</span></tt> é um caminho fácil para adicionar um patch em um pacote. Execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ edit-patch 99-new-patch
</pre></div>
</div>
<p>Isso copiará o empacotamento para um diretório temporário. Agora você pode editar arquivos com um editor de textos ou aplicar patches do upstream, por exemplo:</p>
<div class="highlight-python"><div class="highlight"><pre>$ patch -p1 < ../bugfix.patch
</pre></div>
</div>
<p>Após editar o tipo de arquivo <tt class="docutils literal"><span class="pre">exit</span></tt> ou pressione <tt class="docutils literal"><span class="pre">control-d</span></tt> para sair do shell temporário. O novo patch será adicionado em <tt class="docutils literal"><span class="pre">debian/patches</span></tt>.</p>
</div>
<div class="section" id="testing-the-fix">
<h4>Testando a correção<a class="headerlink" href="#testing-the-fix" title="Link permanente para este título">¶</a></h4>
<p>Para construir um pacote de teste com suas alterações, e execute estes comandos:</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>Isto irá criar um pacote fonte a partir do conteúdo do ramo (“-us -uc” irá apenas omitir o passo para assinar o pacote fonte) e “pbuilder-dist” irá construir o pacote a partir da fonte para qualquer “versão” que você escolher.</p>
<p>Uma vez que a construção for concluída, instale o pacote do <tt class="docutils literal"><span class="pre">~/pbuilder/<lançamento>_result/</span></tt> (usando <tt class="docutils literal"><span class="pre">sudo</span> <span class="pre">dpkg</span> <span class="pre">-i</span> <span class="pre"><pacote>_<versão>.deb</span></tt>). Então teste para ver se a falha está corrigida.</p>
<div class="section" id="documenting-the-fix">
<h5>Documentando a correção<a class="headerlink" href="#documenting-the-fix" title="Link permanente para este título">¶</a></h5>
<p>É muito importante documentar a sua alteração suficientemente de maneira que os desenvolvedores que olharem o código no futuro não terão que adivinhar qual foi o seu raciocínio e quais foram a suposições. Todo pacote fonte do Debian e do Ubuntu inclui o “debian/changelog”, onde alterações em cada pacote enviado são rastreadas.</p>
<p>A maneira mais fácil de atualizar isto é executar:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dch -i
</pre></div>
</div>
<p>Isto irá adicionar um modelo entrada de registro de alteração para você e iniciar um editor onde você possa preencher os espaços em branco. Um exemplo disso poderia ser:</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> should fill out the first and last line of such a changelog entry for
you already. Line 1 consists of the source package name, the version number,
which Ubuntu release it is uploaded to, the urgency (which almost always is
‘low’). The last line always contains the name, email address and timestamp
(in <span class="target" id="index-0"></span><a class="rfc reference external" href="http://tools.ietf.org/html/rfc5322.html"><strong>RFC 5322</strong></a> format) of the change.</p>
<p>Com isso fora do caminho, vamos nos concentrar na entrada do registro de alteração propriamente dita: é muito importante documentar:</p>
<blockquote>
<div><ol class="arabic simple">
<li><p class="first">onde a alteração foi realizada</p>
</li>
<li><p class="first">o que foi alterado</p>
</li>
<li><p class="first">onde a discussão da mudança aconteceu</p>
</li>
</ol>
</div></blockquote>
<p>In our (very sparse) example the last point is covered by <tt class="docutils literal"><span class="pre">(LP:</span> <span class="pre">#123456)</span></tt>
which refers to Launchpad bug 123456. Bug reports or mailing list threads or
specifications are usually good information to provide as a rationale for a
change. As a bonus, if you use the <tt class="docutils literal"><span class="pre">LP:</span> <span class="pre">#<number></span></tt> notation for Launchpad
bugs, the bug will be automatically closed when the package is uploaded to
Ubuntu.</p>
</div>
<div class="section" id="committing-the-fix">
<h5>Submetendo uma correção<a class="headerlink" href="#committing-the-fix" title="Link permanente para este título">¶</a></h5>
<p>Com a entrada escrita e salva no registro de mudanças, você pode apenas executar:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">debcommit</span>
</pre></div>
</div>
<p>e a mudança será submetida (localmente) com sua entrada no registro de mudanças como uma mensagem de submissão.</p>
<p>Para enviar ele para o Launchpad, como um nome de ramo remoto, você precisa manter a seguinte nomenclatura:</p>
<div class="highlight-python"><div class="highlight"><pre>lp:~<yourlpid>/ubuntu/<release>/<package>/<branchname>
</pre></div>
</div>
<p>Isto poderia por exemplo ser:</p>
<div class="highlight-python"><div class="highlight"><pre>lp:~emmaadams/ubuntu/trusty/specialpackage/fix-for-123456
</pre></div>
</div>
<p>Então se apenas você executar:</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>você deve estar preparado. O comando push deve enviá-lo ao Launchpad e o segundo comando irá abrir a página do Launchpad do ramo remoto no seu navegador. Lá, encontre o link “(+) Propose for merging”, clique nele para que a alteração seja revisada por alguém e incluída no Ubuntu.</p>
<p>Nosso artigo sobre <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-sponsorship"><em>buscando orientação</em></a> entra em mais detalhes sobre a obtenção de retorno para as suas alterações propostas.</p>
<p>Se o seu ramo corrigir problemas em uma versão estável ou for uma correção de segurança, você pode querer dar uma olhada no nosso artigo <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/security-and-stable-release-updates"><em>Atualizações de segurança e de versões estáveis</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>Tutorial: corrigindo uma falha no Ubuntu<a class="headerlink" href="#tutorial-fixing-a-bug-in-ubuntu" title="Link permanente para este título">¶</a></h3>
<p>Apesar de a mecânica para <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>corrigir um erro</em></a> ser a mesma para todos os erros, todo problema com que você se depara é provavelmente diferente dos outros. Um exemplo de problema concreto pode ajudar a ter uma ideia do que deve ser considerado em geral.</p>
<div class="admonition note">
<p class="first admonition-title">Nota</p>
<p class="last">No momento que este artigo estava sendo escrito, isto ainda não havia sido corrigido. Quando você estiver lendo o artigo, talvez já tenha sido corrigido. Tome isto como um exemplo e tente adaptá-lo ao problema específico que você está encarando.</p>
</div>
<div class="section" id="confirming-the-problem">
<h4>Confirmando o problema<a class="headerlink" href="#confirming-the-problem" title="Link permanente para este título">¶</a></h4>
<p>Digamos que o pacote “bumprace” não tenha uma página na Internet na sua descrição de pacote. Como primeiro passo, você iria verificar se o problema já esta solucionado. Isto é fácil de verificar, dê uma olhado na Central de Programas ou execute:</p>
<div class="highlight-python"><div class="highlight"><pre>apt-cache show bumprace
</pre></div>
</div>
<p>A saída deve ser similar a isto:</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>Um contra-exemplo seria o “gedit”, que tem uma página na Internet definida:</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>Algumas vezes você ira descobrir que um problema em particular que você está analisando já está corrigido. Para evitar desperdiçar esforço e duplicar trabalho, faz sentido fazer um trabalho de detetive antes.</p>
</div>
<div class="section" id="research-bug-situation">
<h4>Pesquisar situação da falha<a class="headerlink" href="#research-bug-situation" title="Link permanente para este título">¶</a></h4>
<p>Primeiro temos que verificar um relatório de erro para o problema já existe no Ubuntu. Talvez alguém já esteja trabalhando em uma correção, ou que possamos contribuir para solução de alguma maneira. Para o Ubuntu, nós demos uma rápida olhada em <a class="reference external" href="https://bugs.launchpad.net/ubuntu/+source/bumprace">https://bugs.launchpad.net/ubuntu/+source/bumprace</a> e não há um relatório de erro ara o problema lá.</p>
<div class="admonition note">
<p class="first admonition-title">Nota</p>
<p class="last">Para o Ubuntu a URL <tt class="docutils literal"><span class="pre">https://bugs.launchpad.net/ubuntu/+source/<pacote></span></tt> deve sempre levar até a página de falhas do pacote fonte em questão.</p>
</div>
<p>Para o Debian, que é a maior fonte para os pacotes do Ubuntu, nós demos uma olhada em <a class="reference external" href="http://bugs.debian.org/src:bumprace">http://bugs.debian.org/src:bumprace</a> e não achamos um relatório para o nosso problema também.</p>
<div class="admonition note">
<p class="first admonition-title">Nota</p>
<p class="last">Para o Debian a URL <tt class="docutils literal"><span class="pre">http://bugs.debian.org/src:<pacote></span></tt> deve sempre levar até a página de falhas do pacote fonte em questão.</p>
</div>
<p>The problem we are working on is special as it only concerns the
packaging-related bits of <tt class="docutils literal"><span class="pre">bumprace</span></tt>. If it was a problem in the source code
it would be helpful to also check the Upstream bug tracker. This is
unfortunately often different for every package you have a look at, but if
you search the web for it, you should in most cases find it pretty easily.</p>
</div>
<div class="section" id="offering-help">
<h4>Oferecendo ajuda<a class="headerlink" href="#offering-help" title="Link permanente para este título">¶</a></h4>
<p>Se você encontrou um relatório de erro aberto, se ele não estiver atribuído a alguém e você puder corrigi-lo, você deverá comentar no relatório a sua solução. Certifique-se de incluir toda a informação que puder: em que circunstâncias o erro acontece? Como você corrigiu o problema? Você testou a sua solução?</p>
<p>Se nenhum relatório de erro foi arquivado, você pode arquivá-lo. O que você deve ter em mente é: o problema é tão pequeno que pedir para alguém para repará-lo seria suficiente? Você conseguiu corrigir apenas parcialmente o problema e você quer ao menos compartilhar a sua parte na correção?</p>
<p>Isso é ótimo se você pode oferecer ajuda e certamente será apreciado.</p>
</div>
<div class="section" id="fixing-the-issue">
<h4>Corrigindo o problema<a class="headerlink" href="#fixing-the-issue" title="Link permanente para este título">¶</a></h4>
<p>Para este caso específico basta pesquisar na Internet “bumprace” e encontrar a sua página Web. Assegure-se de que é um site ativo e não apenas um catálogo de programas. <a class="reference external" href="http://www.linux-games.com/bumprace/">http://www.linux-games.com/bumprace/</a> parece que é o local apropriado.</p>
<p>Para nos dedicarmos a esse problema no pacote fonte, nós primeiro precisamos do fonte e nós podemos facilmente obtê-lo executando:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr branch ubuntu:bumprace
</pre></div>
</div>
<p>Se você leu <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/debian-dir-overview"><em>A visão geral do diretório Debian</em></a> previamente, você deve se lembrar que página Web para de um pacote está especificada na primeira página do “debian/control”, a seção que inicia com “Source”.</p>
<p>Então o que nós precisamos fazer é executar:</p>
<div class="highlight-python"><div class="highlight"><pre>cd bumprace
</pre></div>
</div>
<p>e edite o <tt class="docutils literal"><span class="pre">debian/control</span></tt> para adicionar <tt class="docutils literal"><span class="pre">Homepage:</span> <span class="pre">http://www.linux-games.com/bumprace/</span></tt>. O final da primeira seção será um bom lugar para colocá-lo. Uma vez que tenha feito isto, salve o arquivo.</p>
<p>Se você executar agora:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr diff
</pre></div>
</div>
<p>você deve ver alguma coisa como isto:</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>The diff is pretty simple to understand. The <tt class="docutils literal"><span class="pre">+</span></tt> indicates a line which was
added. In our cases it was added just before the second section, starting with
<tt class="docutils literal"><span class="pre">Package</span></tt>, which indicates a resulting binary package.</p>
</div>
<div class="section" id="documenting-the-fix">
<h4>Documentando a correção<a class="headerlink" href="#documenting-the-fix" title="Link permanente para este título">¶</a></h4>
<p>É importante explicar para seus colegas desenvolvedores o que exatamente você fez. Se você executar:</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>this will start an editor with a boilerplate changelog entry which you just
have to fill out. In our case something like <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> should do. Then save the file. To double-check this
worked out, run:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr diff debian/changelog
</pre></div>
</div>
<p>e você verá algo como isto:</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>Umas poucas considerações adicionais:</p>
<blockquote>
<div><ul class="simple">
<li><p class="first">Se você tem uma referência para um erro no Launchpad que está corrigido pelo problema, adicione (“LP: #<número do erro>”) para a linha de entrada do registro de alterações, ou seja, “(LP: #123456)”.</p>
</li>
<li><p class="first">Se você deseja que a sua correção seja incluída no Debian, a sintaxe para o erro no Debian é (Closes: #<número do erro>), ou seja, (Closes: #123456)”.</p>
</li>
<li><p class="first">Se for uma referencia para um erro de upstream ou Debian, ou lista de discussão, mencione isto também.</p>
</li>
<li><p class="first">Tente quebrar suas linhas em 80 caracteres.</p>
</li>
<li><p class="first">Tente ser específico, num texto não muito longo, mas o suficiente para que alguém (que não conhece profundamente o problema) possa entender.</p>
</li>
<li><p class="first">Menção como você corrigiu o problema e onde.</p>
</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="testing-the-fix">
<h4>Testando a correção<a class="headerlink" href="#testing-the-fix" title="Link permanente para este título">¶</a></h4>
<p>Para testar a correção, você precisa <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>ter seu ambiente de desenvolvimento configurado</em></a>, então construir o pacote, instalá-lo e verificar se o problema foi resolvido. Em nosso caso isto seria:</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>Na primeira etapa nós construímos o pacote fonte a partir do ramo, então o construímos usando “pbuilder”, e então inspecionamos o pacote para verificar se o campo da página inicial foi adicionado corretamente.</p>
<div class="admonition note">
<p class="first admonition-title">Nota</p>
<p class="last">In a lot of cases you will have to actually install the package
to make sure it works as expected. Our case is a lot easier. If the
build succeeded, you will find the binary packages in
<tt class="docutils literal"><span class="pre">~/pbuilder/<release>_result</span></tt>. Install them via
<tt class="docutils literal"><span class="pre">sudo</span> <span class="pre">dpkg</span> <span class="pre">-i</span> <span class="pre"><package>.deb</span></tt> or by double-clicking on them in your
file manager.</p>
</div>
<p>Como verificamos, o problema agora está resolvido, então o próximo passo é compartilhar nossa solução com o mundo.</p>
</div>
<div class="section" id="getting-the-fix-included">
<h4>Incluindo a correção<a class="headerlink" href="#getting-the-fix-included" title="Link permanente para este título">¶</a></h4>
<p>É feito para incluir a correção o mais upstream possível. Fazendo isto, você pode garantir que todos possam obter a fonte upstream como está, sem precisar fazer modificações locais para corrigi-la.</p>
<p>In our case we established that we have a problem with the packaging, both in
Ubuntu and Debian. As Ubuntu is based on Debian, we will send the fix to
Debian. Once it is included there, it will be picked up by Ubuntu eventually.
The issue in our tutorial is clearly non-critical, so this approach makes
sense. If it is important to fix the issue as soon as possible, you will
need to send the solution to multiple bug trackers. Provided the issue affects
all parties in question.</p>
<p>Para submeter o patch para o Debian, simplesmente execute:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">submittodebian</span>
</pre></div>
</div>
<p>Isto lhe levará por uma série de passos para assegurar que o erro vá parar no lugar correto. Assegure-se de revisar o diff novamente para ter certeza de que não inclui alterações aleatórias que você tenha feito antes.</p>
<p>Comunicação é importante, então quando você adicionar alguma descrição para solicitar a inclusão, seja amigável, explique ela bem.</p>
<p>Se tudo deu certo você deverá receber um e-mail do sistema de rastreamento de erros do Debian com mais informações. Isto pode levar alguns minutos.</p>
<div class="admonition note">
<p class="first admonition-title">Nota</p>
<p class="last">Se o problema só existe no Ubuntu, você pode considerar :doc:<a href="#id1"><span class="problematic" id="id2">`</span></a>Buscar revisão e orientação<./udd-sponsorship>`para que a correção seja incluída.</p>
</div>
</div>
<div class="section" id="additional-considerations">
<h4>Considerações adicionais<a class="headerlink" href="#additional-considerations" title="Link permanente para este título">¶</a></h4>
<p>Se você encontrar um pacote e achar que há algumas coisas pequenas que você pode corrigir ao mesmo tempo, faça isso. Isto irá acelerar a revisão e a inclusão.</p>
<p>Se há várias coisas grandes que você queira corrigir, é prudente que você envie patches individuais ou propostas de mesclagem. Se houver erros individuais já arquivados para esses problemas, isto facilita ainda mais.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/packaging-new-software"></span><div class="section" id="packaging-new-software">
<h3>Empacotando um novo software<a class="headerlink" href="#packaging-new-software" title="Link permanente para este título">¶</a></h3>
<p>Mesmo que haja milhares de pacotes no arquivo do Ubuntu, ainda há os que ninguém pegou ainda. Se houver um programa que você acha que deva ganhar uma exposição maior, talvez você queira colocar a mão na massa e criar um pacote para o Ubuntu ou um <a class="reference external" href="https://help.launchpad.net/Packaging/PPA">PPA</a>. Este guia irá mostrar passo-a-passo o processo de empacotamento e um novo programa.</p>
<p>Você deverá ler o artigo <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>Preparando</em></a> para preparar o seu ambiente de desenvolvimento.</p>
<div class="section" id="checking-the-program">
<h4>Verificando o programa<a class="headerlink" href="#checking-the-program" title="Link permanente para este título">¶</a></h4>
<p>O primeiro estágio no empacotamento é obter o tar da versão a partir do upstream (nós chamamos os autores dos aplicativos de “upstream”) e verificar se ele compila e executa.</p>
<p>Este guia irá mostrar como empacotar um aplicativo simples chamado GNU Hello que foi postado em <a class="reference external" href="http://www.gnu.org/software/hello/">GNU.org</a>.</p>
<p>Se você não tiver as ferramentas para compilação, vamos nos certificar de que você as obtenha antes. E se você não possui as dependências necessárias, vamos instalá-las também.</p>
<p>Instalar ferramentas de construção:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo apt-get install build-essential
</pre></div>
</div>
<p>Baixar pacote principal:</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>Agora descompacte o pacote principal:</p>
<div class="highlight-python"><div class="highlight"><pre>$ tar xf hello-2.7.tar.gz
$ cd hello-2.7
</pre></div>
</div>
<p>Este aplicativo utiliza um sistema de compilação de autoconfiguração, então nós devemos executar ”./configure” para preparar para a compilação.</p>
<p>This will check for the required build dependencies. As <tt class="docutils literal"><span class="pre">hello</span></tt> is a simple
example, <tt class="docutils literal"><span class="pre">build-essential</span></tt> should provide everything we need. For more
complex programs, the command will fail if you do not have the needed libraries
and development files. Install the needed packages and repeat until the command
runs successfully.:</p>
<div class="highlight-python"><div class="highlight"><pre>$ ./configure
</pre></div>
</div>
<p>Agora você pode compilar o fonte:</p>
<div class="highlight-python"><div class="highlight"><pre>$ make
</pre></div>
</div>
<p>Se a compilação concluir com sucesso você poderá instalar e executar o programa:</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>Iniciando um pacote<a class="headerlink" href="#starting-a-package" title="Link permanente para este título">¶</a></h4>
<p><tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> includes a plugin to create a new package from a template. The
plugin is a wrapper around the <tt class="docutils literal"><span class="pre">dh_make</span></tt> command. You should already have
these if you installed <tt class="docutils literal"><span class="pre">packaging-dev</span></tt>. Run the command providing the package
name, version number, and path to the upstream tarball:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo apt-get install dh-make
$ cd ..
$ bzr dh-make hello 2.7 hello-2.7.tar.gz
</pre></div>
</div>
<p>Quando for perguntado o tipo de pacote, digite “s” para um único binário. Isto irá importar o código para um ramo e adicionar o diretório de empacotamento “debian/”. Dê uma olhada no conteúdo. A maioria dos arquivos adicionados são necessários somente para pacotes especializados (como módulos Emacs), então você pode começar removendo os arquivos de exemplo opcionais:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd hello/debian
$ rm *ex *EX
</pre></div>
</div>
<p>Agora você deve customizar cada um dos arquivos.</p>
<p>In <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> change the
version number to an Ubuntu version: <tt class="docutils literal"><span class="pre">2.7-0ubuntu1</span></tt> (upstream version 2.7,
Debian version 0, Ubuntu version 1). Also change <tt class="docutils literal"><span class="pre">unstable</span></tt> to the current
development Ubuntu release such as <tt class="docutils literal"><span class="pre">trusty</span></tt>.</p>
<p>Much of the package building work is done by a series of scripts
called <tt class="docutils literal"><span class="pre">debhelper</span></tt>. The exact behaviour of <tt class="docutils literal"><span class="pre">debhelper</span></tt> changes
with new major versions, the compat file instructs <tt class="docutils literal"><span class="pre">debhelper</span></tt> which
version to act as. You will generally want to set this to the most
recent version which is <tt class="docutils literal"><span class="pre">9</span></tt>.</p>
<p><tt class="docutils literal"><span class="pre">control</span></tt> contains all the metadata of the package. The first paragraph
describes the source package. The second and following paragraphs describe
the binary packages to be built. We will need to add the packages needed to
compile the application to <tt class="docutils literal"><span class="pre">Build-Depends:</span></tt>. For <tt class="docutils literal"><span class="pre">hello</span></tt>, make sure that it
includes at least:</p>
<div class="highlight-python"><div class="highlight"><pre>Build-Depends: debhelper (>= 9)
</pre></div>
</div>
<p>Você também precisará preencher a descrição do programa no campo “Description:”.</p>
<p>“copyright” deve ser preenchido de acordo com a licença do código upstream. De acordo com o arquivo hello/COPYING, ela é GNU GPL 3 ou mais recente.</p>
<p>“docs” contém todos os arquivos de documentação do upstream que você acha que devam ser incluídos no pacote final.</p>
<p>“README.source” e “README.Debian” são necessários somente se o seu pacote tiver quaisquer características fora do padrão. Nós não temos, você pode excluí-los.</p>
<p>“source/format” pode ser deixado como está, ele descreve o formato da versão do pacote fonte e deve ser “3.0 (quilt)”.</p>
<p>O “rules” é o arquivo mais complexo. É um makefile que compila o código e o transforma em um pacote binário. Felizmente, a maior parte do trabalho hoje em dia é feita automaticamente pelo “debhelper 7” para que o alvo makefile universal “%” apenas execute o script “dh”, que irá executar tudo que for necessário.</p>
<p>Todos estes arquivos são explicados mais detalhadamente no artigo <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/debian-dir-overview"><em>resumo do diretório debian</em></a>.</p>
<p>Finalmente submeta o código para seu ramo de empacotamento:</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>Construindo o pacote<a class="headerlink" href="#building-the-package" title="Link permanente para este título">¶</a></h4>
<p>Agora precisamos verificar se nosso empacotamento compila o pacote com sucesso e constrói o pacote binário .deb:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -- -us -uc
$ cd ../../
</pre></div>
</div>
<p>“bzr builddeb” é um comando para construir o pacote no local atual. As opções “-us -uc” dizem que não é preciso que o GPG assine o pacote. O resultado será colocado em ”..”.</p>
<p>Você pode visualizar o conteúdo do pacote com:</p>
<div class="highlight-python"><div class="highlight"><pre>$ lesspipe hello_2.7-0ubuntu1_amd64.deb
</pre></div>
</div>
<p>Install the package and check it works (later you will be able to uninstall it
using <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> if you want):</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo dpkg --install hello_2.7-0ubuntu1_amd64.deb
</pre></div>
</div>
<p>You can also install all packages at once using:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo debi
</pre></div>
</div>
</div>
<div class="section" id="next-steps">
<h4>Próximos passos<a class="headerlink" href="#next-steps" title="Link permanente para este título">¶</a></h4>
<p>Even if it builds the .deb binary package, your packaging may have
bugs. Many errors can be automatically detected by our tool
<tt class="docutils literal"><span class="pre">lintian</span></tt> which can be run on the source .dsc metadata file, .deb
binary packages or .changes file:</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>To see verbose description of the problems use <tt class="docutils literal"><span class="pre">--info</span></tt> lintian flag
or <tt class="docutils literal"><span class="pre">lintian-info</span></tt> command.</p>
<p>Results of Ubuntu archive checks can be found online on
<a class="reference external" href="http://lintian.ubuntuwire.org">http://lintian.ubuntuwire.org</a>.</p>
<p>For Python packages, there is also a <tt class="docutils literal"><span class="pre">lintian4python</span></tt> tool that provides
some additional lintian checks.</p>
<p>Depois de efetuar uma correção no empacotamento, você pode reconstruí-lo usando “-nc” (no clean) não precisando construir tudo novamente:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -- -nc -us -uc
</pre></div>
</div>
<p>Having checked that the package builds locally you should ensure it builds on a
clean system using <tt class="docutils literal"><span class="pre">pbuilder</span></tt>. Since we are going to upload to a PPA
(Personal Package Archive) shortly, this upload will need to be <em>signed</em> to
allow Launchpad to verify that the upload comes from you (you can tell the
upload will be signed because the <tt class="docutils literal"><span class="pre">-us</span></tt> and <tt class="docutils literal"><span class="pre">-uc</span></tt> flags are not passed to
<tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">builddeb</span></tt> like they were before). For signing to work you need to have
set up GPG. If you haven’t set up <tt class="docutils literal"><span class="pre">pbuilder-dist</span></tt> or GPG yet, <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>do so
now</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>Quando você estiver feliz com seu pacote você irá querer que outros revisem-o. Você pode enviar para o ramo no Launchpad para revisão:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push lp:~<lp-username>/+junk/hello-package
</pre></div>
</div>
<p>Enviá-lo ao PPA irá assegurar que ele pode ser construído e irá fornecer uma maneira fácil para você e os outros testarem os pacotes binários. Você deverá configurá um PPA no Launchpad e então enviar o pacote com “dput”:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dput ppa:<lp-username>/<ppa-name> hello_2.7-0ubuntu1.changes
</pre></div>
</div>
<p>Veja <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-uploading"><em>uploading</em></a> para maiores informações.</p>
<p>You can ask for reviews in <tt class="docutils literal"><span class="pre">#ubuntu-motu</span></tt> IRC channel, or on the
<a class="reference external" href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu">MOTU mailing list</a>. There might also be a more specific
team you could ask such as the GNU team for more specific questions.</p>
</div>
<div class="section" id="submitting-for-inclusion">
<h4>Submetendo para inclusão<a class="headerlink" href="#submitting-for-inclusion" title="Link permanente para este título">¶</a></h4>
<p>Há várias maneira pelas quais um pacote pode entrar no Ubuntu. Na maioria dos casos, ir através do Debian primeiro pode ser a melhor maneira. Isto assegurará que o seu pacote alcançará o maior número de usuários, porque estará disponível não somente no Debian e no Ubuntu, mas também em todas as distribuições derivadas. Aqui estão alguns links úteis para enviar novos pacotes para o Debian:</p>
<blockquote>
<div><ul class="simple">
<li><a class="reference external" href="https://wiki.debian.org/DebianMentorsFaq">Debian Mentors FAQ</a> - debian-mentors is for the mentoring of new and
prospective Debian Developers. It is where you can find a sponsor
to upload your package to the archive.</li>
<li><a class="reference external" href="http://www.debian.org/devel/wnpp/">Work-Needing and Prospective Packages</a> - Information on how to file
“Intent to Package” and “Request for Package” bugs as well as list
of open ITPs and RFPs.</li>
<li><a class="reference external" href="http://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage">Debian Developer’s Reference, 5.1. New packages</a> - The entire
document is invaluable for both Ubuntu and Debian packagers. This
section documents processes for submitting new packages.</li>
</ul>
</div></blockquote>
<p>In some cases, it might make sense to go directly into Ubuntu first. For
instance, Debian might be in a freeze making it unlikely that your
package will make it into Ubuntu in time for the next release. This
process is documented on the <a class="reference external" href="https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages">“New Packages”</a> section of the Ubuntu wiki.</p>
</div>
<div class="section" id="screenshots">
<h4>Screenshots<a class="headerlink" href="#screenshots" title="Link permanente para este título">¶</a></h4>
<p>Once you have uploaded a package to debian, you should add screenshots
to allow propective users to see what the program is like. These should
be uploaded to <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>Atualizações de segurança de versão estável<a class="headerlink" href="#security-and-stable-release-updates" title="Link permanente para este título">¶</a></h3>
<div class="section" id="fixing-a-security-bug-in-ubuntu">
<h4>Corrigindo uma falha de segurança no Ubuntu<a class="headerlink" href="#fixing-a-security-bug-in-ubuntu" title="Link permanente para este título">¶</a></h4>
<div class="section" id="introduction">
<h5>Introdução<a class="headerlink" href="#introduction" title="Link permanente para este título">¶</a></h5>
<p>Fixing security bugs in Ubuntu is not really any different than <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>fixing a
regular bug in Ubuntu</em></a>, and it is assumed that you are familiar
with patching normal bugs. To demonstrate where things are different, we will
be updating the dbus package in Ubuntu 12.04 LTS (Precise Pangolin) for a security
update.</p>
</div>
<div class="section" id="obtaining-the-source">
<h5>Obtendo o fonte<a class="headerlink" href="#obtaining-the-source" title="Link permanente para este título">¶</a></h5>
<p>In this example, we already know we want to fix the dbus package in Ubuntu
12.04 LTS (Precise Pangolin). So first you need to determine the version of the
package you want to download. We can use the <tt class="docutils literal"><span class="pre">rmadison</span></tt> to help with this:</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>Typically you will want to choose the highest version for the release you want
to patch that is not in -proposed or -backports. Since we are updating Precise’s
dbus, you’ll download 1.4.18-1ubuntu1.4 from 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>Aplicando um patch no código fonte<a class="headerlink" href="#patching-the-source" title="Link permanente para este título">¶</a></h5>
<p>Now that we have the source package, we need to patch it to fix the
vulnerability. You may use whatever patch method that is appropriate for the
package, including <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro"><em>UDD techniques</em></a>, but this example will
use <tt class="docutils literal"><span class="pre">edit-patch</span></tt> (from the ubuntu-dev-tools package). <tt class="docutils literal"><span class="pre">edit-patch</span></tt> is the
easiest way to patch packages and it is basically a wrapper around every other
patch system you can imagine.</p>
<p>Para criar seu patch usando <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>Isto irá aplicar os patches existentes e colocar o pacote em um diretório temporário. Agora edite os arquivos necessários para corrigir a vulnerabilidade. Frequentemente, o upstream terá fornecido um patch, então você pode aplicá-lo:</p>
<div class="highlight-python"><div class="highlight"><pre>$ patch -p1 < /home/user/dbus-vulnerability.diff
</pre></div>
</div>
<p>Depois de fazer as mudanças necessárias, é só pressionar Ctrl-D ou digitar “exit” para sair temporariamente do shell.</p>
</div>
<div class="section" id="formatting-the-changelog-and-patches">
<h5>Formatando o registro de alteração e os patches<a class="headerlink" href="#formatting-the-changelog-and-patches" title="Link permanente para este título">¶</a></h5>
<p>After applying your patches you will want to update the changelog. The <tt class="docutils literal"><span class="pre">dch</span></tt>
command is used to edit the <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> file and <tt class="docutils literal"><span class="pre">edit-patch</span></tt> will
launch <tt class="docutils literal"><span class="pre">dch</span></tt> automatically after un-applying all the patches. If you are not
using <tt class="docutils literal"><span class="pre">edit-patch</span></tt>, you can launch <tt class="docutils literal"><span class="pre">dch</span> <span class="pre">-i</span></tt> manually. Unlike with regular
patches, you should use the following format (note the distribution name uses
precise-security since this is a security update for Precise) for security
updates:</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>Atualize o seu patch para que use tags apropriadas. Seu patch deve ter no mínimo a orígem, descrição e tags bug-Ubuntu. Por exemplo, edite debian/patches/99-fix-a-vulnerability.patch para ter algo como:</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>Várias vulnerabilidades podem ser corrigidas no mesmo envio de segurança; apenas certifique-se de usar patches diferentes para vulnerabilidades diferentes.</p>
</div>
<div class="section" id="test-and-submit-your-work">
<h5>Testar e enviar o seu trabalho<a class="headerlink" href="#test-and-submit-your-work" title="Link permanente para este título">¶</a></h5>
<p>Neste ponto, o processo é o mesmo que para <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>corrigir um erro comum no Ubuntu</em></a>. Especificamente, você deve:</p>
<blockquote>
<div><ol class="arabic simple">
<li><p class="first">Construir seu pacote e verificar se compilou sem erros e sem quaisquer avisos de compilador</p>
</li>
<li><p class="first">Atualizar para a nova versão do pacote de uma versão anterior</p>
</li>
<li><p class="first">Verifique se o novo pacotes corrige a vulnerabilidade e não introduz nenhuma regressão</p>
</li>
<li><p class="first">Envie seu trabalho via proposta de mesclagem do Launchpad, registre um erro no Launchpad assegurando-se de marcar o erro como erro de segurança e inscreva-se no “ubuntu-security-sponsors”.</p>
</li>
</ol>
</div></blockquote>
<p>Se a vulnerabilidade de segurança não é pública ainda então não adicione a proposta de mesclagem e certifique-se de que você marcou a falha como privada.</p>
<p>The filed bug should include a Test Case, i.e. a comment which clearly shows how
to recreate the bug by running the old version then how to ensure the bug no
longer exists in the new version.</p>
<p>The bug report should also confirm that the issue is fixed in Ubuntu versions
newer than the one with the proposed fix (in the above example newer than
Precise). If the issue is not fixed in newer Ubuntu versions you should prepare
updates for those versions too.</p>
</div>
</div>
<div class="section" id="stable-release-updates">
<h4>Atualizações de versão estável<a class="headerlink" href="#stable-release-updates" title="Link permanente para este título">¶</a></h4>
<p>We also allow updates to releases where a package has a high impact bug such as
a severe regression from a previous release or a bug which could cause data
loss. Due to the potential for such updates to themselves introduce bugs we
only allow this where the change can be easily understood and verified.</p>
<p>O processo para atualizações de versões estáveis é o mesmo que o processo para falhas de seguranção, exceto que você deve registrar “ubuntu-sru” no relatório de erro.</p>
<p>The update will go into the <tt class="docutils literal"><span class="pre">proposed</span></tt> archive (for example
<tt class="docutils literal"><span class="pre">precise-proposed</span></tt>) where it will need to be checked that it fixes the problem
and does not introduce new problems. After a week without reported problems it
can be moved to <tt class="docutils literal"><span class="pre">updates</span></tt>.</p>
<p>See the <a class="reference external" href="https://wiki.ubuntu.com/StableReleaseUpdates">Stable Release Updates wiki page</a> for more information.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/patches-to-packages"></span><div class="section" id="patches-to-packages">
<h3>Patches para pacotes<a class="headerlink" href="#patches-to-packages" title="Link permanente para este título">¶</a></h3>
<p>Sometimes, Ubuntu package maintainers have to change the upstream source code
in order to make it work properly on Ubuntu. Examples include, patches to
upstream that haven’t yet made it into a released version, or changes to the
upstream’s build system needed only for building it on Ubuntu. We could
change the upstream source code directly, but doing this makes it more
difficult to remove the patches later when upstream has incorporated them, or
extract the change to submit to the upstream project. Instead, we keep these
changes as separate patches, in the form of diff files.</p>
<p>Há várias maneiras diferentes de lidar com patches em pacotes Debian, felizmente estamos padronizando um sistema, <a class="reference external" href="https://wiki.debian.org/UsingQuilt">Quilt</a>, que agora é utilizado pela maioria dos pacotes.</p>
<p>Let’s look at an example package, <tt class="docutils literal"><span class="pre">kamoso</span></tt> in Trusty:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:trusty/kamoso
</pre></div>
</div>
<p>The patches are kept in <tt class="docutils literal"><span class="pre">debian/patches</span></tt>. This package has one patch
<tt class="docutils literal"><span class="pre">kubuntu_01_fix_qmax_on_armel.diff</span></tt> to fix a compile failure on ARM. The
patch has been given a name to describe what it does, a number to keep the
patches in order (two patches can overlap if they change the same file) and in
this case the Kubuntu team adds their own prefix to show the patch comes from
them rather than from Debian.</p>
<p>A ordem dos patches para aplicar é mantida em <tt class="docutils literal"><span class="pre">debian/patches/series</span></tt>.</p>
<div class="section" id="patches-with-quilt">
<h4>Patches com o Quilt<a class="headerlink" href="#patches-with-quilt" title="Link permanente para este título">¶</a></h4>
<p>Antes de trabalhar com o Quilt você precisa informar a ele onde encontrar os patches. Adicione isso em seu “~/.bashrc”:</p>
<div class="highlight-python"><div class="highlight"><pre>export QUILT_PATCHES=debian/patches
</pre></div>
</div>
<p>E forneça a origem do arquivo para aplicar a nova exportação:</p>
<div class="highlight-python"><div class="highlight"><pre>$ . ~/.bashrc
</pre></div>
</div>
<p>Por padrão, todos os patches são aplicados diretamente nos checkouts de UDD ou pacotes baixados. Você pode verificar isto com:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt applied
kubuntu_01_fix_qmax_on_armel.diff
</pre></div>
</div>
<p>Se você quisesse remover o patch poderia executar <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>E para aplicar um patch você usa <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>Adicionando um novo patch<a class="headerlink" href="#adding-a-new-patch" title="Link permanente para este título">¶</a></h4>
<p>Para adicionar um novo patch você deve dizer ao Quilt para criar um novo patch, dizer a ele quais arquivos o patch irá alterar, editar os arquivos e então atualizar o patch:</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>O passo <tt class="docutils literal"><span class="pre">quilt</span> <span class="pre">add</span></tt> é importante, se você esquecê-lo os arquivos não vão terminar no patch.</p>
<p>A mudança agora estará em <tt class="docutils literal"><span class="pre">debian/patches/kubuntu_02_program_description.diff</span></tt> e o arquivo <tt class="docutils literal"><span class="pre">series</span></tt> terá um novo patch adicionado a ele. Você deve adicionar o novo arquivo para o empacotamento:</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>O Quilt mantém os seus metadados no diretório ”.pc/”, então atualmente você precisa adicioná-lo ao empacotamento também. Isto deverá ser aprimorado no futuro.</p>
<p>As a general rule you should be careful adding patches to programs unless
they come from upstream, there is often a good reason why that change has not
already been made. The above example changes a user interface string for
example, so it would break all translations. If in doubt, do ask the upstream
author before adding a patch.</p>
</div>
<div class="section" id="patch-headers">
<h4>Patch Headers<a class="headerlink" href="#patch-headers" title="Link permanente para este título">¶</a></h4>
<p>We recommend that you tag every patch with <a class="reference external" href="http://dep.debian.net/deps/dep3/">DEP-3</a> headers by putting them at the top
of patch file. Here are some headers that you can use:</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">Description of what the patch does.
It is formatted like <tt class="docutils literal"><span class="pre">Description</span></tt> field in <tt class="docutils literal"><span class="pre">debian/control</span></tt>:
first line is short description, starting with lowercase letter,
the next lines are long description, indented with a space.</td>
</tr>
<tr class="field-even field"><th class="field-name">Author:</th><td class="field-body">Who wrote the patch (i.e. “Jane Doe <<a class="reference external" href="mailto:packager%40example.com">packager<span>@</span>example<span>.</span>com</a>>”).</td>
</tr>
<tr class="field-odd field"><th class="field-name">Origin:</th><td class="field-body">Where this patch comes from (i.e. “upstream”), when <em>Author</em> is
not present.</td>
</tr>
<tr class="field-even field"><th class="field-name">Bug-Ubuntu:</th><td class="field-body">A link to Launchpad bug, a short form is preferred (like
<em>https://bugs.launchpad.net/bugs/XXXXXXX</em>). If there are also
bugs in upstream or Debian bugtrackers, add <em>Bug</em> or <em>Bug-Debian</em>
headers.</td>
</tr>
<tr class="field-odd field"><th class="field-name">Forwarded:</th><td class="field-body">Whether the patch was forwarded upstream. Either “yes”, “no” or
“not-needed”.</td>
</tr>
<tr class="field-even field"><th class="field-name">Last-Update:</th><td class="field-body">Date of the last revision (in form “YYYY-MM-DD”).</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="upgrading-to-new-upstream-versions">
<h4>Atualizando para novas versões do upstream<a class="headerlink" href="#upgrading-to-new-upstream-versions" title="Link permanente para este título">¶</a></h4>
<p>To upgrade to the new version, you can use <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-upstream</span></tt> command:</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>When you run this command, all patches will be unapplied, because they can
become out of date. They might need to be refreshed to match the new upstream
source or they might need to be removed altogether. To check for problems,
apply the patches one at a time:</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>Se a aplicação puder ser revertida, isto significa que o patch já foi aplicado pelo upstream, então podemos excluir o patch:</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>Então continue:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt push
Applied kubuntu_02_program_description.diff
</pre></div>
</div>
<p>É bom executar uma atualização do patch relativo ao fonte do upstream alterado:</p>
<div class="highlight-python"><div class="highlight"><pre>$ quilt refresh
Refreshed patch kubuntu_02_program_description.diff
</pre></div>
</div>
<p>Então submeta como sempre:</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>Fazendo um pacote usar o Quilt<a class="headerlink" href="#making-a-package-use-quilt" title="Link permanente para este título">¶</a></h4>
<p>Pacotes modernos usam o Quilt por padrão, que é construído dentro do formato do pacote. Verifique <tt class="docutils literal"><span class="pre">debian/source/format</span></tt> para assegurar que ele diz <tt class="docutils literal"><span class="pre">3.0</span> <span class="pre">(quilt)</span></tt>.</p>
<p>Pacotes antigos usando o formato de fonte 1.0 terão que explicitar o uso do Quilt, normalmente incluindo um makefile dentro de <tt class="docutils literal"><span class="pre">debian/rules</span></tt>.</p>
</div>
<div class="section" id="configuring-quilt">
<h4>Configuring Quilt<a class="headerlink" href="#configuring-quilt" title="Link permanente para este título">¶</a></h4>
<p>You can use <tt class="docutils literal"><span class="pre">~/.quiltrc</span></tt> file to configure quilt. Here are some options
that can be useful for using quilt with debian/packages:</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>Outros sistemas de patch<a class="headerlink" href="#other-patch-systems" title="Link permanente para este título">¶</a></h4>
<p>Other patch systems used by packages include <tt class="docutils literal"><span class="pre">dpatch</span></tt> and <tt class="docutils literal"><span class="pre">cdbs</span>
<span class="pre">simple-patchsys</span></tt>, these work similarly to Quilt by keeping patches in
<tt class="docutils literal"><span class="pre">debian/patches</span></tt> but have different commands to apply, un-apply or create
patches. You can find out which patch system is used by a package by using the
<tt class="docutils literal"><span class="pre">what-patch</span></tt> command (from the <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt> package). You can use
<tt class="docutils literal"><span class="pre">edit-patch</span></tt>, shown in <a class="reference internal" href="index.html#working-on-a-fix"><em>previous chapters</em></a>, as a
reliable way to work with all systems.</p>
<p>In even older packages changes will be included directly to sources and kept
in the <tt class="docutils literal"><span class="pre">diff.gz</span></tt> source file. This makes it hard to upgrade to new upstream
versions or differentiate between patches and is best avoided.</p>
<p>Não altere um sistema de patches de um pacote sem discutir isto com o mantenedor Debian ou time Ubuntu responsável. Se não houver sistema de patches, então sinta-se à vontade para adicionar o Quilt.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/fixing-ftbfs"></span><div class="section" id="fixing-ftbfs-packages">
<h3>Fixing FTBFS packages<a class="headerlink" href="#fixing-ftbfs-packages" title="Link permanente para este título">¶</a></h3>
<p>Before a package can be used in Ubuntu, it has to build from source. If it
fails this, it will probably wait in -proposed and will not be available in
the Ubuntu archives. You can find a complete list of packages that are
failing to build from source at <a class="reference external" href="http://qa.ubuntuwire.org/ftbfs/">http://qa.ubuntuwire.org/ftbfs/</a>. There are 5
main categories shown on the page:</p>
<blockquote>
<div><ul class="simple">
<li>Package failed to build (F): Something actually went wrong with the build
process.</li>
<li>Cancelled build (X): The build has been cancelled for some reason. These
should probably be avoided to start with.</li>
<li>Package is waiting on another package (M): This package is waiting on
another package to either build, get updated, or (if the package is in
main) one of it’s dependancies is in the wrong part of the archive.</li>
<li>Failure in the chroot (C): Part of the chroot failed, this is most likely
fixed by a rebuild. Ask a developer to rebuild the package and that should
fix it.</li>
<li>Failed to upload (U): The package could not upload. This is usually just a
case of asking for a rebuild, but check the build log first.</li>
</ul>
</div></blockquote>
<div class="section" id="first-steps">
<h4>First steps<a class="headerlink" href="#first-steps" title="Link permanente para este título">¶</a></h4>
<p>The first thing you’ll want to do is see if you can reproduce the FTBFS
yourself. Get the code either by running <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">branch</span> <span class="pre">lp:ubuntu/PACKAGE</span></tt> and
then getting the tarball or running <tt class="docutils literal"><span class="pre">dget</span> <span class="pre">PACKAGE_DSC</span></tt> on the .dsc file from
the launchpad page. Once you have that, build it in a schroot.</p>
<p>You should be able to reproduce the FTBFS. If not, check if the build is
downloading a missing dependency, which means you just need to make that a
build-dependency in debian/control. Building the package locally can also
help find if the issue is caused by a missing, unlisted, dependency (builds
locally but fails on a schroot).</p>
</div>
<div class="section" id="checking-debian">
<h4>Checking Debian<a class="headerlink" href="#checking-debian" title="Link permanente para este título">¶</a></h4>
<p>Once you have reproduced the issue, it’s time to try and find a solution. If
the package is in Debian as well, you can check if the package builds there
by going to <a class="reference external" href="http://packages.qa.debian.org/PACKAGE">http://packages.qa.debian.org/PACKAGE</a>. If Debian has a newer
version, you should merge it. If not, check the buildlogs and bugs linked on
that page for any extra information on the ftbfs or patches. Debian also
maintains a list of command FTBFSs and how to fix them which can be found at
<a class="reference external" href="https://wiki.debian.org/qa.debian.org/FTBFS">https://wiki.debian.org/qa.debian.org/FTBFS</a>, you will want to check it for
solutions too.</p>
</div>
<div class="section" id="arm64">
<h4>ARM64<a class="headerlink" href="#arm64" title="Link permanente para este título">¶</a></h4>
<p>Ubuntu has added arm64 as a architecture recently, but many packages fail to
build on it. A full list of the packages not building are at
qa.ubuntuwire.org/ftbfs/arm64.html. Many of these are caused by packages
using outdated autotools helper files. Any package with the lintian warning
ancient-autotools-helper-file or outdated-autotools-helper-file will have
this issue. Adding autotools-dev or dh-autoreconf to the build proccess will
usually fix this.</p>
</div>
<div class="section" id="other-causes-of-a-package-to-ftbfs">
<h4>Other causes of a package to FTBFS<a class="headerlink" href="#other-causes-of-a-package-to-ftbfs" title="Link permanente para este título">¶</a></h4>
<p>If a package is in main and missing a dependency that is not in main, you
will have to file a MIR bug. <a class="reference external" href="https://wiki.ubuntu.com/MainInclusionProcess">https://wiki.ubuntu.com/MainInclusionProcess</a>
explains the procedure.</p>
</div>
<div class="section" id="fixing-the-issue">
<h4>Corrigindo o problema<a class="headerlink" href="#fixing-the-issue" title="Link permanente para este título">¶</a></h4>
<p>Once you have found a fix to the problem, follow the same process as any
other bug. Make a patch, add it to a bzr branch or bug, subscribe
ubuntu-sponsors, then try to get it included upstream and/or in Debian.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/libraries"></span><div class="section" id="shared-libraries">
<h3>Bibliotecas compartilhadas<a class="headerlink" href="#shared-libraries" title="Link permanente para este título">¶</a></h3>
<p>Bibliotecas compartilhadas são códigos compilados para serem compartilhados entre diversos programas diferentes. Eles são distribuídos como arquivos ”.so” em “/usr/lib/”.</p>
<p>Uma biblioteca exporta símbolos que são versões compiladas de funções, classes e variáveis. Uma biblioteca tem nome chamado de SONAME que inclui o número de versão. Esta versão SONAME não corresponde necessariamente ao número de versão de lançamento público. Um programa é compilado com uma versão SONAME da biblioteca. Se qualquer dos símbolos for removido ou alterado, então o número da versão precisa ser alterado, o que força todos os pacotes que usam aquela biblioteca a serem recompilados com a nova versão. A numeração de versão é geralmente definida pelo uspstream e nós a seguimos em nossos nomes de pacotes binários chamados numeração ABI. Mas às vezes o upstream não utiliza uma numeração de versão prática e os empacotadores têm que manter uma numeração de versão separada.</p>
<p>As bibliotecas são normalmente distribuídas pelo upstream como versões independentes. Às vezes elas são distribuídas como parte de um programa. Neste caso elas podem ser incluídas no pacote binário junto com o programa se você não espera que outros programas utilizem a biblioteca. Geralmente, elas devem ser divididas em pacotes binários separados.</p>
<p>As bibliotecas em si são colocadas em um pacote binário chamado “libfoo1” onde “foo” é o nome da biblioteca e “1” é a versão do SONAME. Arquivos de desenvolvimento do pacote, como os arquivos de cabeçalhos, necessários para compilar programas com a biblioteca, serão colocados em um pacote chamado “libfoo-dev”.</p>
<div class="section" id="an-example">
<h4>Um exemplo<a class="headerlink" href="#an-example" title="Link permanente para este título">¶</a></h4>
<p>Vamos usar libnova como um exemplo:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:trusty/libnova
$ sudo apt-get install libnova-dev
</pre></div>
</div>
<p>Para encontra o SONAME de uma biblioteca, execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ readelf -a /usr/lib/libnova-0.12.so.2 | grep SONAME
</pre></div>
</div>
<p>O SONAME é “libnova-0.12.so.2”, que corresponde ao nome do arquivo (geralmente é o caso, mas nem sempre). Aqui o upstream colocou o número da versão upstream como parte do SONAME e deu a ele a versão ABI “2”. Nomes de pacotes de bibliotecas devem seguir de acordo como SONAME das bibliotecas que contêm. O pacote binário de biblioteca “libnova-0.12-2” onde “libnova-0.12” é o nome da biblioteca e “2” é o nosso número ABI.</p>
<p>Se o upstream fizer alterações incompatíveis às suas bibliotecas, eles terão que reversionar o SONAME e nós teremos que renomear nossa biblioteca. Quaisquer outros pacotes usando o nosso pacote de biblioteca terão que ser recompilados com a nova versão, o que é chamado “transição” e pode exigir algum trabalho. Com sorte, nosso número ABI continuará a corresponder ao SONAME do uspstream, mas algumas vezes eles introduzem incompatibilidades sem alterar o seu número de versão e nós teremos que alterar o nosso.</p>
<p>Olhando em debian/libnova-0.12-2.install, vemos que inclui dos arquivos:</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>A última é a biblioteca real, completa com numeração de versão. A primeira é um link simbólico que aponta para a verdadeira biblioteca. O link simbólico é o que os programas que utilizam a biblioteca irão procurar, os programas em execução não se importam com alterações de versão menores.</p>
<p><tt class="docutils literal"><span class="pre">libnova-dev.install</span></tt> includes all the files needed to compile a program
with this library. Header files, a config binary, the <tt class="docutils literal"><span class="pre">.la</span></tt> libtool file and
<tt class="docutils literal"><span class="pre">libnova.so</span></tt> which is another symlink pointing at the library, programs
compiling against the library do not care about the major version number
(although the binary they compile into will).</p>
<p><tt class="docutils literal"><span class="pre">.la</span></tt> libtool files are needed on some non-Linux systems with poor library
support but usually cause more problems than they solve on Debian systems. It
is a current <a class="reference external" href="https://wiki.debian.org/ReleaseGoals/LAFileRemoval">Debian goal to remove .la files</a> and we should help with this.</p>
</div>
<div class="section" id="static-libraries">
<h4>Bibliotecas estáticas<a class="headerlink" href="#static-libraries" title="Link permanente para este título">¶</a></h4>
<p>The -dev package also ships <tt class="docutils literal"><span class="pre">usr/lib/libnova.a</span></tt>. This is a static library,
an alternative to the shared library. Any program compiled against the
static library will include the code directory into itself. This gets round
worrying about binary compatibility of the library. However it also means that
any bugs, including security issues, will not be updated along with the library
until the program is recompiled. For this reason programs using static
libraries are discouraged.</p>
</div>
<div class="section" id="symbol-files">
<h4>Arquivos de símbolos<a class="headerlink" href="#symbol-files" title="Link permanente para este título">¶</a></h4>
<p>When a package builds against a library the <tt class="docutils literal"><span class="pre">shlibs</span></tt> mechanism will add a
package dependency on that library. This is why most programs will have
<tt class="docutils literal"><span class="pre">Depends:</span> <span class="pre">${shlibs:Depends}</span></tt> in <tt class="docutils literal"><span class="pre">debian/control</span></tt>. That gets replaced with
the library dependencies at build time. However shlibs can only make it depend
on the major ABI version number, <tt class="docutils literal"><span class="pre">2</span></tt> in our libnova example, so if new symbols
get added in libnova 2.1 a program using these symbols could still be
installed against libnova ABI 2.0 which would then crash.</p>
<p>Para fazer as dependências de uma biblioteca mais precisas, nós mantemos os arquivos ”.symbols” que listam todos os símbolos em uma biblioteca e a versão em que eles aparecem.</p>
<p>libnova não tem arquivo de símbolos, então podemos criar um. Inicie compilando o pacote:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -- -nc
</pre></div>
</div>
<p>O “-nc” irá fazer terminar no final da compilação sem remover os arquivos de compilação. Vá para o diretório de compilação e execute “dpkg-gensymbols” para o pacote de biblioteca:</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>Isto gera um arquivo diff que você pode auto-aplicar:</p>
<div class="highlight-python"><div class="highlight"><pre>$ patch -p0 < symbols.diff
</pre></div>
</div>
<p>Which will create a file named similar to <tt class="docutils literal"><span class="pre">dpkg-gensymbolsnY_WWI</span></tt> that lists
all the symbols. It also lists the current package version. We can remove the
packaging version from that listed in the symbols file because new symbols are
not generally added by new packaging versions, but by the upstream developers:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sed -i s,-0ubuntu2,, dpkg-gensymbolsnY_WWI
</pre></div>
</div>
<p>Agora mova o arquivo para a seu novo local, submeta e faça uma construção de teste:</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>Se a compilação for bem-sucedida, o arquivo de símbolos está correto. Com a próxima versão usptream do libnova, se você executar dpkg-gensymbols novamente ele irá gerar um diff para atualizar o arquivo de símbolos.</p>
</div>
<div class="section" id="c-library-symbols-files">
<h4>Arquivos de símbolos de bibliotecas C++<a class="headerlink" href="#c-library-symbols-files" title="Link permanente para este título">¶</a></h4>
<p>C++ has even more exacting standards of binary compatibility than C. The
Debian Qt/KDE Team maintain some scripts to handle this, see their <a class="reference external" href="http://pkg-kde.alioth.debian.org/symbolfiles.html">Working with
symbols files</a> page for how to use them.</p>
</div>
<div class="section" id="further-reading">
<h4>Leitura adicional<a class="headerlink" href="#further-reading" title="Link permanente para este título">¶</a></h4>
<p>Junichi Uekawa’s <a class="reference external" href="http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html">Debian Library Packaging Guide</a> goes into this topic in more
detail.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/backports"></span><div class="section" id="backporting-software-updates">
<h3>Backport de atualização de programas<a class="headerlink" href="#backporting-software-updates" title="Link permanente para este título">¶</a></h3>
<p>Sometimes you might want to make new functionality available in a stable
release which is not connected to a critical bug fix. For these scenarios
you have two options: either you <a class="reference external" href="https://help.launchpad.net/Packaging/PPA">upload to a PPA</a>
or prepare a backport.</p>
<div class="section" id="personal-package-archive-ppa">
<h4>Arquivo de pacotes pessoal (PPA)<a class="headerlink" href="#personal-package-archive-ppa" title="Link permanente para este título">¶</a></h4>
<p>Usar um PPA tem várias vantagens. É bastante simples e você não precisa da aprovação de ninguém, mas o lado negativo disso é que seus usuários terão que ativá-lo manualmente. É um software de fonte não-padrão.</p>
<p>The <a class="reference external" href="https://help.launchpad.net/Packaging/PPA">PPA documentation on Launchpad</a> is fairly comprehensive and should get
you up and running in no time.</p>
</div>
<div class="section" id="official-ubuntu-backports">
<h4>Ubuntu Backports oficial<a class="headerlink" href="#official-ubuntu-backports" title="Link permanente para este título">¶</a></h4>
<p>O Projeto Backports é uma maneira de fornecer novos recursos aos usuários. Por causa dos riscos intrínsecos dos pacotes de backports, usuários não obtêm pacotes de backports sem algumas ações explícitas de suas partes. Isto geralmente faz com que backports sejam uma via inapropriada para correção de erros. Se um pacote em uma versão do Ubuntu possui um erro, ele deve ser corrigido através do <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/security-and-stable-release-updates"><em>processo de atualização de segurança ou de atualização de versão estável</em></a>, como deve ser.</p>
<p>Uma vez que você tenha decidido que quer que se faça um backport de um pacote para uma versão estável, você precisará construí-lo e testá-lo nessa dada versão estável. “pbuider-dist” (no pacote “ubuntu-dev-tools”) é uma ferramenta muito útil para se fazer isto facilmente.</p>
<p>Para relatar um pedido de backport e tê-lo processado polo time de Backport, você pode utilizar a ferramenta “requestbackport” (também no pacote “ubuntu-dev-tools”). Isso irá determinar que as versões intermediárias para as quais será feito um backport do pacote, listar todas as dependências reversas, e arquivar o pedido de backport. Irá também incluir uma lista de verificação de teste no rastreador de erros.</p>
</div>
</div>
</div>
</div>
<div class="section" id="knowledge-base">
<h2>Base de conhecimento<a class="headerlink" href="#knowledge-base" title="Link permanente para este título">¶</a></h2>
<div class="toctree-wrapper compound">
<span id="document-ubuntu-packaging-guide/communication"></span><div class="section" id="communication-in-ubuntu-development">
<h3>Comunicação no desenvolvimento do Ubuntu<a class="headerlink" href="#communication-in-ubuntu-development" title="Link permanente para este título">¶</a></h3>
<p>Em um projeto aonde milhares de linhas de código são alterados, muitas decisões são tomadas e centenas de pessoas interagem todos os dias, é importante se comunicar de forma eficaz.</p>
<div class="section" id="mailing-lists">
<h4>Listas de e-mails<a class="headerlink" href="#mailing-lists" title="Link permanente para este título">¶</a></h4>
<p>As listas de discussão são ferramentas muito importantes, se você quiser divulgar suas idéias para uma ampla equipe e ter certeza de que você alcance todos, até mesmo através de fusos horários diferentes.</p>
<p>Em termos de desenvolvimento, estas são as mais importantes:</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> (apenas anúncios, os mais importantes anúncios de desenvolvimento aqui)</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> (discussão geral de desenvolvimento do 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> (Time de discussão MOTU, obter ajuda com empacotamento)</p>
</li>
</ul>
</div>
<div class="section" id="irc-channels">
<h4>Canais de IRC<a class="headerlink" href="#irc-channels" title="Link permanente para este título">¶</a></h4>
<p>Para discussões em tempo real, por favor conecte-se na rede irc.freenode.net e entre em qualquer um desses canais:</p>
<ul class="simple">
<li><p class="first">#ubuntu-devel (para discussão geral de desenvolvimento)</p>
</li>
<li><p class="first">#ubuntu-motu (Time de discussão MOTU e obtenção de ajuda em geral)</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>Visão básica do diretório <tt class="docutils literal"><span class="pre">debian/</span></tt><a class="headerlink" href="#basic-overview-of-the-debian-directory" title="Link permanente para este título">¶</a></h3>
<p>Este artigo explicará sucintamente sobre os diferentes arquivos contidos no diretório <tt class="docutils literal"><span class="pre">debian/</span></tt>, importantes ao empacotamento Ubuntu. Os mais importantes são <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> e <tt class="docutils literal"><span class="pre">rules</span></tt>. Eles são obrigatórios para todos os pacotes. Diversos arquivos adicionais dentro de <tt class="docutils literal"><span class="pre">debian/</span></tt> podem ser usados para personalizar e configurar o comportamento do pacote. Alguns desses arquivos são abordados neste artigo, o que não significa que esta seja a lista completa.</p>
<div class="section" id="the-changelog">
<h4>O registro de mudanças<a class="headerlink" href="#the-changelog" title="Link permanente para este título">¶</a></h4>
<p>Este arquivo é, como seu nome implica, uma listagem das mudanças feitas em cada versão. Tem um formato específico que dá o nome do pacote, versão, distribuição, mudanças e quem fez as mudanças em um momento determinado. Se você tiver uma chave GPG (see: <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>Getting set up</em></a>), certifique-se de usar no <tt class="docutils literal"><span class="pre">changelog</span></tt> o mesmo nome e endereço de e-mail da chave. O documento a seguir é um modelo de <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>O formato (principalmente da data) é importante. A data deve estar no formato da <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>, o qual pode ser obtido pelo uso do comando <tt class="docutils literal"><span class="pre">date</span> <span class="pre">-R</span></tt>. Por conveniência, o comando <tt class="docutils literal"><span class="pre">dch</span></tt> pode ser usado para editar o arquivo de mudanças. Ele atualizará a data automaticamente.</p>
<p>Pontos menos importantes são indicados por um traço “-”, enquanto os pontos mais importantes usam um asterisco “*”.</p>
<p>Se você estiver empacotando do zero, <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> está no pacote <tt class="docutils literal"><span class="pre">devscripts</span></tt>) criará um <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> padrão para você.</p>
<p>Aqui está um exemplo de arquivo “changelog” para 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>Observe que a versão tem um <tt class="docutils literal"><span class="pre">-0ubuntu1</span></tt> acrescentado a ela, isso é a revisão da distro, usada para que o empacotamento possa ser atualizado (para corrigir falhas, por exemplo) com novos envios para a mesma versão de lançamento do fonte.</p>
<p>Ubuntu e Debian são ligeiramente diferentes nos esquemas de versionamento de pacotes para evitar pacotes conflitantes com a mesma versão de código fonte. Se um pacote Debian foi mudado no Ubuntu, ele terá <tt class="docutils literal"><span class="pre">ubuntuX</span></tt> (onde <tt class="docutils literal"><span class="pre">X</span></tt> é o número da revisão Ubuntu) acrescentado ao final da versão Debian. Então, se o pacote Debian hello <tt class="docutils literal"><span class="pre">2.6-1</span></tt> sofresse alterações pelo Ubuntu, sua versão seria <tt class="docutils literal"><span class="pre">2.6-1ubuntu1</span></tt>. Se um pacote para determinada aplicação não existir no Debian, então a revisão Debian será <tt class="docutils literal"><span class="pre">0</span></tt> (exemplo, <tt class="docutils literal"><span class="pre">2.6-0ubuntu1</span></tt>).</p>
<p>For further information, see the <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog">changelog section (Section 4.4)</a>
of the Debian Policy Manual.</p>
</div>
<div class="section" id="the-control-file">
<h4>O arquivo de controle<a class="headerlink" href="#the-control-file" title="Link permanente para este título">¶</a></h4>
<p>O arquivo <tt class="docutils literal"><span class="pre">control</span></tt> contém a informação que os gerenciadores de pacotes (tais como <tt class="docutils literal"><span class="pre">apt-get</span></tt>, <tt class="docutils literal"><span class="pre">synaptic</span></tt> e <tt class="docutils literal"><span class="pre">adept</span></tt>) usam, como dependências em tempo de construção de pacote, informações sobre o mantenedor e muito mais.</p>
<p>Para o pacote <tt class="docutils literal"><span class="pre">hello</span></tt> do Ubuntu, o arquivo <tt class="docutils literal"><span class="pre">control</span></tt> parece alguma coisa assim:</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>O primeiro parágrafo descreve o pacote fonte, incluindo a lista de pacotes necessários para construir o pacote a partir do fonte no campo <tt class="docutils literal"><span class="pre">Build-Depends</span></tt>. Também contém algumas meta-informações tais como o nome do mantenedor, a versão de Política Debian que cumpre tal pacote, a localização do repositório de controle de versão de empacotamento e a página de internet do programa original.</p>
<p>Note that in Ubuntu, we set the <tt class="docutils literal"><span class="pre">Maintainer</span></tt> field to a general address
because
anyone can change any package (this differs from Debian where changing packages
is usually restricted to an individual or a team). Packages in Ubuntu should
generally have the <tt class="docutils literal"><span class="pre">Maintainer</span></tt> field set to <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>. If the Maintainer field is modified,
the old value should be saved in the <tt class="docutils literal"><span class="pre">XSBC-Original-Maintainer</span></tt> field. This
can be done automatically with the <tt class="docutils literal"><span class="pre">update-maintainer</span></tt> script available in
the <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt> package. For further information, see the <a class="reference external" href="https://wiki.ubuntu.com/DebianMaintainerField">Debian
Maintainer Field spec</a> on the Ubuntu wiki.</p>
<p>Cada parágrafo adicional descreve um pacote binário a ser construído.</p>
<p>For further information, see the <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-controlfields.html">control file section (Chapter 5)</a>
of the Debian Policy Manual.</p>
</div>
<div class="section" id="the-copyright-file">
<h4>O arquivo de direitos autorais<a class="headerlink" href="#the-copyright-file" title="Link permanente para este título">¶</a></h4>
<p>This file gives the copyright information for both the upstream source and the
packaging. Ubuntu and <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile">Debian Policy (Section 12.5)</a>
require that each package installs a verbatim copy of its copyright and license
information to <tt class="docutils literal"><span class="pre">/usr/share/doc/$(package_name)/copyright</span></tt>.</p>
<p>Geralmente, informações sobre direitos autorais são encontradas no arquivo <tt class="docutils literal"><span class="pre">COPYING</span></tt> do diretório de arquivos fonte do programa. Este arquivo deve incluir informações como os nomes dos autores e do empacotador, a URL da qual o arquivo fonte foi baixado, uma linha com o ano e o titular do direito autoral e o próprio texto de direito autoral. Um exemplo de padrão seria:</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>This example follows the <a class="reference external" href="http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/">Machine-readable debian/copyright</a> format.
You are encouraged to use this format as well.</p>
</div>
<div class="section" id="the-rules-file">
<h4>O arquivo de regras<a class="headerlink" href="#the-rules-file" title="Link permanente para este título">¶</a></h4>
<p>O último arquivo que devemos olhar é o <tt class="docutils literal"><span class="pre">rules</span></tt>. Ele faz todo trabalho de criar nosso pacote. Ele é um Makefile com regras para compilar e instalar a aplicação, então criar o arquivo <tt class="docutils literal"><span class="pre">.deb</span></tt> a partir dos arquivos instalados. Ele também tem uma regra para limpar todos os arquivos de construção para que você possa apenas com os arquivos fonte.</p>
<p>Aqui é uma versão simplificada do arquivo de regras criado pelo <tt class="docutils literal"><span class="pre">dh_make</span></tt> (que pode ser encontrado no pacote <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>Vamos passar com mais detalhes sobre este arquivo. O que ele faz é passar por todas as regras de construção que <tt class="docutils literal"><span class="pre">debian/rules</span></tt> é chamado com argumentos para <tt class="docutils literal"><span class="pre">/usr/bin/dh</span></tt>, no qual ele mesmo chamará todos os comandos <tt class="docutils literal"><span class="pre">dh_*</span></tt> necessários.</p>
<p>“dh” executa uma sequência de comandos debhelper. As sequências suportadas correspondem às regras de um arquivo “debian/rules”: “build”, “clean”, “install”, “binary-arch”, “binary-indep” e “binary”. Para ver quais comandos são executados em cada regra, execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dh binary-arch --no-act
</pre></div>
</div>
<p>Comandos na sequência binary-indep são passados com a opção “-i” para garantir que funcionarão apenas em pacotes binário independentes e comandos na sequência binary-arch são passados com a opção “-a” para garantir que funcionarão apenas em pacotes dependentes de arquiteturas.</p>
<p>Cada comando debhelper gravará em <tt class="docutils literal"><span class="pre">debian/package.debhelper.log</span></tt> quando executado com sucesso. (O qual dh_clean apaga.) então dh pode dizer quais comandos foram executados, para quais pacotes e assim evitar rodar os mesmos comandos novamente.</p>
<p>Cada vez que o <tt class="docutils literal"><span class="pre">dh</span></tt> roda, ele examina o registro e procura pelo último comando registrado que está numa sequência especificada. Então, ele continua com o comando seguinte. As opções <cite>–until`</cite>, <tt class="docutils literal"><span class="pre">--before</span></tt>, <tt class="docutils literal"><span class="pre">--after</span></tt> e <tt class="docutils literal"><span class="pre">--remaining</span></tt> podem sobrescrever este comportamento.</p>
<p>Se o “debian/rules” contiver um alvo com um nome como “override_dh_command”, então quando ele receber este comando o “dh” executará aquele alvo a partir do arquivo rules, em vez de executar o comando real. A substituição do alvo pode então executar o comando com opções adicionais, ou executar comandos totalmente diferentes. (Note que para usar este recurso, você deve construir as dependências com o debhelper 7.0.50 ou superior.)</p>
<p>Veja em <tt class="docutils literal"><span class="pre">/usr/share/doc/debhelper/examples/</span></tt> e <tt class="docutils literal"><span class="pre">man</span> <span class="pre">dh</span></tt> para mais exemplos. Veja também <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules">a seção de regras (Seção 4.9)</a> do Manual de Políticas do Debian.</p>
</div>
<div class="section" id="additional-files">
<h4>Arquivos adicionais<a class="headerlink" href="#additional-files" title="Link permanente para este título">¶</a></h4>
<div class="section" id="the-install-file">
<h5>O arquivo de instalação<a class="headerlink" href="#the-install-file" title="Link permanente para este título">¶</a></h5>
<p>O arquivo <tt class="docutils literal"><span class="pre">install`</span> <span class="pre">é</span> <span class="pre">usado</span> <span class="pre">por</span> <span class="pre">``dh_install</span></tt> para instalar arquivos no pacote binário. Ele possui dois casos de uso padrão:</p>
<ul class="simple">
<li><p class="first">Para arquivos de instalação dentro do seu pacote que não são manipulados pelo sistema de construção do upstream.</p>
</li>
<li><p class="first">Dividindo um grande e único pacote fonte em múltiplos pacotes binários.</p>
</li>
</ul>
<p>No primeiro caso, o arquivo <tt class="docutils literal"><span class="pre">install</span></tt> deveria ter uma linha por arquivo instalado, especificando ambos arquivos e o local da instalação. Por exemplo, o seguinte arquivo <tt class="docutils literal"><span class="pre">install</span></tt> instalaria o script <tt class="docutils literal"><span class="pre">foo</span></tt> na fonte do pacote do diretório raiz para <tt class="docutils literal"><span class="pre">usr/bin</span></tt> e um atalho no diretório <tt class="docutils literal"><span class="pre">debian</span></tt> para <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>When a source package is producing multiple binary packages <tt class="docutils literal"><span class="pre">dh</span></tt> will
install the files into <tt class="docutils literal"><span class="pre">debian/tmp</span></tt> rather than directly into
<tt class="docutils literal"><span class="pre">debian/<package></span></tt>. Files installed into <tt class="docutils literal"><span class="pre">debian/tmp</span></tt> can then be moved
into separate binary packages using multiple <tt class="docutils literal"><span class="pre">$package_name.install</span></tt> files.
This is often done to split large amounts of architecture independent data out
of architecture dependent packages and into <tt class="docutils literal"><span class="pre">Architecture:</span> <span class="pre">all</span></tt> packages. In
this case, only the name of the files (or directories) to be installed are
needed without the installation directory. For example, <tt class="docutils literal"><span class="pre">foo.install</span></tt>
containing only the architecture dependent files might look like:</p>
<div class="highlight-python"><div class="highlight"><pre>usr/bin/
usr/lib/foo/*.so
</pre></div>
</div>
<p>Enquanto <tt class="docutils literal"><span class="pre">foo-common.install</span></tt> contendo apenas o arquivo independente da arquitetura pode parecer como:</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>Isso criará dois pacotes binários, <tt class="docutils literal"><span class="pre">foo</span></tt> e <tt class="docutils literal"><span class="pre">foo-common</span></tt>. Ambos necessitam de seu próprio parágrafo em <tt class="docutils literal"><span class="pre">debian/control</span></tt>.</p>
<p>Veja “man dh_install” e a “seção de arquivo de instalação (Seção 5,11) <<a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install">http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install</a>>”_ do Novo Guia dos Mantenedores do Debian para detalhes adicionais.</p>
</div>
<div class="section" id="the-watch-file">
<h5>O arquivo watch<a class="headerlink" href="#the-watch-file" title="Link permanente para este título">¶</a></h5>
<p>O arquivo “debian/watch” nos permite verificar automaticamente a existência de novas versões no upstream usando a ferramenta “uscan” encontrada no pacote “devscripts”. A primeira linha do arquivo watch deve ser a versão do formato (3, quando este texto foi escrito), enquanto que as linhas seguintes contém quaisquer URLs a serem analisadas. Por exemplo:</p>
<div class="highlight-python"><div class="highlight"><pre>version=3
http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz
</pre></div>
</div>
<p>Ao executar <tt class="docutils literal"><span class="pre">uscan</span></tt> no diretório raiz dos fontes irá comparar o número da versão no upstream em <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> com a última versão disponível no upstream. Se uma nova versão upstream for encontrada, ela será baixada automaticamente. Por exemplo:</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>If your tarballs live on Launchpad, the <tt class="docutils literal"><span class="pre">debian/watch</span></tt> file is a little more
complicated (see <a class="reference external" href="https://answers.launchpad.net/launchpad/+question/21146">Question 21146</a> and <a class="reference external" href="https://launchpad.net/launchpad/+bug/231797">Bug 231797</a>
for why this is). In that case, use something like:</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>Para maiores informações, veja <tt class="docutils literal"><span class="pre">man</span> <span class="pre">uscan</span></tt> e a <a class="reference external" href="http://www.debian.org/doc/debian-policy/ch-source.html#s-debianwatch">seção do arquivo watch (Seção 4.11)</a> do Manual de políticas do Debian.</p>
<p>Para uma lista dos pacotes cujo arquivo “watch” relata não estarem sincronizados com o upstream, consulte <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>O arquivo source/format<a class="headerlink" href="#the-source-format-file" title="Link permanente para este título">¶</a></h5>
<p>Este arquivo indica o formato do pacote fonte. Ele deve conter uma única linha indicando o formato desejado:</p>
<ul class="simple">
<li><p class="first"><tt class="docutils literal"><span class="pre">3.0</span> <span class="pre">(native)</span></tt> para pacotes nativos do Debian (sem versão do upstream)</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">3.0</span> <span class="pre">(quilt)</span></tt> para pacotes com um tarball separado do upstream</p>
</li>
<li><p class="first"><tt class="docutils literal"><span class="pre">1.0</span></tt> para pacotes que desejam declarar explicitamente o formato padrão</p>
</li>
</ul>
<p>Atualmente, o formato fonte do pacote será padronizada para 1.0 se o arquivo não existir. Você pode fazer isso explicitamente no arquivo/formato fonte. Se você escolher não utilizar este arquivo para definir o formato fonte, o Lintian irá lhe avisar sobre o arquivo ausente. Este aviso é apenas uma informação e pode ser ignorado com segurança.</p>
<p>Você é encorajado a usar o mais recente formato de fonte, o 3.0. Ele fornece uma quantia de novos recursos:</p>
<ul class="simple">
<li><p class="first">Suporte para formatos de compressão adicionais: bzip2, lzma e xz</p>
</li>
<li><p class="first">Suporte para múltiplos tarballs do upstream</p>
</li>
<li><p class="first">Não é necessário reempacotar o tarball do upstream para retirar o diretório debian</p>
</li>
<li><p class="first">Mudanças específicas do Debian não são armazenadas em um único .diff.gz, mas em múltiplos patches compatíveis com o quilt em <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> summarizes additional information
concerning the switch to the 3.0 source package formats.</p>
<p>See <tt class="docutils literal"><span class="pre">man</span> <span class="pre">dpkg-source</span></tt> and the <a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcef">source/format section (Section 5.21)</a> of the Debian New Maintainers’ Guide for additional details.</p>
</div>
</div>
<div class="section" id="additional-resources">
<h4>Recursos adicionais<a class="headerlink" href="#additional-resources" title="Link permanente para este título">¶</a></h4>
<p>In addition to the links to the Debian Policy Manual in each section above, the
Debian New Maintainers’ Guide has more detailed descriptions of each file.
<a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dreq.en.html">Chapter 4, “Required files under the debian directory”</a>
further discusses the control, changelog, copyright and rules files.
<a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/dother.en.html">Chapter 5, “Other files under the debian directory”</a>
discusses additional files that may be used.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/auto-pkg-test"></span><div class="section" id="autopkgtest-automatic-testing-for-packages">
<h3>autopkgtest: Teste automático para pacotes<a class="headerlink" href="#autopkgtest-automatic-testing-for-packages" title="Link permanente para este título">¶</a></h3>
<p>The <a class="reference external" href="http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=doc/README.package-tests">DEP 8 specification</a> defines how automatic testing can very easily be
integrated into packages. To integrate a test into a package, all you need to
do is:</p>
<ul>
<li><p class="first">adicione o seguinte à seção Source em <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">adicione um arquivo chamado <tt class="docutils literal"><span class="pre">debian/tests/control</span></tt> que especifica os requisitos para o testbed,</p>
</li>
<li><p class="first">adicione os testes em <tt class="docutils literal"><span class="pre">debian/tests/</span></tt>.</p>
</li>
</ul>
<div class="section" id="testbed-requirements">
<h4>Requisitos do Testbed<a class="headerlink" href="#testbed-requirements" title="Link permanente para este título">¶</a></h4>
<p>In <tt class="docutils literal"><span class="pre">debian/tests/control</span></tt> you specify what to expect from the testbed. So
for example you list all the required packages for the tests, if the testbed
gets broken during the build or if <tt class="docutils literal"><span class="pre">root</span></tt> permissions are required. The
<a class="reference external" href="http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=doc/README.package-tests">DEP 8 specification</a> lists all available options.</p>
<p>Abaixo estamos vendo o pacote fonte do <tt class="docutils literal"><span class="pre">glib2.0</span></tt>. Em um caso muito simples, o arquivo se pareceria com isto:</p>
<div class="highlight-python"><div class="highlight"><pre>Tests: build
Depends: libglib2.0-dev, build-essential
</pre></div>
</div>
<p>Para o teste em <tt class="docutils literal"><span class="pre">debian/tests/build</span></tt> isto deverá garantir que os pacotes <tt class="docutils literal"><span class="pre">libglib2.0-dev</span></tt> e <tt class="docutils literal"><span class="pre">build-essential</span></tt> estão instalados.</p>
<div class="admonition note">
<p class="first admonition-title">Nota</p>
<p class="last">Você pode usar <tt class="docutils literal"><span class="pre">@</span></tt> na linha <tt class="docutils literal"><span class="pre">Depends</span></tt> para indicar que você quer que todos os pacotes instalados sejam compilados pelo pacote fonte em questão.</p>
</div>
</div>
<div class="section" id="the-actual-tests">
<h4>Os testes reais<a class="headerlink" href="#the-actual-tests" title="Link permanente para este título">¶</a></h4>
<p>O teste que deve acompanhar o exemplo acima poderia ser:</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 $WORKDIR"</span> 0 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>Aqui um pedaço simples de código em C é escrito em um diretório temporário. Então este é compilado com bibliotecas do sistema (usando flags e caminhos de biblioteca providos por <cite>pkg-config</cite>). Em seguida o binário compilado, que apenas utiliza partes da funcionalidade do núcleo glib, é executado.</p>
<p>While this test is very small and simple, it covers quite a lot: that your -dev
package has all necessary dependencies, that your package installs working
pkg-config files, headers and libraries are put into the right place, or that
the compiler and linker work. This helps to uncover critical issues early on.</p>
</div>
<div class="section" id="executing-the-test">
<h4>Executando o teste<a class="headerlink" href="#executing-the-test" title="Link permanente para este título">¶</a></h4>
<p>While the test script can be easily executed on its own, it is strongly
recommended to actually use <tt class="docutils literal"><span class="pre">adt-run</span></tt> from the <tt class="docutils literal"><span class="pre">autopkgtest</span></tt> package for
verifying that your test works; otherwise, if it fails in the Ubuntu Continuous
Integration (CI) system, it will not land in Ubuntu. This also avoids cluttering
your workstation with test packages or test configuration if the test does
something more intrusive than the simple example above.</p>
<p>The <a class="reference external" href="file:///usr/share/doc/autopkgtest/README.running-tests.gz">README.running-tests</a>
(<a class="reference external" href="http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=doc/README.package-tests">online version</a>) documentation explains all
available testbeds (schroot, LXC, QEMU, etc.) and the most common scenarios how
to run your tests with <tt class="docutils literal"><span class="pre">adt-run</span></tt>, e. g. with locally built binaries, locally
modified tests, etc.</p>
<p>The Ubuntu CI system uses the QEMU runner and runs the tests from the packages
in the archive, with <tt class="docutils literal"><span class="pre">-proposed</span></tt> enabled. To reproduce the exact same
environment, first install the necessary packages:</p>
<div class="highlight-python"><div class="highlight"><pre>sudo apt-get install autopkgtest qemu-system qemu-utils
</pre></div>
</div>
<p>Now build a testbed with:</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>(Please see its manpage and <tt class="docutils literal"><span class="pre">--help</span></tt> output for selecting different releases,
architectures, output directory, or using proxies). This will build e. g.
<tt class="docutils literal"><span class="pre">adt-trusty-amd64-cloud.img</span></tt>.</p>
<p>Then run the tests of a source package like <tt class="docutils literal"><span class="pre">libpng</span></tt> in that QEMU image:</p>
<div class="highlight-python"><div class="highlight"><pre>adt-run libpng --- qemu adt-trusty-amd64-cloud.img
</pre></div>
</div>
<p>The Ubuntu CI system runs packages with <tt class="docutils literal"><span class="pre">-proposed</span></tt> enabled; to enable that,
run:</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>The <tt class="docutils literal"><span class="pre">adt-run</span></tt> manpage has a lot more valuable information on other testing
options.</p>
</div>
<div class="section" id="further-examples">
<h4>Outros exemplos<a class="headerlink" href="#further-examples" title="Link permanente para este título">¶</a></h4>
<p>Esta lista não é completa, mas pode ajudá-lo a ter uma ideia melhor de como testes automatizados são implementados e usados no Ubuntu.</p>
<ul class="simple">
<li>The <a class="reference external" href="https://bazaar.launchpad.net/+branch/ubuntu/libxml2/files/head:/debian/tests/">libxml2 tests</a> are very similar. They also run a test-build of a
simple piece of C code and execute it.</li>
<li>The <a class="reference external" href="https://bazaar.launchpad.net/+branch/ubuntu/gtk+3.0/files/head:/debian/tests/">gtk+3.0 tests</a> also do a compile/link/run check in the “build” test.
There is an additional “python3-gi” test which verifies that the GTK
library can also be used through introspection.</li>
<li>In the <a class="reference external" href="https://bazaar.launchpad.net/+branch/ubiquity/files/head:/debian/tests/">ubiquity tests</a> the upstream test-suite is executed.</li>
<li>The <a class="reference external" href="https://bazaar.launchpad.net/+branch/ubuntu/gvfs/files/head:/debian/tests/">gvfs tests</a> have comprehensive testing of their functionality and
are very interesting because they emulate usage of CDs, Samba, DAV and
other bits.</li>
</ul>
</div>
<div class="section" id="ubuntu-infrastructure">
<h4>Infraestrutura do Ubuntu<a class="headerlink" href="#ubuntu-infrastructure" title="Link permanente para este título">¶</a></h4>
<p>Packages which have <tt class="docutils literal"><span class="pre">autopkgtest</span></tt> enabled will have their tests run whenever
they get uploaded or any of their dependencies change. The output of
<a class="reference external" href="https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/">automatically run autopkgtest tests</a> can be viewed on the web and is
regularly updated.</p>
<p>Debian also uses <tt class="docutils literal"><span class="pre">adt-run</span></tt> to run package tests, although currently only in
schroots, so results may vary a bit. Results and logs can be seen on
<a class="reference external" href="http://ci.debian.net">http://ci.debian.net</a>. So please submit any test fixes or new
tests to Debian as well.</p>
</div>
<div class="section" id="getting-the-test-into-ubuntu">
<h4>Obtendo o teste no Ubuntu<a class="headerlink" href="#getting-the-test-into-ubuntu" title="Link permanente para este título">¶</a></h4>
<p>O processo de envio de um autopkgtest para um pacote é muito semelhante a <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug"><em>corrigindo um erro no Ubuntu</em></a>. Essencialmente, você simplesmente:</p>
<ul class="simple">
<li><p class="first">execute <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">branch</span> <span class="pre">ubuntu:<nomedopacote></span></tt>,</p>
</li>
<li><p class="first">edite <tt class="docutils literal"><span class="pre">debian/control</span></tt> para habilitar os testes,</p>
</li>
<li><p class="first">adiciona o diretório <tt class="docutils literal"><span class="pre">debian/tests</span></tt>,</p>
</li>
<li>write the <tt class="docutils literal"><span class="pre">debian/tests/control</span></tt> based on the <a class="reference external" href="http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=doc/README.package-tests">DEP 8 Specification</a>,</li>
<li><p class="first">adicione seu(s) caso(s) de teste em <tt class="docutils literal"><span class="pre">debian/tests</span></tt>,</p>
</li>
<li><p class="first">submeta suas mudanças, envie elas para o Launchpad, proponha a mesclagem e obtenha revisões apenas como qualquer outra melhoria no pacote fonte.</p>
</li>
</ul>
</div>
<div class="section" id="what-you-can-do">
<h4>O que você pode fazer<a class="headerlink" href="#what-you-can-do" title="Link permanente para este título">¶</a></h4>
<p>The Ubuntu Engineering team put together a <a class="reference external" href="https://wiki.ubuntu.com/QATeam/RequiredTests">list of required test-cases</a>,
where packages which need tests are put into different categories. Here you
can find examples of these tests and easily assign them to yourself.</p>
<p>If you should run into any problems, you can join the <a class="reference external" href="http://webchat.freenode.net/?channels=ubuntu-quality">#ubuntu-quality IRC
channel</a> to get in touch with developers who can help you.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-getting-the-source"></span><div class="section" id="getting-the-source">
<h3>Obtendo o fonte<a class="headerlink" href="#getting-the-source" title="Link permanente para este título">¶</a></h3>
<div class="section" id="source-package-urls">
<h4>URL dos pacotes de fonte<a class="headerlink" href="#source-package-urls" title="Link permanente para este título">¶</a></h4>
<p>O Bazaar fornece alguns atalhos bem interessantes para acessar os ramos fonte de pacotes do Launchpad tanto do Ubuntu como do Debian.</p>
<p>Para se referir a ramos-fonte digite:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:package
</pre></div>
</div>
<p>Onde <em>pacote</em> se refere ao nome do pacote em que você está interessado. Esta URL se refere ao pacote na versão atualmente em desenvolvimento do Ubuntu. Para se referir ao ramo do Tomboy na versão em desenvolvimento, você usaria:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:tomboy
</pre></div>
</div>
<p>To refer to the version of a source package in an older release of Ubuntu,
just prefix the package name with the release’s code name. E.g. to refer to
Tomboy’s source package in <a class="reference external" href="https://wiki.ubuntu.com/SaucySalamander">Saucy</a> use:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:saucy/tomboy
</pre></div>
</div>
<p>Uma vez que são únicos, você pode abreviar o nome da série da distribuição:</p>
<div class="highlight-python"><div class="highlight"><pre>ubuntu:s/tomboy
</pre></div>
</div>
<p>Você pode utilizar um procedimento semelhante para acessar os ramos fonte no Debian, embora não haja atalhos para os nomes de séries de distribuição do Debian. Para acessar um ramo do Tomboy na série de desenvolvimento atual do Debian, utilize:</p>
<div class="highlight-python"><div class="highlight"><pre>debianlp:tomboy
</pre></div>
</div>
<p>and to access Tomboy in Debian <a class="reference external" href="http://www.debian.org/releases/stable/">Wheezy</a> use:</p>
<div class="highlight-python"><div class="highlight"><pre>debianlp:wheezy/tomboy
</pre></div>
</div>
</div>
<div class="section" id="id1">
<h4>Obtendo o fonte<a class="headerlink" href="#id1" title="Link permanente para este título">¶</a></h4>
<p>Todo pacote fonte no Ubuntu tem um ramo fonte associado no Launchpad. Estes ramos fonte são atualizados automaticamente pelo Launchpad, embora o processo não seja tão fácil de usar atualmente.</p>
<p>Há algumas coisas que fazemos primeiro para que o fluxo de trabalho seja mais eficiente depois. Quando você estiver acostumado com o processo, você irá saber quando faz sentido pular estas etapas.</p>
<div class="section" id="creating-a-shared-repository">
<span id="branching"></span><h5>Criando um repositório compartilhado<a class="headerlink" href="#creating-a-shared-repository" title="Link permanente para este título">¶</a></h5>
<p>Digamos que você quer trabalhar no pacote do Tomboy, e você verificou que o nome do pacote fonte é “tomboy”. Antes de ramificar realmente o código do Tomboy, crie um repositório compartilhado para colocar os ramos deste pacote. O repositório compartilhado irá deixar o trabalho futuro mais eficiente.</p>
<p>Faça isto usando o comando “bzr init-repo”, passando a ele o nome do diretório que gostaríamos de usar:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr init-repo tomboy
</pre></div>
</div>
<p>Você verá que um diretório “tomboy” foi criado na sua área de trabalho atual. Altere para esse novo diretório para o restante de seu trabalho:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy
</pre></div>
</div>
</div>
<div class="section" id="getting-the-trunk-branch">
<h5>Obtendo o ramo trunk<a class="headerlink" href="#getting-the-trunk-branch" title="Link permanente para este título">¶</a></h5>
<p>Nós usamos o comando “bzr branch” para criar um ramo local do pacote. Nós nomearemos o diretório destino de “tomboy.dev” só para que seja fácil de lembrar:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch ubuntu:tomboy tomboy.dev
</pre></div>
</div>
<p>O diretório tomboy.dev representa a versão do Tomboy na versão de desenvolvimento do Ubuntu, e você pode sempre ir a este diretório e executar um “bzr pull” para obter quaisquer atualizações futuras.</p>
</div>
<div class="section" id="ensuring-the-version-is-up-to-date">
<span id="up-to-date"></span><h5>Assegurando que a versão está atualizada<a class="headerlink" href="#ensuring-the-version-is-up-to-date" title="Link permanente para este título">¶</a></h5>
<p>Quando você fizer o seu ramo bzr você irá receber uma mensagem informando se o ramo de empacotamento está atualizado. Por exemplo:</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>Ocasionalmente o importador falha e os ramos de empacotamento não correspondem com o que está no arquivo. Uma mensagem dizendo:</p>
<div class="highlight-python"><div class="highlight"><pre>Packaging branch status: OUT-OF-DATE
</pre></div>
</div>
<p>means the importer has failed. You can find out why on
<a class="reference external" href="http://package-import.ubuntu.com/status/">http://package-import.ubuntu.com/status/</a> and <a class="reference external" href="https://bugs.launchpad.net/udd">file a bug on the UDD
project</a> to get the issue resolved.</p>
</div>
<div class="section" id="upstream-tar">
<h5>Tar do upstream<a class="headerlink" href="#upstream-tar" title="Link permanente para este título">¶</a></h5>
<p>Você pode obter um tar do upstream executando:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr get-orig-source
</pre></div>
</div>
<p>Isto irá tentar vários métodos para obter o tar do upstream, primeiro recriando-o a partir da tag “usptream-x.y” no arquivo do bzr, depois baixando do arquivo do Ubuntu e, por último, executando “debian/rules get-orig-source”. O tar do upstream também será recriado quando o bzr for usado para construir o pacote:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr builddeb
</pre></div>
</div>
<p>The <cite>builddeb</cite> plugin has several <a class="reference external" href="http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/view/head:/doc/user_manual/configuration.rst">configuration options</a>.</p>
</div>
<div class="section" id="getting-a-branch-for-a-particular-release">
<h5>Obtendo um ramo para uma versão em particular<a class="headerlink" href="#getting-a-branch-for-a-particular-release" title="Link permanente para este título">¶</a></h5>
<p>When you want to do something like a <a class="reference external" href="https://wiki.ubuntu.com/StableReleaseUpdates">stable release update</a> (SRU), or you
just want to examine the code in an old release, you’ll want to grab the
branch corresponding to a particular Ubuntu release. For example, to get the
Tomboy package for Quantal do:</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>Importando um pacote de fontes do Debian<a class="headerlink" href="#importing-a-debian-source-package" title="Link permanente para este título">¶</a></h5>
<p>Se o pacote no qual você quer trabalhar estiver disponível no Debian mas não no Ubuntu, ainda assim é fácil importar o código para um ramo bzr local para desenvolvimento. Digamos que você quer importar o pacote fonte “novopacote”. Nós iremos começar criando um repositório compartilhado como de costume, mas também temos que criar uma árvore de trabalho para a qual o pacote fonte será importado (lembre-se de sair do diretório do “tomboy” criado acima):</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>Como você pode ver, nós só precisamos fornecer a localização remota do arquivo dsc, e o Bazaar fará o resto. Agora você tem um ramo fonte no Bazaar.</p>
</div>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-working"></span><div class="section" id="working-on-a-package">
<h3>Trabalhando em um pacote<a class="headerlink" href="#working-on-a-package" title="Link permanente para este título">¶</a></h3>
<p>Uma vez que você tenha a ramificação do pacote fonte em um repositório compartilhado, você deverá criar ramificações adicionais para as correções ou outro trabalho que planeje fazer. Você deverá basear a sua ramificação fora do ramo de origem do pacote para a versão de distribuição para a qual planeja enviar. Normalmente, é a versão de desenvolvimento atual, mas pode ser de versões mais antigas, se você está fazendo um backport de uma SRU, por exemplo.</p>
<div class="section" id="branching-for-a-change">
<h4>Ramificação para uma alteração<a class="headerlink" href="#branching-for-a-change" title="Link permanente para este título">¶</a></h4>
<p>A primeira coisa a fazer é ter certeza de que seu ramo do pacote fonte está atualizado. Ele estará se você tiver conferido, caso contrário, faça isto:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy.dev
$ bzr pull
</pre></div>
</div>
<p>Any updates to the package that have uploaded since your checkout will now be
pulled in. You do not want to make changes to this branch. Instead, create a
branch that will contain just the changes you’re going to make. Let’s say you
want to fix bug 12345 for the Tomboy project. When you’re in the shared
repository you previously created for Tomboy, you can create your bug fix
branch like this:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch tomboy.dev bug-12345
$ cd bug-12345
</pre></div>
</div>
<p>Now you can do all my work in the <tt class="docutils literal"><span class="pre">bug-12345</span></tt> directory. You make changes
there as necessary, committing as you go along. This is just like doing any
kind of software development with Bazaar. You can make intermediate commits
as often as you like, and when your changes are finished, you will use the
standard <tt class="docutils literal"><span class="pre">dch</span></tt> command (from the <tt class="docutils literal"><span class="pre">devscripts</span></tt> package):</p>
<div class="highlight-python"><div class="highlight"><pre>$ dch -i
</pre></div>
</div>
<p>Isso irá deixá-lo em um editor para adicionar uma entrada ao o arquivo <cite>debian/changelog</cite>.</p>
<p id="link-via-changelog">When you added your <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> entry, you should have included a bug
fix tag that indicated which Launchpad bug issue you’re fixing. The format of
this textual tag is pretty strict: <tt class="docutils literal"><span class="pre">LP:</span> <span class="pre">#12345</span></tt>. The space between the
<tt class="docutils literal"><span class="pre">:</span></tt> and the <tt class="docutils literal"><span class="pre">#</span></tt> is required and of course you should use the actual bug
number that you’re fixing. Your <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> entry might look something
like:</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>Submeter com o normal:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr commit
</pre></div>
</div>
<p>A hook in bzr-builddeb will use the debian/changelog text as the commit
message and set the tag to mark bug #12345 as fixed.</p>
<p>Isto funciona somente com o bzr-builddeb 2.7.5 e o bzr 2.4, para versões mais antigas, use “debcommit”.</p>
</div>
<div class="section" id="building-the-package">
<h4>Construindo o pacote<a class="headerlink" href="#building-the-package" title="Link permanente para este título">¶</a></h4>
<p>Along the way, you’ll want to build your branch so that you can test it to
make sure it does actually fix the bug.</p>
<p>A fim de construir o pacote você pode usar o comando <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">builddeb</span></tt> do pacote <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt>. Você pode construir um pacote fonte com:</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> é um nome alternativo para o <tt class="docutils literal"><span class="pre">builddeb</span></tt>.) Você pode deixar o pacote não assinado, anexando <tt class="docutils literal"><span class="pre">--</span> <span class="pre">-uc</span> <span class="pre">-us`</span></tt> para o comando.</p>
<p>Também é possível utilizar as suas ferramentas normais, contanto que elas sejam capazes de remover os diretórios .bzr do pacote, por exemplo:</p>
<div class="highlight-python"><div class="highlight"><pre>$ debuild -i -I
</pre></div>
</div>
<p>If you ever see an error related to trying to build a native package without a
tarball, check to see if there is a <tt class="docutils literal"><span class="pre">.bzr-builddeb/default.conf</span></tt> file
erroneously specifying the package as native. If the changelog version has a
dash in it, then it’s not a native package, so remove the configuration file.
Note that while <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">builddeb</span></tt> has a <tt class="docutils literal"><span class="pre">--native</span></tt> switch, it does not have a
<tt class="docutils literal"><span class="pre">--no-native</span></tt> switch.</p>
<p>Uma vez que você tenha obtido o pacote fonte, você pode construí-lo normalmente com “pbuilder-dist”` (ou “pbuilder” ou “sbuild”_).</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-sponsorship"></span><div class="section" id="seeking-review-and-sponsorship">
<h3>Buscando revisão e orientação<a class="headerlink" href="#seeking-review-and-sponsorship" title="Link permanente para este título">¶</a></h3>
<p>Uma das maiores vantagens de usar o fluxo de trabalho UDD é melhorar a qualidade buscando revisão de alterações por seus pares. E isto acontece mesmo que você não tenha privilégios de envio. É claro, se você não tem privilégios de envio, você deverá buscar orientação.</p>
<p>Uma vez que você esteja satisfeito com a sua correção, e tem um ramo pronto, os passos seguintes podem ser usados para publicar seu ramo no Launchpad, vinculá-lo a um relatório de erro e criar uma <em>proposta de mesclagem</em> para os outros revisarem e para os orientadores enviarem.</p>
<div class="section" id="pushing-to-launchpad">
<span id="merge-proposal"></span><h4>Enviando para o Launchpad<a class="headerlink" href="#pushing-to-launchpad" title="Link permanente para este título">¶</a></h4>
<p>We previously showed you how to <a class="reference internal" href="index.html#link-via-changelog"><em>associate your branch to the bug</em></a> using <tt class="docutils literal"><span class="pre">dch</span></tt> and <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">commit</span></tt>. However, the branch
and bug don’t actually get linked until you push the branch to Launchpad.</p>
<p>Não é essencial que você tenha um link para um erro para cada modificação que você faça, mas se você estiver corrigindo erros relatados, então fazer links para eles será conveniente.</p>
<p>A forma geral do URL para o qual você deve enviar o seu ramo é:</p>
<div class="highlight-python"><div class="highlight"><pre>lp:~<user-id>/ubuntu/<distroseries>/<package>/<branch-name>
</pre></div>
</div>
<p>For example, to push your fix for bug 12345 in the Tomboy package for Trusty,
you’d use:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
</pre></div>
</div>
<p>O último compenente do caminho é arbitrário, depende de você escolher algo significativo.</p>
<p>Entretanto, isto normalmente não é suficiente para conseguir desenvolvedores do Ubuntu para revisar e orientar a sua alteração. Você deve então enviar uma <em>proposta de mesclagem</em>.</p>
<p>Para fazer isto, abra a página do erro em um navegador, p. ex.:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr lp-open
</pre></div>
</div>
<p>Se isso falhar, então você pode usar:</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>where most of the URL matches what you used for <cite>bzr push</cite>. On this page,
you’ll see a link that says <em>Propose for merging into another branch</em>. Type
in an explanation of your change in the <em>Initial Comment</em> box. Lastly, click
<em>Propose Merge</em> to complete the process.</p>
<p>As propostas de mesclagem para ramos de pacotes fonte irão inscrever automaticamente no grupo “~ubuntu-branches”, o que deve ser suficiente para contactar um desenvolvedor Ubuntu que pode revisar e orientar a sua alteração de pacote.</p>
</div>
<div class="section" id="generating-a-debdiff">
<h4>Gerando um debdiff<a class="headerlink" href="#generating-a-debdiff" title="Link permanente para este título">¶</a></h4>
<p>Conforme percebido acima, alguns orientadores ainda preferem revisar um <em>debdiff</em> anexo a relatórios de erro em vez de uma proposta de mesclagem. Se você for solicitado a incluir um debdiff, você pode gerar um como este (de dentro do seu ramo “bug-12345”):</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr diff -rbranch:../tomboy.dev
</pre></div>
</div>
<p>Outra maneira é abrir a proposta de mesclagem e baixar o diff.</p>
<p>Você deve se assegurar que o diff tem as alterações esperadas, nem mais nem menos. Nomeie o diff apropriadamente, p. ex., “foobar-12345.debdiff” e anexe-o ao relatório de erro.</p>
</div>
<div class="section" id="dealing-with-feedback-from-sponsors">
<h4>Lidando com as respostas dos orientadores<a class="headerlink" href="#dealing-with-feedback-from-sponsors" title="Link permanente para este título">¶</a></h4>
<p>Se um orientador revisar seu ramo e pedir a você para mudar algo, você pode fazê-lo facilmente. É só ir ao ramo que você estava trabalhando antes, fazer as alterações solicitadas e então submeter:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr commit
</pre></div>
</div>
<p>Agora quando você enviar seu ramo ao Lauchpad, o Bazaar irá lembrar para onde você o enviou, e irá atualizar o ramo no Lauchpad com as suas últimas submissões. Tudo que você precisa fazer é:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push
</pre></div>
</div>
<p>Você pode então responder o e-mail com a proposta de mesclagem, explicando o que você alterou e pedindo uma nova revisão, ou você pode responder na página da proposta de mesclagem no Launchpad.</p>
<p>Note que se você está sendo orientado através de um debdiff anexado a um relatório de erro, você precisará atualizar manualmente gerando um novo diff e anexando-o ao relatório de erro.</p>
</div>
<div class="section" id="expectations">
<h4>Expectativas<a class="headerlink" href="#expectations" title="Link permanente para este título">¶</a></h4>
<p>Os desenvolvedores do Ubuntu definiram uma agenda de “pilotos de patch”, que regularmente revisam a fila de orientação e dão resposta para os ramos e patches. Apesar de esta medida ter sido posta em prática, pode ainda levar vários dias até que você obtenha retorno. Isto depende de o quanto todos estão ocupados, se o desenvolvimento está congelado, e outros fatores.</p>
<p>Se ainda não lhe foi dito, sinta-se à vontade para se inscrever em “#ubuntu-devel” ou “irc.freenode.net” e descobrir se alguém por lá pode lhe ajuda.</p>
<p>Para mais informações sobre o processo geral de orientação, reveja a documentação na nossa wiki: <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>Enviando um pacote<a class="headerlink" href="#uploading-a-package" title="Link permanente para este título">¶</a></h3>
<p>Once your merge proposal is reviewed and approved, you will want to upload
your package, either to the archive (if you have permission) or to your
<a class="reference external" href="https://help.launchpad.net/Packaging/PPA">Personal Package Archive</a> (PPA). You might also want to do an upload if
you are sponsoring someone else’s changes.</p>
<div class="section" id="uploading-a-change-made-by-you">
<h4>Enviando uma mudança efetuada por você<a class="headerlink" href="#uploading-a-change-made-by-you" title="Link permanente para este título">¶</a></h4>
<p>Quando você tiver um ramo com uma alteração que você gostaria de enviar, você precisa pegar essa alteração no ramo fonte principal, construir o pacote fonte e então enviá-lo.</p>
<p>Primeiro, você precisa verificar se possui a última versão do pacote no seu checkout do trunk do pacote de desenvolvimento:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy/tomboy.dev
$ bzr pull
</pre></div>
</div>
<p>This pulls in any changes that may have been committed while you were working
on your fix. From here, you have several options. If the changes on the
trunk are large and you feel should be tested along with your change you can
merge them into your bug fix branch and test there. If not, then you can
carry on merging your bug fix branch into the development trunk branch. As of
bzr 2.5 and bzr-builddeb 2.8.1, this works with just the standard <tt class="docutils literal"><span class="pre">merge</span></tt>
command:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge ../bug-12345
</pre></div>
</div>
<p>Para versões mais antigas do bzr, você pode usar o comando <a href="#id1"><span class="problematic" id="id2">``</span></a>merge-package `` ao invés de</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge-package ../bug-12345
</pre></div>
</div>
<p>Isto irá mesclar as duas árvores, possivelmente produzirá conflitos, que você precisará resolver manualmente.</p>
<p>Em seguida, você deve certificar se o <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> está como você gostaria, como a distribuição correta, número de versão, etc</p>
<p>Once that is done you should review the change you are about to commit with
<tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span></tt>. This should show you the same changes as a debdiff would before
you upload the source package.</p>
<p>The next step is to build and test the modified source package as you normally
would:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr builddeb -S
</pre></div>
</div>
<p>When you’re finally happy with your branch, make sure you’ve committed all
your changes, then tag the branch with the changelog’s version number. The
<tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">tag</span></tt> command will do this for you automatically when given no
arguments:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr tag
</pre></div>
</div>
<p>Esta tag ira informar ao importador do pacote que o que está no ramo do Bazaar é o mesmo que está no arquivo.</p>
<p>Agora você pode enviar as alterações de volta ao Launchpad</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr push ubuntu:tomboy
</pre></div>
</div>
<p>(Alterar o destino se estiver enviando um SRU ou similar).</p>
<p>You need one last step to get your changes uploaded into Ubuntu or your PPA;
you need to <tt class="docutils literal"><span class="pre">dput</span></tt> the source package to the appropriate location. For
example, if you want to upload your changes to your PPA, you’d do:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dput ppa:imasponsor/myppa tomboy_1.5.2-1ubuntu5_source.changes
</pre></div>
</div>
<p>ou, se você tem permissão para enviar ao arquivo principal:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dput tomboy_1.5.2-1ubuntu5_source.changes
</pre></div>
</div>
<p>You are now free to delete your feature branch, as it is merged, and can
be re-downloaded from Launchpad if needed.</p>
</div>
<div class="section" id="sponsoring-a-change">
<h4>Orientando uma alteração<a class="headerlink" href="#sponsoring-a-change" title="Link permanente para este título">¶</a></h4>
<p>Orientar a alteração de outra pessoa é exatamente como o processo acima, mas em vez de mesclar a partir do ramo que você criou, você mescla a partir do ramo na proposta de mesclagem:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
</pre></div>
</div>
<p>Se houver muitos conflitos de mesclagem, você deverá pedir ao colaborador para corrigi-los. Consulte a próxima seção para saber como cancelar uma mesclagem pendente.</p>
<p>Mas se as alterações lhe parecerem boas, submeta e siga o resto do processo de envio:</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>Cancelando um envio<a class="headerlink" href="#canceling-an-upload" title="Link permanente para este título">¶</a></h4>
<p>A qualquer momento antes de você usar <cite>dput</cite> no fonte do pacote você pode decidir cancelar um upload e reverter as alterações:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr revert
</pre></div>
</div>
<p>Você pode fazer isto se você notar que algo necessita de mais trabalho, ou se você gostaria de pedir ao contribuidor para corrigir conflitos quando estiver orientando.</p>
</div>
<div class="section" id="sponsoring-something-and-making-your-own-changes">
<h4>Orientando algo e fazendo suas próprias alterações<a class="headerlink" href="#sponsoring-something-and-making-your-own-changes" title="Link permanente para este título">¶</a></h4>
<p>Se você vai orientar o trabalho de alguém, mas gostaria de fazer algumas alterações você mesmo, então você pode mesclar o trabalho dele em um ramo separado primeiro.</p>
<p>Se você já tiver um ramo onde esteja trabalhando no pacote e quiser incluir suas alterações, simplesmente execute o “bzr merge” a partir do ramo, em vez de fazer checkout do pacote de desenvolvimento. Você pode então fazer as alterações e submetê-las, e depois continuar com as alterações no pacote.</p>
<p>Se você não tem um ramo, mas gostaria de fazer alterações baseadas no que o colaborador fornece, então você deve iniciar pegando o ramo dele:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr branch lp:~subgenius/ubuntu/trusty/tomboy/bug-12345
</pre></div>
</div>
<p>então trabalhe nesto ramo, e então mescle-o ao principal e carregue-o como se fosse seu próprio trabalho. O colaborador continuará sendo mencionado no changelog, e o Bazaar irá atribuir corretamente as alterações feitas nele.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-latest"></span><div class="section" id="getting-the-latest">
<h3>Obtendo o mais recente<a class="headerlink" href="#getting-the-latest" title="Link permanente para este título">¶</a></h3>
<p>Se alguém mais enviou alterações para um pacote, você deverá puxar essas alterações para suas próprias cópias dos ramos do pacote.</p>
<div class="section" id="updating-your-main-branch">
<h4>Atualizando seu ramo principal<a class="headerlink" href="#updating-your-main-branch" title="Link permanente para este título">¶</a></h4>
<p>Atualizar sua cópia de um ramo que corresponde ao pacote de uma versão específica é bastante simples, é só usar “bzr pull” do diretório apropriado:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy/tomboy.dev
$ bzr pull
</pre></div>
</div>
<p>This works wherever you have a checkout of a branch, so it will work for
things like branches of <cite>saucy</cite>, <cite>trusty-proposed</cite>, etc.</p>
</div>
<div class="section" id="getting-the-latest-in-to-your-working-branches">
<h4>Obtendo os mais recentes para dentro do seu ramo de trabalho<a class="headerlink" href="#getting-the-latest-in-to-your-working-branches" title="Link permanente para este título">¶</a></h4>
<p>Once you have updated your copy of a distroseries branch, then you may want to
merge this in to your working branches as well, so that they are based on the
latest code.</p>
<p>You don’t have to do this all the time though. You can work on slightly older
code with no problems. The disadvantage would come if you were working on
some code that someone else changed. If you are not working on the latest
version then your changes may not be correct, and may even produce conflicts.</p>
<p>The merge does have to be done at some point though. The longer it is left,
the harder may be, so doing it regularly should keep each merge simple. Even
if there are many merges the total effort would hopefully be less.</p>
<p>To merge the changes you just need to use <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt>, but you must
have committed your current work first:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd tomboy/bug-12345
$ bzr merge ../tomboy.dev
</pre></div>
</div>
<p>Any conflicts will be reported, and you can fix them up. To review the
changes that you just merged use <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span></tt>. To undo the merge use <tt class="docutils literal"><span class="pre">bzr</span>
<span class="pre">revert</span></tt>. Once you are happy with the changes then use <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>Fazendo referência à versões de um pacote<a class="headerlink" href="#referring-to-versions-of-a-package" title="Link permanente para este título">¶</a></h4>
<p>You will often think in terms of versions of a package, rather than the
underlying Bazaar revision numbers. <cite>bzr-builddeb</cite> provides a revision
specifier that makes this convenient. Any command that takes a <tt class="docutils literal"><span class="pre">-r</span></tt>
argument to specify a revision or revision range will work with this
specifier, e.g. <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></tt>, and so on. To view the versions of
a package, use the <tt class="docutils literal"><span class="pre">package:</span></tt> specifier:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr diff -r package:0.1-1..package:0.1-2
</pre></div>
</div>
<p>Isso mostra as diferenças entre as versões 0.1-1 e 0.1-2 do pacote.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/udd-merging"></span><div class="section" id="merging-updating-from-debian-and-upstream">
<h3>Mesclando — Atualizando do Debian e do upstream<a class="headerlink" href="#merging-updating-from-debian-and-upstream" title="Link permanente para este título">¶</a></h3>
<p>Merging is one of the strengths of Bazaar, and something we do often in Ubuntu
development. Updates can be merged from Debian, from a new upstream release,
and from other Ubuntu developers. Doing it in Bazaar is pretty simple, and
all based around the <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt> command <a class="footnote-reference" href="#id3" id="id1">[1]</a>.</p>
<p>While you are in any branch’s working directory, you can merge in a branch
from a different location. First check that you have no uncommitted changes:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr status
</pre></div>
</div>
<p>If that reports anything then you will either have to commit the changes,
revert them, or shelve them to come back to later.</p>
<div class="section" id="merging-from-debian">
<h4>Mesclando do Debian<a class="headerlink" href="#merging-from-debian" title="Link permanente para este título">¶</a></h4>
<p>Next run <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge</span></tt> passing the URL of the branch to merge from. For
example, to merge from the version of the package in Debian Unstable
run <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>This will merge the changes since the last merge point and leave you with
changes to review. This may cause some conflicts. You can see everything
that the <tt class="docutils literal"><span class="pre">merge</span></tt> command did by running:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr status
$ bzr diff
</pre></div>
</div>
<p>If conflicts are reported then you need to edit those files to make them look
how they should, removing the <em>conflict markers</em>. Once you have done this,
run:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr resolve
$ bzr conflicts
</pre></div>
</div>
<p>This will resolve any conflicted files that you fixed, and then tell you what
else you have to deal with.</p>
<p>Once any conflicts are resolved, and you have made any other changes that you
need, you will add a new changelog entry, and commit:</p>
<div class="highlight-python"><div class="highlight"><pre>$ dch -i
$ bzr commit
</pre></div>
</div>
<p>conforme descrito anteriormente.</p>
<p>However, before you commit, it is always a good thing to check all the Ubuntu
changes by running:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr diff -r tag:0.6.10-5
</pre></div>
</div>
<p>which will show the differences between the Debian (0.6.10-5) and Ubuntu
versions (0.6.10-5ubuntu1). In similar way you can compare to any other
versions. To see all available versions run:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr tags
</pre></div>
</div>
<p>Depois de testar e submeter para mescla, você deverá buscar orientação ou enviar o arquivo da maneira normal.</p>
<p>If you are going to build the source package from this merged branch, you
would use the <tt class="docutils literal"><span class="pre">-S</span></tt> option to the <tt class="docutils literal"><span class="pre">bd</span></tt> command. One other thing you’ll
want to consider is also using the <tt class="docutils literal"><span class="pre">--package-merge</span></tt> option. This will add
the appropriate <tt class="docutils literal"><span class="pre">-v</span></tt> and <tt class="docutils literal"><span class="pre">-sa</span></tt> options to the source package so that all
the changelog entries since the last Ubuntu change will be included in your
<tt class="docutils literal"><span class="pre">_source.changes</span></tt> file. For example:</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>Mesclando uma nova versão do upstream<a class="headerlink" href="#merging-a-new-upstream-version" title="Link permanente para este título">¶</a></h4>
<p>When upstream releases a new version (or you want to package a snapshot), you
have to merge a tarball into your branch.</p>
<p>This is done using the <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-upstream</span></tt> command. If your package has a
valid <tt class="docutils literal"><span class="pre">debian/watch</span></tt> file, from inside the branch that you want to merge to,
just type this:</p>
<div class="highlight-python"><div class="highlight"><pre>$ bzr merge-upstream
</pre></div>
</div>
<p>This will download the tarball and merge it into your branch, automatically
adding a <tt class="docutils literal"><span class="pre">debian/changelog</span></tt> entry for you. <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> looks at the
<tt class="docutils literal"><span class="pre">debian/watch</span></tt> file for the upstream tarball location.</p>
<p>Se você <em>não</em> tiver uma arquivo “debian/watch”, você terá que especificar a localização do tarball no upstream, e a versão manualmente:</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>A opção “–version” é usada para especificar a versão do upstream que está sendo mesclada, eis que o comando não consegue inferir isto (ainda) .</p>
<p>O último parâmetro é a localização do tarball para o qual você está atualizando; pode ser tanto um caminho do seu sistema de arquivos local, ou um URI http, ftp, sftp, etc, como mostrado. O comando irá baixar automaticamente o tarball para você. O tarball será renomeado apropriadamente e, se necessário, convertido para ”.gz”.</p>
<p>O comando “merge-usptream” irá lhe dizer que terminou com sucesso, ou que houve conflitos. De uma forma ou de outra, você poderá revisar as alterações antes de subemter, como de costume.</p>
<p>If you are merging an upstream release into an existing Bazaar branch that has
not previously used the UDD layout, <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-upstream</span></tt> will fail with an
error that the tag for the previous upstream version is not available; the
merge can’t be completed without knowing what base version to merge against.
To work around this, create a tag in your existing repository for the last
upstream version present there; e.g., if the last Ubuntu release was
<em>1.1-0ubuntu3</em>, create the tag <em>upstream-1.1</em> pointing to the bzr revision you
want to use as the tip of the upstream branch.</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>You will need newer versions of <tt class="docutils literal"><span class="pre">bzr</span></tt> and the <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> for
the <tt class="docutils literal"><span class="pre">merge</span></tt> command to work. Use the versions from Ubuntu 12.04
(Precise) or the development versions from the <tt class="docutils literal"><span class="pre">bzr</span></tt> PPA. Specifically,
you need <tt class="docutils literal"><span class="pre">bzr</span></tt> version 2.5 beta 5 or newer, and <tt class="docutils literal"><span class="pre">bzr-builddeb</span></tt> version
2.8.1 or newer. For older versions, use the <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">merge-package</span></tt> command
instead.</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>To check other available branches of a package in Debian, see
package code page. E.g. <a class="reference external" href="https://code.launchpad.net/debian/+source/tomboy">https://code.launchpad.net/debian/+source/tomboy</a></td></tr>
</tbody>
</table>
</div>
</div>
<span id="document-ubuntu-packaging-guide/chroots"></span><div class="section" id="using-chroots">
<h3>Usando o chroot<a class="headerlink" href="#using-chroots" title="Link permanente para este título">¶</a></h3>
<p>Se você está executando uma versão do Ubuntu mas os pacotes que está trabalhando são de outras versões você pode criar um ambiente da outra versão com um <tt class="docutils literal"><span class="pre">chroot</span></tt>.</p>
<p>Um <tt class="docutils literal"><span class="pre">chroot</span></tt> lhe permite ter um sistema de arquivos completo a partir de outra distribuição, no qual se pode trabalhar normalmente. Isto evita a sobrecarga de uma máquina virtual inteira.</p>
<div class="section" id="creating-a-chroot">
<h4>Criando um chroot<a class="headerlink" href="#creating-a-chroot" title="Link permanente para este título">¶</a></h4>
<p>Use o comando <tt class="docutils literal"><span class="pre">debootstrap</span></tt> para criar um novo chroot:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo debootstrap trusty trusty/
</pre></div>
</div>
<p>This will create a directory <tt class="docutils literal"><span class="pre">trusty</span></tt> and install a minimal trusty system
into it.</p>
<p>If your version of <tt class="docutils literal"><span class="pre">debootstrap</span></tt> does not know about Trusty you can try
upgrading to the version in <tt class="docutils literal"><span class="pre">backports</span></tt>.</p>
<p>Você pode então trabalhar dentro do chroot:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo chroot trusty
</pre></div>
</div>
<p>Onde você pode instalar ou remover qualquer pacote que desejar sem afetar seu sistema principal.</p>
<p>Você pode querer copiar suas chaves GPG/SSH e configuração do Bazaar para dentro do chroot, então você pode acessar e assinar pacotes diretamente:</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>Para impedir que o apt e outros programas reclamem de falta de localizações, você deve instalar o pacote de linguagem relevante para você:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-get install language-pack-en
</pre></div>
</div>
<p>Se você quer executar programas X será necessário vincular o diretório /tmp com o chroot, de fora do chroot execute:</p>
<div class="highlight-python"><div class="highlight"><pre>$ sudo mount -t none -o bind /tmp trusty/tmp
$ xhost +
</pre></div>
</div>
<p>Alguns programas podem necessitar que os diretórios /dev ou /proc estejam vinculados com o chroot.</p>
<p>For more information on chroots see our <a class="reference external" href="https://wiki.ubuntu.com/DebootstrapChroot">Debootstrap Chroot wiki page</a>.</p>
</div>
<div class="section" id="alternatives">
<h4>Alternativas<a class="headerlink" href="#alternatives" title="Link permanente para este título">¶</a></h4>
<p>SBuild is a system similar to PBuilder for creating an environment to run
test package builds in. It closer matches that used by Launchpad for building
packages but takes some more setup compared to PBuilder. See
<a class="reference external" href="https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment">the Security Team Build Environment wiki page</a> for a full explanation.</p>
<p>Full virtual machines can be useful for packaging and testing
programs. TestDrive is a program to automate syncing and running
daily ISO images, see <a class="reference external" href="https://wiki.ubuntu.com/QATeam/Testdrive">the TestDrive wiki page</a> for more information.</p>
<p>Você também pode configurar o pbuilder para pausar quando ele vem através de uma falha de construção. Copie C10shell de /usr/share/doc/pbuilder/examples para dentro do diretório e use o argumento <tt class="docutils literal"><span class="pre">--hookdir=</span></tt> para apontá-lo.</p>
<p>Amazon’s <a class="reference external" href="https://help.ubuntu.com/community/EC2StartersGuide">EC2 cloud computers</a> allow you to hire a computer paying a
few US cents per hour, you can set up Ubuntu machines of any supported
version and package on those. This is useful when you want to compile
many packages at the same time or to overcome bandwidth restraints.</p>
</div>
</div>
<span id="document-ubuntu-packaging-guide/traditional-packaging"></span><div class="section" id="traditional-packaging">
<h3>Empacotamento tradicional<a class="headerlink" href="#traditional-packaging" title="Link permanente para este título">¶</a></h3>
<p>The majority of this guide deals with <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro"><em>Ubuntu Distributed Development</em></a> (UDD) which utilizes the distributed version control system (DVCS)
Bazaar for <a class="reference internal" href="index.html#branching"><em>retrieving package sources</em></a> and submitting fixes
with <a class="reference internal" href="index.html#merge-proposal"><em>merge proposals.</em></a> This article will discuss what we
will call traditional packaging methods for lack of a better word. Before Bazaar
was adopted for Ubuntu development, these were the typical methods for
contributing to Ubuntu.</p>
<p>In some cases, you may need to use these tools instead of UDD. So it is good to
be familiar with them. Before you begin, you should already have read the
article <a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up"><em>Getting Set Up.</em></a></p>
<div class="section" id="getting-the-source">
<h4>Obtendo o fonte<a class="headerlink" href="#getting-the-source" title="Link permanente para este título">¶</a></h4>
<p>Em ordem para obter o pacote fonte, você pode simplesmente executar:</p>
<div class="highlight-python"><div class="highlight"><pre>$ apt-get source <package_name>
</pre></div>
</div>
<p>This method has some draw backs though. It downloads the version of the source
that is available on <strong>your system.</strong> You are likely running the current stable
release, but you want to contribute your change against the package in the
development release. Luckily, the <tt class="docutils literal"><span class="pre">ubuntu-dev-tools</span></tt> package provides a helper
script:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source <package_name>
</pre></div>
</div>
<p>Por padrão, a última versão do pacote na versão de desenvolvimento do Ubuntu será baixada. Você pode também especificar a versão do pacote ou do Ubuntu assim:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source <package_name> trusty
</pre></div>
</div>
<p>to pull the source from the <tt class="docutils literal"><span class="pre">trusty</span></tt> release, or:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source <package_name> 1.0-1ubuntu1
</pre></div>
</div>
<p>para baixar a versão <tt class="docutils literal"><span class="pre">1.0-1ubuntu1</span></tt> do pacote. Para mais informações sobre o comando, consulte <tt class="docutils literal"><span class="pre">man</span> <span class="pre">pull-lp-source</span></tt>.</p>
<p>Para o nosso exemplo, vamos supor que temos um relatório de erro dizendo que “colour” na descrição de <tt class="docutils literal"><span class="pre">xicc</span></tt> deveria ser “color”, e que queremos corrigir isto. (<em>Nota: Este é apenas um exemplo de algo a ser alterado e não um erro real.)</em> Para obter o fonte, execute:</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>Criando um Debdiff<a class="headerlink" href="#creating-a-debdiff" title="Link permanente para este título">¶</a></h4>
<p>Um “debdiff” exibe a diferença entre dois pacotes Debian. O nome do comando usado para gerá-lo também é “debdiff”, que faz parte do pacote “devscripts”. Consulte “man debdiff” para todos os detalhes. Para comparar dois pacotes fonte, passe os dois arquivos “dsc” como argumentos:</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>Para continuar com nosso exemplo, vamos editar o “debian/control” e “corrigir” nosso “erro”:</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>We also must adhere to the <a class="reference external" href="https://wiki.ubuntu.com/DebianMaintainerField">Debian Maintainer Field Spec</a>
and edit <tt class="docutils literal"><span class="pre">debian/control</span></tt> to replace:</p>
<div class="highlight-python"><div class="highlight"><pre>Maintainer: Ross Burton <ross@debian.org>
</pre></div>
</div>
<p>com:</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>Você pode usar a ferramenta “update-maintainer” (no pacote “unbuntu-dev-tools”) para fazer isso.</p>
<p>Lembre-se de documentar suas alterações em “debian/changelog” usando “dch -i” e entaõ podemos gerar um novo pacote fonte:</p>
<div class="highlight-python"><div class="highlight"><pre>$ debuild -S
</pre></div>
</div>
<p>Agora podemos examinar nossas alterações usando “debdiff”:</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>Para criar um arquivo patch que você possa enviar para outros ou anexar a um relatório de erros para orientação, execute:</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>Aplicando um Debdiff<a class="headerlink" href="#applying-a-debdiff" title="Link permanente para este título">¶</a></h4>
<p>Para aplicar um debdiff, primeiramente assegure-se de que possou o código fonte da versão com a qual foi criado:</p>
<div class="highlight-python"><div class="highlight"><pre>$ pull-lp-source xicc 0.2-3
</pre></div>
</div>
<p>Then in a terminal, change to the directory where the source was
uncompressed:</p>
<div class="highlight-python"><div class="highlight"><pre>$ cd xicc-0.2
</pre></div>
</div>
<p>Um debdiff é como um arquivo de patch normal. Aplique-o como de costume com:</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>Empacotamento do KDE<a class="headerlink" href="#kde-packaging" title="Link permanente para este título">¶</a></h3>
<p>Packaging of KDE programs in Ubuntu is managed by the Kubuntu and
MOTU teams. You can contact the Kubuntu team on the <a class="reference external" href="https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel">Kubuntu mailing
list</a> and <tt class="docutils literal"><span class="pre">#kubuntu-devel</span></tt> Freenode IRC channel. More information
about Kubuntu development is on the <a class="reference external" href="https://wiki.kubuntu.org/Kubuntu">Kubuntu wiki page</a>.</p>
<p>Our packaging follows the practices of the <a class="reference external" href="http://pkg-kde.alioth.debian.org/">Debian Qt/KDE Team</a>
and Debian KDE Extras Team. Most of our packages are derived from the
packaging of these Debian teams.</p>
<div class="section" id="patching-policy">
<h4>Politica de patches<a class="headerlink" href="#patching-policy" title="Link permanente para este título">¶</a></h4>
<p>O Kubuntu não adiciona patches aos programas do KDE a menos que venham dos autores do upstream ou submetidos ao upstream com a expectativa de que sejam mesclados logo ou que tenhamos consultado a questão com os autores upstream.</p>
<p>O Kubuntu não altera o nome dos pacotes exceto quando o upstream o requer (como o logo no canto superior esquerdo do menu Kickoff) ou para simplificar (como remover telas de inicialização).</p>
</div>
<div class="section" id="debian-rules">
<h4>debian/rules<a class="headerlink" href="#debian-rules" title="Link permanente para este título">¶</a></h4>
<p>Os pacotes do Debian incluem algumas adições ao uso básico do Debhelper. Elas ficam no pacote “pkg-kde-tools”.</p>
<p>Pacotes que usam o Debhelper 7 devem adicionar a opção “–with=kde”. Isto irá assegurar que os sinalizadores de construção corretos estão sendo usados e adicionar opções como manuseio de stubs do kdeinit e traduções:</p>
<div class="highlight-python"><div class="highlight"><pre>%:
dh $@ --with=kde
</pre></div>
</div>
<p>Alguns pacotes KDE mais novos usam o sistema “dhmk”, uma alternativa ao “dh” feito pelo time do Debian Qt/KDE. Você pode ler sobre ele em /usr/share/pkg-kde-tools/qt-kde-team/2/README. Pacotes que o utilizam irão “incluir /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk” em vez de executar “dh”.</p>
</div>
<div class="section" id="translations">
<h4>Traduções<a class="headerlink" href="#translations" title="Link permanente para este título">¶</a></h4>
<p>Os pacotes do main tem as suas traduções importadas no Launchpad e exportadas do Launchpad para o os pacotes de idioma do Ubuntu.</p>
<p>Então todos os pacotes KDE devem gerar modelos de tradução, incluir ou deixar disponível traduções upstream e manipular traduções de arquivos ”.desktop”.</p>
<p>Para gerar modelos de tradução o pacote precisa incluir um arquivo “Messages.sh”. Reclame ao upstream caso isto não aconteça. Você pode verificar se ele funciona executando “extract-messages.sh” que deve produzir um ou mais arquivos ”.pot” em “po/”. Isto será feito automaticamente durante a construção se você usar a opção “–with=kde” para “dh”.</p>
<p>Upstream will usually have also put the translation <tt class="docutils literal"><span class="pre">.po</span></tt> files into
the <tt class="docutils literal"><span class="pre">po/</span></tt> directory. If they do not, check if they are in separate
upstream language packs such as the KDE SC language packs. If they
are in separate language packs Launchpad will need to associate
these together manually, contact <a class="reference external" href="https://launchpad.net/~dpm">David Planella</a> to do this.</p>
<p>Se um pacote é movido de “universe” para “main”, ele precisará ser reenviado antes que as traduções sejam importadas para o Launchpad.</p>
<p><tt class="docutils literal"><span class="pre">.desktop</span></tt> files also need translations. We patch KDELibs to read
translations out of <tt class="docutils literal"><span class="pre">.po</span></tt> files which are pointed to by a line
<tt class="docutils literal"><span class="pre">X-Ubuntu-Gettext-Domain=</span></tt> added to <tt class="docutils literal"><span class="pre">.desktop</span></tt> files at package
build time. A .pot file for each package is be generated at build
time and .po files need to be downloaded from upstream and included in
the package or in our language packs. The list of .po files to be
downloaded from KDE’s repositories is in
<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>Símbolos de bibliotecas<a class="headerlink" href="#library-symbols" title="Link permanente para este título">¶</a></h4>
<p>Library symbols are tracked in <tt class="docutils literal"><span class="pre">.symbols</span></tt> files to ensure none go
missing for new releases. KDE uses C++ libraries which act a little
differently compared to C libraries. Debian’s Qt/KDE Team have
scripts to handle this. See <a class="reference external" href="http://pkg-kde.alioth.debian.org/symbolfiles.html">Working with symbols files</a> for how to
create and keep these files up to date.</p>
</div>
</div>
</div>
</div>
<div class="section" id="further-reading">
<h2>Leitura adicional<a class="headerlink" href="#further-reading" title="Link permanente para este título">¶</a></h2>
<p>You can read this guide offline in different formats, if you install one of
the <a class="reference external" href="https://launchpad.net/ubuntu/+source/ubuntu-packaging-guide">binary packages</a>.</p>
<p>If you want to learn more about building Debian packages, here are some Debian
resources you may find useful:</p>
<ul class="simple">
<li><a class="reference external" href="https://wiki.debian.org/HowToPackageForDebian">How to package for Debian</a>;</li>
<li><a class="reference external" href="http://www.debian.org/doc/debian-policy/">Debian Policy Manual</a>;</li>
<li><a class="reference external" href="http://www.debian.org/doc/manuals/maint-guide/">Debian New Maintainers’ Guide</a> — available in many languages;</li>
<li><a class="reference external" href="http://www.debian.org/doc/manuals/packaging-tutorial/">Packaging tutorial</a> (also available as a <a class="reference external" href="https://launchpad.net/ubuntu/+source/packaging-tutorial">package</a>);</li>
<li><a class="reference external" href="https://wiki.debian.org/Python/LibraryStyleGuide">Guide for Packaging Python Modules</a>.</li>
</ul>
<p>We are always looking to improve this guide. If you find any problems or have
some suggestions, please <a class="reference external" href="https://bugs.launchpad.net/ubuntu-packaging-guide">report a bug on Launchpad</a>.
If you’d like to help work on the guide, <a class="reference external" href="https://code.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk">grab the source</a> there as well.</p>
</div>
</div>
<div class="divide"></div>
</div>
<div id="sidebar" class="grid_3 omega">
<div class="container-tweet">
<h3>Tabela de Conteúdo</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. Introdução ao desenvolvimento Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/getting-set-up">2. Guia de configuração</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-intro">3. Desenvolvimento distribuído do Ubuntu — Introdução</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug">4. Corrigindo um erro no Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-a-bug-example">5. Tutorial: corrigindo uma falha no Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/packaging-new-software">6. Empacotando um novo software</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/security-and-stable-release-updates">7. Atualizações de segurança de versão estável</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/patches-to-packages">8. Patches para pacotes</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/fixing-ftbfs">9. Fixing FTBFS packages</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/libraries">10. Bibliotecas compartilhadas</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/backports">11. Backport de atualização de programas</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/communication">1. Comunicação no desenvolvimento do Ubuntu</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/debian-dir-overview">2. Visão básica do diretório <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: Teste automático para pacotes</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-getting-the-source">4. Obtendo o fonte</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-working">5. Trabalhando em um pacote</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-sponsorship">6. Buscando revisão e orientação</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-uploading">7. Enviando um pacote</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-latest">8. Obtendo o mais recente</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/udd-merging">9. Mesclando — Atualizando do Debian e do upstream</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/chroots">10. Usando o chroot</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/traditional-packaging">11. Empacotamento tradicional</a></li>
<li class="toctree-l1"><a class="reference internal" href="index.html#document-ubuntu-packaging-guide/kde">12. Empacotamento do 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.6.
<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.
Criado usando <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.3.
<br />
© Copyright 2010-2014 , 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>
|