From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-August/007144.html | 71 + zarb-ml/mageia-dev/2011-August/007145.html | 96 + zarb-ml/mageia-dev/2011-August/007146.html | 95 + zarb-ml/mageia-dev/2011-August/007147.html | 107 + zarb-ml/mageia-dev/2011-August/007148.html | 99 + zarb-ml/mageia-dev/2011-August/007149.html | 109 + zarb-ml/mageia-dev/2011-August/007150.html | 84 + zarb-ml/mageia-dev/2011-August/007151.html | 95 + zarb-ml/mageia-dev/2011-August/007152.html | 95 + zarb-ml/mageia-dev/2011-August/007153.html | 125 + zarb-ml/mageia-dev/2011-August/007154.html | 71 + zarb-ml/mageia-dev/2011-August/007155.html | 107 + zarb-ml/mageia-dev/2011-August/007156.html | 100 + zarb-ml/mageia-dev/2011-August/007157.html | 108 + zarb-ml/mageia-dev/2011-August/007158.html | 87 + zarb-ml/mageia-dev/2011-August/007159.html | 107 + zarb-ml/mageia-dev/2011-August/007160.html | 118 + zarb-ml/mageia-dev/2011-August/007161.html | 94 + zarb-ml/mageia-dev/2011-August/007162.html | 91 + zarb-ml/mageia-dev/2011-August/007163.html | 98 + zarb-ml/mageia-dev/2011-August/007164.html | 103 + zarb-ml/mageia-dev/2011-August/007165.html | 115 + zarb-ml/mageia-dev/2011-August/007166.html | 105 + zarb-ml/mageia-dev/2011-August/007167.html | 114 + zarb-ml/mageia-dev/2011-August/007168.html | 108 + zarb-ml/mageia-dev/2011-August/007169.html | 142 + zarb-ml/mageia-dev/2011-August/007170.html | 95 + zarb-ml/mageia-dev/2011-August/007171.html | 155 ++ zarb-ml/mageia-dev/2011-August/007172.html | 119 + zarb-ml/mageia-dev/2011-August/007173.html | 87 + zarb-ml/mageia-dev/2011-August/007174.html | 97 + zarb-ml/mageia-dev/2011-August/007175.html | 91 + zarb-ml/mageia-dev/2011-August/007176.html | 96 + zarb-ml/mageia-dev/2011-August/007177.html | 93 + zarb-ml/mageia-dev/2011-August/007178.html | 108 + zarb-ml/mageia-dev/2011-August/007179.html | 89 + zarb-ml/mageia-dev/2011-August/007180.html | 100 + zarb-ml/mageia-dev/2011-August/007181.html | 86 + zarb-ml/mageia-dev/2011-August/007182.html | 119 + zarb-ml/mageia-dev/2011-August/007183.html | 123 + zarb-ml/mageia-dev/2011-August/007184.html | 142 + zarb-ml/mageia-dev/2011-August/007185.html | 88 + zarb-ml/mageia-dev/2011-August/007186.html | 80 + zarb-ml/mageia-dev/2011-August/007187.html | 107 + zarb-ml/mageia-dev/2011-August/007188.html | 158 ++ zarb-ml/mageia-dev/2011-August/007189.html | 214 ++ zarb-ml/mageia-dev/2011-August/007190.html | 202 ++ zarb-ml/mageia-dev/2011-August/007191.html | 253 ++ zarb-ml/mageia-dev/2011-August/007192.html | 113 + zarb-ml/mageia-dev/2011-August/007193.html | 107 + zarb-ml/mageia-dev/2011-August/007194.html | 128 + zarb-ml/mageia-dev/2011-August/007195.html | 102 + zarb-ml/mageia-dev/2011-August/007196.html | 122 + zarb-ml/mageia-dev/2011-August/007197.html | 113 + zarb-ml/mageia-dev/2011-August/007198.html | 93 + zarb-ml/mageia-dev/2011-August/007199.html | 99 + zarb-ml/mageia-dev/2011-August/007200.html | 92 + zarb-ml/mageia-dev/2011-August/007201.html | 136 + zarb-ml/mageia-dev/2011-August/007202.html | 113 + zarb-ml/mageia-dev/2011-August/007203.html | 85 + zarb-ml/mageia-dev/2011-August/007204.html | 101 + zarb-ml/mageia-dev/2011-August/007205.html | 111 + zarb-ml/mageia-dev/2011-August/007206.html | 124 + zarb-ml/mageia-dev/2011-August/007207.html | 139 + zarb-ml/mageia-dev/2011-August/007208.html | 113 + zarb-ml/mageia-dev/2011-August/007209.html | 105 + zarb-ml/mageia-dev/2011-August/007210.html | 96 + zarb-ml/mageia-dev/2011-August/007211.html | 108 + zarb-ml/mageia-dev/2011-August/007212.html | 103 + zarb-ml/mageia-dev/2011-August/007213.html | 131 + zarb-ml/mageia-dev/2011-August/007214.html | 96 + zarb-ml/mageia-dev/2011-August/007215.html | 1416 ++++++++++ zarb-ml/mageia-dev/2011-August/007216.html | 127 + zarb-ml/mageia-dev/2011-August/007217.html | 107 + zarb-ml/mageia-dev/2011-August/007218.html | 86 + zarb-ml/mageia-dev/2011-August/007219.html | 115 + zarb-ml/mageia-dev/2011-August/007220.html | 93 + zarb-ml/mageia-dev/2011-August/007221.html | 93 + zarb-ml/mageia-dev/2011-August/007222.html | 120 + zarb-ml/mageia-dev/2011-August/007223.html | 125 + zarb-ml/mageia-dev/2011-August/007224.html | 86 + zarb-ml/mageia-dev/2011-August/007225.html | 96 + zarb-ml/mageia-dev/2011-August/007226.html | 110 + zarb-ml/mageia-dev/2011-August/007227.html | 102 + zarb-ml/mageia-dev/2011-August/007228.html | 103 + zarb-ml/mageia-dev/2011-August/007229.html | 89 + zarb-ml/mageia-dev/2011-August/007230.html | 133 + zarb-ml/mageia-dev/2011-August/007231.html | 93 + zarb-ml/mageia-dev/2011-August/007232.html | 129 + zarb-ml/mageia-dev/2011-August/007233.html | 153 ++ zarb-ml/mageia-dev/2011-August/007234.html | 107 + zarb-ml/mageia-dev/2011-August/007235.html | 114 + zarb-ml/mageia-dev/2011-August/007236.html | 125 + zarb-ml/mageia-dev/2011-August/007237.html | 115 + zarb-ml/mageia-dev/2011-August/007238.html | 122 + zarb-ml/mageia-dev/2011-August/007239.html | 143 + zarb-ml/mageia-dev/2011-August/007240.html | 104 + zarb-ml/mageia-dev/2011-August/007241.html | 154 ++ zarb-ml/mageia-dev/2011-August/007242.html | 175 ++ zarb-ml/mageia-dev/2011-August/007243.html | 86 + zarb-ml/mageia-dev/2011-August/007244.html | 102 + zarb-ml/mageia-dev/2011-August/007245.html | 92 + zarb-ml/mageia-dev/2011-August/007246.html | 94 + zarb-ml/mageia-dev/2011-August/007247.html | 104 + zarb-ml/mageia-dev/2011-August/007248.html | 105 + zarb-ml/mageia-dev/2011-August/007249.html | 179 ++ zarb-ml/mageia-dev/2011-August/007250.html | 108 + zarb-ml/mageia-dev/2011-August/007251.html | 173 ++ zarb-ml/mageia-dev/2011-August/007252.html | 95 + zarb-ml/mageia-dev/2011-August/007253.html | 90 + zarb-ml/mageia-dev/2011-August/007254.html | 181 ++ zarb-ml/mageia-dev/2011-August/007255.html | 102 + zarb-ml/mageia-dev/2011-August/007256.html | 92 + zarb-ml/mageia-dev/2011-August/007257.html | 96 + zarb-ml/mageia-dev/2011-August/007258.html | 116 + zarb-ml/mageia-dev/2011-August/007259.html | 97 + zarb-ml/mageia-dev/2011-August/007260.html | 97 + zarb-ml/mageia-dev/2011-August/007261.html | 106 + zarb-ml/mageia-dev/2011-August/007262.html | 123 + zarb-ml/mageia-dev/2011-August/007263.html | 114 + zarb-ml/mageia-dev/2011-August/007264.html | 95 + zarb-ml/mageia-dev/2011-August/007265.html | 92 + zarb-ml/mageia-dev/2011-August/007266.html | 141 + zarb-ml/mageia-dev/2011-August/007267.html | 100 + zarb-ml/mageia-dev/2011-August/007268.html | 99 + zarb-ml/mageia-dev/2011-August/007269.html | 119 + zarb-ml/mageia-dev/2011-August/007270.html | 83 + zarb-ml/mageia-dev/2011-August/007271.html | 105 + zarb-ml/mageia-dev/2011-August/007272.html | 116 + zarb-ml/mageia-dev/2011-August/007273.html | 94 + zarb-ml/mageia-dev/2011-August/007274.html | 117 + zarb-ml/mageia-dev/2011-August/007275.html | 79 + zarb-ml/mageia-dev/2011-August/007276.html | 99 + zarb-ml/mageia-dev/2011-August/007277.html | 98 + zarb-ml/mageia-dev/2011-August/007278.html | 83 + zarb-ml/mageia-dev/2011-August/007279.html | 102 + zarb-ml/mageia-dev/2011-August/007280.html | 147 + zarb-ml/mageia-dev/2011-August/007281.html | 96 + zarb-ml/mageia-dev/2011-August/007282.html | 95 + zarb-ml/mageia-dev/2011-August/007283.html | 83 + zarb-ml/mageia-dev/2011-August/007284.html | 90 + zarb-ml/mageia-dev/2011-August/007285.html | 76 + zarb-ml/mageia-dev/2011-August/007286.html | 104 + zarb-ml/mageia-dev/2011-August/007287.html | 125 + zarb-ml/mageia-dev/2011-August/007288.html | 86 + zarb-ml/mageia-dev/2011-August/007289.html | 83 + zarb-ml/mageia-dev/2011-August/007290.html | 92 + zarb-ml/mageia-dev/2011-August/007291.html | 101 + zarb-ml/mageia-dev/2011-August/007292.html | 88 + zarb-ml/mageia-dev/2011-August/007293.html | 90 + zarb-ml/mageia-dev/2011-August/007294.html | 79 + zarb-ml/mageia-dev/2011-August/007295.html | 86 + zarb-ml/mageia-dev/2011-August/007296.html | 87 + zarb-ml/mageia-dev/2011-August/007297.html | 85 + zarb-ml/mageia-dev/2011-August/007298.html | 83 + zarb-ml/mageia-dev/2011-August/007299.html | 89 + zarb-ml/mageia-dev/2011-August/007300.html | 79 + zarb-ml/mageia-dev/2011-August/007301.html | 81 + zarb-ml/mageia-dev/2011-August/007302.html | 85 + zarb-ml/mageia-dev/2011-August/007303.html | 87 + zarb-ml/mageia-dev/2011-August/007304.html | 117 + zarb-ml/mageia-dev/2011-August/007305.html | 125 + zarb-ml/mageia-dev/2011-August/007306.html | 97 + zarb-ml/mageia-dev/2011-August/007307.html | 117 + zarb-ml/mageia-dev/2011-August/007308.html | 112 + zarb-ml/mageia-dev/2011-August/007309.html | 122 + zarb-ml/mageia-dev/2011-August/007310.html | 101 + zarb-ml/mageia-dev/2011-August/007311.html | 80 + zarb-ml/mageia-dev/2011-August/007312.html | 147 + zarb-ml/mageia-dev/2011-August/007313.html | 123 + zarb-ml/mageia-dev/2011-August/007314.html | 75 + zarb-ml/mageia-dev/2011-August/007315.html | 116 + zarb-ml/mageia-dev/2011-August/007318.html | 75 + zarb-ml/mageia-dev/2011-August/007319.html | 109 + zarb-ml/mageia-dev/2011-August/007320.html | 118 + zarb-ml/mageia-dev/2011-August/007321.html | 118 + zarb-ml/mageia-dev/2011-August/007322.html | 79 + zarb-ml/mageia-dev/2011-August/007323.html | 74 + zarb-ml/mageia-dev/2011-August/007324.html | 79 + zarb-ml/mageia-dev/2011-August/007325.html | 64 + zarb-ml/mageia-dev/2011-August/007326.html | 71 + zarb-ml/mageia-dev/2011-August/007327.html | 88 + zarb-ml/mageia-dev/2011-August/007328.html | 104 + zarb-ml/mageia-dev/2011-August/007329.html | 90 + zarb-ml/mageia-dev/2011-August/007330.html | 82 + zarb-ml/mageia-dev/2011-August/007331.html | 96 + zarb-ml/mageia-dev/2011-August/007332.html | 169 ++ zarb-ml/mageia-dev/2011-August/007333.html | 101 + zarb-ml/mageia-dev/2011-August/007334.html | 86 + zarb-ml/mageia-dev/2011-August/007335.html | 98 + zarb-ml/mageia-dev/2011-August/007336.html | 89 + zarb-ml/mageia-dev/2011-August/007337.html | 80 + zarb-ml/mageia-dev/2011-August/007338.html | 103 + zarb-ml/mageia-dev/2011-August/007339.html | 78 + zarb-ml/mageia-dev/2011-August/007340.html | 126 + zarb-ml/mageia-dev/2011-August/007341.html | 82 + zarb-ml/mageia-dev/2011-August/007342.html | 117 + zarb-ml/mageia-dev/2011-August/007343.html | 80 + zarb-ml/mageia-dev/2011-August/007344.html | 78 + zarb-ml/mageia-dev/2011-August/007345.html | 119 + zarb-ml/mageia-dev/2011-August/007346.html | 81 + zarb-ml/mageia-dev/2011-August/007347.html | 88 + zarb-ml/mageia-dev/2011-August/007348.html | 95 + zarb-ml/mageia-dev/2011-August/007349.html | 91 + zarb-ml/mageia-dev/2011-August/007350.html | 88 + zarb-ml/mageia-dev/2011-August/007351.html | 100 + zarb-ml/mageia-dev/2011-August/007352.html | 79 + zarb-ml/mageia-dev/2011-August/007353.html | 95 + zarb-ml/mageia-dev/2011-August/007354.html | 92 + zarb-ml/mageia-dev/2011-August/007355.html | 101 + zarb-ml/mageia-dev/2011-August/007356.html | 105 + zarb-ml/mageia-dev/2011-August/007357.html | 127 + zarb-ml/mageia-dev/2011-August/007358.html | 122 + zarb-ml/mageia-dev/2011-August/007359.html | 87 + zarb-ml/mageia-dev/2011-August/007360.html | 92 + zarb-ml/mageia-dev/2011-August/007361.html | 91 + zarb-ml/mageia-dev/2011-August/007362.html | 97 + zarb-ml/mageia-dev/2011-August/007363.html | 98 + zarb-ml/mageia-dev/2011-August/007364.html | 90 + zarb-ml/mageia-dev/2011-August/007365.html | 103 + zarb-ml/mageia-dev/2011-August/007366.html | 93 + zarb-ml/mageia-dev/2011-August/007367.html | 100 + zarb-ml/mageia-dev/2011-August/007368.html | 97 + zarb-ml/mageia-dev/2011-August/007369.html | 105 + zarb-ml/mageia-dev/2011-August/007370.html | 97 + zarb-ml/mageia-dev/2011-August/007371.html | 103 + zarb-ml/mageia-dev/2011-August/007372.html | 87 + zarb-ml/mageia-dev/2011-August/007373.html | 114 + zarb-ml/mageia-dev/2011-August/007374.html | 101 + zarb-ml/mageia-dev/2011-August/007375.html | 108 + zarb-ml/mageia-dev/2011-August/007376.html | 129 + zarb-ml/mageia-dev/2011-August/007377.html | 128 + zarb-ml/mageia-dev/2011-August/007378.html | 89 + zarb-ml/mageia-dev/2011-August/007379.html | 118 + zarb-ml/mageia-dev/2011-August/007380.html | 93 + zarb-ml/mageia-dev/2011-August/007381.html | 91 + zarb-ml/mageia-dev/2011-August/007382.html | 95 + zarb-ml/mageia-dev/2011-August/007383.html | 101 + zarb-ml/mageia-dev/2011-August/007384.html | 95 + zarb-ml/mageia-dev/2011-August/007385.html | 104 + zarb-ml/mageia-dev/2011-August/007386.html | 89 + zarb-ml/mageia-dev/2011-August/007387.html | 101 + zarb-ml/mageia-dev/2011-August/007388.html | 108 + zarb-ml/mageia-dev/2011-August/007389.html | 110 + zarb-ml/mageia-dev/2011-August/007390.html | 128 + zarb-ml/mageia-dev/2011-August/007391.html | 108 + zarb-ml/mageia-dev/2011-August/007392.html | 118 + zarb-ml/mageia-dev/2011-August/007393.html | 99 + zarb-ml/mageia-dev/2011-August/007394.html | 75 + zarb-ml/mageia-dev/2011-August/007395.html | 92 + zarb-ml/mageia-dev/2011-August/007396.html | 92 + zarb-ml/mageia-dev/2011-August/007397.html | 102 + zarb-ml/mageia-dev/2011-August/007398.html | 147 + zarb-ml/mageia-dev/2011-August/007399.html | 123 + zarb-ml/mageia-dev/2011-August/007400.html | 102 + zarb-ml/mageia-dev/2011-August/007401.html | 95 + zarb-ml/mageia-dev/2011-August/007402.html | 107 + zarb-ml/mageia-dev/2011-August/007403.html | 107 + zarb-ml/mageia-dev/2011-August/007404.html | 133 + zarb-ml/mageia-dev/2011-August/007405.html | 119 + zarb-ml/mageia-dev/2011-August/007406.html | 118 + zarb-ml/mageia-dev/2011-August/007407.html | 162 ++ zarb-ml/mageia-dev/2011-August/007408.html | 118 + zarb-ml/mageia-dev/2011-August/007409.html | 87 + zarb-ml/mageia-dev/2011-August/007410.html | 109 + zarb-ml/mageia-dev/2011-August/007411.html | 98 + zarb-ml/mageia-dev/2011-August/007412.html | 121 + zarb-ml/mageia-dev/2011-August/007413.html | 119 + zarb-ml/mageia-dev/2011-August/007414.html | 147 + zarb-ml/mageia-dev/2011-August/007415.html | 141 + zarb-ml/mageia-dev/2011-August/007416.html | 145 + zarb-ml/mageia-dev/2011-August/007417.html | 161 ++ zarb-ml/mageia-dev/2011-August/007418.html | 110 + zarb-ml/mageia-dev/2011-August/007419.html | 102 + zarb-ml/mageia-dev/2011-August/007420.html | 107 + zarb-ml/mageia-dev/2011-August/007421.html | 80 + zarb-ml/mageia-dev/2011-August/007422.html | 117 + zarb-ml/mageia-dev/2011-August/007423.html | 101 + zarb-ml/mageia-dev/2011-August/007424.html | 110 + zarb-ml/mageia-dev/2011-August/007425.html | 130 + zarb-ml/mageia-dev/2011-August/007426.html | 104 + zarb-ml/mageia-dev/2011-August/007427.html | 143 + zarb-ml/mageia-dev/2011-August/007428.html | 106 + zarb-ml/mageia-dev/2011-August/007429.html | 100 + zarb-ml/mageia-dev/2011-August/007430.html | 127 + zarb-ml/mageia-dev/2011-August/007431.html | 115 + zarb-ml/mageia-dev/2011-August/007432.html | 142 + zarb-ml/mageia-dev/2011-August/007433.html | 81 + zarb-ml/mageia-dev/2011-August/007434.html | 143 + zarb-ml/mageia-dev/2011-August/007435.html | 109 + zarb-ml/mageia-dev/2011-August/007436.html | 136 + zarb-ml/mageia-dev/2011-August/007437.html | 129 + zarb-ml/mageia-dev/2011-August/007438.html | 82 + zarb-ml/mageia-dev/2011-August/007439.html | 124 + zarb-ml/mageia-dev/2011-August/007440.html | 95 + zarb-ml/mageia-dev/2011-August/007441.html | 125 + zarb-ml/mageia-dev/2011-August/007442.html | 159 ++ zarb-ml/mageia-dev/2011-August/007443.html | 187 ++ zarb-ml/mageia-dev/2011-August/007444.html | 129 + zarb-ml/mageia-dev/2011-August/007445.html | 119 + zarb-ml/mageia-dev/2011-August/007446.html | 82 + zarb-ml/mageia-dev/2011-August/007447.html | 151 ++ zarb-ml/mageia-dev/2011-August/007448.html | 165 ++ zarb-ml/mageia-dev/2011-August/007449.html | 178 ++ zarb-ml/mageia-dev/2011-August/007450.html | 87 + zarb-ml/mageia-dev/2011-August/007451.html | 105 + zarb-ml/mageia-dev/2011-August/007452.html | 102 + zarb-ml/mageia-dev/2011-August/007453.html | 163 ++ zarb-ml/mageia-dev/2011-August/007454.html | 133 + zarb-ml/mageia-dev/2011-August/007455.html | 124 + zarb-ml/mageia-dev/2011-August/007456.html | 115 + zarb-ml/mageia-dev/2011-August/007457.html | 109 + zarb-ml/mageia-dev/2011-August/007458.html | 134 + zarb-ml/mageia-dev/2011-August/007459.html | 96 + zarb-ml/mageia-dev/2011-August/007460.html | 80 + zarb-ml/mageia-dev/2011-August/007461.html | 154 ++ zarb-ml/mageia-dev/2011-August/007462.html | 99 + zarb-ml/mageia-dev/2011-August/007463.html | 94 + zarb-ml/mageia-dev/2011-August/007464.html | 112 + zarb-ml/mageia-dev/2011-August/007465.html | 130 + zarb-ml/mageia-dev/2011-August/007466.html | 98 + zarb-ml/mageia-dev/2011-August/007467.html | 87 + zarb-ml/mageia-dev/2011-August/007468.html | 77 + zarb-ml/mageia-dev/2011-August/007469.html | 96 + zarb-ml/mageia-dev/2011-August/007470.html | 95 + zarb-ml/mageia-dev/2011-August/007471.html | 140 + zarb-ml/mageia-dev/2011-August/007472.html | 147 + zarb-ml/mageia-dev/2011-August/007473.html | 139 + zarb-ml/mageia-dev/2011-August/007474.html | 144 + zarb-ml/mageia-dev/2011-August/007475.html | 105 + zarb-ml/mageia-dev/2011-August/007476.html | 78 + zarb-ml/mageia-dev/2011-August/007477.html | 123 + zarb-ml/mageia-dev/2011-August/007478.html | 103 + zarb-ml/mageia-dev/2011-August/007479.html | 116 + zarb-ml/mageia-dev/2011-August/007480.html | 96 + zarb-ml/mageia-dev/2011-August/007481.html | 182 ++ zarb-ml/mageia-dev/2011-August/007482.html | 133 + zarb-ml/mageia-dev/2011-August/007483.html | 106 + zarb-ml/mageia-dev/2011-August/007484.html | 301 +++ zarb-ml/mageia-dev/2011-August/007485.html | 94 + zarb-ml/mageia-dev/2011-August/007486.html | 92 + zarb-ml/mageia-dev/2011-August/007487.html | 96 + zarb-ml/mageia-dev/2011-August/007488.html | 101 + zarb-ml/mageia-dev/2011-August/007489.html | 86 + zarb-ml/mageia-dev/2011-August/007490.html | 82 + zarb-ml/mageia-dev/2011-August/007491.html | 104 + zarb-ml/mageia-dev/2011-August/007492.html | 96 + zarb-ml/mageia-dev/2011-August/007493.html | 98 + zarb-ml/mageia-dev/2011-August/007494.html | 94 + zarb-ml/mageia-dev/2011-August/007495.html | 190 ++ zarb-ml/mageia-dev/2011-August/007496.html | 119 + zarb-ml/mageia-dev/2011-August/007497.html | 86 + zarb-ml/mageia-dev/2011-August/007498.html | 88 + zarb-ml/mageia-dev/2011-August/007499.html | 92 + zarb-ml/mageia-dev/2011-August/007500.html | 84 + zarb-ml/mageia-dev/2011-August/007501.html | 88 + zarb-ml/mageia-dev/2011-August/007502.html | 95 + zarb-ml/mageia-dev/2011-August/007503.html | 80 + zarb-ml/mageia-dev/2011-August/007504.html | 81 + zarb-ml/mageia-dev/2011-August/007505.html | 91 + zarb-ml/mageia-dev/2011-August/007506.html | 135 + zarb-ml/mageia-dev/2011-August/007507.html | 173 ++ zarb-ml/mageia-dev/2011-August/007508.html | 116 + zarb-ml/mageia-dev/2011-August/007509.html | 154 ++ zarb-ml/mageia-dev/2011-August/007510.html | 112 + zarb-ml/mageia-dev/2011-August/007511.html | 97 + zarb-ml/mageia-dev/2011-August/007512.html | 103 + zarb-ml/mageia-dev/2011-August/007513.html | 115 + zarb-ml/mageia-dev/2011-August/007514.html | 105 + zarb-ml/mageia-dev/2011-August/007515.html | 154 ++ zarb-ml/mageia-dev/2011-August/007516.html | 148 + zarb-ml/mageia-dev/2011-August/007517.html | 126 + zarb-ml/mageia-dev/2011-August/007518.html | 120 + zarb-ml/mageia-dev/2011-August/007519.html | 171 ++ zarb-ml/mageia-dev/2011-August/007520.html | 147 + zarb-ml/mageia-dev/2011-August/007521.html | 120 + zarb-ml/mageia-dev/2011-August/007522.html | 138 + zarb-ml/mageia-dev/2011-August/007523.html | 102 + zarb-ml/mageia-dev/2011-August/007524.html | 115 + zarb-ml/mageia-dev/2011-August/007525.html | 135 + zarb-ml/mageia-dev/2011-August/007526.html | 88 + zarb-ml/mageia-dev/2011-August/007527.html | 128 + zarb-ml/mageia-dev/2011-August/007528.html | 109 + zarb-ml/mageia-dev/2011-August/007529.html | 97 + zarb-ml/mageia-dev/2011-August/007530.html | 136 + zarb-ml/mageia-dev/2011-August/007531.html | 104 + zarb-ml/mageia-dev/2011-August/007532.html | 104 + zarb-ml/mageia-dev/2011-August/007533.html | 156 ++ zarb-ml/mageia-dev/2011-August/007534.html | 118 + zarb-ml/mageia-dev/2011-August/007535.html | 111 + zarb-ml/mageia-dev/2011-August/007536.html | 114 + zarb-ml/mageia-dev/2011-August/007537.html | 117 + zarb-ml/mageia-dev/2011-August/007538.html | 130 + zarb-ml/mageia-dev/2011-August/007539.html | 181 ++ zarb-ml/mageia-dev/2011-August/007540.html | 140 + zarb-ml/mageia-dev/2011-August/007541.html | 103 + zarb-ml/mageia-dev/2011-August/007542.html | 179 ++ zarb-ml/mageia-dev/2011-August/007543.html | 90 + zarb-ml/mageia-dev/2011-August/007544.html | 105 + zarb-ml/mageia-dev/2011-August/007545.html | 83 + zarb-ml/mageia-dev/2011-August/007546.html | 121 + zarb-ml/mageia-dev/2011-August/007547.html | 95 + zarb-ml/mageia-dev/2011-August/007548.html | 103 + zarb-ml/mageia-dev/2011-August/007549.html | 106 + zarb-ml/mageia-dev/2011-August/007550.html | 113 + zarb-ml/mageia-dev/2011-August/007551.html | 103 + zarb-ml/mageia-dev/2011-August/007552.html | 107 + zarb-ml/mageia-dev/2011-August/007553.html | 111 + zarb-ml/mageia-dev/2011-August/007554.html | 89 + zarb-ml/mageia-dev/2011-August/007555.html | 100 + zarb-ml/mageia-dev/2011-August/007556.html | 101 + zarb-ml/mageia-dev/2011-August/007557.html | 103 + zarb-ml/mageia-dev/2011-August/007558.html | 115 + zarb-ml/mageia-dev/2011-August/007559.html | 111 + zarb-ml/mageia-dev/2011-August/007560.html | 111 + zarb-ml/mageia-dev/2011-August/007561.html | 102 + zarb-ml/mageia-dev/2011-August/007562.html | 98 + zarb-ml/mageia-dev/2011-August/007563.html | 120 + zarb-ml/mageia-dev/2011-August/007564.html | 110 + zarb-ml/mageia-dev/2011-August/007565.html | 130 + zarb-ml/mageia-dev/2011-August/007566.html | 124 + zarb-ml/mageia-dev/2011-August/007567.html | 148 + zarb-ml/mageia-dev/2011-August/007568.html | 86 + zarb-ml/mageia-dev/2011-August/007569.html | 90 + zarb-ml/mageia-dev/2011-August/007570.html | 135 + zarb-ml/mageia-dev/2011-August/007571.html | 89 + zarb-ml/mageia-dev/2011-August/007572.html | 92 + zarb-ml/mageia-dev/2011-August/007573.html | 137 + zarb-ml/mageia-dev/2011-August/007574.html | 116 + zarb-ml/mageia-dev/2011-August/007575.html | 94 + zarb-ml/mageia-dev/2011-August/007576.html | 97 + zarb-ml/mageia-dev/2011-August/007577.html | 133 + zarb-ml/mageia-dev/2011-August/007578.html | 106 + zarb-ml/mageia-dev/2011-August/007579.html | 119 + zarb-ml/mageia-dev/2011-August/007580.html | 84 + zarb-ml/mageia-dev/2011-August/007581.html | 90 + zarb-ml/mageia-dev/2011-August/007582.html | 111 + zarb-ml/mageia-dev/2011-August/007583.html | 121 + zarb-ml/mageia-dev/2011-August/007584.html | 265 ++ zarb-ml/mageia-dev/2011-August/007585.html | 80 + zarb-ml/mageia-dev/2011-August/007586.html | 228 ++ zarb-ml/mageia-dev/2011-August/007587.html | 238 ++ zarb-ml/mageia-dev/2011-August/007588.html | 131 + zarb-ml/mageia-dev/2011-August/007589.html | 105 + zarb-ml/mageia-dev/2011-August/007590.html | 155 ++ zarb-ml/mageia-dev/2011-August/007591.html | 96 + zarb-ml/mageia-dev/2011-August/007592.html | 94 + zarb-ml/mageia-dev/2011-August/007593.html | 100 + zarb-ml/mageia-dev/2011-August/007594.html | 86 + zarb-ml/mageia-dev/2011-August/007595.html | 73 + zarb-ml/mageia-dev/2011-August/007596.html | 80 + zarb-ml/mageia-dev/2011-August/007597.html | 95 + zarb-ml/mageia-dev/2011-August/007598.html | 76 + zarb-ml/mageia-dev/2011-August/007599.html | 104 + zarb-ml/mageia-dev/2011-August/007600.html | 103 + zarb-ml/mageia-dev/2011-August/007601.html | 89 + zarb-ml/mageia-dev/2011-August/007602.html | 107 + zarb-ml/mageia-dev/2011-August/007603.html | 122 + zarb-ml/mageia-dev/2011-August/007604.html | 144 + zarb-ml/mageia-dev/2011-August/007605.html | 105 + zarb-ml/mageia-dev/2011-August/007606.html | 109 + zarb-ml/mageia-dev/2011-August/007607.html | 84 + zarb-ml/mageia-dev/2011-August/007608.html | 141 + zarb-ml/mageia-dev/2011-August/007609.html | 94 + zarb-ml/mageia-dev/2011-August/007610.html | 104 + zarb-ml/mageia-dev/2011-August/007611.html | 173 ++ zarb-ml/mageia-dev/2011-August/007612.html | 104 + zarb-ml/mageia-dev/2011-August/007613.html | 98 + zarb-ml/mageia-dev/2011-August/007614.html | 105 + zarb-ml/mageia-dev/2011-August/007615.html | 117 + zarb-ml/mageia-dev/2011-August/007616.html | 126 + zarb-ml/mageia-dev/2011-August/007617.html | 85 + zarb-ml/mageia-dev/2011-August/007618.html | 96 + zarb-ml/mageia-dev/2011-August/007619.html | 92 + zarb-ml/mageia-dev/2011-August/007620.html | 96 + zarb-ml/mageia-dev/2011-August/007621.html | 99 + zarb-ml/mageia-dev/2011-August/007622.html | 90 + zarb-ml/mageia-dev/2011-August/007623.html | 149 + zarb-ml/mageia-dev/2011-August/007624.html | 79 + zarb-ml/mageia-dev/2011-August/007625.html | 90 + zarb-ml/mageia-dev/2011-August/007626.html | 99 + zarb-ml/mageia-dev/2011-August/007627.html | 146 + zarb-ml/mageia-dev/2011-August/007628.html | 89 + zarb-ml/mageia-dev/2011-August/007629.html | 96 + zarb-ml/mageia-dev/2011-August/007630.html | 69 + zarb-ml/mageia-dev/2011-August/007631.html | 83 + zarb-ml/mageia-dev/2011-August/007632.html | 100 + zarb-ml/mageia-dev/2011-August/007633.html | 83 + zarb-ml/mageia-dev/2011-August/007634.html | 96 + zarb-ml/mageia-dev/2011-August/007635.html | 90 + zarb-ml/mageia-dev/2011-August/007636.html | 92 + zarb-ml/mageia-dev/2011-August/007637.html | 79 + zarb-ml/mageia-dev/2011-August/007638.html | 94 + zarb-ml/mageia-dev/2011-August/007639.html | 100 + zarb-ml/mageia-dev/2011-August/007640.html | 88 + zarb-ml/mageia-dev/2011-August/007641.html | 79 + zarb-ml/mageia-dev/2011-August/007642.html | 86 + zarb-ml/mageia-dev/2011-August/007643.html | 63 + zarb-ml/mageia-dev/2011-August/007644.html | 152 ++ zarb-ml/mageia-dev/2011-August/007645.html | 94 + zarb-ml/mageia-dev/2011-August/007646.html | 91 + zarb-ml/mageia-dev/2011-August/007647.html | 85 + zarb-ml/mageia-dev/2011-August/007648.html | 95 + zarb-ml/mageia-dev/2011-August/007649.html | 101 + zarb-ml/mageia-dev/2011-August/007650.html | 73 + zarb-ml/mageia-dev/2011-August/007651.html | 69 + zarb-ml/mageia-dev/2011-August/007652.html | 139 + zarb-ml/mageia-dev/2011-August/007653.html | 76 + zarb-ml/mageia-dev/2011-August/007654.html | 103 + zarb-ml/mageia-dev/2011-August/007655.html | 77 + zarb-ml/mageia-dev/2011-August/007656.html | 101 + zarb-ml/mageia-dev/2011-August/007657.html | 112 + zarb-ml/mageia-dev/2011-August/007658.html | 70 + zarb-ml/mageia-dev/2011-August/007659.html | 88 + zarb-ml/mageia-dev/2011-August/007660.html | 74 + zarb-ml/mageia-dev/2011-August/007661.html | 102 + zarb-ml/mageia-dev/2011-August/007662.html | 85 + zarb-ml/mageia-dev/2011-August/007663.html | 88 + zarb-ml/mageia-dev/2011-August/007664.html | 86 + zarb-ml/mageia-dev/2011-August/007665.html | 218 ++ zarb-ml/mageia-dev/2011-August/007666.html | 103 + zarb-ml/mageia-dev/2011-August/007667.html | 102 + zarb-ml/mageia-dev/2011-August/007668.html | 120 + zarb-ml/mageia-dev/2011-August/007669.html | 116 + zarb-ml/mageia-dev/2011-August/007670.html | 248 ++ zarb-ml/mageia-dev/2011-August/007671.html | 102 + zarb-ml/mageia-dev/2011-August/007672.html | 97 + zarb-ml/mageia-dev/2011-August/007673.html | 83 + zarb-ml/mageia-dev/2011-August/007674.html | 81 + zarb-ml/mageia-dev/2011-August/007675.html | 80 + zarb-ml/mageia-dev/2011-August/007676.html | 90 + zarb-ml/mageia-dev/2011-August/007677.html | 71 + zarb-ml/mageia-dev/2011-August/007678.html | 113 + zarb-ml/mageia-dev/2011-August/007679.html | 85 + zarb-ml/mageia-dev/2011-August/007680.html | 81 + zarb-ml/mageia-dev/2011-August/007681.html | 102 + zarb-ml/mageia-dev/2011-August/007682.html | 86 + zarb-ml/mageia-dev/2011-August/007683.html | 94 + zarb-ml/mageia-dev/2011-August/007684.html | 95 + zarb-ml/mageia-dev/2011-August/007685.html | 108 + zarb-ml/mageia-dev/2011-August/007686.html | 81 + zarb-ml/mageia-dev/2011-August/007687.html | 112 + zarb-ml/mageia-dev/2011-August/007688.html | 80 + zarb-ml/mageia-dev/2011-August/007689.html | 76 + zarb-ml/mageia-dev/2011-August/007690.html | 115 + zarb-ml/mageia-dev/2011-August/007691.html | 86 + zarb-ml/mageia-dev/2011-August/007692.html | 100 + zarb-ml/mageia-dev/2011-August/007693.html | 103 + zarb-ml/mageia-dev/2011-August/007694.html | 109 + zarb-ml/mageia-dev/2011-August/007695.html | 112 + zarb-ml/mageia-dev/2011-August/007696.html | 87 + zarb-ml/mageia-dev/2011-August/007697.html | 80 + zarb-ml/mageia-dev/2011-August/007698.html | 85 + zarb-ml/mageia-dev/2011-August/007699.html | 78 + zarb-ml/mageia-dev/2011-August/007700.html | 87 + zarb-ml/mageia-dev/2011-August/007701.html | 78 + zarb-ml/mageia-dev/2011-August/007702.html | 80 + zarb-ml/mageia-dev/2011-August/007703.html | 74 + zarb-ml/mageia-dev/2011-August/007704.html | 79 + zarb-ml/mageia-dev/2011-August/007705.html | 101 + zarb-ml/mageia-dev/2011-August/007706.html | 83 + zarb-ml/mageia-dev/2011-August/007707.html | 87 + zarb-ml/mageia-dev/2011-August/007708.html | 66 + zarb-ml/mageia-dev/2011-August/007709.html | 74 + zarb-ml/mageia-dev/2011-August/007710.html | 68 + zarb-ml/mageia-dev/2011-August/007711.html | 89 + zarb-ml/mageia-dev/2011-August/007712.html | 78 + zarb-ml/mageia-dev/2011-August/007713.html | 282 ++ zarb-ml/mageia-dev/2011-August/007714.html | 74 + zarb-ml/mageia-dev/2011-August/007715.html | 80 + zarb-ml/mageia-dev/2011-August/008112.html | 80 + zarb-ml/mageia-dev/2011-August/008113.html | 76 + zarb-ml/mageia-dev/2011-August/008114.html | 94 + zarb-ml/mageia-dev/2011-August/author.html | 2912 ++++++++++++++++++++ zarb-ml/mageia-dev/2011-August/date.html | 2912 ++++++++++++++++++++ zarb-ml/mageia-dev/2011-August/index.html | 1 + zarb-ml/mageia-dev/2011-August/subject.html | 2912 ++++++++++++++++++++ zarb-ml/mageia-dev/2011-August/thread.html | 3907 +++++++++++++++++++++++++++ 578 files changed, 75799 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-August/007144.html create mode 100644 zarb-ml/mageia-dev/2011-August/007145.html create mode 100644 zarb-ml/mageia-dev/2011-August/007146.html create mode 100644 zarb-ml/mageia-dev/2011-August/007147.html create mode 100644 zarb-ml/mageia-dev/2011-August/007148.html create mode 100644 zarb-ml/mageia-dev/2011-August/007149.html create mode 100644 zarb-ml/mageia-dev/2011-August/007150.html create mode 100644 zarb-ml/mageia-dev/2011-August/007151.html create mode 100644 zarb-ml/mageia-dev/2011-August/007152.html create mode 100644 zarb-ml/mageia-dev/2011-August/007153.html create mode 100644 zarb-ml/mageia-dev/2011-August/007154.html create mode 100644 zarb-ml/mageia-dev/2011-August/007155.html create mode 100644 zarb-ml/mageia-dev/2011-August/007156.html create mode 100644 zarb-ml/mageia-dev/2011-August/007157.html create mode 100644 zarb-ml/mageia-dev/2011-August/007158.html create mode 100644 zarb-ml/mageia-dev/2011-August/007159.html create mode 100644 zarb-ml/mageia-dev/2011-August/007160.html create mode 100644 zarb-ml/mageia-dev/2011-August/007161.html create mode 100644 zarb-ml/mageia-dev/2011-August/007162.html create mode 100644 zarb-ml/mageia-dev/2011-August/007163.html create mode 100644 zarb-ml/mageia-dev/2011-August/007164.html create mode 100644 zarb-ml/mageia-dev/2011-August/007165.html create mode 100644 zarb-ml/mageia-dev/2011-August/007166.html create mode 100644 zarb-ml/mageia-dev/2011-August/007167.html create mode 100644 zarb-ml/mageia-dev/2011-August/007168.html create mode 100644 zarb-ml/mageia-dev/2011-August/007169.html create mode 100644 zarb-ml/mageia-dev/2011-August/007170.html create mode 100644 zarb-ml/mageia-dev/2011-August/007171.html create mode 100644 zarb-ml/mageia-dev/2011-August/007172.html create mode 100644 zarb-ml/mageia-dev/2011-August/007173.html create mode 100644 zarb-ml/mageia-dev/2011-August/007174.html create mode 100644 zarb-ml/mageia-dev/2011-August/007175.html create mode 100644 zarb-ml/mageia-dev/2011-August/007176.html create mode 100644 zarb-ml/mageia-dev/2011-August/007177.html create mode 100644 zarb-ml/mageia-dev/2011-August/007178.html create mode 100644 zarb-ml/mageia-dev/2011-August/007179.html create mode 100644 zarb-ml/mageia-dev/2011-August/007180.html create mode 100644 zarb-ml/mageia-dev/2011-August/007181.html create mode 100644 zarb-ml/mageia-dev/2011-August/007182.html create mode 100644 zarb-ml/mageia-dev/2011-August/007183.html create mode 100644 zarb-ml/mageia-dev/2011-August/007184.html create mode 100644 zarb-ml/mageia-dev/2011-August/007185.html create mode 100644 zarb-ml/mageia-dev/2011-August/007186.html create mode 100644 zarb-ml/mageia-dev/2011-August/007187.html create mode 100644 zarb-ml/mageia-dev/2011-August/007188.html create mode 100644 zarb-ml/mageia-dev/2011-August/007189.html create mode 100644 zarb-ml/mageia-dev/2011-August/007190.html create mode 100644 zarb-ml/mageia-dev/2011-August/007191.html create mode 100644 zarb-ml/mageia-dev/2011-August/007192.html create mode 100644 zarb-ml/mageia-dev/2011-August/007193.html create mode 100644 zarb-ml/mageia-dev/2011-August/007194.html create mode 100644 zarb-ml/mageia-dev/2011-August/007195.html create mode 100644 zarb-ml/mageia-dev/2011-August/007196.html create mode 100644 zarb-ml/mageia-dev/2011-August/007197.html create mode 100644 zarb-ml/mageia-dev/2011-August/007198.html create mode 100644 zarb-ml/mageia-dev/2011-August/007199.html create mode 100644 zarb-ml/mageia-dev/2011-August/007200.html create mode 100644 zarb-ml/mageia-dev/2011-August/007201.html create mode 100644 zarb-ml/mageia-dev/2011-August/007202.html create mode 100644 zarb-ml/mageia-dev/2011-August/007203.html create mode 100644 zarb-ml/mageia-dev/2011-August/007204.html create mode 100644 zarb-ml/mageia-dev/2011-August/007205.html create mode 100644 zarb-ml/mageia-dev/2011-August/007206.html create mode 100644 zarb-ml/mageia-dev/2011-August/007207.html create mode 100644 zarb-ml/mageia-dev/2011-August/007208.html create mode 100644 zarb-ml/mageia-dev/2011-August/007209.html create mode 100644 zarb-ml/mageia-dev/2011-August/007210.html create mode 100644 zarb-ml/mageia-dev/2011-August/007211.html create mode 100644 zarb-ml/mageia-dev/2011-August/007212.html create mode 100644 zarb-ml/mageia-dev/2011-August/007213.html create mode 100644 zarb-ml/mageia-dev/2011-August/007214.html create mode 100644 zarb-ml/mageia-dev/2011-August/007215.html create mode 100644 zarb-ml/mageia-dev/2011-August/007216.html create mode 100644 zarb-ml/mageia-dev/2011-August/007217.html create mode 100644 zarb-ml/mageia-dev/2011-August/007218.html create mode 100644 zarb-ml/mageia-dev/2011-August/007219.html create mode 100644 zarb-ml/mageia-dev/2011-August/007220.html create mode 100644 zarb-ml/mageia-dev/2011-August/007221.html create mode 100644 zarb-ml/mageia-dev/2011-August/007222.html create mode 100644 zarb-ml/mageia-dev/2011-August/007223.html create mode 100644 zarb-ml/mageia-dev/2011-August/007224.html create mode 100644 zarb-ml/mageia-dev/2011-August/007225.html create mode 100644 zarb-ml/mageia-dev/2011-August/007226.html create mode 100644 zarb-ml/mageia-dev/2011-August/007227.html create mode 100644 zarb-ml/mageia-dev/2011-August/007228.html create mode 100644 zarb-ml/mageia-dev/2011-August/007229.html create mode 100644 zarb-ml/mageia-dev/2011-August/007230.html create mode 100644 zarb-ml/mageia-dev/2011-August/007231.html create mode 100644 zarb-ml/mageia-dev/2011-August/007232.html create mode 100644 zarb-ml/mageia-dev/2011-August/007233.html create mode 100644 zarb-ml/mageia-dev/2011-August/007234.html create mode 100644 zarb-ml/mageia-dev/2011-August/007235.html create mode 100644 zarb-ml/mageia-dev/2011-August/007236.html create mode 100644 zarb-ml/mageia-dev/2011-August/007237.html create mode 100644 zarb-ml/mageia-dev/2011-August/007238.html create mode 100644 zarb-ml/mageia-dev/2011-August/007239.html create mode 100644 zarb-ml/mageia-dev/2011-August/007240.html create mode 100644 zarb-ml/mageia-dev/2011-August/007241.html create mode 100644 zarb-ml/mageia-dev/2011-August/007242.html create mode 100644 zarb-ml/mageia-dev/2011-August/007243.html create mode 100644 zarb-ml/mageia-dev/2011-August/007244.html create mode 100644 zarb-ml/mageia-dev/2011-August/007245.html create mode 100644 zarb-ml/mageia-dev/2011-August/007246.html create mode 100644 zarb-ml/mageia-dev/2011-August/007247.html create mode 100644 zarb-ml/mageia-dev/2011-August/007248.html create mode 100644 zarb-ml/mageia-dev/2011-August/007249.html create mode 100644 zarb-ml/mageia-dev/2011-August/007250.html create mode 100644 zarb-ml/mageia-dev/2011-August/007251.html create mode 100644 zarb-ml/mageia-dev/2011-August/007252.html create mode 100644 zarb-ml/mageia-dev/2011-August/007253.html create mode 100644 zarb-ml/mageia-dev/2011-August/007254.html create mode 100644 zarb-ml/mageia-dev/2011-August/007255.html create mode 100644 zarb-ml/mageia-dev/2011-August/007256.html create mode 100644 zarb-ml/mageia-dev/2011-August/007257.html create mode 100644 zarb-ml/mageia-dev/2011-August/007258.html create mode 100644 zarb-ml/mageia-dev/2011-August/007259.html create mode 100644 zarb-ml/mageia-dev/2011-August/007260.html create mode 100644 zarb-ml/mageia-dev/2011-August/007261.html create mode 100644 zarb-ml/mageia-dev/2011-August/007262.html create mode 100644 zarb-ml/mageia-dev/2011-August/007263.html create mode 100644 zarb-ml/mageia-dev/2011-August/007264.html create mode 100644 zarb-ml/mageia-dev/2011-August/007265.html create mode 100644 zarb-ml/mageia-dev/2011-August/007266.html create mode 100644 zarb-ml/mageia-dev/2011-August/007267.html create mode 100644 zarb-ml/mageia-dev/2011-August/007268.html create mode 100644 zarb-ml/mageia-dev/2011-August/007269.html create mode 100644 zarb-ml/mageia-dev/2011-August/007270.html create mode 100644 zarb-ml/mageia-dev/2011-August/007271.html create mode 100644 zarb-ml/mageia-dev/2011-August/007272.html create mode 100644 zarb-ml/mageia-dev/2011-August/007273.html create mode 100644 zarb-ml/mageia-dev/2011-August/007274.html create mode 100644 zarb-ml/mageia-dev/2011-August/007275.html create mode 100644 zarb-ml/mageia-dev/2011-August/007276.html create mode 100644 zarb-ml/mageia-dev/2011-August/007277.html create mode 100644 zarb-ml/mageia-dev/2011-August/007278.html create mode 100644 zarb-ml/mageia-dev/2011-August/007279.html create mode 100644 zarb-ml/mageia-dev/2011-August/007280.html create mode 100644 zarb-ml/mageia-dev/2011-August/007281.html create mode 100644 zarb-ml/mageia-dev/2011-August/007282.html create mode 100644 zarb-ml/mageia-dev/2011-August/007283.html create mode 100644 zarb-ml/mageia-dev/2011-August/007284.html create mode 100644 zarb-ml/mageia-dev/2011-August/007285.html create mode 100644 zarb-ml/mageia-dev/2011-August/007286.html create mode 100644 zarb-ml/mageia-dev/2011-August/007287.html create mode 100644 zarb-ml/mageia-dev/2011-August/007288.html create mode 100644 zarb-ml/mageia-dev/2011-August/007289.html create mode 100644 zarb-ml/mageia-dev/2011-August/007290.html create mode 100644 zarb-ml/mageia-dev/2011-August/007291.html create mode 100644 zarb-ml/mageia-dev/2011-August/007292.html create mode 100644 zarb-ml/mageia-dev/2011-August/007293.html create mode 100644 zarb-ml/mageia-dev/2011-August/007294.html create mode 100644 zarb-ml/mageia-dev/2011-August/007295.html create mode 100644 zarb-ml/mageia-dev/2011-August/007296.html create mode 100644 zarb-ml/mageia-dev/2011-August/007297.html create mode 100644 zarb-ml/mageia-dev/2011-August/007298.html create mode 100644 zarb-ml/mageia-dev/2011-August/007299.html create mode 100644 zarb-ml/mageia-dev/2011-August/007300.html create mode 100644 zarb-ml/mageia-dev/2011-August/007301.html create mode 100644 zarb-ml/mageia-dev/2011-August/007302.html create mode 100644 zarb-ml/mageia-dev/2011-August/007303.html create mode 100644 zarb-ml/mageia-dev/2011-August/007304.html create mode 100644 zarb-ml/mageia-dev/2011-August/007305.html create mode 100644 zarb-ml/mageia-dev/2011-August/007306.html create mode 100644 zarb-ml/mageia-dev/2011-August/007307.html create mode 100644 zarb-ml/mageia-dev/2011-August/007308.html create mode 100644 zarb-ml/mageia-dev/2011-August/007309.html create mode 100644 zarb-ml/mageia-dev/2011-August/007310.html create mode 100644 zarb-ml/mageia-dev/2011-August/007311.html create mode 100644 zarb-ml/mageia-dev/2011-August/007312.html create mode 100644 zarb-ml/mageia-dev/2011-August/007313.html create mode 100644 zarb-ml/mageia-dev/2011-August/007314.html create mode 100644 zarb-ml/mageia-dev/2011-August/007315.html create mode 100644 zarb-ml/mageia-dev/2011-August/007318.html create mode 100644 zarb-ml/mageia-dev/2011-August/007319.html create mode 100644 zarb-ml/mageia-dev/2011-August/007320.html create mode 100644 zarb-ml/mageia-dev/2011-August/007321.html create mode 100644 zarb-ml/mageia-dev/2011-August/007322.html create mode 100644 zarb-ml/mageia-dev/2011-August/007323.html create mode 100644 zarb-ml/mageia-dev/2011-August/007324.html create mode 100644 zarb-ml/mageia-dev/2011-August/007325.html create mode 100644 zarb-ml/mageia-dev/2011-August/007326.html create mode 100644 zarb-ml/mageia-dev/2011-August/007327.html create mode 100644 zarb-ml/mageia-dev/2011-August/007328.html create mode 100644 zarb-ml/mageia-dev/2011-August/007329.html create mode 100644 zarb-ml/mageia-dev/2011-August/007330.html create mode 100644 zarb-ml/mageia-dev/2011-August/007331.html create mode 100644 zarb-ml/mageia-dev/2011-August/007332.html create mode 100644 zarb-ml/mageia-dev/2011-August/007333.html create mode 100644 zarb-ml/mageia-dev/2011-August/007334.html create mode 100644 zarb-ml/mageia-dev/2011-August/007335.html create mode 100644 zarb-ml/mageia-dev/2011-August/007336.html create mode 100644 zarb-ml/mageia-dev/2011-August/007337.html create mode 100644 zarb-ml/mageia-dev/2011-August/007338.html create mode 100644 zarb-ml/mageia-dev/2011-August/007339.html create mode 100644 zarb-ml/mageia-dev/2011-August/007340.html create mode 100644 zarb-ml/mageia-dev/2011-August/007341.html create mode 100644 zarb-ml/mageia-dev/2011-August/007342.html create mode 100644 zarb-ml/mageia-dev/2011-August/007343.html create mode 100644 zarb-ml/mageia-dev/2011-August/007344.html create mode 100644 zarb-ml/mageia-dev/2011-August/007345.html create mode 100644 zarb-ml/mageia-dev/2011-August/007346.html create mode 100644 zarb-ml/mageia-dev/2011-August/007347.html create mode 100644 zarb-ml/mageia-dev/2011-August/007348.html create mode 100644 zarb-ml/mageia-dev/2011-August/007349.html create mode 100644 zarb-ml/mageia-dev/2011-August/007350.html create mode 100644 zarb-ml/mageia-dev/2011-August/007351.html create mode 100644 zarb-ml/mageia-dev/2011-August/007352.html create mode 100644 zarb-ml/mageia-dev/2011-August/007353.html create mode 100644 zarb-ml/mageia-dev/2011-August/007354.html create mode 100644 zarb-ml/mageia-dev/2011-August/007355.html create mode 100644 zarb-ml/mageia-dev/2011-August/007356.html create mode 100644 zarb-ml/mageia-dev/2011-August/007357.html create mode 100644 zarb-ml/mageia-dev/2011-August/007358.html create mode 100644 zarb-ml/mageia-dev/2011-August/007359.html create mode 100644 zarb-ml/mageia-dev/2011-August/007360.html create mode 100644 zarb-ml/mageia-dev/2011-August/007361.html create mode 100644 zarb-ml/mageia-dev/2011-August/007362.html create mode 100644 zarb-ml/mageia-dev/2011-August/007363.html create mode 100644 zarb-ml/mageia-dev/2011-August/007364.html create mode 100644 zarb-ml/mageia-dev/2011-August/007365.html create mode 100644 zarb-ml/mageia-dev/2011-August/007366.html create mode 100644 zarb-ml/mageia-dev/2011-August/007367.html create mode 100644 zarb-ml/mageia-dev/2011-August/007368.html create mode 100644 zarb-ml/mageia-dev/2011-August/007369.html create mode 100644 zarb-ml/mageia-dev/2011-August/007370.html create mode 100644 zarb-ml/mageia-dev/2011-August/007371.html create mode 100644 zarb-ml/mageia-dev/2011-August/007372.html create mode 100644 zarb-ml/mageia-dev/2011-August/007373.html create mode 100644 zarb-ml/mageia-dev/2011-August/007374.html create mode 100644 zarb-ml/mageia-dev/2011-August/007375.html create mode 100644 zarb-ml/mageia-dev/2011-August/007376.html create mode 100644 zarb-ml/mageia-dev/2011-August/007377.html create mode 100644 zarb-ml/mageia-dev/2011-August/007378.html create mode 100644 zarb-ml/mageia-dev/2011-August/007379.html create mode 100644 zarb-ml/mageia-dev/2011-August/007380.html create mode 100644 zarb-ml/mageia-dev/2011-August/007381.html create mode 100644 zarb-ml/mageia-dev/2011-August/007382.html create mode 100644 zarb-ml/mageia-dev/2011-August/007383.html create mode 100644 zarb-ml/mageia-dev/2011-August/007384.html create mode 100644 zarb-ml/mageia-dev/2011-August/007385.html create mode 100644 zarb-ml/mageia-dev/2011-August/007386.html create mode 100644 zarb-ml/mageia-dev/2011-August/007387.html create mode 100644 zarb-ml/mageia-dev/2011-August/007388.html create mode 100644 zarb-ml/mageia-dev/2011-August/007389.html create mode 100644 zarb-ml/mageia-dev/2011-August/007390.html create mode 100644 zarb-ml/mageia-dev/2011-August/007391.html create mode 100644 zarb-ml/mageia-dev/2011-August/007392.html create mode 100644 zarb-ml/mageia-dev/2011-August/007393.html create mode 100644 zarb-ml/mageia-dev/2011-August/007394.html create mode 100644 zarb-ml/mageia-dev/2011-August/007395.html create mode 100644 zarb-ml/mageia-dev/2011-August/007396.html create mode 100644 zarb-ml/mageia-dev/2011-August/007397.html create mode 100644 zarb-ml/mageia-dev/2011-August/007398.html create mode 100644 zarb-ml/mageia-dev/2011-August/007399.html create mode 100644 zarb-ml/mageia-dev/2011-August/007400.html create mode 100644 zarb-ml/mageia-dev/2011-August/007401.html create mode 100644 zarb-ml/mageia-dev/2011-August/007402.html create mode 100644 zarb-ml/mageia-dev/2011-August/007403.html create mode 100644 zarb-ml/mageia-dev/2011-August/007404.html create mode 100644 zarb-ml/mageia-dev/2011-August/007405.html create mode 100644 zarb-ml/mageia-dev/2011-August/007406.html create mode 100644 zarb-ml/mageia-dev/2011-August/007407.html create mode 100644 zarb-ml/mageia-dev/2011-August/007408.html create mode 100644 zarb-ml/mageia-dev/2011-August/007409.html create mode 100644 zarb-ml/mageia-dev/2011-August/007410.html create mode 100644 zarb-ml/mageia-dev/2011-August/007411.html create mode 100644 zarb-ml/mageia-dev/2011-August/007412.html create mode 100644 zarb-ml/mageia-dev/2011-August/007413.html create mode 100644 zarb-ml/mageia-dev/2011-August/007414.html create mode 100644 zarb-ml/mageia-dev/2011-August/007415.html create mode 100644 zarb-ml/mageia-dev/2011-August/007416.html create mode 100644 zarb-ml/mageia-dev/2011-August/007417.html create mode 100644 zarb-ml/mageia-dev/2011-August/007418.html create mode 100644 zarb-ml/mageia-dev/2011-August/007419.html create mode 100644 zarb-ml/mageia-dev/2011-August/007420.html create mode 100644 zarb-ml/mageia-dev/2011-August/007421.html create mode 100644 zarb-ml/mageia-dev/2011-August/007422.html create mode 100644 zarb-ml/mageia-dev/2011-August/007423.html create mode 100644 zarb-ml/mageia-dev/2011-August/007424.html create mode 100644 zarb-ml/mageia-dev/2011-August/007425.html create mode 100644 zarb-ml/mageia-dev/2011-August/007426.html create mode 100644 zarb-ml/mageia-dev/2011-August/007427.html create mode 100644 zarb-ml/mageia-dev/2011-August/007428.html create mode 100644 zarb-ml/mageia-dev/2011-August/007429.html create mode 100644 zarb-ml/mageia-dev/2011-August/007430.html create mode 100644 zarb-ml/mageia-dev/2011-August/007431.html create mode 100644 zarb-ml/mageia-dev/2011-August/007432.html create mode 100644 zarb-ml/mageia-dev/2011-August/007433.html create mode 100644 zarb-ml/mageia-dev/2011-August/007434.html create mode 100644 zarb-ml/mageia-dev/2011-August/007435.html create mode 100644 zarb-ml/mageia-dev/2011-August/007436.html create mode 100644 zarb-ml/mageia-dev/2011-August/007437.html create mode 100644 zarb-ml/mageia-dev/2011-August/007438.html create mode 100644 zarb-ml/mageia-dev/2011-August/007439.html create mode 100644 zarb-ml/mageia-dev/2011-August/007440.html create mode 100644 zarb-ml/mageia-dev/2011-August/007441.html create mode 100644 zarb-ml/mageia-dev/2011-August/007442.html create mode 100644 zarb-ml/mageia-dev/2011-August/007443.html create mode 100644 zarb-ml/mageia-dev/2011-August/007444.html create mode 100644 zarb-ml/mageia-dev/2011-August/007445.html create mode 100644 zarb-ml/mageia-dev/2011-August/007446.html create mode 100644 zarb-ml/mageia-dev/2011-August/007447.html create mode 100644 zarb-ml/mageia-dev/2011-August/007448.html create mode 100644 zarb-ml/mageia-dev/2011-August/007449.html create mode 100644 zarb-ml/mageia-dev/2011-August/007450.html create mode 100644 zarb-ml/mageia-dev/2011-August/007451.html create mode 100644 zarb-ml/mageia-dev/2011-August/007452.html create mode 100644 zarb-ml/mageia-dev/2011-August/007453.html create mode 100644 zarb-ml/mageia-dev/2011-August/007454.html create mode 100644 zarb-ml/mageia-dev/2011-August/007455.html create mode 100644 zarb-ml/mageia-dev/2011-August/007456.html create mode 100644 zarb-ml/mageia-dev/2011-August/007457.html create mode 100644 zarb-ml/mageia-dev/2011-August/007458.html create mode 100644 zarb-ml/mageia-dev/2011-August/007459.html create mode 100644 zarb-ml/mageia-dev/2011-August/007460.html create mode 100644 zarb-ml/mageia-dev/2011-August/007461.html create mode 100644 zarb-ml/mageia-dev/2011-August/007462.html create mode 100644 zarb-ml/mageia-dev/2011-August/007463.html create mode 100644 zarb-ml/mageia-dev/2011-August/007464.html create mode 100644 zarb-ml/mageia-dev/2011-August/007465.html create mode 100644 zarb-ml/mageia-dev/2011-August/007466.html create mode 100644 zarb-ml/mageia-dev/2011-August/007467.html create mode 100644 zarb-ml/mageia-dev/2011-August/007468.html create mode 100644 zarb-ml/mageia-dev/2011-August/007469.html create mode 100644 zarb-ml/mageia-dev/2011-August/007470.html create mode 100644 zarb-ml/mageia-dev/2011-August/007471.html create mode 100644 zarb-ml/mageia-dev/2011-August/007472.html create mode 100644 zarb-ml/mageia-dev/2011-August/007473.html create mode 100644 zarb-ml/mageia-dev/2011-August/007474.html create mode 100644 zarb-ml/mageia-dev/2011-August/007475.html create mode 100644 zarb-ml/mageia-dev/2011-August/007476.html create mode 100644 zarb-ml/mageia-dev/2011-August/007477.html create mode 100644 zarb-ml/mageia-dev/2011-August/007478.html create mode 100644 zarb-ml/mageia-dev/2011-August/007479.html create mode 100644 zarb-ml/mageia-dev/2011-August/007480.html create mode 100644 zarb-ml/mageia-dev/2011-August/007481.html create mode 100644 zarb-ml/mageia-dev/2011-August/007482.html create mode 100644 zarb-ml/mageia-dev/2011-August/007483.html create mode 100644 zarb-ml/mageia-dev/2011-August/007484.html create mode 100644 zarb-ml/mageia-dev/2011-August/007485.html create mode 100644 zarb-ml/mageia-dev/2011-August/007486.html create mode 100644 zarb-ml/mageia-dev/2011-August/007487.html create mode 100644 zarb-ml/mageia-dev/2011-August/007488.html create mode 100644 zarb-ml/mageia-dev/2011-August/007489.html create mode 100644 zarb-ml/mageia-dev/2011-August/007490.html create mode 100644 zarb-ml/mageia-dev/2011-August/007491.html create mode 100644 zarb-ml/mageia-dev/2011-August/007492.html create mode 100644 zarb-ml/mageia-dev/2011-August/007493.html create mode 100644 zarb-ml/mageia-dev/2011-August/007494.html create mode 100644 zarb-ml/mageia-dev/2011-August/007495.html create mode 100644 zarb-ml/mageia-dev/2011-August/007496.html create mode 100644 zarb-ml/mageia-dev/2011-August/007497.html create mode 100644 zarb-ml/mageia-dev/2011-August/007498.html create mode 100644 zarb-ml/mageia-dev/2011-August/007499.html create mode 100644 zarb-ml/mageia-dev/2011-August/007500.html create mode 100644 zarb-ml/mageia-dev/2011-August/007501.html create mode 100644 zarb-ml/mageia-dev/2011-August/007502.html create mode 100644 zarb-ml/mageia-dev/2011-August/007503.html create mode 100644 zarb-ml/mageia-dev/2011-August/007504.html create mode 100644 zarb-ml/mageia-dev/2011-August/007505.html create mode 100644 zarb-ml/mageia-dev/2011-August/007506.html create mode 100644 zarb-ml/mageia-dev/2011-August/007507.html create mode 100644 zarb-ml/mageia-dev/2011-August/007508.html create mode 100644 zarb-ml/mageia-dev/2011-August/007509.html create mode 100644 zarb-ml/mageia-dev/2011-August/007510.html create mode 100644 zarb-ml/mageia-dev/2011-August/007511.html create mode 100644 zarb-ml/mageia-dev/2011-August/007512.html create mode 100644 zarb-ml/mageia-dev/2011-August/007513.html create mode 100644 zarb-ml/mageia-dev/2011-August/007514.html create mode 100644 zarb-ml/mageia-dev/2011-August/007515.html create mode 100644 zarb-ml/mageia-dev/2011-August/007516.html create mode 100644 zarb-ml/mageia-dev/2011-August/007517.html create mode 100644 zarb-ml/mageia-dev/2011-August/007518.html create mode 100644 zarb-ml/mageia-dev/2011-August/007519.html create mode 100644 zarb-ml/mageia-dev/2011-August/007520.html create mode 100644 zarb-ml/mageia-dev/2011-August/007521.html create mode 100644 zarb-ml/mageia-dev/2011-August/007522.html create mode 100644 zarb-ml/mageia-dev/2011-August/007523.html create mode 100644 zarb-ml/mageia-dev/2011-August/007524.html create mode 100644 zarb-ml/mageia-dev/2011-August/007525.html create mode 100644 zarb-ml/mageia-dev/2011-August/007526.html create mode 100644 zarb-ml/mageia-dev/2011-August/007527.html create mode 100644 zarb-ml/mageia-dev/2011-August/007528.html create mode 100644 zarb-ml/mageia-dev/2011-August/007529.html create mode 100644 zarb-ml/mageia-dev/2011-August/007530.html create mode 100644 zarb-ml/mageia-dev/2011-August/007531.html create mode 100644 zarb-ml/mageia-dev/2011-August/007532.html create mode 100644 zarb-ml/mageia-dev/2011-August/007533.html create mode 100644 zarb-ml/mageia-dev/2011-August/007534.html create mode 100644 zarb-ml/mageia-dev/2011-August/007535.html create mode 100644 zarb-ml/mageia-dev/2011-August/007536.html create mode 100644 zarb-ml/mageia-dev/2011-August/007537.html create mode 100644 zarb-ml/mageia-dev/2011-August/007538.html create mode 100644 zarb-ml/mageia-dev/2011-August/007539.html create mode 100644 zarb-ml/mageia-dev/2011-August/007540.html create mode 100644 zarb-ml/mageia-dev/2011-August/007541.html create mode 100644 zarb-ml/mageia-dev/2011-August/007542.html create mode 100644 zarb-ml/mageia-dev/2011-August/007543.html create mode 100644 zarb-ml/mageia-dev/2011-August/007544.html create mode 100644 zarb-ml/mageia-dev/2011-August/007545.html create mode 100644 zarb-ml/mageia-dev/2011-August/007546.html create mode 100644 zarb-ml/mageia-dev/2011-August/007547.html create mode 100644 zarb-ml/mageia-dev/2011-August/007548.html create mode 100644 zarb-ml/mageia-dev/2011-August/007549.html create mode 100644 zarb-ml/mageia-dev/2011-August/007550.html create mode 100644 zarb-ml/mageia-dev/2011-August/007551.html create mode 100644 zarb-ml/mageia-dev/2011-August/007552.html create mode 100644 zarb-ml/mageia-dev/2011-August/007553.html create mode 100644 zarb-ml/mageia-dev/2011-August/007554.html create mode 100644 zarb-ml/mageia-dev/2011-August/007555.html create mode 100644 zarb-ml/mageia-dev/2011-August/007556.html create mode 100644 zarb-ml/mageia-dev/2011-August/007557.html create mode 100644 zarb-ml/mageia-dev/2011-August/007558.html create mode 100644 zarb-ml/mageia-dev/2011-August/007559.html create mode 100644 zarb-ml/mageia-dev/2011-August/007560.html create mode 100644 zarb-ml/mageia-dev/2011-August/007561.html create mode 100644 zarb-ml/mageia-dev/2011-August/007562.html create mode 100644 zarb-ml/mageia-dev/2011-August/007563.html create mode 100644 zarb-ml/mageia-dev/2011-August/007564.html create mode 100644 zarb-ml/mageia-dev/2011-August/007565.html create mode 100644 zarb-ml/mageia-dev/2011-August/007566.html create mode 100644 zarb-ml/mageia-dev/2011-August/007567.html create mode 100644 zarb-ml/mageia-dev/2011-August/007568.html create mode 100644 zarb-ml/mageia-dev/2011-August/007569.html create mode 100644 zarb-ml/mageia-dev/2011-August/007570.html create mode 100644 zarb-ml/mageia-dev/2011-August/007571.html create mode 100644 zarb-ml/mageia-dev/2011-August/007572.html create mode 100644 zarb-ml/mageia-dev/2011-August/007573.html create mode 100644 zarb-ml/mageia-dev/2011-August/007574.html create mode 100644 zarb-ml/mageia-dev/2011-August/007575.html create mode 100644 zarb-ml/mageia-dev/2011-August/007576.html create mode 100644 zarb-ml/mageia-dev/2011-August/007577.html create mode 100644 zarb-ml/mageia-dev/2011-August/007578.html create mode 100644 zarb-ml/mageia-dev/2011-August/007579.html create mode 100644 zarb-ml/mageia-dev/2011-August/007580.html create mode 100644 zarb-ml/mageia-dev/2011-August/007581.html create mode 100644 zarb-ml/mageia-dev/2011-August/007582.html create mode 100644 zarb-ml/mageia-dev/2011-August/007583.html create mode 100644 zarb-ml/mageia-dev/2011-August/007584.html create mode 100644 zarb-ml/mageia-dev/2011-August/007585.html create mode 100644 zarb-ml/mageia-dev/2011-August/007586.html create mode 100644 zarb-ml/mageia-dev/2011-August/007587.html create mode 100644 zarb-ml/mageia-dev/2011-August/007588.html create mode 100644 zarb-ml/mageia-dev/2011-August/007589.html create mode 100644 zarb-ml/mageia-dev/2011-August/007590.html create mode 100644 zarb-ml/mageia-dev/2011-August/007591.html create mode 100644 zarb-ml/mageia-dev/2011-August/007592.html create mode 100644 zarb-ml/mageia-dev/2011-August/007593.html create mode 100644 zarb-ml/mageia-dev/2011-August/007594.html create mode 100644 zarb-ml/mageia-dev/2011-August/007595.html create mode 100644 zarb-ml/mageia-dev/2011-August/007596.html create mode 100644 zarb-ml/mageia-dev/2011-August/007597.html create mode 100644 zarb-ml/mageia-dev/2011-August/007598.html create mode 100644 zarb-ml/mageia-dev/2011-August/007599.html create mode 100644 zarb-ml/mageia-dev/2011-August/007600.html create mode 100644 zarb-ml/mageia-dev/2011-August/007601.html create mode 100644 zarb-ml/mageia-dev/2011-August/007602.html create mode 100644 zarb-ml/mageia-dev/2011-August/007603.html create mode 100644 zarb-ml/mageia-dev/2011-August/007604.html create mode 100644 zarb-ml/mageia-dev/2011-August/007605.html create mode 100644 zarb-ml/mageia-dev/2011-August/007606.html create mode 100644 zarb-ml/mageia-dev/2011-August/007607.html create mode 100644 zarb-ml/mageia-dev/2011-August/007608.html create mode 100644 zarb-ml/mageia-dev/2011-August/007609.html create mode 100644 zarb-ml/mageia-dev/2011-August/007610.html create mode 100644 zarb-ml/mageia-dev/2011-August/007611.html create mode 100644 zarb-ml/mageia-dev/2011-August/007612.html create mode 100644 zarb-ml/mageia-dev/2011-August/007613.html create mode 100644 zarb-ml/mageia-dev/2011-August/007614.html create mode 100644 zarb-ml/mageia-dev/2011-August/007615.html create mode 100644 zarb-ml/mageia-dev/2011-August/007616.html create mode 100644 zarb-ml/mageia-dev/2011-August/007617.html create mode 100644 zarb-ml/mageia-dev/2011-August/007618.html create mode 100644 zarb-ml/mageia-dev/2011-August/007619.html create mode 100644 zarb-ml/mageia-dev/2011-August/007620.html create mode 100644 zarb-ml/mageia-dev/2011-August/007621.html create mode 100644 zarb-ml/mageia-dev/2011-August/007622.html create mode 100644 zarb-ml/mageia-dev/2011-August/007623.html create mode 100644 zarb-ml/mageia-dev/2011-August/007624.html create mode 100644 zarb-ml/mageia-dev/2011-August/007625.html create mode 100644 zarb-ml/mageia-dev/2011-August/007626.html create mode 100644 zarb-ml/mageia-dev/2011-August/007627.html create mode 100644 zarb-ml/mageia-dev/2011-August/007628.html create mode 100644 zarb-ml/mageia-dev/2011-August/007629.html create mode 100644 zarb-ml/mageia-dev/2011-August/007630.html create mode 100644 zarb-ml/mageia-dev/2011-August/007631.html create mode 100644 zarb-ml/mageia-dev/2011-August/007632.html create mode 100644 zarb-ml/mageia-dev/2011-August/007633.html create mode 100644 zarb-ml/mageia-dev/2011-August/007634.html create mode 100644 zarb-ml/mageia-dev/2011-August/007635.html create mode 100644 zarb-ml/mageia-dev/2011-August/007636.html create mode 100644 zarb-ml/mageia-dev/2011-August/007637.html create mode 100644 zarb-ml/mageia-dev/2011-August/007638.html create mode 100644 zarb-ml/mageia-dev/2011-August/007639.html create mode 100644 zarb-ml/mageia-dev/2011-August/007640.html create mode 100644 zarb-ml/mageia-dev/2011-August/007641.html create mode 100644 zarb-ml/mageia-dev/2011-August/007642.html create mode 100644 zarb-ml/mageia-dev/2011-August/007643.html create mode 100644 zarb-ml/mageia-dev/2011-August/007644.html create mode 100644 zarb-ml/mageia-dev/2011-August/007645.html create mode 100644 zarb-ml/mageia-dev/2011-August/007646.html create mode 100644 zarb-ml/mageia-dev/2011-August/007647.html create mode 100644 zarb-ml/mageia-dev/2011-August/007648.html create mode 100644 zarb-ml/mageia-dev/2011-August/007649.html create mode 100644 zarb-ml/mageia-dev/2011-August/007650.html create mode 100644 zarb-ml/mageia-dev/2011-August/007651.html create mode 100644 zarb-ml/mageia-dev/2011-August/007652.html create mode 100644 zarb-ml/mageia-dev/2011-August/007653.html create mode 100644 zarb-ml/mageia-dev/2011-August/007654.html create mode 100644 zarb-ml/mageia-dev/2011-August/007655.html create mode 100644 zarb-ml/mageia-dev/2011-August/007656.html create mode 100644 zarb-ml/mageia-dev/2011-August/007657.html create mode 100644 zarb-ml/mageia-dev/2011-August/007658.html create mode 100644 zarb-ml/mageia-dev/2011-August/007659.html create mode 100644 zarb-ml/mageia-dev/2011-August/007660.html create mode 100644 zarb-ml/mageia-dev/2011-August/007661.html create mode 100644 zarb-ml/mageia-dev/2011-August/007662.html create mode 100644 zarb-ml/mageia-dev/2011-August/007663.html create mode 100644 zarb-ml/mageia-dev/2011-August/007664.html create mode 100644 zarb-ml/mageia-dev/2011-August/007665.html create mode 100644 zarb-ml/mageia-dev/2011-August/007666.html create mode 100644 zarb-ml/mageia-dev/2011-August/007667.html create mode 100644 zarb-ml/mageia-dev/2011-August/007668.html create mode 100644 zarb-ml/mageia-dev/2011-August/007669.html create mode 100644 zarb-ml/mageia-dev/2011-August/007670.html create mode 100644 zarb-ml/mageia-dev/2011-August/007671.html create mode 100644 zarb-ml/mageia-dev/2011-August/007672.html create mode 100644 zarb-ml/mageia-dev/2011-August/007673.html create mode 100644 zarb-ml/mageia-dev/2011-August/007674.html create mode 100644 zarb-ml/mageia-dev/2011-August/007675.html create mode 100644 zarb-ml/mageia-dev/2011-August/007676.html create mode 100644 zarb-ml/mageia-dev/2011-August/007677.html create mode 100644 zarb-ml/mageia-dev/2011-August/007678.html create mode 100644 zarb-ml/mageia-dev/2011-August/007679.html create mode 100644 zarb-ml/mageia-dev/2011-August/007680.html create mode 100644 zarb-ml/mageia-dev/2011-August/007681.html create mode 100644 zarb-ml/mageia-dev/2011-August/007682.html create mode 100644 zarb-ml/mageia-dev/2011-August/007683.html create mode 100644 zarb-ml/mageia-dev/2011-August/007684.html create mode 100644 zarb-ml/mageia-dev/2011-August/007685.html create mode 100644 zarb-ml/mageia-dev/2011-August/007686.html create mode 100644 zarb-ml/mageia-dev/2011-August/007687.html create mode 100644 zarb-ml/mageia-dev/2011-August/007688.html create mode 100644 zarb-ml/mageia-dev/2011-August/007689.html create mode 100644 zarb-ml/mageia-dev/2011-August/007690.html create mode 100644 zarb-ml/mageia-dev/2011-August/007691.html create mode 100644 zarb-ml/mageia-dev/2011-August/007692.html create mode 100644 zarb-ml/mageia-dev/2011-August/007693.html create mode 100644 zarb-ml/mageia-dev/2011-August/007694.html create mode 100644 zarb-ml/mageia-dev/2011-August/007695.html create mode 100644 zarb-ml/mageia-dev/2011-August/007696.html create mode 100644 zarb-ml/mageia-dev/2011-August/007697.html create mode 100644 zarb-ml/mageia-dev/2011-August/007698.html create mode 100644 zarb-ml/mageia-dev/2011-August/007699.html create mode 100644 zarb-ml/mageia-dev/2011-August/007700.html create mode 100644 zarb-ml/mageia-dev/2011-August/007701.html create mode 100644 zarb-ml/mageia-dev/2011-August/007702.html create mode 100644 zarb-ml/mageia-dev/2011-August/007703.html create mode 100644 zarb-ml/mageia-dev/2011-August/007704.html create mode 100644 zarb-ml/mageia-dev/2011-August/007705.html create mode 100644 zarb-ml/mageia-dev/2011-August/007706.html create mode 100644 zarb-ml/mageia-dev/2011-August/007707.html create mode 100644 zarb-ml/mageia-dev/2011-August/007708.html create mode 100644 zarb-ml/mageia-dev/2011-August/007709.html create mode 100644 zarb-ml/mageia-dev/2011-August/007710.html create mode 100644 zarb-ml/mageia-dev/2011-August/007711.html create mode 100644 zarb-ml/mageia-dev/2011-August/007712.html create mode 100644 zarb-ml/mageia-dev/2011-August/007713.html create mode 100644 zarb-ml/mageia-dev/2011-August/007714.html create mode 100644 zarb-ml/mageia-dev/2011-August/007715.html create mode 100644 zarb-ml/mageia-dev/2011-August/008112.html create mode 100644 zarb-ml/mageia-dev/2011-August/008113.html create mode 100644 zarb-ml/mageia-dev/2011-August/008114.html create mode 100644 zarb-ml/mageia-dev/2011-August/author.html create mode 100644 zarb-ml/mageia-dev/2011-August/date.html create mode 120000 zarb-ml/mageia-dev/2011-August/index.html create mode 100644 zarb-ml/mageia-dev/2011-August/subject.html create mode 100644 zarb-ml/mageia-dev/2011-August/thread.html (limited to 'zarb-ml/mageia-dev/2011-August') diff --git a/zarb-ml/mageia-dev/2011-August/007144.html b/zarb-ml/mageia-dev/2011-August/007144.html new file mode 100644 index 000000000..206d44d27 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007144.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] Packages with wrong RPM group + + + + + + + + + +

[Mageia-dev] Packages with wrong RPM group

+ Matteo Pasotti + pasotti.matteo at gmail.com +
+ Mon Aug 1 00:25:49 CEST 2011 +

+
+ +
Il 31/07/11 16.58, Samuel Verschelde ha scritto:
+> Le dimanche 31 juillet 2011 16:47:42, Christiaan Welvaart a écrit :
+>> On Sat, 30 Jul 2011, Samuel Verschelde wrote:
+>>> The following packages have RPM groups that are not valid for Mageia
+> packages:
+>> What list of groups did you use? Development/Tools is not listed in
+>> /usr/share/rpmlint/config.d/distribution.exceptions.conf but you didn't
+>> list package(s) with that group.
+>>
+>>
+>>       Christiaan
+> I just reported the packages I noticed, I can have missed some of them :)
+>
+> Samuel
+Thank you Samuel, I'll fix axel as soon as I can.
+
+Matteo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007145.html b/zarb-ml/mageia-dev/2011-August/007145.html new file mode 100644 index 000000000..842b8bd9b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007145.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Thomas Lottmann + skipercooker at gmail.com +
+ Mon Aug 1 11:42:26 CEST 2011 +

+
+ +
Hello,
+
+I should have written this mail much sooner, but finally, I am totally, 
+completely and starting to be hatefully fed up of these tools.
+
+The Mandriva/Mageia tools that manage the network on computers, 
+especially the wireless networks are completely dysfunctional. While the 
+Network Center does not seem to even communicate with the system tools 
+to know what is happening during the link setup, it does not 
+auto-refresh network lists properly.
+
+Since 2010.1 now even mixes up itself in it's own network scripts (the 
+ones stored in wireless.d). This maxes it wrongly detect numerous 
+wireless points (he seen WPA2 Enterperise hotspots as opened or WEP, or 
+more nerving, becomes incapable or storing the right authentication 
+information). A tool that breaks itself is a complete shame!
+
+The GUI is also appalling. Despite it's numerous possibilities, it is a 
+mess and 60% of it cannot be used by something else than the system or a 
+network expert.
+
+The code itself is undocumented and it extremely difficult to read.
+
+These tools are getting really bad and not working properly anyway since 
+a long time now. So either we fix it and improve it (recoding?), either 
+we definitely switch to Network Manager. I am ready to participate if 
+necessary (despite my lack of competence), but I do not want to see 
+these tools 'as is' on my computer anymore, and no longer want to see 
+these issues that down Mageia's reputation in comparison to other 
+popular projects here such as Arch, Fedora or Ubuntu, who do have proper 
+tools delivered by default.
+
+This is not the first time I complain about this tool. We should not 
+leave this unchanged. It is far too annoying and pushing to so much loss 
+of time.
+
+Yours sincerely,.
+
+Thomas.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007146.html b/zarb-ml/mageia-dev/2011-August/007146.html new file mode 100644 index 000000000..f573d81bc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007146.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Mon Aug 1 12:36:47 CEST 2011 +

+
+ +
On Friday, 29 July 2011 20:52:14 Luis Daniel Lucio Quiroz wrote:
+> Helow
+> 
+> Specially tu buchan, in my experince, when trying to making work a Squid
+> with an ugly wik2k8 we realize that the squid helper is not working. 
+
+I had no problems with this in providing one of the two sets of squid proxy 
+servers that had a role in presenting the 2010 FIFA World Cup. (The other set 
+of proxies used Basic authentication against OpenLDAP).
+
+> After doing research we realize that samba has a helper that works
+
+You mean ntlm_auth, which has been in samba-common for years, and works with 
+Squid, Apache and FreeRADIUS ?
+
+> , i was
+> wondering if you can do a subpackage of that helper so the squid may do a
+> suggests to that only.
+
+I need more details ... so far this sounds like a question, not a proposal.
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007147.html b/zarb-ml/mageia-dev/2011-August/007147.html new file mode 100644 index 000000000..aac61c0e1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007147.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Mon Aug 1 13:10:08 CEST 2011 +

+
+ +
2011/8/1 Thomas Lottmann <skipercooker at gmail.com>:
+> Hello,
+>
+> I should have written this mail much sooner, but finally, I am totally,
+> completely and starting to be hatefully fed up of these tools.
+>
+> The Mandriva/Mageia tools that manage the network on computers, especially
+> the wireless networks are completely dysfunctional. While the Network Center
+> does not seem to even communicate with the system tools to know what is
+> happening during the link setup, it does not auto-refresh network lists
+> properly.
+>
+> Since 2010.1 now even mixes up itself in it's own network scripts (the ones
+> stored in wireless.d). This maxes it wrongly detect numerous wireless points
+> (he seen WPA2 Enterperise hotspots as opened or WEP, or more nerving,
+> becomes incapable or storing the right authentication information). A tool
+> that breaks itself is a complete shame!
+>
+> The GUI is also appalling. Despite it's numerous possibilities, it is a mess
+> and 60% of it cannot be used by something else than the system or a network
+> expert.
+>
+> The code itself is undocumented and it extremely difficult to read.
+>
+> These tools are getting really bad and not working properly anyway since a
+> long time now. So either we fix it and improve it (recoding?), either we
+> definitely switch to Network Manager. I am ready to participate if necessary
+> (despite my lack of competence), but I do not want to see these tools 'as
+> is' on my computer anymore, and no longer want to see these issues that down
+> Mageia's reputation in comparison to other popular projects here such as
+> Arch, Fedora or Ubuntu, who do have proper tools delivered by default.
+>
+> This is not the first time I complain about this tool. We should not leave
+> this unchanged. It is far too annoying and pushing to so much loss of time.
+
+While I cannot confirm the problems you are talking about in former
+Mandriva (2010.x) nor in Mageia 1, I do have the problems in Mageia
+Cauldron, mostly caused by (guess what?) - network-manager! I reported
+about this in the forum
+(https://forums.mageia.org/en/viewtopic.php?f=15&t=869).
+Just current case: after an update run in Cauldron my wifi does not
+connect, then connects and disconnects again after a few seconds.
+After trying several measurements like removing the setup-script,
+removing the connection in MCC, etc., all without result, I
+de-installed network-manager and configured wifi again by the draktool
+without NM - it works now.
+
+As you see, my "mileage" varies from yours. :)
+
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007148.html b/zarb-ml/mageia-dev/2011-August/007148.html new file mode 100644 index 000000000..dc34b3686 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007148.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [RPM] cauldron core/release rpmlint-mageia-policy-0.2.9-5.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release rpmlint-mageia-policy-0.2.9-5.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Aug 1 14:03:27 CEST 2011 +

+
+ +
On 1 August 2011 13:59, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> misc <misc> 0.2.9-5.mga2:
+> + Revision: 131149
+> - add exception for filesystem and x11-server-common
+> - add some exception for kppp-provider, asked by mikala on irc
+> - new policy to fix -debug rejection
+> - better filtering for debug package
+> - new release to deploy the fixed config on valstar
+> - simplify the various exception
+> - remove old code that was moved to another file
+> - do not warn for lack of %clean, close #2260
+
+
+As for recent firefox upload, the changelog looks like
+previous releases weren't marked/tagged as such in SVN...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007149.html b/zarb-ml/mageia-dev/2011-August/007149.html new file mode 100644 index 000000000..4d345b6fd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007149.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] [RPM] cauldron core/release rpmlint-mageia-policy-0.2.9-5.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release rpmlint-mageia-policy-0.2.9-5.mga2

+ D.Morgan + dmorganec at gmail.com +
+ Mon Aug 1 14:11:44 CEST 2011 +

+
+ +
On Mon, Aug 1, 2011 at 2:03 PM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 1 August 2011 13:59, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>> misc <misc> 0.2.9-5.mga2:
+>> + Revision: 131149
+>> - add exception for filesystem and x11-server-common
+>> - add some exception for kppp-provider, asked by mikala on irc
+>> - new policy to fix -debug rejection
+>> - better filtering for debug package
+>> - new release to deploy the fixed config on valstar
+>> - simplify the various exception
+>> - remove old code that was moved to another file
+>> - do not warn for lack of %clean, close #2260
+>
+>
+> As for recent firefox upload, the changelog looks like
+> previous releases weren't marked/tagged as such in SVN...
+>
+
+yes seems that we have a pb in youri ( i think this is here )  with
+markrelease since some days.
+
+Does someone can look to this ?  have we changed something regarding
+the configuration ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007150.html b/zarb-ml/mageia-dev/2011-August/007150.html new file mode 100644 index 000000000..4e527c0b2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007150.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 14:12:44 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 13:10:08 Wolfgang Bornath a écrit :
+[....]
+> > This is not the first time I complain about this tool. We should
+> > not leave this unchanged. It is far too annoying and pushing to
+> > so much loss of time.
+> While I cannot confirm the problems you are talking about in former
+> Mandriva (2010.x) nor in Mageia 1, I do have the problems in Mageia
+> Cauldron, mostly caused by (guess what?) - network-manager! I reported
+> about this in the forum
+> (https://forums.mageia.org/en/viewtopic.php?f=15&t=869).
+> Just current case: after an update run in Cauldron my wifi does not
+> connect, then connects and disconnects again after a few seconds.
+> After trying several measurements like removing the setup-script,
+> removing the connection in MCC, etc., all without result, I
+> de-installed network-manager and configured wifi again by the draktool
+> without NM - it works now.
+NetworkManager 0.8997 in cauldron did not have the mdv patch at all 
+because nm 0.9 is different than the 0.7 & 0.8.x branch.
+(Some mails was sent on the mailing list for that if i'm not wrong), so 
+you can expect that nm will conflict & try to start the network while 
+mageia tools (drakx) are trying also which can explain why you were not 
+able to connect at all.
+However blino did  patch yesterday night the ifcfg-rh plugin so at least 
+now nm is able to *ignore* the device managed by  drakx tools so you 
+should not have the same problem now.
+
+-- 
+Balcaen John
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007151.html b/zarb-ml/mageia-dev/2011-August/007151.html new file mode 100644 index 000000000..8ac4132e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007151.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mesa-7.11-0.rc4.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mesa-7.11-0.rc4.1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Aug 1 14:23:15 CEST 2011 +

+
+ +
On 1 August 2011 00:26, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> tv <tv> 7.11-0.rc4.1.mga2:
+> + Revision: 131074
+> - new prerelease
+> - new prerelease
+
+Mesa-7.11 final is out.
+Btw, we could add a tainted build of mesa with OpenGL floating-point
+textures support
+(new in 7.11, disabled by default b/c of some patents).
+WDYT?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007152.html b/zarb-ml/mageia-dev/2011-August/007152.html new file mode 100644 index 000000000..655f92345 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007152.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [RPM] cauldron core/release mesa-7.11-0.rc4.1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release mesa-7.11-0.rc4.1.mga2

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 14:26:58 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 14:23:15 Thierry Vignaud a écrit :
+[...]
+> 
+> Mesa-7.11 final is out.
+> Btw, we could add a tainted build of mesa with OpenGL floating-point
+> textures support
+> (new in 7.11, disabled by default b/c of some patents).
+It could be a good idea.
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007153.html b/zarb-ml/mageia-dev/2011-August/007153.html new file mode 100644 index 000000000..a3e2d5315 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007153.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Sigrid Carrera + sigrid.carrera at googlemail.com +
+ Mon Aug 1 14:35:11 CEST 2011 +

+
+ +
Hi Wolfgang, *, 
+
+On Mon, 1 Aug 2011 13:10:08 +0200
+Wolfgang Bornath <molch.b at googlemail.com> wrote:
+
+> 2011/8/1 Thomas Lottmann <skipercooker at gmail.com>:
+> > Hello,
+> >
+> > I should have written this mail much sooner, but finally, I am totally,
+> > completely and starting to be hatefully fed up of these tools.
+> >
+> > The Mandriva/Mageia tools that manage the network on computers, especially
+> > the wireless networks are completely dysfunctional. While the Network Center
+> > does not seem to even communicate with the system tools to know what is
+> > happening during the link setup, it does not auto-refresh network lists
+> > properly.
+> >
+> > Since 2010.1 now even mixes up itself in it's own network scripts (the ones
+> > stored in wireless.d). This maxes it wrongly detect numerous wireless points
+> > (he seen WPA2 Enterperise hotspots as opened or WEP, or more nerving,
+> > becomes incapable or storing the right authentication information). A tool
+> > that breaks itself is a complete shame!
+
+I agree, I had this happening to me as well. I'm running Mageia 1, the stable distribution, not a Cauldron installation. 
+
+I have already entered a bug report about my problem (see https://bugs.mageia.org/show_bug.cgi?id=1263) and it is annoying. 
+without any reason (at least, not one, that I can see) my wireless connection disconnects and every try to reconnect ends in failure. And if I check then the configuration, the connection is set to either OPEN or WEP instead of WPA2. 
+
+> >
+> > The GUI is also appalling. Despite it's numerous possibilities, it is a mess
+> > and 60% of it cannot be used by something else than the system or a network
+> > expert.
+
+I don't have a specific opinion about the GUI. When it works, it's fine. I am wondering sometimes, what all those options are for, but since now, I've always managed to get a working connection, so this is not a mayor issue for me. 
+
+> >
+> > The code itself is undocumented and it extremely difficult to read.
+> >
+> > These tools are getting really bad and not working properly anyway since a
+> > long time now. So either we fix it and improve it (recoding?), either we
+> > definitely switch to Network Manager. I am ready to participate if necessary
+> > (despite my lack of competence), but I do not want to see these tools 'as
+> > is' on my computer anymore, and no longer want to see these issues that down
+> > Mageia's reputation in comparison to other popular projects here such as
+> > Arch, Fedora or Ubuntu, who do have proper tools delivered by default.
+> >
+> > This is not the first time I complain about this tool. We should not leave
+> > this unchanged. It is far too annoying and pushing to so much loss of time.
+
+I can't say anything about the code, I haven't looked at it. (Not that I understand much about coding). ;) 
+
+> 
+> While I cannot confirm the problems you are talking about in former
+> Mandriva (2010.x) nor in Mageia 1, I do have the problems in Mageia
+> Cauldron, mostly caused by (guess what?) - network-manager! I reported
+> about this in the forum
+> (https://forums.mageia.org/en/viewtopic.php?f=15&t=869).
+> Just current case: after an update run in Cauldron my wifi does not
+> connect, then connects and disconnects again after a few seconds.
+> After trying several measurements like removing the setup-script,
+> removing the connection in MCC, etc., all without result, I
+> de-installed network-manager and configured wifi again by the draktool
+> without NM - it works now.
+> 
+> As you see, my "mileage" varies from yours. :)
+
+Yes, indeed, the experiences vary. But this doesn't mean, that one opinion or experience can be dismissed because you have some different experiences. (Wobo, this is not meant as a comment to you personally, it's more a general comment!) 
+
+Sigrid
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007154.html b/zarb-ml/mageia-dev/2011-August/007154.html new file mode 100644 index 000000000..f91a0170c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007154.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Mon Aug 1 14:50:10 CEST 2011 +

+
+ +
2011/8/1 Sigrid Carrera <sigrid.carrera at googlemail.com>:
+> Hi Wolfgang, *,
+>
+> On Mon, 1 Aug 2011 13:10:08 +0200
+> Wolfgang Bornath <molch.b at googlemail.com> wrote:
+>>
+>> As you see, my "mileage" varies from yours. :)
+>
+> Yes, indeed, the experiences vary. But this doesn't mean, that one opinion or experience can be dismissed because you have some different experiences. (Wobo, this is not meant as a comment to you personally, it's more a general comment!)
+
+That's what I wanted to say with my comment to Thomas' mail. :)
+draknet and the others are not faulty in general, the same as
+network-manager is not the general solution.
+-- 
+wobo
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007155.html b/zarb-ml/mageia-dev/2011-August/007155.html new file mode 100644 index 000000000..e6646c8cf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007155.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] [131153] merge some sub packages + + + + + + + + + +

[Mageia-dev] [131153] merge some sub packages

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 14:50:10 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 14:19:01 root at mageia.org a écrit :
+> Revision: 131153
+> Author:   fwang
+> Date:     2011-08-01 14:19:00 +0200 (Mon, 01 Aug 2011)
+> Log Message:
+> -----------
+> merge some sub packages
+[...]
+
+Why i'm agree to merge the scripts package (well sort of but i can 
+understand) could you please reverse the merge of the 
+amarokcollectionscanner 
+because the purpose of it is to be used *without* amarok for example on 
+another server
+
+have a look @ http://amarok.kde.org/wiki/Batch_Mode .
+
+Also it would be nice to have a *proper* changelog not only merge of 
+subpackage but also which sub package has been merged.
+
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007156.html b/zarb-ml/mageia-dev/2011-August/007156.html new file mode 100644 index 000000000..ec7daeb30 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007156.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Secret Maryo Chronicles + + + + + + + + + +

[Mageia-dev] Secret Maryo Chronicles

+ José Jorge + lists.jjorge at free.fr +
+ Mon Aug 1 15:01:31 CEST 2011 +

+
+ +
hi,
+
+I have started importing the game Secret Maryo Chronicles, which was already in Mandriva:
+http://svnweb.mageia.org/packages/cauldron/smc/
+
+As I am a padawan, I asked it's submit to stormi, which as a good mentor carefully found that it is not in Fedora because they feel it can be sued by Nintendo.
+Still, Debian has accepted it after some content was changed :
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405441
+As of 2010, we can see in their forum that they were still replacing some graphics with less sue-able ones:
+http://www.secretmaryo.org/phpBB3/viewtopic.php?p=18333#p18333
+http://www.secretmaryo.org/phpBB3/viewtopic.php?f=1&t=3495
+
+Now the question :  shall we import this game into Mageia?
+
+Thanks for your attention.
+
+Zézinho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007157.html b/zarb-ml/mageia-dev/2011-August/007157.html new file mode 100644 index 000000000..d13a1873b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007157.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Thomas Lottmann + skipercooker at gmail.com +
+ Mon Aug 1 15:29:36 CEST 2011 +

+
+ +
Le 01/08/2011 14:50, Wolfgang Bornath a écrit :
+> 2011/8/1 Sigrid Carrera<sigrid.carrera at googlemail.com>:
+>> Hi Wolfgang, *,
+>>
+>> On Mon, 1 Aug 2011 13:10:08 +0200
+>> Wolfgang Bornath<molch.b at googlemail.com>  wrote:
+>>> As you see, my "mileage" varies from yours. :)
+>> Yes, indeed, the experiences vary. But this doesn't mean, that one opinion or experience can be dismissed because you have some different experiences. (Wobo, this is not meant as a comment to you personally, it's more a general comment!)
+> That's what I wanted to say with my comment to Thomas' mail. :)
+> draknet and the others are not faulty in general, the same as
+> network-manager is not the general solution.
+I have been encountering repeatedly the same issues since more than 
+three months, and right now it has been happening repeatadly on other 
+laptops with the same issue (Drakxnet not able to understand it's own 
+config files). More weird now, on one of the laptops, he seems to not be 
+able to parse /etc/wpa_supplicant.conf, for absolutely no reason.
+
+I set aside the other issues of the tool (the 'progress message' that is 
+in reality a timeout that gives you an error message while it is still 
+connecting... and other stuff).
+
+The other main issue I see si that Drakxnet is coded in Perl and uses a 
+lot of perl scripts, like the drakxtools. This makes it hard to 
+maintain, and to improve.
+
+If I posted this mail, it is because my experience is seriously downed 
+my this network tool that is absolutely not polished. It works, but you 
+need to understand it's way of working... which is not normal.
+
+I know it works fine for several people. Personally, I am often having 
+issues because it's disconnects on it's own, and no longer sees any 
+networks when it should. Then it has difficulty  reconnecting.
+
+Windows, Fedora and Ubuntu's wireless tools work absolutely smoothly at 
+my school. And now, other people testing Mageia as school are having the 
+same issues I have. This is frustrating and I can assure you these 
+home-made network tools have to be improved and fixed.
+
+If you want to, I can attempt to make a list of the isses and 
+incoherencies I find, although they are not hard to see. But as I 
+mentionned earlier, this is a tool that is hard to maintain, and I 
+cannot learn perl right now. This means someone else who knows pearl and 
+the tool may have to put his hands in it, and he may not have the time for.
+
+If NetworkManager is easier to maintain and works fine, then I think it 
+can be a better solution. Just offering or trying to find solutions, 
+because this tool seriously does not work properly here.
+
+My two cents,
+
+Thomas.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007158.html b/zarb-ml/mageia-dev/2011-August/007158.html new file mode 100644 index 000000000..3f8dcf086 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007158.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Antoine Pitrou + solipsis at pitrou.net +
+ Mon Aug 1 15:34:39 CEST 2011 +

+
+ +
On Mon, 1 Aug 2011 14:50:10 +0200
+Wolfgang Bornath <molch.b at googlemail.com>
+wrote:
+> 2011/8/1 Sigrid Carrera <sigrid.carrera at googlemail.com>:
+> > Hi Wolfgang, *,
+> >
+> > On Mon, 1 Aug 2011 13:10:08 +0200
+> > Wolfgang Bornath <molch.b at googlemail.com> wrote:
+> >>
+> >> As you see, my "mileage" varies from yours. :)
+> >
+> > Yes, indeed, the experiences vary. But this doesn't mean, that one opinion or experience can be dismissed because you have some different experiences. (Wobo, this is not meant as a comment to you personally, it's more a general comment!)
+> 
+> That's what I wanted to say with my comment to Thomas' mail. :)
+> draknet and the others are not faulty in general, the same as
+> network-manager is not the general solution.
+
+I'm not sure what "faulty in general" means, but I have also found the
+network tools to be quite suboptimal, even though I have simple needs.
+For example, it recently had trouble reconnecting (using DHCP) after I
+rebooted my DSL modem.
+
+Regards
+
+Antoine.
+
+
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007159.html b/zarb-ml/mageia-dev/2011-August/007159.html new file mode 100644 index 000000000..a1a353aa4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007159.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Aug 1 15:59:24 CEST 2011 +

+
+ +
On 1 August 2011 15:29, Thomas Lottmann <skipercooker at gmail.com> wrote:
+> The other main issue I see si that Drakxnet is coded in Perl and uses a lot
+> of perl scripts, like the drakxtools. This makes it hard to maintain, and to
+> improve.
+
+That's just your own POV.
+Not the POV of maintainers.
+
+> I know it works fine for several people. Personally, I am often having
+> issues because it's disconnects on it's own,
+
+This has nothing to do with drakconnect that don't handle that.
+If the network disconnected, that's the issue between the routers,
+the network, the kernel, ....
+
+> and no longer sees any networks when it should.
+
+which points to either network issue or kernel driver issue, not drakconnect.
+
+> Then it has difficulty  reconnecting.
+
+Same, reconnecting is the job of dhcp-client, ifplugd and the like.
+Not drakconnect's job.
+
+> Windows, Fedora and Ubuntu's wireless tools work absolutely smoothly at my
+> school. And now, other people testing Mageia as school are having the same
+> issues I have. This is frustrating and I can assure you these home-made
+> network tools have to be improved and fixed.
+
+Well, Fedora tool (really NM) has its own bugs.
+And I'm pretty sure people who've used MS, Apple or whatever OS/tool
+they're used to, have also encountered issues
+
+> If you want to, I can attempt to make a list of the isses and incoherencies
+> I find, although they are not hard to see.
+
+Indeed, please just fill in _several_ bugs (one report per issue)
+against drakx-net
+
+> But as I mentionned earlier, this
+> is a tool that is hard to maintain, and I cannot learn perl right now.
+
+That's just _your_ personnal though, not his maintainer's.
+aka "this is a tool that is hard to maintain" really means "you would not be
+able to maintain it"
+
+> If NetworkManager is easier to maintain and works fine, then I think it can
+> be a better solution. Just offering or trying to find solutions, because
+> this tool seriously does not work properly here.
+
+it has its own flaws too...
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007160.html b/zarb-ml/mageia-dev/2011-August/007160.html new file mode 100644 index 000000000..ac1561246 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007160.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] [131169] + + + + + + + + + +

[Mageia-dev] [131169]

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 16:09:02 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 15:30:59 root at mageia.org a écrit :
+> Revision: 131169
+> Author:   ze
+> Date:     2011-08-01 15:30:58 +0200 (Mon, 01 Aug 2011)
+> Log Message:
+> -----------
+> 
+> - split libraries
+[...]
+>  Provides:	qt4-mobility = %{version}-%{release}
+> -Requires:	%{libname} = %{version}-%{release}
+> +Requires:	%libQtBearer = %{version}
+> +Requires:	%libQtContacts = %{version}
+> +Requires:	%libQtConnectivity = %{version}
+> +Requires:	%libQtFeedback = %{version}
+> +Requires:	%libQtGallery = %{version}
+> +Requires:	%libQtLocation = %{version}
+> +Requires:	%libQtMultimediaKit = %{version}
+> +Requires:	%libQtOrganizer = %{version}
+> +Requires:	%libQtPublishSubscribe = %{version}
+> +Requires:	%libQtSensors = %{version}
+> +Requires:	%libQtServiceFramework = %{version}
+> +Requires:	%libQtSystemInfo = %{version}
+> +Requires:	%libQtVersit = %{version}
+> +Requires:	%libQtVersitOrganizer = %{version}
+[...]
+Do we really need explicite requires here ?
+I hope/guess it should be automatically handled by rpm.
+Also i seed  you start using some qt4 macros we spoke about on irc, did 
+you forget to send a RFC mail regarding thoses qt4 macros ?
+
+Also maybe we could avoid capitalized characters in rpm's name ?
+  lib(64)QtBearer1 should better be lib(64)qtbearer1 .
+
+Regards, 
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007161.html b/zarb-ml/mageia-dev/2011-August/007161.html new file mode 100644 index 000000000..fefbf5140 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007161.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] GNOME3/GDM + + + + + + + + + +

[Mageia-dev] GNOME3/GDM

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Aug 1 16:55:02 CEST 2011 +

+
+ +
I tried GDM and GNOME3 after the latest metacity update for 
+registration, to see if the Alt-F4 mess and other anomalies were gone.  
+The Alt-F4 mess seems to be, but there have been regressions.
+
+GDM now crashes/restarts if you try to log into an LXDE desktop.
+
+GNOME3 now displays the desktop links with missing characters.  The 
+Applications link at the top left doesn't display at all, while for 
+other strings on the desktop (e.g. the dropdown for your username, 
+giving your status and links for system settings, logout, etc.) display 
+with every other character (or sometimes more) blanked out, although the 
+links themselves work if you can guess which one to use.
+
+Anybody confirm ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007162.html b/zarb-ml/mageia-dev/2011-August/007162.html new file mode 100644 index 000000000..86ba80e04 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007162.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] GNOME3/GDM + + + + + + + + + +

[Mageia-dev] GNOME3/GDM

+ Kira + elegant.pegasus at gmail.com +
+ Mon Aug 1 16:59:06 CEST 2011 +

+
+ +
在 Mon, 01 Aug 2011 22:55:02 +0800, Frank Griffin <ftg at roadrunner.com>寫道:
+
+> I tried GDM and GNOME3 after the latest metacity update for  
+> registration, to see if the Alt-F4 mess and other anomalies were gone.   
+> The Alt-F4 mess seems to be, but there have been regressions.
+>
+> GDM now crashes/restarts if you try to log into an LXDE desktop.
+>
+This one is already confirmed.
+
+Currently you could use KDM as substitude...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007163.html b/zarb-ml/mageia-dev/2011-August/007163.html new file mode 100644 index 000000000..8e0e68c3a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007163.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] GNOME3/GDM + + + + + + + + + +

[Mageia-dev] GNOME3/GDM

+ Frank Griffin + ftg at roadrunner.com +
+ Mon Aug 1 17:04:13 CEST 2011 +

+
+ +
On 08/01/2011 10:59 AM, Kira wrote:
+> 在 Mon, 01 Aug 2011 22:55:02 +0800, Frank Griffin <ftg at roadrunner.com>
+> 寫道:
+>
+>> I tried GDM and GNOME3 after the latest metacity update for
+>> registration, to see if the Alt-F4 mess and other anomalies were
+>> gone. The Alt-F4 mess seems to be, but there have been regressions.
+>>
+>> GDM now crashes/restarts if you try to log into an LXDE desktop.
+>>
+> This one is already confirmed.
+>
+> Currently you could use KDM as substitude...
+>
+
+Actually, you can't. I was about to reply to my own post that I switched
+back to KDM as a fallback, but that crashes/restarts as well trying to
+start LXDE.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007164.html b/zarb-ml/mageia-dev/2011-August/007164.html new file mode 100644 index 000000000..fcc0d49cb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007164.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] GNOME3/GDM + + + + + + + + + +

[Mageia-dev] GNOME3/GDM

+ Kira + elegant.pegasus at gmail.com +
+ Mon Aug 1 17:08:56 CEST 2011 +

+
+ +
在 Mon, 01 Aug 2011 23:04:13 +0800, Frank Griffin <ftg at roadrunner.com>寫道:
+
+> On 08/01/2011 10:59 AM, Kira wrote:
+>> 在 Mon, 01 Aug 2011 22:55:02 +0800, Frank Griffin <ftg at roadrunner.com>
+>> 寫道:
+>>
+>>> I tried GDM and GNOME3 after the latest metacity update for
+>>> registration, to see if the Alt-F4 mess and other anomalies were
+>>> gone. The Alt-F4 mess seems to be, but there have been regressions.
+>>>
+>>> GDM now crashes/restarts if you try to log into an LXDE desktop.
+>>>
+>> This one is already confirmed.
+>>
+>> Currently you could use KDM as substitude...
+>>
+>
+> Actually, you can't. I was about to reply to my own post that I switched
+> back to KDM as a fallback, but that crashes/restarts as well trying to
+> start LXDE.
+Last time I read colin's thread was saying KDM works...
+
+Maybe a new issue? What's abnormal in xsession-error?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007165.html b/zarb-ml/mageia-dev/2011-August/007165.html new file mode 100644 index 000000000..a4002c27e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007165.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] GNOME3/GDM + + + + + + + + + +

[Mageia-dev] GNOME3/GDM

+ John Balcaen + mikala at mageia.org +
+ Mon Aug 1 17:13:21 CEST 2011 +

+
+ +
2011/8/1 Kira <elegant.pegasus at gmail.com>:
+> 在 Mon, 01 Aug 2011 23:04:13 +0800, Frank Griffin <ftg at roadrunner.com>寫道:
+>
+>> On 08/01/2011 10:59 AM, Kira wrote:
+>>>
+>>> 在 Mon, 01 Aug 2011 22:55:02 +0800, Frank Griffin <ftg at roadrunner.com>
+>>> 寫道:
+>>>
+>>>> I tried GDM and GNOME3 after the latest metacity update for
+>>>> registration, to see if the Alt-F4 mess and other anomalies were
+>>>> gone. The Alt-F4 mess seems to be, but there have been regressions.
+>>>>
+>>>> GDM now crashes/restarts if you try to log into an LXDE desktop.
+>>>>
+>>> This one is already confirmed.
+>>>
+>>> Currently you could use KDM as substitude...
+>>>
+>>
+>> Actually, you can't. I was about to reply to my own post that I switched
+>> back to KDM as a fallback, but that crashes/restarts as well trying to
+>> start LXDE.
+>
+> Last time I read colin's thread was saying KDM works...
+>
+> Maybe a new issue? What's abnormal in xsession-error?
+>
+nop it seems a problem with lxde itself because it's also failing without dm.
+
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007166.html b/zarb-ml/mageia-dev/2011-August/007166.html new file mode 100644 index 000000000..923f2f75b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007166.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] [131194] new provides, people may miss kopete irc capability + + + + + + + + + +

[Mageia-dev] [131194] new provides, people may miss kopete irc capability

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 17:45:41 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 17:33:06 root at mageia.org a écrit :
+> Revision: 131194
+> Author:   dlucio
+> Date:     2011-08-01 17:33:05 +0200 (Mon, 01 Aug 2011)
+> Log Message:
+> -----------
+> new provides, people may miss kopete irc capability
+[...]
+>  BuildRequires:  ircclient-qt-devel >= 0.3.2
+> +Provides:	kde4-irc-client
+I'm not sure it's wise to add this provided here currently we have for 
+example already konversation & quassel for this.
+>From my point of view we should stick like this.
+(or i can add a provides on quassel-client too :p )
+
+Also please note that in a near future kopete is going to be replaced by 
+telepathy-kde (& we're not going to add a provides kde4-irc-client to 
+telepathy-haze i hope :p )
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007167.html b/zarb-ml/mageia-dev/2011-August/007167.html new file mode 100644 index 000000000..658595ab8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007167.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] GNOME3/GDM + + + + + + + + + +

[Mageia-dev] GNOME3/GDM

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 17:41:02 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 12:13:21 vous avez écrit :
+> 2011/8/1 Kira <elegant.pegasus at gmail.com>:
+> > 在 Mon, 01 Aug 2011 23:04:13 +0800, Frank Griffin <ftg at roadrunner.com>寫
+道:
+> >> On 08/01/2011 10:59 AM, Kira wrote:
+> >>> 在 Mon, 01 Aug 2011 22:55:02 +0800, Frank Griffin
+> >>> <ftg at roadrunner.com>>>> 
+> >>> 寫道:
+> >>>> I tried GDM and GNOME3 after the latest metacity update for
+> >>>> registration, to see if the Alt-F4 mess and other anomalies
+> >>>> were
+> >>>> gone. The Alt-F4 mess seems to be, but there have been
+> >>>> regressions.
+> >>>> 
+> >>>> GDM now crashes/restarts if you try to log into an LXDE
+> >>>> desktop.
+> >>> 
+> >>> This one is already confirmed.
+> >>> 
+> >>> Currently you could use KDM as substitude...
+> >> 
+> >> Actually, you can't. I was about to reply to my own post that I
+> >> switched back to KDM as a fallback, but that crashes/restarts
+> >> as well trying to start LXDE.
+> > 
+> > Last time I read colin's thread was saying KDM works...
+> > 
+> > Maybe a new issue? What's abnormal in xsession-error?
+> 
+> nop it seems a problem with lxde itself because it's also failing
+> without dm.
+There is https://bugs.mageia.org/show_bug.cgi?id=2354
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007168.html b/zarb-ml/mageia-dev/2011-August/007168.html new file mode 100644 index 000000000..e20bc67c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007168.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] [RPM] cauldron core/release rpmlint-mageia-policy-0.2.9-5.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release rpmlint-mageia-policy-0.2.9-5.mga2

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Mon Aug 1 18:21:41 CEST 2011 +

+
+ +
2011/8/1 D.Morgan <dmorganec at gmail.com>
+
+> On Mon, Aug 1, 2011 at 2:03 PM, Thierry Vignaud
+> <thierry.vignaud at gmail.com> wrote:
+> > On 1 August 2011 13:59, Mageia Team <buildsystem-daemon at mageia.org>
+> wrote:
+> >> misc <misc> 0.2.9-5.mga2:
+> >> + Revision: 131149
+> >> - add exception for filesystem and x11-server-common
+> >> - add some exception for kppp-provider, asked by mikala on irc
+> >> - new policy to fix -debug rejection
+> >> - better filtering for debug package
+> >> - new release to deploy the fixed config on valstar
+> >> - simplify the various exception
+> >> - remove old code that was moved to another file
+> >> - do not warn for lack of %clean, close #2260
+> >
+> >
+> > As for recent firefox upload, the changelog looks like
+> > previous releases weren't marked/tagged as such in SVN...
+> >
+>
+> yes seems that we have a pb in youri ( i think this is here )  with
+> markrelease since some days.
+>
+
+I've filed a bug about it:
+https://bugs.mageia.org/show_bug.cgi?id=2337
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110801/dabafa35/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007169.html b/zarb-ml/mageia-dev/2011-August/007169.html new file mode 100644 index 000000000..b5868f9cd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007169.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Aug 1 20:21:21 CEST 2011 +

+
+ +
Op maandag 01 augustus 2011 11:42:26 schreef Thomas Lottmann:
+> Hello,
+> 
+> I should have written this mail much sooner, but finally, I am totally,
+> completely and starting to be hatefully fed up of these tools.
+> 
+> The Mandriva/Mageia tools that manage the network on computers,
+> especially the wireless networks are completely dysfunctional. While the
+> Network Center does not seem to even communicate with the system tools
+> to know what is happening during the link setup, it does not
+> auto-refresh network lists properly.
+> 
+> Since 2010.1 now even mixes up itself in it's own network scripts (the
+> ones stored in wireless.d). This maxes it wrongly detect numerous
+> wireless points (he seen WPA2 Enterperise hotspots as opened or WEP, or
+> more nerving, becomes incapable or storing the right authentication
+> information). A tool that breaks itself is a complete shame!
+> 
+> The GUI is also appalling. Despite it's numerous possibilities, it is a
+> mess and 60% of it cannot be used by something else than the system or a
+> network expert.
+> 
+> The code itself is undocumented and it extremely difficult to read.
+> 
+> These tools are getting really bad and not working properly anyway since
+> a long time now. So either we fix it and improve it (recoding?), either
+> we definitely switch to Network Manager. I am ready to participate if
+> necessary (despite my lack of competence), but I do not want to see
+> these tools 'as is' on my computer anymore, and no longer want to see
+> these issues that down Mageia's reputation in comparison to other
+> popular projects here such as Arch, Fedora or Ubuntu, who do have proper
+> tools delivered by default.
+> 
+> This is not the first time I complain about this tool. We should not
+> leave this unchanged. It is far too annoying and pushing to so much loss
+> of time.
+> 
+> Yours sincerely,.
+> 
+> Thomas.
+
+
+personally, alot of problems could likely be attributed to using all those 
+several of those apps together.
+
+imho, the network tools should be redesigned a bit, according to good 
+usability, but mostly, either they should all be nicely integrated which each 
+other, or we should just have one that does all nicely.
+
+personally, i find the netapplet the best working and use that exclusively to 
+avoid issues.
+
+but sadly, even netapplet is far from complete.
+
+as some kind of start, we should have an app that exists in drakconf, but also 
+accessible via an applet, but again, perhaps we should have multiple applets, 
+with one for each connection.
+
+eg: a wifi access link, 2 network connections (one of which goes to internet), 
+and 3 openvpn tunnels (as an example) it would even be better, if bluetooth 
+networking could also be included. (this would also allow for multiple 
+internet connections at a later time with some advanced routing)
+
+at the same time, people could tell at a glance if they accidentally use more 
+than one internet access method.
+
+about openvpn, some of those are user-related (even though they have effects on 
+global routing), especially password related things, personally, i think it'd 
+be better if these can only be controlled through the applet by the user it's 
+from (with perhaps an option to allow any user to control this too)
+
+again with openvpn, it would be usefull if there was some kind of way to know 
+it's not only running, but also if it's essentially active or not, and if it's 
+used as a internet gateway.
+
+These are some things which i have noticed over the years of using it and 
+listening to end-user problems.
+
+
+perhaps the above can be used as a starting point for a usability scheme.
+
+Thomas, since you feel this strongly, are you willing to spend some time on 
+this?
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007170.html b/zarb-ml/mageia-dev/2011-August/007170.html new file mode 100644 index 000000000..be7eadcc0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007170.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] RaLink 3062 WiFi card + + + + + + + + + +

[Mageia-dev] RaLink 3062 WiFi card

+ Christiaan Welvaart + cjw at daneel.dyndns.org +
+ Mon Aug 1 20:38:20 CEST 2011 +

+
+ +
hi,
+
+It turns out that support for this chip (see subject) is disabled in 
+mageia kernels:
+
+# CONFIG_RT2800PCI_RT33XX is not set
+# CONFIG_RT2800PCI_RT35XX is not set
+
+Similar options for the rt2800 USB driver are also not enabled.
+
+
+     Christiaan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007171.html b/zarb-ml/mageia-dev/2011-August/007171.html new file mode 100644 index 000000000..64d5f02a9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007171.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ D.Morgan + dmorganec at gmail.com +
+ Mon Aug 1 21:04:33 CEST 2011 +

+
+ +
On Mon, Aug 1, 2011 at 8:21 PM, Maarten Vanraes
+<maarten.vanraes at gmail.com> wrote:
+> Op maandag 01 augustus 2011 11:42:26 schreef Thomas Lottmann:
+>> Hello,
+>>
+>> I should have written this mail much sooner, but finally, I am totally,
+>> completely and starting to be hatefully fed up of these tools.
+>>
+>> The Mandriva/Mageia tools that manage the network on computers,
+>> especially the wireless networks are completely dysfunctional. While the
+>> Network Center does not seem to even communicate with the system tools
+>> to know what is happening during the link setup, it does not
+>> auto-refresh network lists properly.
+>>
+>> Since 2010.1 now even mixes up itself in it's own network scripts (the
+>> ones stored in wireless.d). This maxes it wrongly detect numerous
+>> wireless points (he seen WPA2 Enterperise hotspots as opened or WEP, or
+>> more nerving, becomes incapable or storing the right authentication
+>> information). A tool that breaks itself is a complete shame!
+>>
+>> The GUI is also appalling. Despite it's numerous possibilities, it is a
+>> mess and 60% of it cannot be used by something else than the system or a
+>> network expert.
+>>
+>> The code itself is undocumented and it extremely difficult to read.
+>>
+>> These tools are getting really bad and not working properly anyway since
+>> a long time now. So either we fix it and improve it (recoding?), either
+>> we definitely switch to Network Manager. I am ready to participate if
+>> necessary (despite my lack of competence), but I do not want to see
+>> these tools 'as is' on my computer anymore, and no longer want to see
+>> these issues that down Mageia's reputation in comparison to other
+>> popular projects here such as Arch, Fedora or Ubuntu, who do have proper
+>> tools delivered by default.
+>>
+>> This is not the first time I complain about this tool. We should not
+>> leave this unchanged. It is far too annoying and pushing to so much loss
+>> of time.
+>>
+>> Yours sincerely,.
+>>
+>> Thomas.
+>
+>
+> personally, alot of problems could likely be attributed to using all those
+> several of those apps together.
+>
+> imho, the network tools should be redesigned a bit, according to good
+> usability, but mostly, either they should all be nicely integrated which each
+> other, or we should just have one that does all nicely.
+>
+> personally, i find the netapplet the best working and use that exclusively to
+> avoid issues.
+>
+> but sadly, even netapplet is far from complete.
+>
+> as some kind of start, we should have an app that exists in drakconf, but also
+> accessible via an applet, but again, perhaps we should have multiple applets,
+> with one for each connection.
+>
+> eg: a wifi access link, 2 network connections (one of which goes to internet),
+> and 3 openvpn tunnels (as an example) it would even be better, if bluetooth
+> networking could also be included. (this would also allow for multiple
+> internet connections at a later time with some advanced routing)
+>
+> at the same time, people could tell at a glance if they accidentally use more
+> than one internet access method.
+>
+> about openvpn, some of those are user-related (even though they have effects on
+> global routing), especially password related things, personally, i think it'd
+> be better if these can only be controlled through the applet by the user it's
+> from (with perhaps an option to allow any user to control this too)
+>
+> again with openvpn, it would be usefull if there was some kind of way to know
+> it's not only running, but also if it's essentially active or not, and if it's
+> used as a internet gateway.
+>
+> These are some things which i have noticed over the years of using it and
+> listening to end-user problems.
+>
+>
+> perhaps the above can be used as a starting point for a usability scheme.
+>
+> Thomas, since you feel this strongly, are you willing to spend some time on
+> this?
+>
+
+AFAIK this is not on mageia 2 specs, maybe you should not ask ppl if
+they have time to work on things not on specs, and try to focus on
+specs.
+We have a lot to do already don't you think ?
+
+Maybe it could be nice to improve net_applet instead of doing "yet an
+other software for network".
+I used some other distro for years and now i use mageia. Honnestly i
+miss nothing ( from a normal user POV )
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007172.html b/zarb-ml/mageia-dev/2011-August/007172.html new file mode 100644 index 000000000..131416ac2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007172.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [131194] new provides, people may miss kopete irc capability + + + + + + + + + +

[Mageia-dev] [131194] new provides, people may miss kopete irc capability

+ Angelo Naselli + anaselli at linux.it +
+ Mon Aug 1 22:28:29 CEST 2011 +

+
+ +
In data lunedì 1 agosto 2011 17:45:41, Balcaen John ha scritto:
+> Le Lundi 1 Août 2011 17:33:06 root at mageia.org a écrit :
+> > Revision: 131194
+> > Author:   dlucio
+> > Date:     2011-08-01 17:33:05 +0200 (Mon, 01 Aug 2011)
+> > Log Message:
+> > -----------
+> > new provides, people may miss kopete irc capability
+\o/ irc in kopete is one o the thing i missed with kde4 :D
+I will check it asap
+> 
+> [...]
+> 
+> >  BuildRequires:  ircclient-qt-devel >= 0.3.2
+> > 
+> > +Provides:	kde4-irc-client
+> 
+> I'm not sure it's wise to add this provided here currently we have for
+> example already konversation & quassel for this.
+> 
+> >From my point of view we should stick like this.
+> 
+> (or i can add a provides on quassel-client too :p )
+> 
+> Also please note that in a near future kopete is going to be replaced by
+> telepathy-kde (& we're not going to add a provides kde4-irc-client to
+> telepathy-haze i hope :p )
+Well i don't know what the future is going to take me, but sure what made me 
+using kopete in past was that i could use one single application for a lot of 
+client ;)
+
+Cheers,
+
+-- 
+	Angelo
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 198 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20110801/bd40fd1c/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007173.html b/zarb-ml/mageia-dev/2011-August/007173.html new file mode 100644 index 000000000..c34ce01b1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007173.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] [131194] new provides, people may miss kopete irc capability + + + + + + + + + +

[Mageia-dev] [131194] new provides, people may miss kopete irc capability

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 22:31:13 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 22:28:29 Angelo Naselli a écrit :
+[...]
+> 
+> Well i don't know what the future is going to take me, but sure what
+> made me using kopete in past was that i could use one single
+> application for a lot of client ;)
+You can do the same with telepathy-kde ;o)
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007174.html b/zarb-ml/mageia-dev/2011-August/007174.html new file mode 100644 index 000000000..d37be1529 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007174.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Mon Aug 1 22:34:55 CEST 2011 +

+
+ +
Le Lundi 01 Août 2011 12:36:47 Buchan Milne a écrit :
+> On Friday, 29 July 2011 20:52:14 Luis Daniel Lucio Quiroz wrote:
+> > Helow
+> > 
+> > Specially tu buchan, in my experince, when trying to making work a Squid
+> > with an ugly wik2k8 we realize that the squid helper is not working.
+> 
+> I had no problems with this in providing one of the two sets of squid proxy
+> servers that had a role in presenting the 2010 FIFA World Cup. (The other
+> set of proxies used Basic authentication against OpenLDAP).
+> 
+> > After doing research we realize that samba has a helper that works
+> 
+> You mean ntlm_auth, which has been in samba-common for years, and works with
+> Squid, Apache and FreeRADIUS ?
+> 
+> > , i was
+> > wondering if you can do a subpackage of that helper so the squid may do
+> > a
+> > suggests to that only.
+> 
+> I need more details ... so far this sounds like a question, not a proposal.
+> 
+> Regards,
+> Buchan
+
+Yes, itis a prposal
+
+if you can add a subpackage like
+
+samba-helpers inwher eyou place tthe ntlm_auth and others from samba
+and i then do a suggest from squid to ask for them
+
+
+LD
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007175.html b/zarb-ml/mageia-dev/2011-August/007175.html new file mode 100644 index 000000000..1d22a3962 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007175.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Aug 1 22:34:31 CEST 2011 +

+
+ +
Op maandag 01 augustus 2011 21:04:33 schreef D.Morgan:
+> On Mon, Aug 1, 2011 at 8:21 PM, Maarten Vanraes
+[...]
+> > Thomas, since you feel this strongly, are you willing to spend some time
+> > on this?
+> 
+> AFAIK this is not on mageia 2 specs, maybe you should not ask ppl if
+> they have time to work on things not on specs, and try to focus on
+> specs.
+> We have a lot to do already don't you think ?
+> 
+> Maybe it could be nice to improve net_applet instead of doing "yet an
+> other software for network".
+> I used some other distro for years and now i use mageia. Honnestly i
+> miss nothing ( from a normal user POV )
+
+Ah well, i guess i wasn't really clear, i do not mean make another one, i 
+meant adapting one to fit the usability stuff.
+
+Also, i thought this was on for mageia 2, but i was mistaken, only installer 
+redesign was listed on the features to be done.
+
+it's true that maybe i shouldn't ask people to work on it, but if they aren't 
+doing anything else, nothing prevents them from making it, besides, if a real 
+usability study is done, this takes ages to complete, and then it could be 
+ready for mageia 3.
+
+oh and it's not because everything can be done, that there isn't a perhaps 
+more suitable way.
+
+In any case, i myself don't have the time to work on this one, but i still 
+listed some stuff that IMHO can be done better.
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007176.html b/zarb-ml/mageia-dev/2011-August/007176.html new file mode 100644 index 000000000..e3d8bf7a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007176.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [131194] new provides, people may miss kopete irc capability + + + + + + + + + +

[Mageia-dev] [131194] new provides, people may miss kopete irc capability

+ Angelo Naselli + anaselli at linux.it +
+ Mon Aug 1 22:54:59 CEST 2011 +

+
+ +
In data lunedì 1 agosto 2011 22:31:13, Balcaen John ha scritto:
+> Le Lundi 1 Août 2011 22:28:29 Angelo Naselli a écrit :
+> [...]
+> 
+> > Well i don't know what the future is going to take me, but sure what
+> > made me using kopete in past was that i could use one single
+> > application for a lot of client ;)
+> 
+> You can do the same with telepathy-kde ;o)
+I read their blog... will see if it meets my expectation.... maybe :p
+
+-- 
+	Angelo
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 198 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20110801/a88adc6e/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007177.html b/zarb-ml/mageia-dev/2011-August/007177.html new file mode 100644 index 000000000..9c15a0a89 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007177.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] [RPM] cauldron core/release x11-server-1.10.3.901-1.mga2 ( Missing signature) + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release x11-server-1.10.3.901-1.mga2 ( Missing signature)

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 1 23:26:07 CEST 2011 +

+
+ +
Le Lundi 1 Août 2011 20:21:45 Mageia Team a écrit :
+> Name        : x11-server                   Relocations: (not
+> relocatable) Version     : 1.10.3.901                        Vendor:
+[...]
+> 
+> tv <tv> 1.10.3.901-1.mga2:
+> + Revision: 131064
+> - 1.10.4 RC1
+
+x11-server-common-1.10.3.901-1.mga2.x86_64.rpm is not signed.
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007178.html b/zarb-ml/mageia-dev/2011-August/007178.html new file mode 100644 index 000000000..bfb842221 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007178.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] [131194] new provides, people may miss kopete irc capability + + + + + + + + + +

[Mageia-dev] [131194] new provides, people may miss kopete irc capability

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Tue Aug 2 00:01:23 CEST 2011 +

+
+ +
Le Lundi 01 Août 2011 12:45:41 Balcaen John a écrit :
+> Le Lundi 1 Août 2011 17:33:06 root at mageia.org a écrit :
+> > Revision: 131194
+> > Author:   dlucio
+> > Date:     2011-08-01 17:33:05 +0200 (Mon, 01 Aug 2011)
+> > Log Message:
+> > -----------
+> > new provides, people may miss kopete irc capability
+> 
+> [...]
+> 
+> >  BuildRequires:  ircclient-qt-devel >= 0.3.2
+> > 
+> > +Provides:	kde4-irc-client
+> 
+> I'm not sure it's wise to add this provided here currently we have for
+> example already konversation & quassel for this.
+> From my point of view we should stick like this.
+> (or i can add a provides on quassel-client too :p )
+> 
+> Also please note that in a near future kopete is going to be replaced by
+> telepathy-kde (& we're not going to add a provides kde4-irc-client to
+> telepathy-haze i hope :p )
+> 
+> Regards,
+
+When télépathy is ready we can drop all the irc programs jeje
+
+Well it is another option, i've been using it since 1 year without problem and 
+I'm sure that many kde3 people that jump to kde4 are missing this capability 
+from kopete
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007179.html b/zarb-ml/mageia-dev/2011-August/007179.html new file mode 100644 index 000000000..e633e2f1e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007179.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] [131194] new provides, people may miss kopete irc capability + + + + + + + + + +

[Mageia-dev] [131194] new provides, people may miss kopete irc capability

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Tue Aug 2 00:04:28 CEST 2011 +

+
+ +
Le Lundi 01 Août 2011 17:31:13 Balcaen John a écrit :
+> Le Lundi 1 Août 2011 22:28:29 Angelo Naselli a écrit :
+> [...]
+> 
+> > Well i don't know what the future is going to take me, but sure what
+> > made me using kopete in past was that i could use one single
+> > application for a lot of client ;)
+> 
+> You can do the same with telepathy-kde ;o)
+
+Mikala, whendo you think télépaty will be ready
+
+is kopete telepathy aware or we shall wailt until kde4.8?
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007180.html b/zarb-ml/mageia-dev/2011-August/007180.html new file mode 100644 index 000000000..7f47bb556 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007180.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Upcoming German Linux Event in August + + + + + + + + + +

[Mageia-dev] Upcoming German Linux Event in August

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Tue Aug 2 09:03:06 CEST 2011 +

+
+ +
Hi there,
+
+Am Donnerstag, 14. Juli 2011, 19:39:00 schrieben Sie:
+> on August, 20th and 21st the FrOSCon ( Free and Open Source Software
+> Conference http://www.froscon.org/ ) will take place at the campus of
+> the University of Applied Sciences Bonn-Rhein-Sieg.
+> Mageia will share a booth there with mandrivauser.de community.
+> We will have a project room of our own in which at least four
+> conferences will take place. Also it is possible to stay over night in
+> the project room (provided you bring a sleeping bag).
+> We welcome any visitors from opur neighbour countries (after all, Bonn
+> isn't all that far from the French, Dutch and Belgish border).
+> 
+> An information page about the planing status (in German) can be found
+> here: http://www.mandrivauser.de/doku/doku.php?id=veranstaltungen
+> 
+this is just a reminder for anybody who might be interested.
+We only have about 3 weeks left till FrOSCon, so if you'd like to come, now 
+would be the best time for traveling preparations :)
+
+See you,
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007181.html b/zarb-ml/mageia-dev/2011-August/007181.html new file mode 100644 index 000000000..1e06e3a56 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007181.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] installer stage2 now uses perl-5.14 + + + + + + + + + +

[Mageia-dev] installer stage2 now uses perl-5.14

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 2 09:27:33 CEST 2011 +

+
+ +
Hi
+
+The installer stage2 now uses perl-5.14 instead of perl-5.12 as in Mga1.
+It looks like it works OK.
+Please report any regression.
+(For the record, we did have regressions when we switched from perl-5.10
+to perl-5.12 such as bugs #29 & #39)
+
+See you
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007182.html b/zarb-ml/mageia-dev/2011-August/007182.html new file mode 100644 index 000000000..a55eba31b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007182.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Need mentor(s) to become a Mageia packager + + + + + + + + + +

[Mageia-dev] Need mentor(s) to become a Mageia packager

+ Samuel Verschelde + stormi at laposte.net +
+ Tue Aug 2 10:14:42 CEST 2011 +

+
+ +
Le samedi 30 juillet 2011 20:27:01, D.Morgan a écrit :
+> On Sat, Jul 30, 2011 at 7:15 PM, Samuel Verschelde <stormi at laposte.net> 
+wrote:
+> > Le jeudi 30 juin 2011 22:32:45, Vincent a écrit :
+> >> Hi All,
+> >> 
+> >> I would like to participate to your project and to help you by packaging
+> >> rpms.
+> >> 
+> >> As I don't know what needs to be packed, I've tried to make rpm for
+> >> ZoneMinder 1.24.4. But it fails to install into BUILDROOT environment. I
+> >> must have done something wrong while setting installation destinations.
+> >> 
+> >> Attached is the spec file, and the patch to make it compiled.
+> >> 
+> >> If any mentor could help me, or assign me something else to pack, I
+> >> would be glad.
+> >> 
+> >> Regards
+> >> 
+> >> 
+> >> Vincent
+> > 
+> > Vincent has been waiting for a mentor for 1 month, which is a long time
+> > for someone who kindly offers to help. I know that every mentor already
+> > has several apprentices, but could someone add one to his list ?
+> > 
+> > Thanks in advance.
+> > 
+> > Best regards
+> > 
+> > Samuel Verschelde
+> 
+> i have not a lot of time but i can take a last apprentice.
+
+I didn't andre999 had contacted directly several packagers to ask them if they 
+were OK to mentor someone, and so Vincent has finally found a mentor : 
+steletch.
+
+First time ever that we have several mentors for an apprentice, nice :)
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007183.html b/zarb-ml/mageia-dev/2011-August/007183.html new file mode 100644 index 000000000..119f52ddf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007183.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Need mentor(s) to become a Mageia packager + + + + + + + + + +

[Mageia-dev] Need mentor(s) to become a Mageia packager

+ D.Morgan + dmorganec at gmail.com +
+ Tue Aug 2 10:20:49 CEST 2011 +

+
+ +
On Tue, Aug 2, 2011 at 10:14 AM, Samuel Verschelde <stormi at laposte.net> wrote:
+> Le samedi 30 juillet 2011 20:27:01, D.Morgan a écrit :
+>> On Sat, Jul 30, 2011 at 7:15 PM, Samuel Verschelde <stormi at laposte.net>
+> wrote:
+>> > Le jeudi 30 juin 2011 22:32:45, Vincent a écrit :
+>> >> Hi All,
+>> >>
+>> >> I would like to participate to your project and to help you by packaging
+>> >> rpms.
+>> >>
+>> >> As I don't know what needs to be packed, I've tried to make rpm for
+>> >> ZoneMinder 1.24.4. But it fails to install into BUILDROOT environment. I
+>> >> must have done something wrong while setting installation destinations.
+>> >>
+>> >> Attached is the spec file, and the patch to make it compiled.
+>> >>
+>> >> If any mentor could help me, or assign me something else to pack, I
+>> >> would be glad.
+>> >>
+>> >> Regards
+>> >>
+>> >>
+>> >> Vincent
+>> >
+>> > Vincent has been waiting for a mentor for 1 month, which is a long time
+>> > for someone who kindly offers to help. I know that every mentor already
+>> > has several apprentices, but could someone add one to his list ?
+>> >
+>> > Thanks in advance.
+>> >
+>> > Best regards
+>> >
+>> > Samuel Verschelde
+>>
+>> i have not a lot of time but i can take a last apprentice.
+>
+> I didn't andre999 had contacted directly several packagers to ask them if they
+> were OK to mentor someone, and so Vincent has finally found a mentor :
+> steletch.
+>
+> First time ever that we have several mentors for an apprentice, nice :)
+>
+> Samuel
+>
+
+oh ok :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007184.html b/zarb-ml/mageia-dev/2011-August/007184.html new file mode 100644 index 000000000..9caed0c91 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007184.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Thomas Lottmann + skipercooker at gmail.com +
+ Tue Aug 2 10:56:55 CEST 2011 +

+
+ +
You are right in several points, but... :-)
+
+Le 01/08/2011 15:59, Thierry Vignaud a écrit :
+> On 1 August 2011 15:29, Thomas Lottmann<skipercooker at gmail.com>  wrote:
+>> The other main issue I see si that Drakxnet is coded in Perl and uses a lot
+>> of perl scripts, like the drakxtools. This makes it hard to maintain, and to
+>> improve.
+> That's just your own POV.
+> Not the POV of maintainers.
+
+Are there other maintainers for this tool than it's creators or 
+long-time maintainers? This is not only my POV, but also what I have 
+heard from a variety of people since the time I participate a little. 
+Anyway...
+
+>> I know it works fine for several people. Personally, I am often having
+>> issues because it's disconnects on it's own,
+> This has nothing to do with drakconnect that don't handle that.
+> If the network disconnected, that's the issue between the routers,
+> the network, the kernel, ....
+> and no longer sees any networks when it should.
+> which points to either network issue or kernel driver issue, not drakconnect.
+
+Other people not using Mageia do not get as often disconnected as me 
+when using public hotspots. Mageia wireless tools seem to have more 
+difficulty to connect and keep the connections to hotspots that have a 
+low (not bad, low) quality signal, while Windows keeps connected, or, 
+quickly reconnects automatically.
+
+Meanwhile, I have to reconnect manually and, more frustrating, it seems 
+the wireless utility sometime attempts to reconnect automatically, but I 
+can't clearly know.
+
+The other bizarre thing I often see is when the hotspots he sees fall 
+from 35 to 0 (or 1, the hotspot he's tryign to connect). This is not 
+normal, I have not observed this NM, Windows or Mac OS X tools.
+
+>
+>> Then it has difficulty  reconnecting.
+> Same, reconnecting is the job of dhcp-client, ifplugd and the like.
+> Not drakconnect's job.
+
+I can't tell. I can only observe and I do not invent what I describe 
+(and have already described in the past). :-)
+
+>> Windows, Fedora and Ubuntu's wireless tools work absolutely smoothly at my
+>> school. And now, other people testing Mageia as school are having the same
+>> issues I have. This is frustrating and I can assure you these home-made
+>> network tools have to be improved and fixed.
+> Well, Fedora tool (really NM) has its own bugs.
+True.
+> And I'm pretty sure people who've used MS, Apple or whatever OS/tool
+> they're used to, have also encountered issues
+True. But these issues are less evident to find apparently, and do not 
+affect that much user experience.
+
+When a user wants to connect to a wireless hotspot, he should just click 
+connect, enter his IDs and it should work fluently. If it is often the 
+case with Mageia tools with a personal hotspot and when you're next to 
+it, it is not always the case when you use it everyday, and, sadly, 
+other tools do better and have a more stable and smooth wireless  
+connectivity, even if they also encournter issues. Their issues are not 
+that much affecting user experience like the ones I have described.
+>> If you want to, I can attempt to make a list of the isses and incoherencies
+>> I find, although they are not hard to see.
+> Indeed, please just fill in _several_ bugs (one report per issue)
+> against drakx-net
+
+I will do one report for each issue I find in drakxnet, with as much 
+details as possible, yes. I shall also do a video capture of the issue 
+if it can help. this will take me a lot of time, but I will do it.
+
+>> But as I mentionned earlier, this
+>> is a tool that is hard to maintain, and I cannot learn perl right now.
+> That's just _your_ personnal though, not his maintainer's.
+> aka "this is a tool that is hard to maintain" really means "you would not be
+> able to maintain it"
+Right.
+>> If NetworkManager is easier to maintain and works fine, then I think it can
+>> be a better solution. Just offering or trying to find solutions, because
+>> this tool seriously does not work properly here.
+> it has its own flaws too...
+Yes, but it does not confuses itself with it's own configuration files. 
+Clearly, all programs can have flaws, but sincerely, it is not working 
+well in Mageia and is not pleasant to use. Otherwise I would not report 
+again about it. ;-)
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007185.html b/zarb-ml/mageia-dev/2011-August/007185.html new file mode 100644 index 000000000..100b81797 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007185.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [RPM] cauldron core/release x11-server-1.10.3.901-1.mga2 ( Missing signature) + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release x11-server-1.10.3.901-1.mga2 ( Missing signature)

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Aug 2 15:14:20 CEST 2011 +

+
+ +
On Mon, 01 Aug 2011, Balcaen John wrote:
+
+> Le Lundi 1 Août 2011 20:21:45 Mageia Team a écrit :
+> > Name        : x11-server                   Relocations: (not
+> > relocatable) Version     : 1.10.3.901                        Vendor:
+> [...]
+> > 
+> > tv <tv> 1.10.3.901-1.mga2:
+> > + Revision: 131064
+> > - 1.10.4 RC1
+> 
+> x11-server-common-1.10.3.901-1.mga2.x86_64.rpm is not signed.
+
+It is now signed.
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007186.html b/zarb-ml/mageia-dev/2011-August/007186.html new file mode 100644 index 000000000..afa8ca40a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007186.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Not here until September 4th + + + + + + + + + +

[Mageia-dev] Not here until September 4th

+ philippe makowski + makowski.mageia at gmail.com +
+ Tue Aug 2 15:18:12 CEST 2011 +

+
+ +
Hi all,
+
+I will be without Internet from August 20 to September 4
+and too busy on other stuff from today to August 20
+so roughly don't count me in before September 5
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007187.html b/zarb-ml/mageia-dev/2011-August/007187.html new file mode 100644 index 000000000..1e35eb88b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007187.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Tue Aug 2 17:04:41 CEST 2011 +

+
+ +
On Monday, 1 August 2011 22:34:55 Luis Daniel Lucio Quiroz wrote:
+> Le Lundi 01 Août 2011 12:36:47 Buchan Milne a écrit :
+> > On Friday, 29 July 2011 20:52:14 Luis Daniel Lucio Quiroz wrote:
+> > > Helow
+> > > 
+> > > Specially tu buchan, in my experince, when trying to making work a
+> > > Squid with an ugly wik2k8 we realize that the squid helper is not
+> > > working.
+> > 
+> > I had no problems with this in providing one of the two sets of squid
+> > proxy servers that had a role in presenting the 2010 FIFA World Cup.
+> > (The other set of proxies used Basic authentication against OpenLDAP).
+> > 
+> > > After doing research we realize that samba has a helper that works
+> > 
+> > You mean ntlm_auth, which has been in samba-common for years, and works
+> > with Squid, Apache and FreeRADIUS ?
+> > 
+> > > , i was
+> > > wondering if you can do a subpackage of that helper so the squid may do
+> > > a
+> > > suggests to that only.
+> > 
+> > I need more details ... so far this sounds like a question, not a
+> > proposal.
+> > 
+> > Regards,
+> > Buchan
+> 
+> Yes, itis a prposal
+> 
+> if you can add a subpackage like
+> 
+> samba-helpers inwher eyou place tthe ntlm_auth and others from samba
+> and i then do a suggest from squid to ask for them
+
+Samba-common is the right package for this. I see no need to have a squid-
+specific subpackage (and then samba-apache, samba-freeradius, with the same 
+content, or all virtual packages just pulling samba-common).
+
+Feel free to mess up your squid package by adding suggests on samba-common, 
+but since installing the right package is trivially solved by the admin and is 
+a small portion of the work required, I would personally prefer not to 
+increase the default footprint of any installation that pulls in squid.
+
+Regards,
+Buchan
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007188.html b/zarb-ml/mageia-dev/2011-August/007188.html new file mode 100644 index 000000000..14191907d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007188.html @@ -0,0 +1,158 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Marcello Anni + marcello.anni at alice.it +
+ Tue Aug 2 17:21:09 CEST 2011 +

+
+ +
> You are right in several points, but... :-)
+> 
+> Le 01/08/2011 15:59, Thierry Vignaud a écrit :
+> > On 1 August 2011 15:29, Thomas Lottmann<skipercooker at gmail.com>  wrote:
+> >> The other main issue I see si that Drakxnet is coded in Perl and uses a 
+lot
+> >> of perl scripts, like the drakxtools. This makes it hard to maintain, and 
+to
+> >> improve.
+> > That's just your own POV.
+> > Not the POV of maintainers.
+> 
+> Are there other maintainers for this tool than it's creators or 
+> long-time maintainers? This is not only my POV, but also what I have 
+> heard from a variety of people since the time I participate a little. 
+> Anyway...
+> 
+> >> I know it works fine for several people. Personally, I am often having
+> >> issues because it's disconnects on it's own,
+> > This has nothing to do with drakconnect that don't handle that.
+> > If the network disconnected, that's the issue between the routers,
+> > the network, the kernel, ....
+> > and no longer sees any networks when it should.
+> > which points to either network issue or kernel driver issue, not 
+drakconnect.
+> 
+> Other people not using Mageia do not get as often disconnected as me 
+> when using public hotspots. Mageia wireless tools seem to have more 
+> difficulty to connect and keep the connections to hotspots that have a 
+> low (not bad, low) quality signal, while Windows keeps connected, or, 
+> quickly reconnects automatically.
+> 
+> Meanwhile, I have to reconnect manually and, more frustrating, it seems 
+> the wireless utility sometime attempts to reconnect automatically, but I 
+> can't clearly know.
+> 
+> The other bizarre thing I often see is when the hotspots he sees fall 
+> from 35 to 0 (or 1, the hotspot he's tryign to connect). This is not 
+> normal, I have not observed this NM, Windows or Mac OS X tools.
+> 
+> >
+> >> Then it has difficulty  reconnecting.
+> > Same, reconnecting is the job of dhcp-client, ifplugd and the like.
+> > Not drakconnect's job.
+> 
+> I can't tell. I can only observe and I do not invent what I describe 
+> (and have already described in the past). :-)
+> 
+> >> Windows, Fedora and Ubuntu's wireless tools work absolutely smoothly at 
+my
+> >> school. And now, other people testing Mageia as school are having the 
+same
+> >> issues I have. This is frustrating and I can assure you these home-made
+> >> network tools have to be improved and fixed.
+> > Well, Fedora tool (really NM) has its own bugs.
+> True.
+> > And I'm pretty sure people who've used MS, Apple or whatever OS/tool
+> > they're used to, have also encountered issues
+> True. But these issues are less evident to find apparently, and do not 
+> affect that much user experience.
+> 
+> When a user wants to connect to a wireless hotspot, he should just click 
+> connect, enter his IDs and it should work fluently. If it is often the 
+> case with Mageia tools with a personal hotspot and when you're next to 
+> it, it is not always the case when you use it everyday, and, sadly, 
+> other tools do better and have a more stable and smooth wireless  
+> connectivity, even if they also encournter issues. Their issues are not 
+> that much affecting user experience like the ones I have described.
+> >> If you want to, I can attempt to make a list of the isses and 
+incoherencies
+> >> I find, although they are not hard to see.
+> > Indeed, please just fill in _several_ bugs (one report per issue)
+> > against drakx-net
+> 
+> I will do one report for each issue I find in drakxnet, with as much 
+> details as possible, yes. I shall also do a video capture of the issue 
+> if it can help. this will take me a lot of time, but I will do it.
+> 
+> >> But as I mentionned earlier, this
+> >> is a tool that is hard to maintain, and I cannot learn perl right now.
+> > That's just _your_ personnal though, not his maintainer's.
+> > aka "this is a tool that is hard to maintain" really means "you would not 
+be
+> > able to maintain it"
+> Right.
+> >> If NetworkManager is easier to maintain and works fine, then I think it 
+can
+> >> be a better solution. Just offering or trying to find solutions, because
+> >> this tool seriously does not work properly here.
+> > it has its own flaws too...
+> Yes, but it does not confuses itself with it's own configuration files. 
+> Clearly, all programs can have flaws, but sincerely, it is not working 
+> well in Mageia and is not pleasant to use. Otherwise I would not report 
+> again about it. ;-)
+> 
+
+btw, i think ALL mageia tools must be redesigned to match the medium usability 
+level of nowadays... 
+
+
+cheers,
+Marcello
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007189.html b/zarb-ml/mageia-dev/2011-August/007189.html new file mode 100644 index 000000000..bc75030b7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007189.html @@ -0,0 +1,214 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Tue Aug 2 17:29:35 CEST 2011 +

+
+ +
On Monday, 1 August 2011 20:21:21 Maarten Vanraes wrote:
+> Op maandag 01 augustus 2011 11:42:26 schreef Thomas Lottmann:
+> > Hello,
+> > 
+> > I should have written this mail much sooner, but finally, I am totally,
+> > completely and starting to be hatefully fed up of these tools.
+> > 
+> > The Mandriva/Mageia tools that manage the network on computers,
+> > especially the wireless networks are completely dysfunctional. While the
+> > Network Center does not seem to even communicate with the system tools
+> > to know what is happening during the link setup, it does not
+> > auto-refresh network lists properly.
+> > 
+> > Since 2010.1 now even mixes up itself in it's own network scripts (the
+> > ones stored in wireless.d). This maxes it wrongly detect numerous
+> > wireless points (he seen WPA2 Enterperise hotspots as opened or WEP, or
+> > more nerving, becomes incapable or storing the right authentication
+> > information).
+
+My "production" laptop is still currently running Mandriva 2010.x, and I don't 
+have problems like this. Work networks run WPA2-Enterprise with EAP-PEAP-
+MSCHAPv2, home runs WPA2-Personal. In the cases I have seen this, it is 
+typically a buggy AP (and in some cases, other platforms have also mis-
+detected the network details). In some cases, upgrading the AP firmware has 
+resolved the problem.
+
+But, these are *specific* issues, and need bug reports with detailed 
+information.
+
+> > A tool that breaks itself is a complete shame!
+> > 
+> > The GUI is also appalling. Despite it's numerous possibilities, it is a
+> > mess and 60% of it cannot be used by something else than the system or a
+> > network expert.
+
+There are some deficiencies, but in many cases it does at least work. And at 
+least my network comes up regardless of how I boot, where I booted to, whether 
+a user is logged in to a desktop or not (which is not the case on e.g. 
+Fedora).
+
+> > 
+> > The code itself is undocumented and it extremely difficult to read.
+> >
+
+The few times I looked at the code, it was quite readable. Unfortunately, the 
+pieces I wanted to do something about ended up requiring changes in non-perl 
+parts.
+ 
+> > These tools are getting really bad and not working properly anyway since
+> > a long time now. So either we fix it and improve it (recoding?), either
+> > we definitely switch to Network Manager.
+
+Please no. The biggest frustrations I personally have have nothing to do with 
+net_applet vs NM. My current biggest frustrations are:
+
+1)That wpa_supplicant doesn't return different results on incorrect (WPA2-
+Enterprise EAP-PEAP) passwords:
+http://hostap.epitest.fi/bugz/show_bug.cgi?id=399
+
+2)That net_applet doesn't prompt for passwords if wpa_supplicant says it needs 
+a password. I filed a bug for this against Mandriva:
+https://qa.mandriva.com/show_bug.cgi?id=51705
+
+Implementing the required dbus communication would allow a number of other 
+improvements (e.g. not having to restart wpa_supplicant for configuration 
+changes, possibly avoid manual parsing/writing of the configuration etc.).
+
+> > I am ready to participate if
+> > necessary (despite my lack of competence), but I do not want to see
+> > these tools 'as is' on my computer anymore, and no longer want to see
+> > these issues that down Mageia's reputation in comparison to other
+> > popular projects here such as Arch, Fedora or Ubuntu, who do have proper
+> > tools delivered by default.
+
+I disagree with your statement. For example, while Fedora may seem to have 
+"proper tools", there are many use cases that aren't considered, and a number 
+of issues are still experienced (at least according to my colleagues reports).
+
+Allowing NM or non-NM, and having both improved would be win-win.
+
+> > 
+> > This is not the first time I complain about this tool. We should not
+> > leave this unchanged. It is far too annoying and pushing to so much loss
+> > of time.
+> > 
+> > Yours sincerely,.
+> > 
+> > Thomas.
+> 
+> personally, alot of problems could likely be attributed to using all those
+> several of those apps together.
+> 
+> imho, the network tools should be redesigned a bit, according to good
+> usability, but mostly, either they should all be nicely integrated which
+> each other, or we should just have one that does all nicely.
+> 
+> personally, i find the netapplet the best working and use that exclusively
+> to avoid issues.
+> 
+> but sadly, even netapplet is far from complete.
+> 
+> as some kind of start, we should have an app that exists in drakconf, but
+> also accessible via an applet, but again, perhaps we should have multiple
+> applets, with one for each connection.
+
+I don't think this is necessary, the 'Network Center' does an adequate job 
+(taking into account some limitations in the network scripts).
+
+> eg: a wifi access link, 2 network connections (one of which goes to
+> internet), and 3 openvpn tunnels (as an example) it would even be better,
+> if bluetooth networking could also be included.
+
+Bluetooth networking *can* be included, but there is an artificial limitation 
+on only one ppp connection, so you wouldn't be able to have a Bluetooth SPP-
+based ppp connection as well as a mobile-broadband-dongle-based connection (or 
+ADSL).
+
+For bluetooth ppp over SPP, the bluetooth configuration only needs to be done 
+once ever (if done correctly), the rfcomm connections will be established when 
+necessary.
+
+(Or, are you referring to PAN?).
+
+> (this would also allow for
+> multiple internet connections at a later time with some advanced routing)
+> 
+> at the same time, people could tell at a glance if they accidentally use
+> more than one internet access method.
+
+You can see this in Network Center.
+
+> about openvpn, some of those are user-related (even though they have
+> effects on global routing), especially password related things,
+> personally, i think it'd be better if these can only be controlled through
+> the applet by the user it's from (with perhaps an option to allow any user
+> to control this too)
+> 
+> again with openvpn, it would be usefull if there was some kind of way to
+> know it's not only running, but also if it's essentially active or not,
+> and if it's used as a internet gateway.
+
+Well, the general feedback provided to users (also with e.g. ppp connections) 
+could be improved.
+
+> 
+> These are some things which i have noticed over the years of using it and
+> listening to end-user problems.
+> 
+> 
+> perhaps the above can be used as a starting point for a usability scheme.
+> 
+> Thomas, since you feel this strongly, are you willing to spend some time on
+> this?
+
+
+Regards,
+Buchan
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007190.html b/zarb-ml/mageia-dev/2011-August/007190.html new file mode 100644 index 000000000..b75efa04b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007190.html @@ -0,0 +1,202 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Tue Aug 2 17:42:25 CEST 2011 +

+
+ +
On Tuesday, 2 August 2011 10:56:55 Thomas Lottmann wrote:
+> You are right in several points, but... :-)
+> 
+> Le 01/08/2011 15:59, Thierry Vignaud a écrit :
+> > On 1 August 2011 15:29, Thomas Lottmann<skipercooker at gmail.com>  wrote:
+> >> The other main issue I see si that Drakxnet is coded in Perl and uses a
+> >> lot of perl scripts, like the drakxtools. This makes it hard to
+> >> maintain, and to improve.
+> > 
+> > That's just your own POV.
+> > Not the POV of maintainers.
+> 
+> Are there other maintainers for this tool than it's creators or
+> long-time maintainers? This is not only my POV, but also what I have
+> heard from a variety of people since the time I participate a little.
+> Anyway...
+> 
+> >> I know it works fine for several people. Personally, I am often having
+> >> issues because it's disconnects on it's own,
+> > 
+> > This has nothing to do with drakconnect that don't handle that.
+> > If the network disconnected, that's the issue between the routers,
+> > the network, the kernel, ....
+> > and no longer sees any networks when it should.
+> > which points to either network issue or kernel driver issue, not
+> > drakconnect.
+> 
+> Other people not using Mageia do not get as often disconnected as me
+> when using public hotspots.
+
+Sure, this should be investigated, however it could be due to things besides 
+the network GUI tools etc. For example, if using wpa_supplicant, once you have 
+selected a wireless network, the Mandriva tools do virtually nothing.
+
+BTW., I notice (from wpa_gui, *not* net_applet, and even without net_applet 
+running) that my machine re-associates to our WPA2-Enterprise network more 
+frequently than other operating systems.
+
+> Mageia wireless tools seem to have more
+> difficulty to connect and keep the connections to hotspots that have a
+> low (not bad, low) quality signal, while Windows keeps connected, or,
+> quickly reconnects automatically.
+
+These symptoms don't appear to be related to which GUI tool configures 
+wpa_supplicant, but rather points to wpa_supplicant or driver/firmware 
+problems.
+
+> Meanwhile, I have to reconnect manually and, more frustrating, it seems
+> the wireless utility sometime attempts to reconnect automatically, but I
+> can't clearly know.
+> 
+> The other bizarre thing I often see is when the hotspots he sees fall
+> from 35 to 0 (or 1, the hotspot he's tryign to connect). This is not
+> normal, I have not observed this NM, Windows or Mac OS X tools.
+> 
+> >> Then it has difficulty  reconnecting.
+> > 
+> > Same, reconnecting is the job of dhcp-client, ifplugd and the like.
+> > Not drakconnect's job.
+> 
+> I can't tell. I can only observe and I do not invent what I describe
+> (and have already described in the past). :-)
+
+You could investigate by connecting manaully (iwconfig, wpa_cli, wpa_gui etc.) 
+and report whether doing so solves your problems. If not, you are blaming the 
+wrong thing.
+
+> >> Windows, Fedora and Ubuntu's wireless tools work absolutely smoothly at
+> >> my school. And now, other people testing Mageia as school are having
+> >> the same issues I have. This is frustrating and I can assure you these
+> >> home-made network tools have to be improved and fixed.
+> > 
+> > Well, Fedora tool (really NM) has its own bugs.
+> 
+> True.
+> 
+> > And I'm pretty sure people who've used MS, Apple or whatever OS/tool
+> > they're used to, have also encountered issues
+> 
+> True. But these issues are less evident to find apparently, and do not
+> affect that much user experience.
+> 
+> When a user wants to connect to a wireless hotspot, he should just click
+> connect, enter his IDs and it should work fluently.
+
+This works for me (except I don't want my Single-Sign-On password in a clear-
+text configuration file, but it seems no distro has fixed all the issues with 
+this yet).
+
+> If it is often the
+> case with Mageia tools with a personal hotspot and when you're next to
+> it, it is not always the case when you use it everyday, and, sadly,
+> other tools do better and have a more stable and smooth wireless
+> connectivity, even if they also encournter issues. Their issues are not
+> that much affecting user experience like the ones I have described.
+> 
+> >> If you want to, I can attempt to make a list of the isses and
+> >> incoherencies I find, although they are not hard to see.
+> > 
+> > Indeed, please just fill in _several_ bugs (one report per issue)
+> > against drakx-net
+> 
+> I will do one report for each issue I find in drakxnet, with as much
+> details as possible, yes. I shall also do a video capture of the issue
+> if it can help.
+
+I would rather spend the time testing whether the behaviour is the same 
+without e.g. net_applet. Videos showing nothing that can help find the problem 
+is just a waste of time.
+
+> this will take me a lot of time, but I will do it.
+> 
+> >> But as I mentionned earlier, this
+> >> is a tool that is hard to maintain, and I cannot learn perl right now.
+
+Who says your issues are in this tool?
+
+> > 
+> > That's just _your_ personnal though, not his maintainer's.
+> > aka "this is a tool that is hard to maintain" really means "you would not
+> > be able to maintain it"
+> 
+> Right.
+> 
+> >> If NetworkManager is easier to maintain and works fine, then I think it
+> >> can be a better solution. Just offering or trying to find solutions,
+> >> because this tool seriously does not work properly here.
+> > 
+> > it has its own flaws too...
+> 
+> Yes, but it does not confuses itself with it's own configuration files.
+
+Hmm, you mean wpa_supplicant.conf? That's not net_applet's own configuration 
+file ... but configuring wpa_supplicant via dbus or the unix socket may be 
+better.
+
+> Clearly, all programs can have flaws, but sincerely, it is not working
+> well in Mageia and is not pleasant to use. Otherwise I would not report
+> again about it. ;-)
+
+But, please investigate *what* pieces of Mageia are at fault, it seems you 
+have assumed that anything to do with any network issue at all, regardless of 
+whether it is the AP, the device, the firmware, driver, kernel, supplicant, or 
+GUI, is due to the net_applet and associated tools.
+
+Regards,
+Buchan
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007191.html b/zarb-ml/mageia-dev/2011-August/007191.html new file mode 100644 index 000000000..30dd6b2c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007191.html @@ -0,0 +1,253 @@ + + + + [Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it. + + + + + + + + + +

[Mageia-dev] Drakxnet, drakroam and Draknetcenter : let's fix it or throw it.

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Aug 2 22:20:49 CEST 2011 +

+
+ +
Op dinsdag 02 augustus 2011 17:29:35 schreef Buchan Milne:
+> On Monday, 1 August 2011 20:21:21 Maarten Vanraes wrote:
+> > Op maandag 01 augustus 2011 11:42:26 schreef Thomas Lottmann:
+> > > Hello,
+> > > 
+> > > I should have written this mail much sooner, but finally, I am totally,
+> > > completely and starting to be hatefully fed up of these tools.
+> > > 
+> > > The Mandriva/Mageia tools that manage the network on computers,
+> > > especially the wireless networks are completely dysfunctional. While
+> > > the Network Center does not seem to even communicate with the system
+> > > tools to know what is happening during the link setup, it does not
+> > > auto-refresh network lists properly.
+> > > 
+> > > Since 2010.1 now even mixes up itself in it's own network scripts (the
+> > > ones stored in wireless.d). This maxes it wrongly detect numerous
+> > > wireless points (he seen WPA2 Enterperise hotspots as opened or WEP, or
+> > > more nerving, becomes incapable or storing the right authentication
+> > > information).
+> 
+> My "production" laptop is still currently running Mandriva 2010.x, and I
+> don't have problems like this. Work networks run WPA2-Enterprise with
+> EAP-PEAP- MSCHAPv2, home runs WPA2-Personal. In the cases I have seen
+> this, it is typically a buggy AP (and in some cases, other platforms have
+> also mis- detected the network details). In some cases, upgrading the AP
+> firmware has resolved the problem.
+> 
+> But, these are *specific* issues, and need bug reports with detailed
+> information.
+> 
+> > > A tool that breaks itself is a complete shame!
+> > > 
+> > > The GUI is also appalling. Despite it's numerous possibilities, it is a
+> > > mess and 60% of it cannot be used by something else than the system or
+> > > a network expert.
+> 
+> There are some deficiencies, but in many cases it does at least work. And
+> at least my network comes up regardless of how I boot, where I booted to,
+> whether a user is logged in to a desktop or not (which is not the case on
+> e.g. Fedora).
+> 
+> > > The code itself is undocumented and it extremely difficult to read.
+> 
+> The few times I looked at the code, it was quite readable. Unfortunately,
+> the pieces I wanted to do something about ended up requiring changes in
+> non-perl parts.
+> 
+> > > These tools are getting really bad and not working properly anyway
+> > > since a long time now. So either we fix it and improve it (recoding?),
+> > > either we definitely switch to Network Manager.
+> 
+> Please no. The biggest frustrations I personally have have nothing to do
+> with net_applet vs NM. My current biggest frustrations are:
+> 
+> 1)That wpa_supplicant doesn't return different results on incorrect (WPA2-
+> Enterprise EAP-PEAP) passwords:
+> http://hostap.epitest.fi/bugz/show_bug.cgi?id=399
+> 
+> 2)That net_applet doesn't prompt for passwords if wpa_supplicant says it
+> needs a password. I filed a bug for this against Mandriva:
+> https://qa.mandriva.com/show_bug.cgi?id=51705
+> 
+> Implementing the required dbus communication would allow a number of other
+> improvements (e.g. not having to restart wpa_supplicant for configuration
+> changes, possibly avoid manual parsing/writing of the configuration etc.).
+> 
+> > > I am ready to participate if
+> > > necessary (despite my lack of competence), but I do not want to see
+> > > these tools 'as is' on my computer anymore, and no longer want to see
+> > > these issues that down Mageia's reputation in comparison to other
+> > > popular projects here such as Arch, Fedora or Ubuntu, who do have
+> > > proper tools delivered by default.
+> 
+> I disagree with your statement. For example, while Fedora may seem to have
+> "proper tools", there are many use cases that aren't considered, and a
+> number of issues are still experienced (at least according to my
+> colleagues reports).
+> 
+> Allowing NM or non-NM, and having both improved would be win-win.
+> 
+> > > This is not the first time I complain about this tool. We should not
+> > > leave this unchanged. It is far too annoying and pushing to so much
+> > > loss of time.
+> > > 
+> > > Yours sincerely,.
+> > > 
+> > > Thomas.
+> > 
+> > personally, alot of problems could likely be attributed to using all
+> > those several of those apps together.
+> > 
+> > imho, the network tools should be redesigned a bit, according to good
+> > usability, but mostly, either they should all be nicely integrated which
+> > each other, or we should just have one that does all nicely.
+> > 
+> > personally, i find the netapplet the best working and use that
+> > exclusively to avoid issues.
+> > 
+> > but sadly, even netapplet is far from complete.
+> > 
+> > as some kind of start, we should have an app that exists in drakconf, but
+> > also accessible via an applet, but again, perhaps we should have multiple
+> > applets, with one for each connection.
+> 
+> I don't think this is necessary, the 'Network Center' does an adequate job
+> (taking into account some limitations in the network scripts).
+> 
+> > eg: a wifi access link, 2 network connections (one of which goes to
+> > internet), and 3 openvpn tunnels (as an example) it would even be better,
+> > if bluetooth networking could also be included.
+> 
+> Bluetooth networking *can* be included, but there is an artificial
+> limitation on only one ppp connection, so you wouldn't be able to have a
+> Bluetooth SPP- based ppp connection as well as a
+> mobile-broadband-dongle-based connection (or ADSL).
+
+why would there be only 1 possible ppp connection? that sounds odd.
+
+> For bluetooth ppp over SPP, the bluetooth configuration only needs to be
+> done once ever (if done correctly), the rfcomm connections will be
+> established when necessary.
+> 
+> (Or, are you referring to PAN?).
+
+i think i was, yes, but i'm not too clear on how this sort of thing works
+
+> > (this would also allow for
+> > multiple internet connections at a later time with some advanced routing)
+> > 
+> > at the same time, people could tell at a glance if they accidentally use
+> > more than one internet access method.
+> 
+> You can see this in Network Center.
+
+yes, but i'm not really a fan of network center, and the whole point of the 
+net_applet is that you can always see it, in your systray area. which is where 
+i'd like to have all current networking connections separately, so you can 
+have 3 openvpn connection and 3 icons, it can more easily show you which are 
+working and which aren't.
+
+each of those icons should be 4 state, off-state (but present), on-state, fail-
+state and gateway-state (this connection is use as one of the default routes.)
+
+(incidentally, i'd also like for most connections to set up default route and 
+having some small advanced routing that would at least enforce symmetrical 
+routing.
+
+eg: each such icon could have as right click menu:
+ - enable/disable
+ - reconnect (?)
+ - use for internet (default route)
+ - delete
+-------------------
+ - add new connection (wizard with several types: vpn, virtual interfaces, 
+bonds, bridges, etc... )
+ - firewall ----> (firewall options)
+---------------
+ - network center
+ - help
+ - exit
+
+ie: no more "followed interface, and the like options, because they only 
+confuse people.
+
+in drakconf there should then be a network center which is the same thing if 
+you click on the net_applet on network center.
+
+the network center should also be an extension of net_applet, the same icons 
+should be shown, but bigger with the same states and same right click menu,.
+
+
+iow: i would like them all to be nicely integrated with eachother.
+
+
+> > about openvpn, some of those are user-related (even though they have
+> > effects on global routing), especially password related things,
+> > personally, i think it'd be better if these can only be controlled
+> > through the applet by the user it's from (with perhaps an option to
+> > allow any user to control this too)
+> > 
+> > again with openvpn, it would be usefull if there was some kind of way to
+> > know it's not only running, but also if it's essentially active or not,
+> > and if it's used as a internet gateway.
+> 
+> Well, the general feedback provided to users (also with e.g. ppp
+> connections) could be improved.
+> 
+> > These are some things which i have noticed over the years of using it and
+> > listening to end-user problems.
+> > 
+> > 
+> > perhaps the above can be used as a starting point for a usability scheme.
+> > 
+> > Thomas, since you feel this strongly, are you willing to spend some time
+> > on this?
+> 
+> Regards,
+> Buchan
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007192.html b/zarb-ml/mageia-dev/2011-August/007192.html new file mode 100644 index 000000000..39aaf1f1a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007192.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Aug 2 22:23:24 CEST 2011 +

+
+ +
Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne:
+> On Monday, 1 August 2011 22:34:55 Luis Daniel Lucio Quiroz wrote:
+> > Le Lundi 01 Août 2011 12:36:47 Buchan Milne a écrit :
+> > > On Friday, 29 July 2011 20:52:14 Luis Daniel Lucio Quiroz wrote:
+> > > > Helow
+> > > > 
+> > > > Specially tu buchan, in my experince, when trying to making work a
+> > > > Squid with an ugly wik2k8 we realize that the squid helper is not
+> > > > working.
+> > > 
+> > > I had no problems with this in providing one of the two sets of squid
+> > > proxy servers that had a role in presenting the 2010 FIFA World Cup.
+> > > (The other set of proxies used Basic authentication against OpenLDAP).
+> > > 
+> > > > After doing research we realize that samba has a helper that works
+> > > 
+> > > You mean ntlm_auth, which has been in samba-common for years, and works
+> > > with Squid, Apache and FreeRADIUS ?
+> > > 
+> > > > , i was
+> > > > wondering if you can do a subpackage of that helper so the squid may
+> > > > do a
+> > > > suggests to that only.
+> > > 
+> > > I need more details ... so far this sounds like a question, not a
+> > > proposal.
+> > > 
+> > > Regards,
+> > > Buchan
+> > 
+> > Yes, itis a prposal
+> > 
+> > if you can add a subpackage like
+> > 
+> > samba-helpers inwher eyou place tthe ntlm_auth and others from samba
+> > and i then do a suggest from squid to ask for them
+> 
+> Samba-common is the right package for this. I see no need to have a squid-
+> specific subpackage (and then samba-apache, samba-freeradius, with the same
+> content, or all virtual packages just pulling samba-common).
+> 
+> Feel free to mess up your squid package by adding suggests on samba-common,
+> but since installing the right package is trivially solved by the admin and
+> is a small portion of the work required, I would personally prefer not to
+> increase the default footprint of any installation that pulls in squid.
+> 
+> Regards,
+> Buchan
+
+
+this is really imho an example where conditional suggests could work well: if 
+you have squid already installed and you're installing samba, this subpackage 
+could then be suggested. (and vice versa).
+
+something i would like to see in mageia whenever time allows me to actually 
+work on this feature.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007193.html b/zarb-ml/mageia-dev/2011-August/007193.html new file mode 100644 index 000000000..aca336970 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007193.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 00:25:22 CEST 2011 +

+
+ +
Hi,
+
+Just so you know, I'm in the process of pushing a new PulseAudio version.
+
+I've been using this version for several months and it's pretty stable,
+but all the same, those of you who value the "stability" of sound in
+Cauldron should maybe take this opportunity to make some selective edits
+of your skip list.
+
+We're looking for feedback upstream, so please read the notes here:
+http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/10546
+
+(in particular, please try and take a backup of your ~/.pulse/ folder
+before upgrading)
+
+
+And please submit bug reports and feedback (preferably straight to
+https://bugs.freedesktop.org/ rather than via the mga tracker as there
+is little point in that :D)
+
+There will be a new pavucontrol coming soon too.
+
+Cheers
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007194.html b/zarb-ml/mageia-dev/2011-August/007194.html new file mode 100644 index 000000000..c85934cc8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007194.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Wed Aug 3 02:14:25 CEST 2011 +

+
+ +
Le Mardi 02 Août 2011 17:04:41 Buchan Milne a écrit :
+> On Monday, 1 August 2011 22:34:55 Luis Daniel Lucio Quiroz wrote:
+> > Le Lundi 01 Août 2011 12:36:47 Buchan Milne a écrit :
+> > > On Friday, 29 July 2011 20:52:14 Luis Daniel Lucio Quiroz wrote:
+> > > > Helow
+> > > > 
+> > > > Specially tu buchan, in my experince, when trying to making work
+> > > > a
+> > > > Squid with an ugly wik2k8 we realize that the squid helper is
+> > > > not
+> > > > working.
+> > > 
+> > > I had no problems with this in providing one of the two sets of
+> > > squid
+> > > proxy servers that had a role in presenting the 2010 FIFA World Cup.
+> > > (The other set of proxies used Basic authentication against
+> > > OpenLDAP).
+> > > 
+> > > > After doing research we realize that samba has a helper that
+> > > > works
+> > > 
+> > > You mean ntlm_auth, which has been in samba-common for years, and
+> > > works
+> > > with Squid, Apache and FreeRADIUS ?
+> > > 
+> > > > , i was
+> > > > wondering if you can do a subpackage of that helper so the squid
+> > > > may do a
+> > > > suggests to that only.
+> > > 
+> > > I need more details ... so far this sounds like a question, not a
+> > > proposal.
+> > > 
+> > > Regards,
+> > > Buchan
+> > 
+> > Yes, itis a prposal
+> > 
+> > if you can add a subpackage like
+> > 
+> > samba-helpers inwher eyou place tthe ntlm_auth and others from samba
+> > and i then do a suggest from squid to ask for them
+> 
+> Samba-common is the right package for this. I see no need to have a squid-
+> specific subpackage (and then samba-apache, samba-freeradius, with the same
+> content, or all virtual packages just pulling samba-common).
+> 
+> Feel free to mess up your squid package by adding suggests on samba-common,
+> but since installing the right package is trivially solved by the admin and
+> is a small portion of the work required, I would personally prefer not to
+> increase the default footprint of any installation that pulls in squid.
+> 
+> Regards,
+> Buchan
+
+I got your point.  Just that from my poing of view not a squid admin must know 
+samba package and it is quite difficult to figure it out that ntml_auth helper 
+for squid (the one that works with ntlm2) is in samba-commong package.
+
+Also that when you install samba-common you are carrying other rpms because 
+dependencis thats why i was asking you to place a samba-squid subpackage
+
+LD
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007195.html b/zarb-ml/mageia-dev/2011-August/007195.html new file mode 100644 index 000000000..032c263eb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007195.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ D.Morgan + dmorganec at gmail.com +
+ Wed Aug 3 02:28:55 CEST 2011 +

+
+ +
On Wed, Aug 3, 2011 at 12:25 AM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> Hi,
+>
+> Just so you know, I'm in the process of pushing a new PulseAudio version.
+>
+> I've been using this version for several months and it's pretty stable,
+> but all the same, those of you who value the "stability" of sound in
+> Cauldron should maybe take this opportunity to make some selective edits
+> of your skip list.
+>
+> We're looking for feedback upstream, so please read the notes here:
+> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/10546
+>
+> (in particular, please try and take a backup of your ~/.pulse/ folder
+> before upgrading)
+>
+>
+> And please submit bug reports and feedback (preferably straight to
+> https://bugs.freedesktop.org/ rather than via the mga tracker as there
+> is little point in that :D)
+>
+> There will be a new pavucontrol coming soon too.
+>
+> Cheers
+>
+> Col
+>
+
+Hi colin,
+
+first thanks for this mail explaining this update ( really appreciated ).
+
+Is there tasks, you would like mageia users/testers do ?
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007196.html b/zarb-ml/mageia-dev/2011-August/007196.html new file mode 100644 index 000000000..ee198a6cf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007196.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Wed Aug 3 04:31:39 CEST 2011 +

+
+ +
Le Mardi 2 Août 2011 16:45:13 Mageia Team a écrit :
+> Name        : gnutls                       Relocations: (not
+> relocatable) Version     : 3.0.0                             Vendor:
+> Mageia.Org Release     : 1.mga2                        Build Date:
+> Tue Aug  2 16:34:03 2011 Install Date: (not installed)              
+> Build Host: ecosse Group       : System/Libraries              Source
+> RPM: (none) Size        : 4548019                          License:
+> GPLv3+ and LGPLv3+ Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.gnutls.org
+> Summary     : Library providing a secure layer (SSL)
+> Description :
+> GnuTLS is a project that aims to develop a library which provides
+> a secure layer, over a reliable transport layer.
+> 
+> fwang <fwang> 3.0.0-1.mga2:
+> + Revision: 131369
+> - update file list
+> - br p11-kit
+> - new version 3.0.0 (only nettle backend is supported)
+With this  gnutls upgrade & switch to nettle backend support only 
+telepathy-gabble (at least since i'm using it daily) is  broken but 
+maybe more things are broken now since there some  API/ABI changes with 
+this 3.0 release, could you fix it please ( as reminder the nettle 
+backend support was not supported by telepathy-gabble one month ago when 
+you did switch on nettle backend support only for the 2.12.7 release   
+cf https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007197.html b/zarb-ml/mageia-dev/2011-August/007197.html new file mode 100644 index 000000000..41ebfc809 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007197.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Upcoming German Linux Event in August + + + + + + + + + +

[Mageia-dev] Upcoming German Linux Event in August

+ Remco Rijnders + remco at webconquest.com +
+ Wed Aug 3 07:48:22 CEST 2011 +

+
+ +
On Tue, Aug 02, 2011 at 09:03:06AM +0200, Oliver Burger wrote:
+>Hi there,
+>
+>Am Donnerstag, 14. Juli 2011, 19:39:00 schrieben Sie:
+>> on August, 20th and 21st the FrOSCon ( Free and Open Source Software
+>> Conference http://www.froscon.org/ ) will take place at the campus of
+>> the University of Applied Sciences Bonn-Rhein-Sieg.
+>> Mageia will share a booth there with mandrivauser.de community.
+>> We will have a project room of our own in which at least four
+>> conferences will take place. Also it is possible to stay over night in
+>> the project room (provided you bring a sleeping bag).
+>> We welcome any visitors from opur neighbour countries (after all, Bonn
+>> isn't all that far from the French, Dutch and Belgish border).
+>>
+>> An information page about the planing status (in German) can be found
+>> here: http://www.mandrivauser.de/doku/doku.php?id=veranstaltungen
+>>
+>this is just a reminder for anybody who might be interested.
+>We only have about 3 weeks left till FrOSCon, so if you'd like to come, now
+>would be the best time for traveling preparations :)
+>
+>See you,
+>
+>Oliver
+
+Hi Oliver,
+
+I will attend the conference and your presentation :)
+
+Will be nice to meet some of the people I've gotten to know a bit over the 
+past few months.
+
+I also hope to be able to get some GPG-signatures from people in the wider 
+Mageia community at either the keysigning event at the conference (see 
+http://ksp.froscon.org ) or, if that conflicts with social bbq 
+obligations, perhaps at some other time in the Mageia conference room.
+
+Thanks and regards,
+
+Remco
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110803/6c1700a4/attachment.asc>
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007198.html b/zarb-ml/mageia-dev/2011-August/007198.html new file mode 100644 index 000000000..d03f3a3b1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007198.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 10:45:33 CEST 2011 +

+
+ +
'Twas brillig, and D.Morgan at 03/08/11 01:28 did gyre and gimble:
+> first thanks for this mail explaining this update ( really appreciated ).
+> 
+> Is there tasks, you would like mageia users/testers do ?
+
+Nothing specific. There are several new features, but in this case I'm
+most interested in ensuring things are stable. So really I'm looking for
+any test cases where things used to work and now don't. This may be
+related to hardware I don't have etc., so this is the tricky bit for me
+testing personally! But otherwise, just use as normal and report any
+crashes :)
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007199.html b/zarb-ml/mageia-dev/2011-August/007199.html new file mode 100644 index 000000000..e8c11e598 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007199.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Kira + elegant.pegasus at gmail.com +
+ Wed Aug 3 10:49:20 CEST 2011 +

+
+ +
在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John <mikala at mageia.org>寫道:
+> With this  gnutls upgrade & switch to nettle backend support only
+> telepathy-gabble (at least since i'm using it daily) is  broken but
+> maybe more things are broken now since there some  API/ABI changes with
+> this 3.0 release, could you fix it please ( as reminder the nettle
+> backend support was not supported by telepathy-gabble one month ago when
+> you did switch on nettle backend support only for the 2.12.7 release
+> cf https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+>
+Is it only me that aria2 completely broke up after update?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007200.html b/zarb-ml/mageia-dev/2011-August/007200.html new file mode 100644 index 000000000..766f8a0c9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007200.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Kira + elegant.pegasus at gmail.com +
+ Wed Aug 3 10:54:37 CEST 2011 +

+
+ +
在 Wed, 03 Aug 2011 16:45:33 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:
+
+> 'Twas brillig, and D.Morgan at 03/08/11 01:28 did gyre and gimble:
+>> first thanks for this mail explaining this update ( really appreciated  
+>> ).
+>>
+>> Is there tasks, you would like mageia users/testers do ?
+>
+> Nothing specific. There are several new features, but in this case I'm
+> most interested in ensuring things are stable. So really I'm looking for
+> any test cases where things used to work and now don't. This may be
+> related to hardware I don't have etc., so this is the tricky bit for me
+> testing personally! But otherwise, just use as normal and report any
+> crashes :)
+>
+> Col
+>
+Inside VBox, my cauldron box failed to play anything out...
+
+There an error message about Phonon complaining pulseaudio unusable,
+
+changing to use Intel HDA device(which is what VBox passed to it), but
+
+still nothing play out.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007201.html b/zarb-ml/mageia-dev/2011-August/007201.html new file mode 100644 index 000000000..469efdd00 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007201.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] [RPM] 1 tainted/updates_testing freetype2-2.4.6-0.1.mga1.tainted + + + + + + + + + +

[Mageia-dev] [RPM] 1 tainted/updates_testing freetype2-2.4.6-0.1.mga1.tainted

+ Samuel Verschelde + stormi at laposte.net +
+ Wed Aug 3 11:29:14 CEST 2011 +

+
+ +
Le mardi 2 août 2011 13:23:12, Mageia Team a écrit :
+> Name        : freetype2                    Relocations: (not relocatable)
+> Version     : 2.4.6                             Vendor: Mageia.Org
+> Release     : 0.1.mga1.tainted              Build Date: Tue Aug  2 12:57:34
+> 2011 Install Date: (not installed)               Build Host: ecosse
+> Group       : System/Libraries              Source RPM: (none)
+> Size        : 1764860                          License: FreeType
+> License/GPL Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.freetype.org/
+> Summary     : A free and portable TrueType font rendering engine
+> Description :
+> The FreeType2 engine is a free and portable TrueType font rendering engine.
+> It has been developed to provide TT support to a great variety of
+> platforms and environments. Note that FreeType2 is a library, not a
+> stand-alone application, though some utility applications are included
+> 
+> 
+> This package is in the "tainted" section because it has subpixel hinting
+> enabled which is covered by software patents.
+> 
+> fwang <fwang> 2.4.6-0.1.mga1:
+> + Revision: 131330
+> - new version 2.4.6 (fix CVE-2011-0226)
+> - drop merged autohint patch
+> 
+>   + ahmad <ahmad>
+>     - Enable tainted build
+>     - Adapt the package(s) descriptions
+
+I haven't seen a bug report assigned to the QA team for update validation. Did 
+you forget it or is the update candidate not ready ?
+
+See http://www.mageia.org/wiki/doku.php?id=updates_policy
+
+Best regards
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007202.html b/zarb-ml/mageia-dev/2011-August/007202.html new file mode 100644 index 000000000..cbb8ecd60 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007202.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 11:30:59 CEST 2011 +

+
+ +
'Twas brillig, and Kira at 03/08/11 09:54 did gyre and gimble:
+> 在 Wed, 03 Aug 2011 16:45:33 +0800, Colin Guthrie
+> <mageia at colin.guthr.ie>寫道:
+> 
+>> 'Twas brillig, and D.Morgan at 03/08/11 01:28 did gyre and gimble:
+>>> first thanks for this mail explaining this update ( really
+>>> appreciated ).
+>>>
+>>> Is there tasks, you would like mageia users/testers do ?
+>>
+>> Nothing specific. There are several new features, but in this case I'm
+>> most interested in ensuring things are stable. So really I'm looking for
+>> any test cases where things used to work and now don't. This may be
+>> related to hardware I don't have etc., so this is the tricky bit for me
+>> testing personally! But otherwise, just use as normal and report any
+>> crashes :)
+>>
+>> Col
+>>
+> Inside VBox, my cauldron box failed to play anything out...
+> 
+> There an error message about Phonon complaining pulseaudio unusable,
+> 
+> changing to use Intel HDA device(which is what VBox passed to it), but
+> 
+> still nothing play out.
+
+Interesting.... Is that after a reboot or just after upgrade? I can see
+things being mostly broken until a reboot (or at least  a PA restart:
+(pulseaudio -k; start-pulseaudio-x11; start-pulseaudio-kde))
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007203.html b/zarb-ml/mageia-dev/2011-August/007203.html new file mode 100644 index 000000000..c81975505 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007203.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Kira + elegant.pegasus at gmail.com +
+ Wed Aug 3 11:34:18 CEST 2011 +

+
+ +
在 Wed, 03 Aug 2011 17:30:59 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:
+>> Inside VBox, my cauldron box failed to play anything out...
+>>
+>> There an error message about Phonon complaining pulseaudio unusable,
+>>
+>> changing to use Intel HDA device(which is what VBox passed to it), but
+>>
+>> still nothing play out.
+>
+> Interesting.... Is that after a reboot or just after upgrade? I can see
+> things being mostly broken until a reboot (or at least  a PA restart:
+> (pulseaudio -k; start-pulseaudio-x11; start-pulseaudio-kde))
+>
+> Col
+>
+>
+Still functional after upgrade, but unusable after reboot...
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007204.html b/zarb-ml/mageia-dev/2011-August/007204.html new file mode 100644 index 000000000..783b8bd0e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007204.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 12:01:42 CEST 2011 +

+
+ +
'Twas brillig, and Kira at 03/08/11 10:34 did gyre and gimble:
+> but unusable after reboot
+
+Hmm, OK, did you install everything? Or were some packages kept. You'll
+have to remove e.g. padevchooser (if it's left over from a previous
+Mandriva install - we don't provide it in Mga) and libpulsebrowse
+package as these have been deprecated.
+
+Can you provide the output of:
+
+ PULSE_LOG=99 pactl stat
+
+and (if it works)
+
+ pacmd list
+
+Cheers
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007205.html b/zarb-ml/mageia-dev/2011-August/007205.html new file mode 100644 index 000000000..94d05dee9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007205.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Kira + elegant.pegasus at gmail.com +
+ Wed Aug 3 12:11:36 CEST 2011 +

+
+ +
在 Wed, 03 Aug 2011 18:01:42 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:
+
+> 'Twas brillig, and Kira at 03/08/11 10:34 did gyre and gimble:
+>> but unusable after reboot
+>
+> Hmm, OK, did you install everything? Or were some packages kept. You'll
+> have to remove e.g. padevchooser (if it's left over from a previous
+> Mandriva install - we don't provide it in Mga) and libpulsebrowse
+> package as these have been deprecated.
+It's a clean system updated ever since Mageia 1 alpha 1..:)
+
+>
+> Can you provide the output of:
+>
+>  PULSE_LOG=99 pactl stat
+
+Using shared memory pool with 1024 slots of size 64.0 KiB each total size  
+is 64.0 MiB, maximum usable slot size is 65472
+Trying to connect to  
+home/kira/.pulse/e6367bf3d9d..(whatever)-runtime/native...
+SHM possible: yes Protocol version: remote 23, local 23
+Negotiated SHM: yes Currently in use: 1 blocks containing 63.9 KiB bytes  
+total.
+Allocated during whole lifetime: 49 blocks containing 2.4 MiB bytes total.
+取樣快取大小:0B
+
+>
+> and (if it works)
+>
+>  pacmd list
+In the attachment.
+
+>
+> Cheers
+>
+> Col
+>
+>
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: report.txt
+URL: </pipermail/mageia-dev/attachments/20110803/3c621f6e/attachment.txt>
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007206.html b/zarb-ml/mageia-dev/2011-August/007206.html new file mode 100644 index 000000000..18cd3d87e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007206.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Aug 3 12:17:39 CEST 2011 +

+
+ +
2011/8/3 Colin Guthrie <mageia at colin.guthr.ie>:
+> 'Twas brillig, and Kira at 03/08/11 09:54 did gyre and gimble:
+>> 在 Wed, 03 Aug 2011 16:45:33 +0800, Colin Guthrie
+>> <mageia at colin.guthr.ie>寫道:
+>>
+>>> 'Twas brillig, and D.Morgan at 03/08/11 01:28 did gyre and gimble:
+>>>> first thanks for this mail explaining this update ( really
+>>>> appreciated ).
+>>>>
+>>>> Is there tasks, you would like mageia users/testers do ?
+>>>
+>>> Nothing specific. There are several new features, but in this case I'm
+>>> most interested in ensuring things are stable. So really I'm looking for
+>>> any test cases where things used to work and now don't. This may be
+>>> related to hardware I don't have etc., so this is the tricky bit for me
+>>> testing personally! But otherwise, just use as normal and report any
+>>> crashes :)
+>>>
+>>> Col
+>>>
+>> Inside VBox, my cauldron box failed to play anything out...
+>>
+>> There an error message about Phonon complaining pulseaudio unusable,
+>>
+>> changing to use Intel HDA device(which is what VBox passed to it), but
+>>
+>> still nothing play out.
+>
+> Interesting.... Is that after a reboot or just after upgrade? I can see
+> things being mostly broken until a reboot (or at least  a PA restart:
+> (pulseaudio -k; start-pulseaudio-x11; start-pulseaudio-kde))
+>
+
+Just my experiences after todays updates of PA (64-bit):
+Right after update everything worked as expected (tested Rhythmbox
+(mp3), browser (flash plugin), sound recorder.
+
+After reboot the same except that the mic does not work anymore.
+
+Another thing: when I plugin headset the mic and output work, internal
+speakers are off. When I unplug the headset, neither mic nor speakers
+are working (although the settings in PA configuration are ok). I have
+to  restart PA to get back sound. This "plugin, plugout" worked
+before.
+
+-- 
+wobo
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007207.html b/zarb-ml/mageia-dev/2011-August/007207.html new file mode 100644 index 000000000..01cabbd24 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007207.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 12:29:10 CEST 2011 +

+
+ +
'Twas brillig, and Kira at 03/08/11 11:11 did gyre and gimble:
+> 在 Wed, 03 Aug 2011 18:01:42 +0800, Colin Guthrie
+> <mageia at colin.guthr.ie>寫道:
+> 
+>> 'Twas brillig, and Kira at 03/08/11 10:34 did gyre and gimble:
+>>> but unusable after reboot
+>>
+>> Hmm, OK, did you install everything? Or were some packages kept. You'll
+>> have to remove e.g. padevchooser (if it's left over from a previous
+>> Mandriva install - we don't provide it in Mga) and libpulsebrowse
+>> package as these have been deprecated.
+> It's a clean system updated ever since Mageia 1 alpha 1..:)
+> 
+>>
+>> Can you provide the output of:
+>>
+>>  PULSE_LOG=99 pactl stat
+> 
+> Using shared memory pool with 1024 slots of size 64.0 KiB each total
+> size is 64.0 MiB, maximum usable slot size is 65472
+> Trying to connect to
+> home/kira/.pulse/e6367bf3d9d..(whatever)-runtime/native...
+> SHM possible: yes Protocol version: remote 23, local 23
+> Negotiated SHM: yes Currently in use: 1 blocks containing 63.9 KiB bytes
+> total.
+> Allocated during whole lifetime: 49 blocks containing 2.4 MiB bytes total.
+> 取樣快取大小:0B
+
+Worrying!
+
+Is this localized at all? If so what language?
+
+>> and (if it works)
+>>
+>>  pacmd list
+> In the attachment.
+
+While there are some strange characters in that output too (again on a
+localised string), it also shows that it's using an auto-null sink.
+
+This happens when we cannot open the real sound h/w
+
+Can you supply:
+
+sudo fuser -v /dev/snd/*
+
+and
+
+pulseaudio -k; pulseaudio -vvvvv
+
+output? (for the second one, you may have to do:
+echo "autospawn=no" >> ~/.pulse/client.conf
+in order for it to actually start on the command line and not be
+autospawned by something else!)
+
+Cheers
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007208.html b/zarb-ml/mageia-dev/2011-August/007208.html new file mode 100644 index 000000000..c3d959483 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007208.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 12:30:40 CEST 2011 +

+
+ +
'Twas brillig, and Wolfgang Bornath at 03/08/11 11:17 did gyre and gimble:
+> Just my experiences after todays updates of PA (64-bit):
+> Right after update everything worked as expected (tested Rhythmbox
+> (mp3), browser (flash plugin), sound recorder.
+> 
+> After reboot the same except that the mic does not work anymore.
+
+Interesting. Can you supply a "pacmd ls" output after a clean boot (no
+hotplug)?
+
+> Another thing: when I plugin headset the mic and output work, internal
+> speakers are off. When I unplug the headset, neither mic nor speakers
+> are working (although the settings in PA configuration are ok). I have
+> to  restart PA to get back sound. This "plugin, plugout" worked
+> before.
+
+It certainly should. Can you also supply the "pacmd ls" output after
+this happens so I can compare it to the first one?
+
+Much appreciated.
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007209.html b/zarb-ml/mageia-dev/2011-August/007209.html new file mode 100644 index 000000000..c14b87a9a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007209.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Kira + elegant.pegasus at gmail.com +
+ Wed Aug 3 13:36:02 CEST 2011 +

+
+ +
在 Wed, 03 Aug 2011 18:29:10 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:>
+> Worrying!
+>
+> Is this localized at all? If so what language?
+>
+Traditional Chinese...Sorry...
+
+It means sampling cache size: 0B
+
+>
+> Can you supply:
+>
+> sudo fuser -v /dev/snd/*
+
+/dev/snd/controlC0:  kira    3001  F.... kde4
+		     kira	3216  F.... kmix
+/dev/snd/pcmC0D1p:   kira	3695  F...m amarok
+
+>
+> and
+>
+> pulseaudio -k; pulseaudio -vvvvv
+1. E: main.c: unable to terminate background program: No such process  
+exist.
+
+2. as in the attachment, but still some localized message inside. Sorry.
+
+>
+> output? (for the second one, you may have to do:
+> echo "autospawn=no" >> ~/.pulse/client.conf
+> in order for it to actually start on the command line and not be
+> autospawned by something else!)
+>
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: report1.txt
+URL: </pipermail/mageia-dev/attachments/20110803/a0a57eba/attachment-0001.txt>
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007210.html b/zarb-ml/mageia-dev/2011-August/007210.html new file mode 100644 index 000000000..0b3f1d2dd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007210.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Wed Aug 3 13:51:34 CEST 2011 +

+
+ +
Le Mercredi 3 Août 2011 16:49:20 Kira a écrit :
+> 在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John <mikala at mageia.org>寫道:
+> > With this  gnutls upgrade & switch to nettle backend support only
+> > telepathy-gabble (at least since i'm using it daily) is  broken
+> > but
+> > maybe more things are broken now since there some  API/ABI changes
+> > with this 3.0 release, could you fix it please ( as reminder the
+> > nettle backend support was not supported by telepathy-gabble one
+> > month ago when you did switch on nettle backend support only for
+> > the 2.12.7 release cf
+> > https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+> Is it only me that aria2 completely broke up after update
+Someone told that the last aria2 was broken after this update too on 
+irc, so there is at least two people :p
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007211.html b/zarb-ml/mageia-dev/2011-August/007211.html new file mode 100644 index 000000000..bb56342ab --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007211.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Wed Aug 3 14:01:47 CEST 2011 +

+
+ +
2011/8/3 Kira <elegant.pegasus at gmail.com>:
+> 在 Wed, 03 Aug 2011 18:29:10 +0800, Colin Guthrie <mageia at colin.guthr.ie>寫道:>
+>>
+>> Worrying!
+>>
+>> Is this localized at all? If so what language?
+>>
+> Traditional Chinese...Sorry...
+>
+> It means sampling cache size: 0B
+>
+>>
+>> Can you supply:
+>>
+>> sudo fuser -v /dev/snd/*
+>
+> /dev/snd/controlC0:  kira    3001  F.... kde4
+>                     kira       3216  F.... kmix
+> /dev/snd/pcmC0D1p:   kira       3695  F...m amarok
+>
+>>
+>> and
+>>
+>> pulseaudio -k; pulseaudio -vvvvv
+>
+> 1. E: main.c: unable to terminate background program: No such process exist.
+>
+> 2. as in the attachment, but still some localized message inside. Sorry.
+>
+>>
+>> output? (for the second one, you may have to do:
+>> echo "autospawn=no" >> ~/.pulse/client.conf
+>> in order for it to actually start on the command line and not be
+>> autospawned by something else!)
+>
+
+Put LC_ALL=C before any command and the output will be in English, e.g.:
+LC_ALL=C urpmi --auto-update
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007212.html b/zarb-ml/mageia-dev/2011-August/007212.html new file mode 100644 index 000000000..41fd40de0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007212.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Aug 3 14:02:51 CEST 2011 +

+
+ +
Am Mittwoch, 3. August 2011 schrieb Colin Guthrie <mageia at colin.guthr.ie>:
+> 'Twas brillig, and Wolfgang Bornath at 03/08/11 11:17 did gyre and gimble:
+>> Just my experiences after todays updates of PA (64-bit):
+>> Right after update everything worked as expected (tested Rhythmbox
+>> (mp3), browser (flash plugin), sound recorder.
+>>
+>> After reboot the same except that the mic does not work anymore.
+>
+> Interesting. Can you supply a "pacmd ls" output after a clean boot (no
+> hotplug)?
+>
+>> Another thing: when I plugin headset the mic and output work, internal
+>> speakers are off. When I unplug the headset, neither mic nor speakers
+>> are working (although the settings in PA configuration are ok). I have
+>> to  restart PA to get back sound. This "plugin, plugout" worked
+>> before.
+>
+> It certainly should. Can you also supply the "pacmd ls" output after
+> this happens so I can compare it to the first one?
+>
+> Much appreciated.
+>
+
+On the road now. Will reply later
+-- 
+Wobo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110803/95bcf70a/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007213.html b/zarb-ml/mageia-dev/2011-August/007213.html new file mode 100644 index 000000000..8ae30e226 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007213.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 14:27:16 CEST 2011 +

+
+ +
'Twas brillig, and Ahmad Samir at 03/08/11 13:01 did gyre and gimble:
+> 2011/8/3 Kira <elegant.pegasus at gmail.com>:
+>> 在 Wed, 03 Aug 2011 18:29:10 +0800, Colin Guthrie <mageia at colin.guthr.ie>寫道:>
+>>>
+>>> Worrying!
+>>>
+>>> Is this localized at all? If so what language?
+>>>
+>> Traditional Chinese...Sorry...
+>>
+>> It means sampling cache size: 0B
+>>
+>>>
+>>> Can you supply:
+>>>
+>>> sudo fuser -v /dev/snd/*
+>>
+>> /dev/snd/controlC0:  kira    3001  F.... kde4
+>>                     kira       3216  F.... kmix
+>> /dev/snd/pcmC0D1p:   kira       3695  F...m amarok
+>>
+>>>
+>>> and
+>>>
+>>> pulseaudio -k; pulseaudio -vvvvv
+>>
+>> 1. E: main.c: unable to terminate background program: No such process exist.
+>>
+>> 2. as in the attachment, but still some localized message inside. Sorry.
+>>
+>>>
+>>> output? (for the second one, you may have to do:
+>>> echo "autospawn=no" >> ~/.pulse/client.conf
+>>> in order for it to actually start on the command line and not be
+>>> autospawned by something else!)
+>>
+> 
+> Put LC_ALL=C before any command and the output will be in English, e.g.:
+> LC_ALL=C urpmi --auto-update
+> 
+
+Also please run this as your regular user, not root.
+
+You should also ensure that no applications are running that are using
+the /dev/snd/pcm* devices, e.g. with the fuser command above, you should
+kill off amarok before trying to start PA.
+
+Cheers
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007214.html b/zarb-ml/mageia-dev/2011-August/007214.html new file mode 100644 index 000000000..ef4943aed --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007214.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 3 14:27:53 CEST 2011 +

+
+ +
'Twas brillig, and Wolfgang Bornath at 03/08/11 13:02 did gyre and gimble:
+> On the road now. Will reply later
+
+No rush. I'll be travelling a bit soon anyway so may not be able to pick
+this up for a day or so.
+
+Cheers
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007215.html b/zarb-ml/mageia-dev/2011-August/007215.html new file mode 100644 index 000000000..513fa71fc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007215.html @@ -0,0 +1,1416 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Aug 3 14:34:17 CEST 2011 +

+
+ +
2011/8/3 Colin Guthrie <mageia at colin.guthr.ie>:
+> 'Twas brillig, and Wolfgang Bornath at 03/08/11 11:17 did gyre and gimble:
+>> Just my experiences after todays updates of PA (64-bit):
+>> Right after update everything worked as expected (tested Rhythmbox
+>> (mp3), browser (flash plugin), sound recorder.
+>>
+>> After reboot the same except that the mic does not work anymore.
+>
+> Interesting. Can you supply a "pacmd ls" output after a clean boot (no
+> hotplug)?
+
+After a fresdh boot, nothing attached, internal speaker works,
+internal mic does not work
+--> see pacmd_ls_1.txt
+
+>> Another thing: when I plugin headset the mic and output work, internal
+>> speakers are off. When I unplug the headset, neither mic nor speakers
+>> are working (although the settings in PA configuration are ok). I have
+>> to  restart PA to get back sound. This "plugin, plugout" worked
+>> before.
+>
+> It certainly should. Can you also supply the "pacmd ls" output after
+> this happens so I can compare it to the first one?
+
+Plugged in headset, no sound, neither from internal speakers nor from headset.
+--> see pacmd_ls_2.txt
+
+-- 
+wobo
+-------------- next part --------------
+Welcome to PulseAudio! Use "help" for usage information.
+>>> Memory blocks currently allocated: 1, size: 63,9 KiB.
+Memory blocks allocated during the whole lifetime: 3553, size: 12,9 MiB.
+Memory blocks imported from other processes: 0, size: 0 B.
+Memory blocks exported to other processes: 0, size: 0 B.
+Total sample cache size: 0 B.
+Default sample spec: s16le 2ch 44100Hz
+Default channel map: front-left,front-right
+Default sink name: alsa_output.pci-0000_00_1b.0.analog-stereo
+Default source name: alsa_input.pci-0000_00_1b.0.analog-stereo
+Memory blocks of type POOL: 1 allocated/1700 accumulated.
+Memory blocks of type POOL_EXTERNAL: 0 allocated/999 accumulated.
+Memory blocks of type APPENDED: 0 allocated/0 accumulated.
+Memory blocks of type USER: 0 allocated/0 accumulated.
+Memory blocks of type FIXED: 0 allocated/1673 accumulated.
+Memory blocks of type IMPORTED: 0 allocated/180 accumulated.
+23 module(s) loaded.
+    index: 0
+	name: <module-device-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore the volume/mute state of devices"
+		module.version = "0.99.1"
+    index: 1
+	name: <module-stream-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore the volume/mute/device state of streams"
+		module.version = "0.99.1"
+    index: 2
+	name: <module-card-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore profile of cards"
+		module.version = "0.99.1"
+    index: 3
+	name: <module-augment-properties>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Augment the property sets of streams with additional static information"
+		module.version = "0.99.1"
+    index: 4
+	name: <module-alsa-card>
+	argument: <device_id="1" name="pci-0000_02_00.1" card_name="alsa_card.pci-0000_02_00.1" namereg_fail=false tsched=yes ignore_dB=no sync_volume=yes card_properties="module-udev-detect.discovered=1">
+	used: 0
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "ALSA Card"
+		module.version = "0.99.1"
+    index: 5
+	name: <module-alsa-card>
+	argument: <device_id="0" name="pci-0000_00_1b.0" card_name="alsa_card.pci-0000_00_1b.0" namereg_fail=false tsched=yes ignore_dB=no sync_volume=yes card_properties="module-udev-detect.discovered=1">
+	used: 0
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "ALSA Card"
+		module.version = "0.99.1"
+    index: 6
+	name: <module-udev-detect>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Detect available audio hardware and load matching drivers"
+		module.version = "0.99.1"
+    index: 7
+	name: <module-bluetooth-discover>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Joao Paulo Rechi Vita"
+		module.description = "Detect available bluetooth audio devices and load bluetooth audio drivers"
+		module.version = "0.99.1"
+    index: 8
+	name: <module-esound-protocol-unix>
+	argument: <>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "ESOUND protocol (UNIX sockets)"
+		module.version = "0.99.1"
+    index: 9
+	name: <module-native-protocol-unix>
+	argument: <>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Native protocol (UNIX sockets)"
+		module.version = "0.99.1"
+    index: 10
+	name: <module-dbus-protocol>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Tanu Kaskinen"
+		module.description = "D-Bus interface"
+		module.version = "0.99.1"
+    index: 11
+	name: <module-gconf>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "GConf Adapter"
+		module.version = "0.99.1"
+    index: 12
+	name: <module-default-device-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore the default sink and source"
+		module.version = "0.99.1"
+    index: 13
+	name: <module-rescue-streams>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "When a sink/source is removed, try to move their streams to the default sink/source"
+		module.version = "0.99.1"
+    index: 14
+	name: <module-always-sink>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Colin Guthrie"
+		module.description = "Always keeps at least one sink loaded even if it's a null one"
+		module.version = "0.99.1"
+    index: 15
+	name: <module-intended-roles>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically set device of streams based of intended roles of devices"
+		module.version = "0.99.1"
+    index: 16
+	name: <module-suspend-on-idle>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "When a sink/source is idle for too long, suspend it"
+		module.version = "0.99.1"
+    index: 17
+	name: <module-console-kit>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Create a client for each ConsoleKit session of this user"
+		module.version = "0.99.1"
+    index: 18
+	name: <module-position-event-sounds>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Position event sounds between L and R depending on the position on screen of the widget triggering them."
+		module.version = "0.99.1"
+    index: 19
+	name: <module-cork-music-on-phone>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Mute or cork music while a phone stream exists"
+		module.version = "0.99.1"
+    index: 20
+	name: <module-x11-publish>
+	argument: <display=:0>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "X11 credential publisher"
+		module.version = "0.99.1"
+    index: 21
+	name: <module-x11-xsmp>
+	argument: <display=:0 session_manager=local/wobolap:@/tmp/.ICE-unix/2658,unix/wobolap:/tmp/.ICE-unix/2658>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "X11 session management"
+		module.version = "0.99.1"
+    index: 22
+	name: <module-cli-protocol-unix>
+	argument: <>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Command line interface protocol (UNIX sockets)"
+		module.version = "0.99.1"
+2 sink(s) available.
+    index: 0
+	name: <alsa_output.pci-0000_02_00.1.hdmi-stereo>
+	driver: <module-alsa-card.c>
+	flags: HARDWARE DECIBEL_VOLUME LATENCY FLAT_VOLUME DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 9050
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume: 100%
+	             0,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max request: 0 KiB
+	max rewind: 0 KiB
+	monitor source: 0
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	card: 0 <alsa_card.pci-0000_02_00.1>
+	module: 4
+	properties:
+		alsa.resolution_bits = "16"
+		device.api = "alsa"
+		device.class = "sound"
+		alsa.class = "generic"
+		alsa.subclass = "generic-mix"
+		alsa.name = "HDMI 0"
+		alsa.id = "HDMI 0"
+		alsa.subdevice = "0"
+		alsa.subdevice_name = "subdevice #0"
+		alsa.device = "3"
+		alsa.card = "1"
+		alsa.card_name = "HDA NVidia"
+		alsa.long_card_name = "HDA NVidia at 0xcdefc000 irq 16"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:02:00.1"
+		sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:02:00.1/sound/card1"
+		device.bus = "pci"
+		device.vendor.id = "10de"
+		device.vendor.name = "nVidia Corporation"
+		device.product.id = "0be3"
+		device.product.name = "High Definition Audio Controller"
+		device.string = "hdmi:1"
+		device.buffering.buffer_size = "352768"
+		device.buffering.fragment_size = "176384"
+		device.access_mode = "mmap+timer"
+		device.profile.name = "hdmi-stereo"
+		device.profile.description = "Digital Stereo (HDMI)"
+		device.description = "High Definition Audio Controller Digital Stereo (HDMI)"
+		alsa.mixer_name = "Nvidia GPU 0b HDMI/DP"
+		alsa.components = "HDA:10de000b,10de0101,00100100"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+  * index: 1
+	name: <alsa_output.pci-0000_00_1b.0.analog-stereo>
+	driver: <module-alsa-card.c>
+	flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY FLAT_VOLUME DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 9959
+	volume: 0: 145% 1: 145%
+	        0: 9,64 dB 1: 9,64 dB
+	        balance 0,00
+	base volume:  96%
+	             -1,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max request: 0 KiB
+	max rewind: 0 KiB
+	monitor source: 1
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	card: 1 <alsa_card.pci-0000_00_1b.0>
+	module: 5
+	properties:
+		alsa.resolution_bits = "16"
+		device.api = "alsa"
+		device.class = "sound"
+		alsa.class = "generic"
+		alsa.subclass = "generic-mix"
+		alsa.name = "ALC269 Analog"
+		alsa.id = "ALC269 Analog"
+		alsa.subdevice = "0"
+		alsa.subdevice_name = "subdevice #0"
+		alsa.device = "0"
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "front:0"
+		device.buffering.buffer_size = "352768"
+		device.buffering.fragment_size = "176384"
+		device.access_mode = "mmap+timer"
+		device.profile.name = "analog-stereo"
+		device.profile.description = "Analog Stereo"
+		device.description = "Internal Audio Analog Stereo"
+		alsa.mixer_name = "Realtek ALC269"
+		alsa.components = "HDA:10ec0269,144dc06a,00100004"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	ports:
+		analog-output-speaker: Analog Speakers (priority 10000)
+		analog-output-headphones: Analog Headphones (priority 9000)
+	active port: <analog-output-speaker>
+3 source(s) available.
+    index: 0
+	name: <alsa_output.pci-0000_02_00.1.hdmi-stereo.monitor>
+	driver: <module-alsa-card.c>
+	flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 1050
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume: 100%
+	             0,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max rewind: 0 KiB
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	monitor_of: 0
+	card: 0 <alsa_card.pci-0000_02_00.1>
+	module: 4
+	properties:
+		device.description = "Monitor of High Definition Audio Controller Digital Stereo (HDMI)"
+		device.class = "monitor"
+		alsa.card = "1"
+		alsa.card_name = "HDA NVidia"
+		alsa.long_card_name = "HDA NVidia at 0xcdefc000 irq 16"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:02:00.1"
+		sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:02:00.1/sound/card1"
+		device.bus = "pci"
+		device.vendor.id = "10de"
+		device.vendor.name = "nVidia Corporation"
+		device.product.id = "0be3"
+		device.product.name = "High Definition Audio Controller"
+		device.string = "1"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+    index: 1
+	name: <alsa_output.pci-0000_00_1b.0.analog-stereo.monitor>
+	driver: <module-alsa-card.c>
+	flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 1950
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume: 100%
+	             0,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max rewind: 0 KiB
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	monitor_of: 1
+	card: 1 <alsa_card.pci-0000_00_1b.0>
+	module: 5
+	properties:
+		device.description = "Monitor of Internal Audio Analog Stereo"
+		device.class = "monitor"
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "0"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+  * index: 2
+	name: <alsa_input.pci-0000_00_1b.0.analog-stereo>
+	driver: <module-alsa-card.c>
+	flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 9959
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume:  10%
+	             -59,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max rewind: 0 KiB
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	card: 1 <alsa_card.pci-0000_00_1b.0>
+	module: 5
+	properties:
+		alsa.resolution_bits = "16"
+		device.api = "alsa"
+		device.class = "sound"
+		alsa.class = "generic"
+		alsa.subclass = "generic-mix"
+		alsa.name = "ALC269 Analog"
+		alsa.id = "ALC269 Analog"
+		alsa.subdevice = "0"
+		alsa.subdevice_name = "subdevice #0"
+		alsa.device = "0"
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "front:0"
+		device.buffering.buffer_size = "352768"
+		device.buffering.fragment_size = "176384"
+		device.access_mode = "mmap+timer"
+		device.profile.name = "analog-stereo"
+		device.profile.description = "Analog Stereo"
+		device.description = "Internal Audio Analog Stereo"
+		alsa.mixer_name = "Realtek ALC269"
+		alsa.components = "HDA:10ec0269,144dc06a,00100004"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	ports:
+		analog-input-microphone-internal: Internal Microphone (priority 8900)
+		analog-input-microphone: Analog Microphone (priority 8900)
+	active port: <analog-input-microphone>
+8 client(s) logged in.
+    index: 0
+	driver: <module-console-kit.c>
+	owner module: 17
+	properties:
+		application.name = "ConsoleKit Session /org/freedesktop/ConsoleKit/Session11"
+		console-kit.session = "/org/freedesktop/ConsoleKit/Session11"
+    index: 1
+	driver: <module-console-kit.c>
+	owner module: 17
+	properties:
+		application.name = "ConsoleKit Session /org/freedesktop/ConsoleKit/Session1"
+		console-kit.session = "/org/freedesktop/ConsoleKit/Session1"
+    index: 2
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Volume Control Media Keys"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		application.id = "org.gnome.VolumeControl"
+		application.icon_name = "multimedia-volume-control"
+		application.version = "3.1.4"
+		application.process.id = "2677"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-settings-daemon"
+		application.language = "en_US.UTF-8"
+		window.x11.display = ":0"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 5
+	driver: <module-x11-xsmp.c>
+	owner module: 21
+	properties:
+		application.name = "XSMP Session on gnome-session as 10894f35148fe4e071131237412814306200000026580030"
+		xsmp.vendor = "gnome-session"
+		xsmp.client.id = "10894f35148fe4e071131237412814306200000026580030"
+    index: 7
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Shell"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		application.id = "org.gnome.Shell"
+		application.process.id = "2834"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-shell"
+		application.language = "en_US.UTF-8"
+		window.x11.display = ":0"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 8
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Shell Volume Control"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		application.id = "org.gnome.VolumeControl"
+		application.icon_name = "multimedia-volume-control"
+		application.version = "3.1.4"
+		application.process.id = "2834"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-shell"
+		application.language = "en_US.UTF-8"
+		window.x11.display = ":0"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 10
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Shell"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		window.x11.display = ":0"
+		window.x11.screen = "0"
+		application.process.id = "2834"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-shell"
+		application.language = "en_US.UTF-8"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 15
+	driver: <cli.c>
+	owner module: 22
+	properties:
+		application.name = "UNIX socket client"
+2 card(s) available.
+    index: 0
+	name: <alsa_card.pci-0000_02_00.1>
+	driver: <module-alsa-card.c>
+	owner module: 4
+	properties:
+		alsa.card = "1"
+		alsa.card_name = "HDA NVidia"
+		alsa.long_card_name = "HDA NVidia at 0xcdefc000 irq 16"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:02:00.1"
+		sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:02:00.1/sound/card1"
+		device.bus = "pci"
+		device.vendor.id = "10de"
+		device.vendor.name = "nVidia Corporation"
+		device.product.id = "0be3"
+		device.product.name = "High Definition Audio Controller"
+		device.string = "1"
+		device.description = "High Definition Audio Controller"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	profiles:
+		output:hdmi-stereo: Digital Stereo (HDMI) Output (priority 5400)
+		off: Off (priority 0)
+	active profile: <output:hdmi-stereo>
+	sinks:
+		alsa_output.pci-0000_02_00.1.hdmi-stereo/#0: High Definition Audio Controller Digital Stereo (HDMI)
+	sources:
+		alsa_output.pci-0000_02_00.1.hdmi-stereo.monitor/#0: Monitor of High Definition Audio Controller Digital Stereo (HDMI)
+    index: 1
+	name: <alsa_card.pci-0000_00_1b.0>
+	driver: <module-alsa-card.c>
+	owner module: 5
+	properties:
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "0"
+		device.description = "Internal Audio"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	profiles:
+		output:analog-stereo: Analog Stereo Output (priority 6000)
+		output:analog-stereo+input:analog-stereo: Analog Stereo Duplex (priority 6060)
+		output:analog-surround-40: Analog Surround 4.0 Output (priority 700)
+		output:analog-surround-40+input:analog-stereo: Analog Surround 4.0 Output + Analog Stereo Input (priority 760)
+		input:analog-stereo: Analog Stereo Input (priority 60)
+		off: Off (priority 0)
+	active profile: <output:analog-stereo+input:analog-stereo>
+	sinks:
+		alsa_output.pci-0000_00_1b.0.analog-stereo/#1: Internal Audio Analog Stereo
+	sources:
+		alsa_output.pci-0000_00_1b.0.analog-stereo.monitor/#1: Monitor of Internal Audio Analog Stereo
+		alsa_input.pci-0000_00_1b.0.analog-stereo/#2: Internal Audio Analog Stereo
+0 sink input(s) available.
+0 source outputs(s) available.
+0 cache entrie(s) available.
+>>> 
+-------------- next part --------------
+Welcome to PulseAudio! Use "help" for usage information.
+>>> Memory blocks currently allocated: 1, size: 63,9 KiB.
+Memory blocks allocated during the whole lifetime: 21306, size: 53,7 MiB.
+Memory blocks imported from other processes: 0, size: 0 B.
+Memory blocks exported to other processes: 0, size: 0 B.
+Total sample cache size: 0 B.
+Default sample spec: s16le 2ch 44100Hz
+Default channel map: front-left,front-right
+Default sink name: alsa_output.pci-0000_00_1b.0.analog-stereo
+Default source name: alsa_input.pci-0000_00_1b.0.analog-stereo
+Memory blocks of type POOL: 1 allocated/15958 accumulated.
+Memory blocks of type POOL_EXTERNAL: 0 allocated/999 accumulated.
+Memory blocks of type APPENDED: 0 allocated/0 accumulated.
+Memory blocks of type USER: 0 allocated/0 accumulated.
+Memory blocks of type FIXED: 0 allocated/2345 accumulated.
+Memory blocks of type IMPORTED: 0 allocated/3003 accumulated.
+23 module(s) loaded.
+    index: 0
+	name: <module-device-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore the volume/mute state of devices"
+		module.version = "0.99.1"
+    index: 1
+	name: <module-stream-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore the volume/mute/device state of streams"
+		module.version = "0.99.1"
+    index: 2
+	name: <module-card-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore profile of cards"
+		module.version = "0.99.1"
+    index: 3
+	name: <module-augment-properties>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Augment the property sets of streams with additional static information"
+		module.version = "0.99.1"
+    index: 4
+	name: <module-alsa-card>
+	argument: <device_id="1" name="pci-0000_02_00.1" card_name="alsa_card.pci-0000_02_00.1" namereg_fail=false tsched=yes ignore_dB=no sync_volume=yes card_properties="module-udev-detect.discovered=1">
+	used: 0
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "ALSA Card"
+		module.version = "0.99.1"
+    index: 5
+	name: <module-alsa-card>
+	argument: <device_id="0" name="pci-0000_00_1b.0" card_name="alsa_card.pci-0000_00_1b.0" namereg_fail=false tsched=yes ignore_dB=no sync_volume=yes card_properties="module-udev-detect.discovered=1">
+	used: 0
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "ALSA Card"
+		module.version = "0.99.1"
+    index: 6
+	name: <module-udev-detect>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Detect available audio hardware and load matching drivers"
+		module.version = "0.99.1"
+    index: 7
+	name: <module-bluetooth-discover>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Joao Paulo Rechi Vita"
+		module.description = "Detect available bluetooth audio devices and load bluetooth audio drivers"
+		module.version = "0.99.1"
+    index: 8
+	name: <module-esound-protocol-unix>
+	argument: <>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "ESOUND protocol (UNIX sockets)"
+		module.version = "0.99.1"
+    index: 9
+	name: <module-native-protocol-unix>
+	argument: <>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Native protocol (UNIX sockets)"
+		module.version = "0.99.1"
+    index: 10
+	name: <module-dbus-protocol>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Tanu Kaskinen"
+		module.description = "D-Bus interface"
+		module.version = "0.99.1"
+    index: 11
+	name: <module-gconf>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "GConf Adapter"
+		module.version = "0.99.1"
+    index: 12
+	name: <module-default-device-restore>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically restore the default sink and source"
+		module.version = "0.99.1"
+    index: 13
+	name: <module-rescue-streams>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "When a sink/source is removed, try to move their streams to the default sink/source"
+		module.version = "0.99.1"
+    index: 14
+	name: <module-always-sink>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Colin Guthrie"
+		module.description = "Always keeps at least one sink loaded even if it's a null one"
+		module.version = "0.99.1"
+    index: 15
+	name: <module-intended-roles>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Automatically set device of streams based of intended roles of devices"
+		module.version = "0.99.1"
+    index: 16
+	name: <module-suspend-on-idle>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "When a sink/source is idle for too long, suspend it"
+		module.version = "0.99.1"
+    index: 17
+	name: <module-console-kit>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Create a client for each ConsoleKit session of this user"
+		module.version = "0.99.1"
+    index: 18
+	name: <module-position-event-sounds>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Position event sounds between L and R depending on the position on screen of the widget triggering them."
+		module.version = "0.99.1"
+    index: 19
+	name: <module-cork-music-on-phone>
+	argument: <>
+	used: -1
+	load once: yes
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Mute or cork music while a phone stream exists"
+		module.version = "0.99.1"
+    index: 20
+	name: <module-x11-publish>
+	argument: <display=:0>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "X11 credential publisher"
+		module.version = "0.99.1"
+    index: 21
+	name: <module-x11-xsmp>
+	argument: <display=:0 session_manager=local/wobolap:@/tmp/.ICE-unix/2658,unix/wobolap:/tmp/.ICE-unix/2658>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "X11 session management"
+		module.version = "0.99.1"
+    index: 22
+	name: <module-cli-protocol-unix>
+	argument: <>
+	used: -1
+	load once: no
+	properties:
+		module.author = "Lennart Poettering"
+		module.description = "Command line interface protocol (UNIX sockets)"
+		module.version = "0.99.1"
+2 sink(s) available.
+    index: 0
+	name: <alsa_output.pci-0000_02_00.1.hdmi-stereo>
+	driver: <module-alsa-card.c>
+	flags: HARDWARE DECIBEL_VOLUME LATENCY FLAT_VOLUME DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 9050
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume: 100%
+	             0,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max request: 0 KiB
+	max rewind: 0 KiB
+	monitor source: 0
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	card: 0 <alsa_card.pci-0000_02_00.1>
+	module: 4
+	properties:
+		alsa.resolution_bits = "16"
+		device.api = "alsa"
+		device.class = "sound"
+		alsa.class = "generic"
+		alsa.subclass = "generic-mix"
+		alsa.name = "HDMI 0"
+		alsa.id = "HDMI 0"
+		alsa.subdevice = "0"
+		alsa.subdevice_name = "subdevice #0"
+		alsa.device = "3"
+		alsa.card = "1"
+		alsa.card_name = "HDA NVidia"
+		alsa.long_card_name = "HDA NVidia at 0xcdefc000 irq 16"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:02:00.1"
+		sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:02:00.1/sound/card1"
+		device.bus = "pci"
+		device.vendor.id = "10de"
+		device.vendor.name = "nVidia Corporation"
+		device.product.id = "0be3"
+		device.product.name = "High Definition Audio Controller"
+		device.string = "hdmi:1"
+		device.buffering.buffer_size = "352768"
+		device.buffering.fragment_size = "176384"
+		device.access_mode = "mmap+timer"
+		device.profile.name = "hdmi-stereo"
+		device.profile.description = "Digital Stereo (HDMI)"
+		device.description = "High Definition Audio Controller Digital Stereo (HDMI)"
+		alsa.mixer_name = "Nvidia GPU 0b HDMI/DP"
+		alsa.components = "HDA:10de000b,10de0101,00100100"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+  * index: 1
+	name: <alsa_output.pci-0000_00_1b.0.analog-stereo>
+	driver: <module-alsa-card.c>
+	flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY FLAT_VOLUME DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 9959
+	volume: 0: 145% 1: 145%
+	        0: 9,64 dB 1: 9,64 dB
+	        balance 0,00
+	base volume:  96%
+	             -1,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max request: 0 KiB
+	max rewind: 0 KiB
+	monitor source: 1
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	card: 1 <alsa_card.pci-0000_00_1b.0>
+	module: 5
+	properties:
+		alsa.resolution_bits = "16"
+		device.api = "alsa"
+		device.class = "sound"
+		alsa.class = "generic"
+		alsa.subclass = "generic-mix"
+		alsa.name = "ALC269 Analog"
+		alsa.id = "ALC269 Analog"
+		alsa.subdevice = "0"
+		alsa.subdevice_name = "subdevice #0"
+		alsa.device = "0"
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "front:0"
+		device.buffering.buffer_size = "352768"
+		device.buffering.fragment_size = "176384"
+		device.access_mode = "mmap+timer"
+		device.profile.name = "analog-stereo"
+		device.profile.description = "Analog Stereo"
+		device.description = "Internal Audio Analog Stereo"
+		alsa.mixer_name = "Realtek ALC269"
+		alsa.components = "HDA:10ec0269,144dc06a,00100004"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	ports:
+		analog-output-speaker: Analog Speakers (priority 10000)
+		analog-output-headphones: Analog Headphones (priority 9000)
+	active port: <analog-output-speaker>
+3 source(s) available.
+    index: 0
+	name: <alsa_output.pci-0000_02_00.1.hdmi-stereo.monitor>
+	driver: <module-alsa-card.c>
+	flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 1050
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume: 100%
+	             0,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max rewind: 0 KiB
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	monitor_of: 0
+	card: 0 <alsa_card.pci-0000_02_00.1>
+	module: 4
+	properties:
+		device.description = "Monitor of High Definition Audio Controller Digital Stereo (HDMI)"
+		device.class = "monitor"
+		alsa.card = "1"
+		alsa.card_name = "HDA NVidia"
+		alsa.long_card_name = "HDA NVidia at 0xcdefc000 irq 16"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:02:00.1"
+		sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:02:00.1/sound/card1"
+		device.bus = "pci"
+		device.vendor.id = "10de"
+		device.vendor.name = "nVidia Corporation"
+		device.product.id = "0be3"
+		device.product.name = "High Definition Audio Controller"
+		device.string = "1"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+    index: 1
+	name: <alsa_output.pci-0000_00_1b.0.analog-stereo.monitor>
+	driver: <module-alsa-card.c>
+	flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 1950
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume: 100%
+	             0,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max rewind: 0 KiB
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	monitor_of: 1
+	card: 1 <alsa_card.pci-0000_00_1b.0>
+	module: 5
+	properties:
+		device.description = "Monitor of Internal Audio Analog Stereo"
+		device.class = "monitor"
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "0"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+  * index: 2
+	name: <alsa_input.pci-0000_00_1b.0.analog-stereo>
+	driver: <module-alsa-card.c>
+	flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
+	state: SUSPENDED
+	suspend cause: IDLE 
+	priority: 9959
+	volume: 0: 100% 1: 100%
+	        0: 0,00 dB 1: 0,00 dB
+	        balance 0,00
+	base volume:  10%
+	             -59,00 dB
+	volume steps: 65537
+	muted: no
+	current latency: 0,00 ms
+	max rewind: 0 KiB
+	sample spec: s16le 2ch 44100Hz
+	channel map: front-left,front-right
+	             Stereo
+	used by: 0
+	linked by: 0
+	configured latency: 0,00 ms; range is 0,50 .. 1999,82 ms
+	card: 1 <alsa_card.pci-0000_00_1b.0>
+	module: 5
+	properties:
+		alsa.resolution_bits = "16"
+		device.api = "alsa"
+		device.class = "sound"
+		alsa.class = "generic"
+		alsa.subclass = "generic-mix"
+		alsa.name = "ALC269 Analog"
+		alsa.id = "ALC269 Analog"
+		alsa.subdevice = "0"
+		alsa.subdevice_name = "subdevice #0"
+		alsa.device = "0"
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "front:0"
+		device.buffering.buffer_size = "352768"
+		device.buffering.fragment_size = "176384"
+		device.access_mode = "mmap+timer"
+		device.profile.name = "analog-stereo"
+		device.profile.description = "Analog Stereo"
+		device.description = "Internal Audio Analog Stereo"
+		alsa.mixer_name = "Realtek ALC269"
+		alsa.components = "HDA:10ec0269,144dc06a,00100004"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	ports:
+		analog-input-microphone-internal: Internal Microphone (priority 8900)
+		analog-input-microphone: Analog Microphone (priority 8900)
+	active port: <analog-input-microphone>
+8 client(s) logged in.
+    index: 0
+	driver: <module-console-kit.c>
+	owner module: 17
+	properties:
+		application.name = "ConsoleKit Session /org/freedesktop/ConsoleKit/Session11"
+		console-kit.session = "/org/freedesktop/ConsoleKit/Session11"
+    index: 1
+	driver: <module-console-kit.c>
+	owner module: 17
+	properties:
+		application.name = "ConsoleKit Session /org/freedesktop/ConsoleKit/Session1"
+		console-kit.session = "/org/freedesktop/ConsoleKit/Session1"
+    index: 2
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Volume Control Media Keys"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		application.id = "org.gnome.VolumeControl"
+		application.icon_name = "multimedia-volume-control"
+		application.version = "3.1.4"
+		application.process.id = "2677"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-settings-daemon"
+		application.language = "en_US.UTF-8"
+		window.x11.display = ":0"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 5
+	driver: <module-x11-xsmp.c>
+	owner module: 21
+	properties:
+		application.name = "XSMP Session on gnome-session as 10894f35148fe4e071131237412814306200000026580030"
+		xsmp.vendor = "gnome-session"
+		xsmp.client.id = "10894f35148fe4e071131237412814306200000026580030"
+    index: 7
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Shell"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		application.id = "org.gnome.Shell"
+		application.process.id = "2834"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-shell"
+		application.language = "en_US.UTF-8"
+		window.x11.display = ":0"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 8
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Shell Volume Control"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		application.id = "org.gnome.VolumeControl"
+		application.icon_name = "multimedia-volume-control"
+		application.version = "3.1.4"
+		application.process.id = "2834"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-shell"
+		application.language = "en_US.UTF-8"
+		window.x11.display = ":0"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 10
+	driver: <protocol-native.c>
+	owner module: 9
+	properties:
+		application.name = "GNOME Shell"
+		native-protocol.peer = "UNIX socket client"
+		native-protocol.version = "23"
+		window.x11.display = ":0"
+		window.x11.screen = "0"
+		application.process.id = "2834"
+		application.process.user = "wobo"
+		application.process.host = "wobolap"
+		application.process.binary = "gnome-shell"
+		application.language = "en_US.UTF-8"
+		application.process.machine_id = "f6057340281881c56233ba3f0000008f"
+		application.process.session_id = "f6057340281881c56233ba3f0000008f-1312374123.38554-1006383499"
+    index: 17
+	driver: <cli.c>
+	owner module: 22
+	properties:
+		application.name = "UNIX socket client"
+2 card(s) available.
+    index: 0
+	name: <alsa_card.pci-0000_02_00.1>
+	driver: <module-alsa-card.c>
+	owner module: 4
+	properties:
+		alsa.card = "1"
+		alsa.card_name = "HDA NVidia"
+		alsa.long_card_name = "HDA NVidia at 0xcdefc000 irq 16"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:02:00.1"
+		sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:02:00.1/sound/card1"
+		device.bus = "pci"
+		device.vendor.id = "10de"
+		device.vendor.name = "nVidia Corporation"
+		device.product.id = "0be3"
+		device.product.name = "High Definition Audio Controller"
+		device.string = "1"
+		device.description = "High Definition Audio Controller"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	profiles:
+		output:hdmi-stereo: Digital Stereo (HDMI) Output (priority 5400)
+		off: Off (priority 0)
+	active profile: <output:hdmi-stereo>
+	sinks:
+		alsa_output.pci-0000_02_00.1.hdmi-stereo/#0: High Definition Audio Controller Digital Stereo (HDMI)
+	sources:
+		alsa_output.pci-0000_02_00.1.hdmi-stereo.monitor/#0: Monitor of High Definition Audio Controller Digital Stereo (HDMI)
+    index: 1
+	name: <alsa_card.pci-0000_00_1b.0>
+	driver: <module-alsa-card.c>
+	owner module: 5
+	properties:
+		alsa.card = "0"
+		alsa.card_name = "HDA Intel"
+		alsa.long_card_name = "HDA Intel at 0xf0b00000 irq 43"
+		alsa.driver_name = "snd_hda_intel"
+		device.bus_path = "pci-0000:00:1b.0"
+		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
+		device.bus = "pci"
+		device.vendor.id = "8086"
+		device.vendor.name = "Intel Corporation"
+		device.product.id = "3b56"
+		device.product.name = "5 Series/3400 Series Chipset High Definition Audio"
+		device.form_factor = "internal"
+		device.string = "0"
+		device.description = "Internal Audio"
+		module-udev-detect.discovered = "1"
+		device.icon_name = "audio-card-pci"
+	profiles:
+		output:analog-stereo: Analog Stereo Output (priority 6000)
+		output:analog-stereo+input:analog-stereo: Analog Stereo Duplex (priority 6060)
+		output:analog-surround-40: Analog Surround 4.0 Output (priority 700)
+		output:analog-surround-40+input:analog-stereo: Analog Surround 4.0 Output + Analog Stereo Input (priority 760)
+		input:analog-stereo: Analog Stereo Input (priority 60)
+		off: Off (priority 0)
+	active profile: <output:analog-stereo+input:analog-stereo>
+	sinks:
+		alsa_output.pci-0000_00_1b.0.analog-stereo/#1: Internal Audio Analog Stereo
+	sources:
+		alsa_output.pci-0000_00_1b.0.analog-stereo.monitor/#1: Monitor of Internal Audio Analog Stereo
+		alsa_input.pci-0000_00_1b.0.analog-stereo/#2: Internal Audio Analog Stereo
+0 sink input(s) available.
+0 source outputs(s) available.
+0 cache entrie(s) available.
+>>> 
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007216.html b/zarb-ml/mageia-dev/2011-August/007216.html new file mode 100644 index 000000000..4421de82a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007216.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Marianne Lombard + marianne at tuxette.fr +
+ Wed Aug 3 19:50:17 CEST 2011 +

+
+ +
Le 03/08/2011 13:51, Balcaen John a écrit :
+> Le Mercredi 3 Août 2011 16:49:20 Kira a écrit :
+>> 在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John<mikala at mageia.org>寫道:
+>>> With this  gnutls upgrade&  switch to nettle backend support only
+>>> telepathy-gabble (at least since i'm using it daily) is  broken
+>>> but
+>>> maybe more things are broken now since there some  API/ABI changes
+>>> with this 3.0 release, could you fix it please ( as reminder the
+>>> nettle backend support was not supported by telepathy-gabble one
+>>> month ago when you did switch on nettle backend support only for
+>>> the 2.12.7 release cf
+>>> https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+>> Is it only me that aria2 completely broke up after update
+> Someone told that the last aria2 was broken after this update too on
+> irc, so there is at least two people :p
+>
+I confirm what mikala is saying. Since yesterday update, aria2 looks 
+broken (or at least not totally functionnal) :
+> [jehane at bleuet ~]$ sudo urpmi --auto-update
+> WARNING: no socket to connect to
+> le média « Core Release » est à jour
+> WARNING: no socket to connect to
+> le média « Core Updates » est à jour
+> WARNING: no socket to connect to
+> le média « Nonfree Release » est à jour
+> WARNING: no socket to connect to
+> le média « Nonfree Updates » est à jour
+> WARNING: no socket to connect to
+> le média « Tainted Release » est à jour
+> WARNING: no socket to connect to
+> le média « Tainted Updates » est à jour
+> WARNING: no socket to connect to
+> le média « Core 32bit Release » est à jour
+> WARNING: no socket to connect to
+> le média « Core 32bit Updates » est à jour
+> Afin de poursuivre la mise à jour, le paquetage suivant doit être 
+> désinstallé :
+> lib64pulsezeroconf0-0.9.23-1.mga2.x86_64
+>  (en raison du manque de libpulsecommon-0.9.23.so()(64bit)) (o/N)
+
+Can you be more careful when you update something related to the "core 
+tools" of the distribution ?
+
+  Regards
+
+
+
+-- 
+Marianne Lombard (Jehane)
+Mageia User - Mageia french translation team
+Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007217.html b/zarb-ml/mageia-dev/2011-August/007217.html new file mode 100644 index 000000000..e91c0053c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007217.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Marianne Lombard + marianne at tuxette.fr +
+ Wed Aug 3 19:54:14 CEST 2011 +

+
+ +
Le 03/08/2011 13:51, Balcaen John a écrit :
+> Le Mercredi 3 Août 2011 16:49:20 Kira a écrit :
+>> 在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John<mikala at mageia.org>寫道:
+>>> With this  gnutls upgrade&  switch to nettle backend support only
+>>> telepathy-gabble (at least since i'm using it daily) is  broken
+>>> but
+>>> maybe more things are broken now since there some  API/ABI changes
+>>> with this 3.0 release, could you fix it please ( as reminder the
+>>> nettle backend support was not supported by telepathy-gabble one
+>>> month ago when you did switch on nettle backend support only for
+>>> the 2.12.7 release cf
+>>> https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+>> Is it only me that aria2 completely broke up after update
+> Someone told that the last aria2 was broken after this update too on
+> irc, so there is at least two people :p
+>
+Liferea is broken too (not a vital software but it's nice to reed his feed)
+> [jehane at bleuet ~]$ liferea
+> liferea: symbol lookup error: /usr/lib64/gio/modules/libgiognutls.so: 
+> undefined symbol: gnutls_certificate_verify_peers
+
+Regards
+
+-- 
+Marianne Lombard (Jehane)
+Mageia User - Mageia french translation team
+Inside every fat girl, there is a thin girl waiting to get out (and a lot of chocolate) - Terry Pratchett
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007218.html b/zarb-ml/mageia-dev/2011-August/007218.html new file mode 100644 index 000000000..48f521098 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007218.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] group names? + + + + + + + + + +

[Mageia-dev] group names?

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Wed Aug 3 20:18:41 CEST 2011 +

+
+ +
- log4cpp-doc-1.0-0.mga2.i586:
+ - non-standard-group Documentation
+
+what should be the group, or a link in wiki to check the correct names?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007219.html b/zarb-ml/mageia-dev/2011-August/007219.html new file mode 100644 index 000000000..ab534621e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007219.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ John Balcaen + mikala at mageia.org +
+ Wed Aug 3 20:26:52 CEST 2011 +

+
+ +
2011/8/3 Marianne Lombard <marianne at tuxette.fr>:
+> Le 03/08/2011 13:51, Balcaen John a écrit :
+>>
+>> Le Mercredi 3 Août 2011 16:49:20 Kira a écrit :
+>>>
+>>> 在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John<mikala at mageia.org>寫道:
+>>>>
+>>>> With this  gnutls upgrade&  switch to nettle backend support only
+>>>> telepathy-gabble (at least since i'm using it daily) is  broken
+>>>> but
+>>>> maybe more things are broken now since there some  API/ABI changes
+>>>> with this 3.0 release, could you fix it please ( as reminder the
+>>>> nettle backend support was not supported by telepathy-gabble one
+>>>> month ago when you did switch on nettle backend support only for
+>>>> the 2.12.7 release cf
+>>>> https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+>>>
+>>> Is it only me that aria2 completely broke up after update
+>>
+>> Someone told that the last aria2 was broken after this update too on
+>> irc, so there is at least two people :p
+>>
+> Liferea is broken too (not a vital software but it's nice to reed his feed)
+>>
+>> [jehane at bleuet ~]$ liferea
+>> liferea: symbol lookup error: /usr/lib64/gio/modules/libgiognutls.so:
+>> undefined symbol: gnutls_certificate_verify_peers
+It's not available anymore with gnutls 3.0 (cf
+http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5243
+), but liferea has not been rebuild for the new gnutls so we need at
+least to try a rebuild.
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007220.html b/zarb-ml/mageia-dev/2011-August/007220.html new file mode 100644 index 000000000..eba999d9b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007220.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] group names? + + + + + + + + + +

[Mageia-dev] group names?

+ John Balcaen + mikala at mageia.org +
+ Wed Aug 3 20:32:17 CEST 2011 +

+
+ +
2011/8/3 Luis Daniel Lucio Quiroz <dlucio at okay.com.mx>:
+> - log4cpp-doc-1.0-0.mga2.i586:
+>  - non-standard-group Documentation
+>
+> what should be the group, or a link in wiki to check the correct names?
+http://www.mageia.org/wiki/doku.php?id=rpm_groups
+
+Regards,
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007221.html b/zarb-ml/mageia-dev/2011-August/007221.html new file mode 100644 index 000000000..b271aaaa8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007221.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] group names? + + + + + + + + + +

[Mageia-dev] group names?

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Wed Aug 3 20:46:19 CEST 2011 +

+
+ +
Le Mercredi 03 Août 2011 15:32:17 John Balcaen a écrit :
+> 2011/8/3 Luis Daniel Lucio Quiroz <dlucio at okay.com.mx>:
+> > - log4cpp-doc-1.0-0.mga2.i586:
+> >  - non-standard-group Documentation
+> > 
+> > what should be the group, or a link in wiki to check the correct names?
+> 
+> http://www.mageia.org/wiki/doku.php?id=rpm_groups
+> 
+> Regards,
+
+Thanks
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007222.html b/zarb-ml/mageia-dev/2011-August/007222.html new file mode 100644 index 000000000..043b7ebfc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007222.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ John Balcaen + mikala at mageia.org +
+ Wed Aug 3 21:13:37 CEST 2011 +

+
+ +
2011/8/3 John Balcaen <mikala at mageia.org>:
+> 2011/8/3 Marianne Lombard <marianne at tuxette.fr>:
+>> Le 03/08/2011 13:51, Balcaen John a écrit :
+>>>
+>>> Le Mercredi 3 Août 2011 16:49:20 Kira a écrit :
+>>>>
+>>>> 在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John<mikala at mageia.org>寫道:
+>>>>>
+>>>>> With this  gnutls upgrade&  switch to nettle backend support only
+>>>>> telepathy-gabble (at least since i'm using it daily) is  broken
+>>>>> but
+>>>>> maybe more things are broken now since there some  API/ABI changes
+>>>>> with this 3.0 release, could you fix it please ( as reminder the
+>>>>> nettle backend support was not supported by telepathy-gabble one
+>>>>> month ago when you did switch on nettle backend support only for
+>>>>> the 2.12.7 release cf
+>>>>> https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+>>>>
+>>>> Is it only me that aria2 completely broke up after update
+>>>
+>>> Someone told that the last aria2 was broken after this update too on
+>>> irc, so there is at least two people :p
+>>>
+>> Liferea is broken too (not a vital software but it's nice to reed his feed)
+>>>
+>>> [jehane at bleuet ~]$ liferea
+>>> liferea: symbol lookup error: /usr/lib64/gio/modules/libgiognutls.so:
+>>> undefined symbol: gnutls_certificate_verify_peers
+> It's not available anymore with gnutls 3.0 (cf
+> http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5243
+> ), but liferea has not been rebuild for the new gnutls so we need at
+> least to try a rebuild.
+Well i pushed a rebuild of 1.6.6b but i guess it won't work since the 1.7.6
+build locally(in iurt) is also failing with the same error. (which is
+normal since
+it's not available anymore in gnutls 3.0)
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007223.html b/zarb-ml/mageia-dev/2011-August/007223.html new file mode 100644 index 000000000..39df94a7f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007223.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ D.Morgan + dmorganec at gmail.com +
+ Wed Aug 3 22:43:21 CEST 2011 +

+
+ +
On Wed, Aug 3, 2011 at 7:50 PM, Marianne Lombard <marianne at tuxette.fr> wrote:
+> Le 03/08/2011 13:51, Balcaen John a écrit :
+>>
+>> Le Mercredi 3 Août 2011 16:49:20 Kira a écrit :
+>>>
+>>> 在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John<mikala at mageia.org>寫道:
+>>>>
+>>>> With this  gnutls upgrade&  switch to nettle backend support only
+>>>> telepathy-gabble (at least since i'm using it daily) is  broken
+>>>> but
+>>>> maybe more things are broken now since there some  API/ABI changes
+>>>> with this 3.0 release, could you fix it please ( as reminder the
+>>>> nettle backend support was not supported by telepathy-gabble one
+>>>> month ago when you did switch on nettle backend support only for
+>>>> the 2.12.7 release cf
+>>>> https://mageia.org/pipermail/mageia-dev/2011-June/005996.html ).
+>>>
+>>> Is it only me that aria2 completely broke up after update
+>>
+>> Someone told that the last aria2 was broken after this update too on
+>> irc, so there is at least two people :p
+>>
+> I confirm what mikala is saying. Since yesterday update, aria2 looks broken
+> (or at least not totally functionnal) :
+>>
+>> [jehane at bleuet ~]$ sudo urpmi --auto-update
+>> WARNING: no socket to connect to
+>> le média « Core Release » est à jour
+>> WARNING: no socket to connect to
+>> le média « Core Updates » est à jour
+>> WARNING: no socket to connect to
+>> le média « Nonfree Release » est à jour
+>> WARNING: no socket to connect to
+>> le média « Nonfree Updates » est à jour
+>> WARNING: no socket to connect to
+>> le média « Tainted Release » est à jour
+>> WARNING: no socket to connect to
+>> le média « Tainted Updates » est à jour
+>> WARNING: no socket to connect to
+>> le média « Core 32bit Release » est à jour
+>> WARNING: no socket to connect to
+>> le média « Core 32bit Updates » est à jour
+>> Afin de poursuivre la mise à jour, le paquetage suivant doit être
+>> désinstallé :
+>> lib64pulsezeroconf0-0.9.23-1.mga2.x86_64
+>>  (en raison du manque de libpulsecommon-0.9.23.so()(64bit)) (o/N)
+>
+> Can you be more careful when you update something related to the "core
+> tools" of the distribution ?
+>
+what ? the error here is about PA not to gnutls
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007224.html b/zarb-ml/mageia-dev/2011-August/007224.html new file mode 100644 index 000000000..a5b7acdd1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007224.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Wed Aug 3 23:16:51 CEST 2011 +

+
+ +
Le Mercredi 3 Août 2011 22:43:21 D.Morgan a écrit :
+[...]
+> 
+> what ? the error here is about PA not to gnutls
+She's talking about the 
+« WARNING: no socket to connect to  »
+warning i guess.
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007225.html b/zarb-ml/mageia-dev/2011-August/007225.html new file mode 100644 index 000000000..ac7a38af0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007225.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ D.Morgan + dmorganec at gmail.com +
+ Wed Aug 3 23:35:37 CEST 2011 +

+
+ +
On Wed, Aug 3, 2011 at 11:16 PM, Balcaen John <mikala at mageia.org> wrote:
+> Le Mercredi 3 Août 2011 22:43:21 D.Morgan a écrit :
+> [...]
+>>
+>> what ? the error here is about PA not to gnutls
+> She's talking about the
+> « WARNING: no socket to connect to  »
+> warning i guess.
+>
+> Regards,
+>
+> --
+> Balcaen John
+>
+
+ah and this is gnutls errors ?
+
+Just for the infos after the last cauldron update aria seems to works
+fine. ( except the « WARNING: no socket to connect to  » errors that i
+don't understand for the moment.
+
+but it "works" ;)
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007226.html b/zarb-ml/mageia-dev/2011-August/007226.html new file mode 100644 index 000000000..591a2d06f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007226.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Thu Aug 4 00:56:04 CEST 2011 +

+
+ +
Le Mercredi 3 Août 2011 19:54:14 Marianne Lombard a écrit :
+> Le 03/08/2011 13:51, Balcaen John a écrit :
+> > Le Mercredi 3 Août 2011 16:49:20 Kira a écrit :
+> >> 在 Wed, 03 Aug 2011 10:31:39 +0800, Balcaen John<mikala at mageia.org>寫
+道:
+> >>> With this  gnutls upgrade&  switch to nettle backend support
+> >>> only
+> >>> telepathy-gabble (at least since i'm using it daily) is 
+> >>> broken
+> >>> but
+> >>> maybe more things are broken now since there some  API/ABI
+> >>> changes with this 3.0 release, could you fix it please ( as
+> >>> reminder the nettle backend support was not supported by
+> >>> telepathy-gabble one month ago when you did switch on nettle
+> >>> backend support only for the 2.12.7 release cf
+> >>> https://mageia.org/pipermail/mageia-dev/2011-June/005996.html
+> >>> ).
+> >> 
+> >> Is it only me that aria2 completely broke up after update
+> > 
+> > Someone told that the last aria2 was broken after this update too
+> > on irc, so there is at least two people :p
+> 
+> Liferea is broken too (not a vital software but it's nice to reed his
+> feed)
+> > [jehane at bleuet ~]$ liferea
+> > liferea: symbol lookup error:
+> > /usr/lib64/gio/modules/libgiognutls.so: undefined symbol:
+> > gnutls_certificate_verify_peers
+Ok it should be fixed soon by the patch from dmorgan to part to the new 
+gnutls api.
+
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007227.html b/zarb-ml/mageia-dev/2011-August/007227.html new file mode 100644 index 000000000..f0de97f06 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007227.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ D.Morgan + dmorganec at gmail.com +
+ Thu Aug 4 00:57:46 CEST 2011 +

+
+ +
On Wed, Aug 3, 2011 at 11:35 PM, D.Morgan <dmorganec at gmail.com> wrote:
+> On Wed, Aug 3, 2011 at 11:16 PM, Balcaen John <mikala at mageia.org> wrote:
+>> Le Mercredi 3 Août 2011 22:43:21 D.Morgan a écrit :
+>> [...]
+>>>
+>>> what ? the error here is about PA not to gnutls
+>> She's talking about the
+>> « WARNING: no socket to connect to  »
+>> warning i guess.
+>>
+>> Regards,
+>>
+>> --
+>> Balcaen John
+>>
+>
+> ah and this is gnutls errors ?
+>
+> Just for the infos after the last cauldron update aria seems to works
+> fine. ( except the « WARNING: no socket to connect to  » errors that i
+> don't understand for the moment.
+>
+> but it "works" ;)
+>
+
+should be OK for liferea, epiphany, ... ( all the apps using glib-networking ).
+
+Please test and report
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007228.html b/zarb-ml/mageia-dev/2011-August/007228.html new file mode 100644 index 000000000..fba73c032 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007228.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [RPM] cauldron core/release grilo-plugins-0.1.16-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release grilo-plugins-0.1.16-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Thu Aug 4 01:40:26 CEST 2011 +

+
+ +
Le Mercredi 3 Août 2011 23:01:06 Mageia Team a écrit :
+> Name        : grilo-plugins                Relocations: (not
+[...]
+> 
+> fwang <fwang> 0.1.16-1.mga2:
+> + Revision: 131582
+> - recognize tracker 0.11
+> - br quvi
+> - tweak br
+> - imported package grilo-plugins
+There's a missing requires :
+
+adding a reason to already rejected package grilo-
+plugins-0.1.16-1.mga2.x86_64: unsatisfied gupnp-av[>= 0.5.0]   
+
+so totem can't be installed too :
+
+set_rejected: totem-3.1.0-4.mga2.x86_64                                                                                                                                                 
+requiring grilo-plugins,libgrilo-0.1.so.0()(64bit) for 
+totem-3.1.4-2.mga2.x86_64                                                                                                        
+chosen lib64grilo0.1_0-0.1.16-1.mga2.x86_64 for libgrilo-0.1.so.0()
+(64bit)             
+
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007229.html b/zarb-ml/mageia-dev/2011-August/007229.html new file mode 100644 index 000000000..3e65f6500 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007229.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] [RPM] 1 core/updates_testing schroot-1.4.22-1.1.mga1 + + + + + + + + + +

[Mageia-dev] [RPM] 1 core/updates_testing schroot-1.4.22-1.1.mga1

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Aug 4 12:39:00 CEST 2011 +

+
+ +
On 4 August 2011 11:19, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> stormi <stormi> 1.4.22-1.1.mga1:
+> + Revision: 130495
+> - update release and subrel according to updates policy
+>
+>  + philippem <philippem>
+>    - Silent fix files
+>    - New upstream stable release 1.4.22
+>      + Don't use rbind when mounting filesystems in the chroot
+>      + Session metadata includes the original chroot name
+>      + Improved man pages
+
+Please do not paste upstream changelog in package changelog.
+Thx
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007230.html b/zarb-ml/mageia-dev/2011-August/007230.html new file mode 100644 index 000000000..8452acefd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007230.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] systemd + ACL: Why it is broken. + + + + + + + + + +

[Mageia-dev] systemd + ACL: Why it is broken.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 4 19:43:47 CEST 2011 +

+
+ +
Hi,
+
+OK, so the reason that device ACLs are kinda broken with systemd is
+because the acl stuff is being done twice, once via udev and again via
+systemd.... but sadly systemd gets it wrong as it's not aware of the
+user session, see:
+systemd-loginctl --no-pager
+
+
+This is due to the fact that some essential additions to
+/etc/pam.d/system-auth are not done when systemd is installed.
+
+I added the following line to the end of my system-auth (the "login"
+file where console kit connector lies didn't work):
+
+-session    optional      pam_systemd.so
+
+
+
+The question is, how should we handle this? Edit the pam package and add
+it or do something more complex? AFAIK Fedora uses a system to manage
+these files called authconfig.... not sure if we could/should adopt
+that. I don't know much about it.
+
+
+
+
+On a related note, we'll also need to rebuild udev without udev-acl
+support, as this is now
+handled by systemd. At present, with the above fix to pam, I will be
+getting my ACLs written twice, which (when systemd knows I'm logged in)
+is fine. I think it's actually the default in udev 173, but
+we can do that manually with 172 via:
+  --disable-udev_acl
+in udev.
+
+That said, this would commit us to systemd so we need to tread carefully
+here as without systemd, then the ACLs would not get written with
+obvious consequences (basically the exact opposite of now!).
+
+Anyway, for now I have my ACLs back and can use my audio devices! Yay!
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007231.html b/zarb-ml/mageia-dev/2011-August/007231.html new file mode 100644 index 000000000..4aca95af3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007231.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Thu Aug 4 21:26:04 CEST 2011 +

+
+ +
Helo,
+
+As my experience in security field, to make Mageia more available in enterprise 
+environments, and specially those that are security paranoid, i'm planning to 
+port SRM.  SRM is a package that does a "secure" file deleting according some 
+security standards (i dont remember right now names, i guess it is something 
+in NIST, but that doesnt matter really).
+
+My question is, what should be the procedure that when you install srm, then 
+the normal rm command could be replaced?  i was thinking in pushing an alias 
+but what other alternatives do i have?
+
+please comment,
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007232.html b/zarb-ml/mageia-dev/2011-August/007232.html new file mode 100644 index 000000000..c6f09a0be --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007232.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Aug 5 00:55:54 CEST 2011 +

+
+ +
'Twas brillig, and Luis Daniel Lucio Quiroz at 04/08/11 21:26 did gyre
+and gimble:
+> Helo,
+> 
+> As my experience in security field, to make Mageia more available in enterprise 
+> environments, and specially those that are security paranoid, i'm planning to 
+> port SRM.  SRM is a package that does a "secure" file deleting according some 
+> security standards (i dont remember right now names, i guess it is something 
+> in NIST, but that doesnt matter really).
+> 
+> My question is, what should be the procedure that when you install srm, then 
+> the normal rm command could be replaced?  i was thinking in pushing an alias 
+> but what other alternatives do i have?
+
+Well you could theoretically use alternatives, but I would suspect that
+such a fundamental tool as rm would probably be very dangerous to
+package in that way (the alternatives scripts themselves may use rm!)
+
+So I think an alias would be best, but it'll only cover users/scripts
+calling rm and not general unlinking... It likely won't cover GUIs and
+other deletion methods. With that in mind, is it work aliasing rm at all
+seeing as it'll only catch a subset of "delete" operations? You wouldn't
+want to give a false sense of security after all...
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007233.html b/zarb-ml/mageia-dev/2011-August/007233.html new file mode 100644 index 000000000..37d2e6a3f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007233.html @@ -0,0 +1,153 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Aug 5 01:12:50 CEST 2011 +

+
+ +
'Twas brillig, and Wolfgang Bornath at 03/08/11 14:34 did gyre and gimble:
+> 2011/8/3 Colin Guthrie <mageia at colin.guthr.ie>:
+>> 'Twas brillig, and Wolfgang Bornath at 03/08/11 11:17 did gyre and gimble:
+>>> Just my experiences after todays updates of PA (64-bit):
+>>> Right after update everything worked as expected (tested Rhythmbox
+>>> (mp3), browser (flash plugin), sound recorder.
+>>>
+>>> After reboot the same except that the mic does not work anymore.
+>>
+>> Interesting. Can you supply a "pacmd ls" output after a clean boot (no
+>> hotplug)?
+> 
+> After a fresdh boot, nothing attached, internal speaker works,
+> internal mic does not work
+> --> see pacmd_ls_1.txt
+> 
+>>> Another thing: when I plugin headset the mic and output work, internal
+>>> speakers are off. When I unplug the headset, neither mic nor speakers
+>>> are working (although the settings in PA configuration are ok). I have
+>>> to  restart PA to get back sound. This "plugin, plugout" worked
+>>> before.
+>>
+>> It certainly should. Can you also supply the "pacmd ls" output after
+>> this happens so I can compare it to the first one?
+> 
+> Plugged in headset, no sound, neither from internal speakers nor from headset.
+> --> see pacmd_ls_2.txt
+
+Hmmm, nothing obvious here....
+
+Can I clarify a few things with you?
+
+By "headset" do you mean an analog one? i.e. two 3.5mm jacks into the
+mic and headphone port?
+
+When on headphones does everything work nicely if you switch the profile
+to "Analog Headphones" on the sink (via pavucontrol under "Ouput
+devices" tab), including volume control? If not then there may be alsa
+controls that bypass this functionality (amixer -c0 will likely tell you
+- I've seen controls called e.g. "Independent HP"...
+
+	ports:
+		analog-output-speaker: Analog Speakers (priority 10000)
+		analog-output-headphones: Analog Headphones (priority 9000)
+	active port: <analog-output-speaker>
+
+As we do not listen to jack-sense events at all, I've very surprised
+that plugging and unplugging a jack should make any difference to PA...
+or at least it should make the same difference before as with now...
+
+One way to test:
+ pasuspender bash
+ aplay -c0 /path/to/wav
+  <plugin HP, then unplug.... does it restore to speakers?>
+ exit (to get out of the pasuspender shell)
+
+
+As for the Mic not working, can you change the mic to "Internal
+Microphone" in pavucontrol's "Input Devices" tab? Does this now work
+with nothing plugged in? When something is plugged in, does it actually
+record from that mic or is it still picking things up from the internal
+one on your laptop?
+
+Cheers
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007234.html b/zarb-ml/mageia-dev/2011-August/007234.html new file mode 100644 index 000000000..1b35a1f9a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007234.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Problems with dbus + + + + + + + + + +

[Mageia-dev] Problems with dbus

+ JA Magallon + jamagallon at ono.com +
+ Fri Aug 5 00:23:51 CEST 2011 +

+
+ +
Hi...
+
+I'm on limited internet connection, so I'll be quick and dirty.
+Plz, take a look at this mdv bug:
+https://qa.mandriva.com/show_bug.cgi?id=63728
+
+(copy)
+the problem is a bug in
+libdbus-glib-1_2 package, it is necessary a Debian patch
+http://patch-tracker.debian.org/package/dbus-glib/0.94-4
+
+I suffer it for Usb modem, and mdv package made it work.
+Probably hurts more apps...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007235.html b/zarb-ml/mageia-dev/2011-August/007235.html new file mode 100644 index 000000000..feeaab929 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007235.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ andre999 + andr55 at laposte.net +
+ Fri Aug 5 00:39:35 CEST 2011 +

+
+ +
Luis Daniel Lucio Quiroz a écrit :
+> Helo,
+>
+> As my experience in security field, to make Mageia more available in enterprise
+> environments, and specially those that are security paranoid, i'm planning to
+> port SRM.  SRM is a package that does a "secure" file deleting according some
+> security standards (i dont remember right now names, i guess it is something
+> in NIST, but that doesnt matter really).
+>
+> My question is, what should be the procedure that when you install srm, then
+> the normal rm command could be replaced?  i was thinking in pushing an alias
+> but what other alternatives do i have?
+>
+> please comment,
+>
+> LD
+
+At first glance that sounds like a reasonable approach EXCEPT -- a system-level 
+alias would be over-ridden by a user alias.
+A user could innocently have an alias such as :
+alias rm="rm -i"
+
+rm is in /bin
+- /bin/rm could be replaced with a link to srm, but I don't know if that would 
+be considered acceptable.
+rm would have to be restored if srm were uninstalled
+
+- wouldn't a link in /usr/bin/rm be executed first ?
+Of course that doesn't cover execution with root privileges.
+An alias in root wouldn't necessarily work, as an admin could inadvertantly 
+replace it with another.  (By loading a new file with some changed alias, for 
+example.)
+But probably less likely than some user doing the same on their profile.
+
+There could be other approaches as well ... :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007236.html b/zarb-ml/mageia-dev/2011-August/007236.html new file mode 100644 index 000000000..2fed2e3cd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007236.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Fri Aug 5 01:36:13 CEST 2011 +

+
+ +
Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit :
+> Luis Daniel Lucio Quiroz a écrit :
+> > Helo,
+> > 
+> > As my experience in security field, to make Mageia more available in
+> > enterprise environments, and specially those that are security
+> > paranoid, i'm planning to port SRM.  SRM is a package that does a
+> > "secure" file deleting according some security standards (i dont
+> > remember right now names, i guess it is something in NIST, but that
+> > doesnt matter really).
+> > 
+> > My question is, what should be the procedure that when you install srm,
+> > then the normal rm command could be replaced?  i was thinking in
+> > pushing an alias but what other alternatives do i have?
+> > 
+> > please comment,
+> > 
+> > LD
+> 
+> At first glance that sounds like a reasonable approach EXCEPT -- a
+> system-level alias would be over-ridden by a user alias.
+> A user could innocently have an alias such as :
+> alias rm="rm -i"
+> 
+> rm is in /bin
+> - /bin/rm could be replaced with a link to srm, but I don't know if that
+> would be considered acceptable.
+> rm would have to be restored if srm were uninstalled
+> 
+> - wouldn't a link in /usr/bin/rm be executed first ?
+> Of course that doesn't cover execution with root privileges.
+> An alias in root wouldn't necessarily work, as an admin could inadvertantly
+> replace it with another.  (By loading a new file with some changed alias,
+> for example.)
+> But probably less likely than some user doing the same on their profile.
+> 
+> There could be other approaches as well ... :)
+
+You are right! :)
+
+Well another option could be this:
+
+a. we change coreutils to install /bin/rm as  /bin/rm.vanilla (or other name, 
+that really doesnt matter),
+b. i change srm to install itself in /bin instead of /usr/bin
+c. we place alternatives in both packages to provide /bin/rm, giving 
+preference to srm if installed, otherwise it will use rm of coreutils
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007237.html b/zarb-ml/mageia-dev/2011-August/007237.html new file mode 100644 index 000000000..e92dae54f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007237.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 5 02:03:22 CEST 2011 +

+
+ +
On Fri, 05 Aug 2011, Colin Guthrie wrote:
+
+> 'Twas brillig, and Luis Daniel Lucio Quiroz at 04/08/11 21:26 did gyre
+> and gimble:
+> > Helo,
+> > 
+> > As my experience in security field, to make Mageia more available in enterprise 
+> > environments, and specially those that are security paranoid, i'm planning to 
+> > port SRM.  SRM is a package that does a "secure" file deleting according some 
+> > security standards (i dont remember right now names, i guess it is something 
+> > in NIST, but that doesnt matter really).
+> > 
+> > My question is, what should be the procedure that when you install srm, then 
+> > the normal rm command could be replaced?  i was thinking in pushing an alias 
+> > but what other alternatives do i have?
+> 
+> Well you could theoretically use alternatives, but I would suspect that
+> such a fundamental tool as rm would probably be very dangerous to
+> package in that way (the alternatives scripts themselves may use rm!)
+> 
+> So I think an alias would be best, but it'll only cover users/scripts
+> calling rm and not general unlinking... It likely won't cover GUIs and
+> other deletion methods. With that in mind, is it work aliasing rm at all
+> seeing as it'll only catch a subset of "delete" operations? You wouldn't
+> want to give a false sense of security after all...
+
+Yes, this would be better done on filesystem/kernel. Like this :
+http://thread.gmane.org/gmane.comp.file-systems.ext4/26548
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007238.html b/zarb-ml/mageia-dev/2011-August/007238.html new file mode 100644 index 000000000..5e430ac97 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007238.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Fri Aug 5 02:16:39 CEST 2011 +

+
+ +
Le Vendredi 05 Août 2011 02:03:22 nicolas vigier a écrit :
+> On Fri, 05 Aug 2011, Colin Guthrie wrote:
+> > 'Twas brillig, and Luis Daniel Lucio Quiroz at 04/08/11 21:26 did gyre
+> > 
+> > and gimble:
+> > > Helo,
+> > > 
+> > > As my experience in security field, to make Mageia more available in
+> > > enterprise environments, and specially those that are security
+> > > paranoid, i'm planning to port SRM.  SRM is a package that does a
+> > > "secure" file deleting according some security standards (i dont
+> > > remember right now names, i guess it is something in NIST, but that
+> > > doesnt matter really).
+> > > 
+> > > My question is, what should be the procedure that when you install
+> > > srm, then the normal rm command could be replaced?  i was thinking
+> > > in pushing an alias but what other alternatives do i have?
+> > 
+> > Well you could theoretically use alternatives, but I would suspect that
+> > such a fundamental tool as rm would probably be very dangerous to
+> > package in that way (the alternatives scripts themselves may use rm!)
+> > 
+> > So I think an alias would be best, but it'll only cover users/scripts
+> > calling rm and not general unlinking... It likely won't cover GUIs and
+> > other deletion methods. With that in mind, is it work aliasing rm at all
+> > seeing as it'll only catch a subset of "delete" operations? You wouldn't
+> > want to give a false sense of security after all...
+> 
+> Yes, this would be better done on filesystem/kernel. Like this :
+> http://thread.gmane.org/gmane.comp.file-systems.ext4/26548
+
+I got your poing,  however i remember that SRM uses some specific algorithmis 
+that are recomended in NIST, thats why i remember we chose SRM and we void 
+zero filling techniques.
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007239.html b/zarb-ml/mageia-dev/2011-August/007239.html new file mode 100644 index 000000000..52f2cf04e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007239.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ andre999 + andr55 at laposte.net +
+ Fri Aug 5 06:50:53 CEST 2011 +

+
+ +
Luis Daniel Lucio Quiroz a écrit :
+> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit :
+>> Luis Daniel Lucio Quiroz a écrit :
+>>> Helo,
+>>>
+>>> As my experience in security field, to make Mageia more available in
+>>> enterprise environments, and specially those that are security
+>>> paranoid, i'm planning to port SRM.  SRM is a package that does a
+>>> "secure" file deleting according some security standards (i dont
+>>> remember right now names, i guess it is something in NIST, but that
+>>> doesnt matter really).
+>>>
+>>> My question is, what should be the procedure that when you install srm,
+>>> then the normal rm command could be replaced?  i was thinking in
+>>> pushing an alias but what other alternatives do i have?
+>>>
+>>> please comment,
+>>>
+>>> LD
+>>
+>> At first glance that sounds like a reasonable approach EXCEPT -- a
+>> system-level alias would be over-ridden by a user alias.
+>> A user could innocently have an alias such as :
+>> alias rm="rm -i"
+>>
+>> rm is in /bin
+>> - /bin/rm could be replaced with a link to srm, but I don't know if that
+>> would be considered acceptable.
+>> rm would have to be restored if srm were uninstalled
+>>
+>> - wouldn't a link in /usr/bin/rm be executed first ?
+>> Of course that doesn't cover execution with root privileges.
+>> An alias in root wouldn't necessarily work, as an admin could inadvertantly
+>> replace it with another.  (By loading a new file with some changed alias,
+>> for example.)
+>> But probably less likely than some user doing the same on their profile.
+>>
+>> There could be other approaches as well ... :)
+>
+> You are right! :)
+>
+> Well another option could be this:
+>
+> a. we change coreutils to install /bin/rm as  /bin/rm.vanilla (or other name,
+> that really doesnt matter),
+> b. i change srm to install itself in /bin instead of /usr/bin
+> c. we place alternatives in both packages to provide /bin/rm, giving
+> preference to srm if installed, otherwise it will use rm of coreutils
+>
+> LD
+
+That would probably be the ideal approach.  But it might take a while to get 
+the changes accepted in coreutils.
+
+Maybe it could be all done from srm ?
+On srm install,
+a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?)
+b. create /bin/rm link to /bin/srm
+
+On srm uninstall, we ensure that
+a. rm /bin/rm link
+b. rename /bin/rm.vanilla to /bin/rm
+
+Hopefully that could be done reliably, with an uninstall script.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007240.html b/zarb-ml/mageia-dev/2011-August/007240.html new file mode 100644 index 000000000..a728888e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007240.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel + + + + + + + + + +

[Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Fri Aug 5 11:03:31 CEST 2011 +

+
+ +
Helo
+
+Well i've only tried in *-desktop kernels
+in
+
+2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module
+3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in pcmcia 
+slot but after that nothing happens,  I've tried loading by hand ath5k module, 
+but it doesnt works.  iwconfig or ifconfig -a commands doesnt shows nothing 
+eighter.
+
+Just for your knowledge
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007241.html b/zarb-ml/mageia-dev/2011-August/007241.html new file mode 100644 index 000000000..5a323d083 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007241.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Aug 5 12:14:14 CEST 2011 +

+
+ +
'Twas brillig, and Luis Daniel Lucio Quiroz at 05/08/11 02:16 did gyre
+and gimble:
+> Le Vendredi 05 Août 2011 02:03:22 nicolas vigier a écrit :
+>> On Fri, 05 Aug 2011, Colin Guthrie wrote:
+>>> 'Twas brillig, and Luis Daniel Lucio Quiroz at 04/08/11 21:26 did gyre
+>>>
+>>> and gimble:
+>>>> Helo,
+>>>>
+>>>> As my experience in security field, to make Mageia more available in
+>>>> enterprise environments, and specially those that are security
+>>>> paranoid, i'm planning to port SRM.  SRM is a package that does a
+>>>> "secure" file deleting according some security standards (i dont
+>>>> remember right now names, i guess it is something in NIST, but that
+>>>> doesnt matter really).
+>>>>
+>>>> My question is, what should be the procedure that when you install
+>>>> srm, then the normal rm command could be replaced?  i was thinking
+>>>> in pushing an alias but what other alternatives do i have?
+>>>
+>>> Well you could theoretically use alternatives, but I would suspect that
+>>> such a fundamental tool as rm would probably be very dangerous to
+>>> package in that way (the alternatives scripts themselves may use rm!)
+>>>
+>>> So I think an alias would be best, but it'll only cover users/scripts
+>>> calling rm and not general unlinking... It likely won't cover GUIs and
+>>> other deletion methods. With that in mind, is it work aliasing rm at all
+>>> seeing as it'll only catch a subset of "delete" operations? You wouldn't
+>>> want to give a false sense of security after all...
+>>
+>> Yes, this would be better done on filesystem/kernel. Like this :
+>> http://thread.gmane.org/gmane.comp.file-systems.ext4/26548
+> 
+> I got your poing,  however i remember that SRM uses some specific algorithmis 
+> that are recomended in NIST, thats why i remember we chose SRM and we void 
+> zero filling techniques.
+
+Even still, Nicolas's point remains that this system (even if it uses
+special algorithms rather than just zero'ing) would be better
+implemented somewhere lower rather than in a single userspace tool.
+
+I'm not saying the userspace tool is not useful in the event that the
+underlying system does not have the capabilities, but using an alias or
+otherwise making the standard rm command == srm, is IMO just a token
+gesture and does not really address wider security concerns.
+
+IMO it would be better to just provide the tool and let people who
+specifically want secure delete use it manually when needed.
+
+Otherwise users may be duped into a false sense of security by
+installing the "secure deletes" package and then delete files thorough
+Nautilus or Konq under the false impression they are securely deleted.
+
+That's just my thoughts on it tho'. :)
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007242.html b/zarb-ml/mageia-dev/2011-August/007242.html new file mode 100644 index 000000000..7b098a85d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007242.html @@ -0,0 +1,175 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Aug 5 12:17:50 CEST 2011 +

+
+ +
'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble:
+> Luis Daniel Lucio Quiroz a écrit :
+>> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit :
+>>> Luis Daniel Lucio Quiroz a écrit :
+>>>> Helo,
+>>>>
+>>>> As my experience in security field, to make Mageia more available in
+>>>> enterprise environments, and specially those that are security
+>>>> paranoid, i'm planning to port SRM.  SRM is a package that does a
+>>>> "secure" file deleting according some security standards (i dont
+>>>> remember right now names, i guess it is something in NIST, but that
+>>>> doesnt matter really).
+>>>>
+>>>> My question is, what should be the procedure that when you install srm,
+>>>> then the normal rm command could be replaced?  i was thinking in
+>>>> pushing an alias but what other alternatives do i have?
+>>>>
+>>>> please comment,
+>>>>
+>>>> LD
+>>>
+>>> At first glance that sounds like a reasonable approach EXCEPT -- a
+>>> system-level alias would be over-ridden by a user alias.
+>>> A user could innocently have an alias such as :
+>>> alias rm="rm -i"
+>>>
+>>> rm is in /bin
+>>> - /bin/rm could be replaced with a link to srm, but I don't know if that
+>>> would be considered acceptable.
+>>> rm would have to be restored if srm were uninstalled
+>>>
+>>> - wouldn't a link in /usr/bin/rm be executed first ?
+>>> Of course that doesn't cover execution with root privileges.
+>>> An alias in root wouldn't necessarily work, as an admin could
+>>> inadvertantly
+>>> replace it with another.  (By loading a new file with some changed
+>>> alias,
+>>> for example.)
+>>> But probably less likely than some user doing the same on their profile.
+>>>
+>>> There could be other approaches as well ... :)
+>>
+>> You are right! :)
+>>
+>> Well another option could be this:
+>>
+>> a. we change coreutils to install /bin/rm as  /bin/rm.vanilla (or
+>> other name,
+>> that really doesnt matter),
+>> b. i change srm to install itself in /bin instead of /usr/bin
+>> c. we place alternatives in both packages to provide /bin/rm, giving
+>> preference to srm if installed, otherwise it will use rm of coreutils
+>>
+>> LD
+> 
+> That would probably be the ideal approach.  But it might take a while to
+> get the changes accepted in coreutils.
+> 
+> Maybe it could be all done from srm ?
+> On srm install,
+> a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?)
+> b. create /bin/rm link to /bin/srm
+
+Definitely not. It's against the commandments: Thou shalt not mess with
+another packages' files.
+
+> On srm uninstall, we ensure that
+> a. rm /bin/rm link
+> b. rename /bin/rm.vanilla to /bin/rm
+> 
+> Hopefully that could be done reliably, with an uninstall script.
+
+No, this is very bad.
+
+It's what the alternatives system was designed to do for you, but I
+really don't think that something as fundamental as rm should be messed
+with in this way as I mentioned in my own email.
+
+srm is an add on userspace tool. To implement secure deletes properly,
+you would want support at a lower level (i.e in the kernel/fs).
+
+I think srm should just be a tool people use explicitly when they want to.
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007243.html b/zarb-ml/mageia-dev/2011-August/007243.html new file mode 100644 index 000000000..72749d97a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007243.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Sander Lepik + sander.lepik at eesti.ee +
+ Fri Aug 5 11:21:47 CEST 2011 +

+
+ +
05.08.2011 13:17, Colin Guthrie kirjutas:
+> I think srm should just be a tool people use explicitly when they want to.
+>
+> Col
++1
+
+--
+Sander
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007244.html b/zarb-ml/mageia-dev/2011-August/007244.html new file mode 100644 index 000000000..e3475f196 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007244.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel + + + + + + + + + +

[Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Aug 5 11:39:18 CEST 2011 +

+
+ +
On 5 August 2011 11:03, Luis Daniel Lucio Quiroz <dlucio at okay.com.mx> wrote:
+> Well i've only tried in *-desktop kernels
+> in
+>
+> 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module
+> 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in pcmcia
+> slot but after that nothing happens,  I've tried loading by hand ath5k module,
+> but it doesnt works.  iwconfig or ifconfig -a commands doesnt shows nothing
+> eighter.
+>
+> Just for your knowledge
+
+Please open a bug report instead of sending a mail.
+Paste output of "lspcidrake -v|egrep -i 'net|ath'"
+Also attach (ie do not paste) your dmesg output to the BR.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007245.html b/zarb-ml/mageia-dev/2011-August/007245.html new file mode 100644 index 000000000..598ecbea0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007245.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Wed Aug 3 14:01:16 CEST 2011 +

+
+ +
On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote:
+> Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne:
+> > Samba-common is the right package for this. I see no need to have a
+> > squid- specific subpackage (and then samba-apache, samba-freeradius,
+> > with the same content, or all virtual packages just pulling
+> > samba-common).
+> > 
+> > Feel free to mess up your squid package by adding suggests on
+> > samba-common, but since installing the right package is trivially solved
+> > by the admin and is a small portion of the work required, I would
+> > personally prefer not to increase the default footprint of any
+> > installation that pulls in squid.
+
+
+> this is really imho an example where conditional suggests could work well:
+> if you have squid already installed and you're installing samba, this
+> subpackage could then be suggested. (and vice versa).
+
+But, it is irrelevant. samba-common is required by both samba-client and 
+samba-server, so you can't install samba without getting ntlm_auth.
+
+This is really about whether squid should pull in any pieces of samba by 
+default, and could be solved by adding:
+Suggests: samba-common
+
+to squid. But, I don't see much value, as this is a small part of the work 
+required to get a single-sign on authentication solution for squid against AD. 
+The default squid.conf already has example configs showing that ntlm_auth is 
+required, and all we are saving the user is a 'urpmf ntlm_auth' and a 'urpmi 
+samba-common'. However, there are many scenarios squid can be deployed (e.g. 
+SSO with GSSAPI, basic auth with LDAP, PAM, NIS etc., no authentication, peer 
+cache only etc.), and I don't see a reason to pull in samba-common by default, 
+when it saves the admin very little effort.
+
+Regards,
+Buchan
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007246.html b/zarb-ml/mageia-dev/2011-August/007246.html new file mode 100644 index 000000000..b5c700b9e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007246.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Fri Aug 5 12:42:26 CEST 2011 +

+
+ +
On Friday, 5 August 2011 12:14:14 Colin Guthrie wrote:
+
+> Otherwise users may be duped into a false sense of security by
+> installing the "secure deletes" package and then delete files thorough
+> Nautilus or Konq under the false impression they are securely deleted.
+
+Or from another Mageia host with a stock rm over NFS or similar, or from a 
+non-Mageia client via Samba, sftp or fish etc., DAV or any of the non-
+commandline ways of deleting a file.
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007247.html b/zarb-ml/mageia-dev/2011-August/007247.html new file mode 100644 index 000000000..20ddf92fc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007247.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Thomas Backlund + tmb at mageia.org +
+ Fri Aug 5 12:45:43 CEST 2011 +

+
+ +
Buchan Milne skrev 5.8.2011 13:42:
+> On Friday, 5 August 2011 12:14:14 Colin Guthrie wrote:
+>
+>> Otherwise users may be duped into a false sense of security by
+>> installing the "secure deletes" package and then delete files thorough
+>> Nautilus or Konq under the false impression they are securely deleted.
+>
+> Or from another Mageia host with a stock rm over NFS or similar, or from a
+> non-Mageia client via Samba, sftp or fish etc., DAV or any of the non-
+> commandline ways of deleting a file.
+>
+
+And another problem with "secure erase" both on tool and filesystem 
+level...
+
+It wont work on SSDs due to their firmware implemented wear leveling ...
+
+really think srm should stay as parallell installable with original rm 
+intact.
+
+--
+Thomas
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007248.html b/zarb-ml/mageia-dev/2011-August/007248.html new file mode 100644 index 000000000..2dd21fe1e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007248.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel + + + + + + + + + +

[Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Aug 5 13:12:20 CEST 2011 +

+
+ +
Am 05.08.2011 11:39, schrieb Thierry Vignaud:
+> On 5 August 2011 11:03, Luis Daniel Lucio Quiroz<dlucio at okay.com.mx>  wrote:
+>> Well i've only tried in *-desktop kernels
+>> in
+>>
+>> 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module
+>> 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in pcmcia
+>> slot but after that nothing happens,  I've tried loading by hand ath5k module,
+>> but it doesnt works.  iwconfig or ifconfig -a commands doesnt shows nothing
+>> eighter.
+>>
+>> Just for your knowledge
+> Please open a bug report instead of sending a mail.
+> Paste output of "lspcidrake -v|egrep -i 'net|ath'"
+> Also attach (ie do not paste) your dmesg output to the BR.
+>
+There was a similar forum post for atk_htc, it just needed a newer firmware,
+maybe you can adapt that to ath5k module: 
+https://forums.mageia.org/en/viewtopic.php?f=15&t=842
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007249.html b/zarb-ml/mageia-dev/2011-August/007249.html new file mode 100644 index 000000000..1938389a7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007249.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] [126688] - 0.94 + + + + + + + + + +

[Mageia-dev] [126688] - 0.94

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Aug 5 14:20:52 CEST 2011 +

+
+ +
On 19 July 2011 21:12,  <root at mageia.org> wrote:
+> Revision 126688 Author cjw Date 2011-07-19 21:12:55 +0200 (Tue, 19 Jul 2011)
+>
+> Log Message
+>
+> - 0.94
+>
+> Modified Paths
+>
+> cauldron/dbus-glib/current/SPECS/dbus-glib.spec
+>
+> Modified: cauldron/dbus-glib/current/SPECS/dbus-glib.spec
+> ===================================================================
+> --- cauldron/dbus-glib/current/SPECS/dbus-glib.spec	2011-07-19 19:12:47 UTC
+> (rev 126687)
+> +++ cauldron/dbus-glib/current/SPECS/dbus-glib.spec	2011-07-19 19:12:55 UTC
+> (rev 126688)
+> @@ -1,13 +1,6 @@
+> -#if %mandriva_branch == Cooker
+> -# Cooker
+> -%define release %mkrel 2
+> -#%else
+> -# Old distros
+> -#define subrel 2
+> -#define release %mkrel 1
+> -#endif
+> -%define glib2_version           2.6.0
+> -%define dbus_version		0.94
+> +%define release %mkrel 1
+> +%define glib2_version           2.26.0
+> +%define dbus_version		1.2.16
+>
+>  %define lib_major 2
+>  %define lib_api 1
+> @@ -18,13 +11,12 @@
+>
+>  Summary: D-Bus message bus
+>  Name: dbus-glib
+> -Version: 0.88
+> +Version: 0.94
+>  Release: %release
+>  URL: http://www.freedesktop.org/Software/dbus
+>  Source0:
+> http://dbus.freedesktop.org/releases/%name/%{name}-%{version}.tar.gz
+>  License: AFL and GPLv2
+>  Group: System/Libraries
+> -BuildRoot: %{_tmppath}/%{name}-%{version}-root
+>  BuildRequires: glib2-devel >= %{glib2_version}
+>  BuildRequires: dbus-devel >= %{dbus_version}
+>  BuildRequires: libxml2-devel
+> @@ -63,7 +55,7 @@
+>  %setup -q
+>
+>  %build
+> -
+> +autoreconf -fi
+
+Hello,
+
+The issue or running autoreconf in spec files is still unresolved, either:
+- We only run it when needed (i.e. a patch that modifies configure.ac,
+Makefile.{am,in}, building with a newer/older libtool) OR
+- We run it in all the specs of packages that use libtool
+
+Right now in most specs we only run it when needed, except some specs
+you modified (like this one).
+
+I am not with or against (don't have enough knowledge about libtool),
+just pointing out that if autoreconf should be run for all packages
+using libtool, then the policy should be clarified and applied to all
+specs.
+
+>  %configure2_5x  \
+>      --disable-tests \
+>      --disable-verbose-mode \
+> @@ -99,9 +91,9 @@
+>  %{_libdir}/pkgconfig/dbus-glib-%{lib_api}.pc
+>  %{_includedir}/dbus-1.0/dbus/dbus-glib-bindings.h
+>  %{_includedir}/dbus-1.0/dbus/dbus-gtype-specialized.h
+> -%{_includedir}/dbus-1.0/dbus/dbus-glib-error-enum.h
+>  %{_includedir}/dbus-1.0/dbus/dbus-glib-lowlevel.h
+>  %{_includedir}/dbus-1.0/dbus/dbus-glib.h
+> +%{_includedir}/dbus-1.0/dbus/dbus-gvalue-parse-variant.h
+>  %{_datadir}/gtk-doc/html/dbus-glib/
+>  %{_mandir}/man1/*
+>
+>
+>
+
+
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007250.html b/zarb-ml/mageia-dev/2011-August/007250.html new file mode 100644 index 000000000..177ee43a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007250.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Problems with dbus + + + + + + + + + +

[Mageia-dev] Problems with dbus

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Aug 5 14:34:13 CEST 2011 +

+
+ +
On 5 August 2011 00:23, JA Magallon <jamagallon at ono.com> wrote:
+> Hi...
+>
+> I'm on limited internet connection, so I'll be quick and dirty.
+> Plz, take a look at this mdv bug:
+> https://qa.mandriva.com/show_bug.cgi?id=63728
+>
+> (copy)
+> the problem is a bug in
+> libdbus-glib-1_2 package, it is necessary a Debian patch
+> http://patch-tracker.debian.org/package/dbus-glib/0.94-4
+>
+> I suffer it for Usb modem, and mdv package made it work.
+> Probably hurts more apps...
+>
+
+Patch added from upstream GIT
+https://bugs.freedesktop.org/show_bug.cgi?id=37852 (same patch).
+
+Please test. (I didn't see any rebuild of network*manager-* in Debian,
+so I am not sure a rebuild is required).
+
+And a bug report would have worked to track the issue.
+
+-- 
+Ahmad Samir
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007251.html b/zarb-ml/mageia-dev/2011-August/007251.html new file mode 100644 index 000000000..79a5c4f7d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007251.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ andre999 + andr55 at laposte.net +
+ Fri Aug 5 14:58:12 CEST 2011 +

+
+ +
Colin Guthrie a écrit :
+> 'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble:
+>> Luis Daniel Lucio Quiroz a écrit :
+>>> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit :
+>>>> Luis Daniel Lucio Quiroz a écrit :
+>>>>> Helo,
+>>>>>
+>>>>> As my experience in security field, to make Mageia more available in
+>>>>> enterprise environments, and specially those that are security
+>>>>> paranoid, i'm planning to port SRM.  SRM is a package that does a
+>>>>> "secure" file deleting according some security standards (i dont
+>>>>> remember right now names, i guess it is something in NIST, but that
+>>>>> doesnt matter really).
+>>>>>
+>>>>> My question is, what should be the procedure that when you install srm,
+>>>>> then the normal rm command could be replaced?  i was thinking in
+>>>>> pushing an alias but what other alternatives do i have?
+>>>>>
+>>>>> please comment,
+>>>>>
+>>>>> LD
+>>>>
+>>>> At first glance that sounds like a reasonable approach EXCEPT -- a
+>>>> system-level alias would be over-ridden by a user alias.
+>>>> A user could innocently have an alias such as :
+>>>> alias rm="rm -i"
+>>>>
+>>>> rm is in /bin
+>>>> - /bin/rm could be replaced with a link to srm, but I don't know if that
+>>>> would be considered acceptable.
+>>>> rm would have to be restored if srm were uninstalled
+>>>>
+>>>> - wouldn't a link in /usr/bin/rm be executed first ?
+>>>> Of course that doesn't cover execution with root privileges.
+>>>> An alias in root wouldn't necessarily work, as an admin could
+>>>> inadvertantly
+>>>> replace it with another.  (By loading a new file with some changed
+>>>> alias,
+>>>> for example.)
+>>>> But probably less likely than some user doing the same on their profile.
+>>>>
+>>>> There could be other approaches as well ... :)
+>>>
+>>> You are right! :)
+>>>
+>>> Well another option could be this:
+>>>
+>>> a. we change coreutils to install /bin/rm as  /bin/rm.vanilla (or
+>>> other name,
+>>> that really doesnt matter),
+>>> b. i change srm to install itself in /bin instead of /usr/bin
+>>> c. we place alternatives in both packages to provide /bin/rm, giving
+>>> preference to srm if installed, otherwise it will use rm of coreutils
+>>>
+>>> LD
+>>
+>> That would probably be the ideal approach.  But it might take a while to
+>> get the changes accepted in coreutils.
+>>
+>> Maybe it could be all done from srm ?
+>> On srm install,
+>> a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?)
+>> b. create /bin/rm link to /bin/srm
+>
+> Definitely not. It's against the commandments: Thou shalt not mess with
+> another packages' files.
+
+ok.  I suspected that.
+It would be nice to have a list of these points for newer packagers.
+
+>> On srm uninstall, we ensure that
+>> a. rm /bin/rm link
+>> b. rename /bin/rm.vanilla to /bin/rm
+>>
+>> Hopefully that could be done reliably, with an uninstall script.
+>
+> No, this is very bad.
+>
+> It's what the alternatives system was designed to do for you, but I
+> really don't think that something as fundamental as rm should be messed
+> with in this way as I mentioned in my own email.
+>
+> srm is an add on userspace tool. To implement secure deletes properly,
+> you would want support at a lower level (i.e in the kernel/fs).
+
+makes sense.
+
+> I think srm should just be a tool people use explicitly when they want to.
+
+When I think about it, deleting with a pattern instead of just zeros is 
+probably only advantageous when a disk is being disposed of -- in which case 
+srm being a userspace tool is not a disadvantage.
+
+> Col
+>
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007252.html b/zarb-ml/mageia-dev/2011-August/007252.html new file mode 100644 index 000000000..f882959ec --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007252.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Aug 5 16:23:19 CEST 2011 +

+
+ +
Am 05.08.2011 14:58, schrieb andre999:
+> Colin Guthrie a écrit :
+>
+>> I think srm should just be a tool people use explicitly when they want to.
+>
+> When I think about it, deleting with a pattern instead of just zeros is 
+> probably only advantageous when a disk is being disposed of -- in which case 
+> srm being a userspace tool is not a disadvantage.
+>
+>> Col
+>>
+>
+Well, if you want to dispose the disk, then i'd use something like Dariks Boot 
+and Nuke (DBAN):
+http://www.dban.org/
+It offers really secure methods of overwriting your data with varying patterns,
+and if you want to dispose a whole disk. then maybe an userspace tool to delete 
+single
+files is not the best suited tool, IMHO.
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007253.html b/zarb-ml/mageia-dev/2011-August/007253.html new file mode 100644 index 000000000..f517cbf4c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007253.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Remove noarch packages in x86_64 + + + + + + + + + +

[Mageia-dev] Remove noarch packages in x86_64

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 5 18:00:17 CEST 2011 +

+
+ +
On Tue, 26 Jul 2011, Thomas Spuhler wrote:
+
+> Can someone that has the powers please remove these noarch packages in the 64 
+> bit repos
+
+Why do they need to be removed ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007254.html b/zarb-ml/mageia-dev/2011-August/007254.html new file mode 100644 index 000000000..5d7a359a6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007254.html @@ -0,0 +1,181 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Fri Aug 5 18:00:02 CEST 2011 +

+
+ +
Le Vendredi 05 Août 2011 08:58:12 andre999 a écrit :
+> Colin Guthrie a écrit :
+> > 'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble:
+> >> Luis Daniel Lucio Quiroz a écrit :
+> >>> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit :
+> >>>> Luis Daniel Lucio Quiroz a écrit :
+> >>>>> Helo,
+> >>>>> 
+> >>>>> As my experience in security field, to make Mageia more
+> >>>>> available in
+> >>>>> enterprise environments, and specially those that are security
+> >>>>> paranoid, i'm planning to port SRM.  SRM is a package that does
+> >>>>> a
+> >>>>> "secure" file deleting according some security standards (i dont
+> >>>>> remember right now names, i guess it is something in NIST, but
+> >>>>> that
+> >>>>> doesnt matter really).
+> >>>>> 
+> >>>>> My question is, what should be the procedure that when you
+> >>>>> install srm, then the normal rm command could be replaced?  i
+> >>>>> was thinking in pushing an alias but what other alternatives do
+> >>>>> i have?
+> >>>>> 
+> >>>>> please comment,
+> >>>>> 
+> >>>>> LD
+> >>>> 
+> >>>> At first glance that sounds like a reasonable approach EXCEPT -- a
+> >>>> system-level alias would be over-ridden by a user alias.
+> >>>> A user could innocently have an alias such as :
+> >>>> alias rm="rm -i"
+> >>>> 
+> >>>> rm is in /bin
+> >>>> - /bin/rm could be replaced with a link to srm, but I don't know
+> >>>> if that would be considered acceptable.
+> >>>> rm would have to be restored if srm were uninstalled
+> >>>> 
+> >>>> - wouldn't a link in /usr/bin/rm be executed first ?
+> >>>> Of course that doesn't cover execution with root privileges.
+> >>>> An alias in root wouldn't necessarily work, as an admin could
+> >>>> inadvertantly
+> >>>> replace it with another.  (By loading a new file with some changed
+> >>>> alias,
+> >>>> for example.)
+> >>>> But probably less likely than some user doing the same on their
+> >>>> profile.
+> >>>> 
+> >>>> There could be other approaches as well ... :)
+> >>> 
+> >>> You are right! :)
+> >>> 
+> >>> Well another option could be this:
+> >>> 
+> >>> a. we change coreutils to install /bin/rm as  /bin/rm.vanilla (or
+> >>> other name,
+> >>> that really doesnt matter),
+> >>> b. i change srm to install itself in /bin instead of /usr/bin
+> >>> c. we place alternatives in both packages to provide /bin/rm, giving
+> >>> preference to srm if installed, otherwise it will use rm of
+> >>> coreutils
+> >>> 
+> >>> LD
+> >> 
+> >> That would probably be the ideal approach.  But it might take a while
+> >> to
+> >> get the changes accepted in coreutils.
+> >> 
+> >> Maybe it could be all done from srm ?
+> >> On srm install,
+> >> a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?)
+> >> b. create /bin/rm link to /bin/srm
+> > 
+> > Definitely not. It's against the commandments: Thou shalt not mess with
+> > another packages' files.
+> 
+> ok.  I suspected that.
+> It would be nice to have a list of these points for newer packagers.
+> 
+> >> On srm uninstall, we ensure that
+> >> a. rm /bin/rm link
+> >> b. rename /bin/rm.vanilla to /bin/rm
+> >> 
+> >> Hopefully that could be done reliably, with an uninstall script.
+> > 
+> > No, this is very bad.
+> > 
+> > It's what the alternatives system was designed to do for you, but I
+> > really don't think that something as fundamental as rm should be messed
+> > with in this way as I mentioned in my own email.
+> > 
+> > srm is an add on userspace tool. To implement secure deletes properly,
+> > you would want support at a lower level (i.e in the kernel/fs).
+> 
+> makes sense.
+> 
+> > I think srm should just be a tool people use explicitly when they want
+> > to.
+> When I think about it, deleting with a pattern instead of just zeros is
+> probably only advantageous when a disk is being disposed of -- in which case
+> srm being a userspace tool is not a disadvantage.
+> 
+> > Col
+Good point
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007255.html b/zarb-ml/mageia-dev/2011-August/007255.html new file mode 100644 index 000000000..f30162887 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007255.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 5 18:17:15 CEST 2011 +

+
+ +
Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne:
+> On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote:
+> > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne:
+> > > Samba-common is the right package for this. I see no need to have a
+> > > squid- specific subpackage (and then samba-apache, samba-freeradius,
+> > > with the same content, or all virtual packages just pulling
+> > > samba-common).
+> > > 
+> > > Feel free to mess up your squid package by adding suggests on
+> > > samba-common, but since installing the right package is trivially
+> > > solved by the admin and is a small portion of the work required, I
+> > > would personally prefer not to increase the default footprint of any
+> > > installation that pulls in squid.
+> > 
+> > this is really imho an example where conditional suggests could work
+> > well: if you have squid already installed and you're installing samba,
+> > this subpackage could then be suggested. (and vice versa).
+> 
+> But, it is irrelevant. samba-common is required by both samba-client and
+> samba-server, so you can't install samba without getting ntlm_auth.
+
+there is definately a misunderstanding here, conditional suggests are not 
+usefull for requires, only for suggests
+ 
+> This is really about whether squid should pull in any pieces of samba by
+> default, and could be solved by adding:
+> Suggests: samba-common
+> 
+> to squid. But, I don't see much value, as this is a small part of the work
+> required to get a single-sign on authentication solution for squid against
+> AD. The default squid.conf already has example configs showing that
+> ntlm_auth is required, and all we are saving the user is a 'urpmf
+> ntlm_auth' and a 'urpmi samba-common'. However, there are many scenarios
+> squid can be deployed (e.g. SSO with GSSAPI, basic auth with LDAP, PAM,
+> NIS etc., no authentication, peer cache only etc.), and I don't see a
+> reason to pull in samba-common by default, when it saves the admin very
+> little effort.
+> 
+> Regards,
+> Buchan
+
+well if it was in a separate package (and not in samba-common), it would be 
+interesting to have conditional suggests. because then samba would pull it in; 
+and squid too, without needing samba if you don't have it.
+
+but, maybe i'm misunderstanding this thread
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007256.html b/zarb-ml/mageia-dev/2011-August/007256.html new file mode 100644 index 000000000..c08940e18 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007256.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Cauldron Install borked + + + + + + + + + +

[Mageia-dev] Cauldron Install borked

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Aug 5 18:24:57 CEST 2011 +

+
+ +
Doing a fresh install, after partitioning but before package selection 
+(last popup shows "looking for installed packages"), you get an error 
+panel saying:
+
+An error occurred
+rm of /mnt/var/cache/urpmi/mirrors.cache failed: No such file or directory
+
+Clicking OK sends you back to disk partitioning again.
+
+Why should a failed rm halt the install ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007257.html b/zarb-ml/mageia-dev/2011-August/007257.html new file mode 100644 index 000000000..ecdd3f35e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007257.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Proposal for backport process and policy + + + + + + + + + +

[Mageia-dev] Proposal for backport process and policy

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 5 19:05:21 CEST 2011 +

+
+ +
On Tue, 26 Jul 2011, Samuel Verschelde wrote:
+
+> 
+> *** Old backports ***  
+> Remove old backports when newer ones are submitted
+> - otherwise we let people use old bugged or plagged with security issues 
+> packages, when they don't necessarily know that there are problems with them
+> - simpler choice : users have to choose between the version in updates and the 
+> one in backports, not more
+
+rpmdrake shows older versions too ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007258.html b/zarb-ml/mageia-dev/2011-August/007258.html new file mode 100644 index 000000000..194390244 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007258.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Fri Aug 5 19:05:43 CEST 2011 +

+
+ +
Le Vendredi 05 Août 2011 18:17:15 Maarten Vanraes a écrit :
+> Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne:
+> > On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote:
+> > > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne:
+> > > > Samba-common is the right package for this. I see no need to
+> > > > have a
+> > > > squid- specific subpackage (and then samba-apache,
+> > > > samba-freeradius,
+> > > > with the same content, or all virtual packages just pulling
+> > > > samba-common).
+> > > > 
+> > > > Feel free to mess up your squid package by adding suggests on
+> > > > samba-common, but since installing the right package is
+> > > > trivially
+> > > > solved by the admin and is a small portion of the work required,
+> > > > I
+> > > > would personally prefer not to increase the default footprint of
+> > > > any
+> > > > installation that pulls in squid.
+> > > 
+> > > this is really imho an example where conditional suggests could work
+> > > well: if you have squid already installed and you're installing
+> > > samba,
+> > > this subpackage could then be suggested. (and vice versa).
+> > 
+> > But, it is irrelevant. samba-common is required by both samba-client and
+> > samba-server, so you can't install samba without getting ntlm_auth.
+> 
+> there is definately a misunderstanding here, conditional suggests are not
+> usefull for requires, only for suggests
+> 
+> > This is really about whether squid should pull in any pieces of samba by
+> > default, and could be solved by adding:
+> > Suggests: samba-common
+> > 
+> > to squid. But, I don't see much value, as this is a small part of the
+> > work required to get a single-sign on authentication solution for squid
+> > against AD. The default squid.conf already has example configs showing
+> > that ntlm_auth is required, and all we are saving the user is a 'urpmf
+> > ntlm_auth' and a 'urpmi samba-common'. However, there are many
+> > scenarios squid can be deployed (e.g. SSO with GSSAPI, basic auth with
+> > LDAP, PAM, NIS etc., no authentication, peer cache only etc.), and I
+> > don't see a reason to pull in samba-common by default, when it saves
+> > the admin very little effort.
+> > 
+> > Regards,
+> > Buchan
+> 
+> well if it was in a separate package (and not in samba-common), it would be
+> interesting to have conditional suggests. because then samba would pull it
+> in; and squid too, without needing samba if you don't have it.
+> 
+> but, maybe i'm misunderstanding this thread
+
+That's what i was asking
+to create a new subpckage  samba-helper-squid to stor ntlm_auth since 
+ntlm_auth is not linked with other lib it can stand by itself in a independend 
+subpackage to make a suggest from squid.  But it seems Buchan refuses.
+
+LD
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007259.html b/zarb-ml/mageia-dev/2011-August/007259.html new file mode 100644 index 000000000..aa6860c1f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007259.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Proposal for backport process and policy + + + + + + + + + +

[Mageia-dev] Proposal for backport process and policy

+ Samuel Verschelde + stormi at laposte.net +
+ Fri Aug 5 19:11:45 CEST 2011 +

+
+ +
Le vendredi 5 août 2011 19:05:21, nicolas vigier a écrit :
+> On Tue, 26 Jul 2011, Samuel Verschelde wrote:
+> > *** Old backports ***
+> > Remove old backports when newer ones are submitted
+> > - otherwise we let people use old bugged or plagged with security issues
+> > packages, when they don't necessarily know that there are problems with
+> > them - simpler choice : users have to choose between the version in
+> > updates and the one in backports, not more
+> 
+> rpmdrake shows older versions too ?
+
+Yes.
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007260.html b/zarb-ml/mageia-dev/2011-August/007260.html new file mode 100644 index 000000000..0e7efd361 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007260.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Cauldron Install borked + + + + + + + + + +

[Mageia-dev] Cauldron Install borked

+ Frank Griffin + ftg at roadrunner.com +
+ Fri Aug 5 19:15:04 CEST 2011 +

+
+ +
On 08/05/2011 12:24 PM, Frank Griffin wrote:
+> Doing a fresh install, after partitioning but before package selection 
+> (last popup shows "looking for installed packages"), you get an error 
+> panel saying:
+>
+> An error occurred
+> rm of /mnt/var/cache/urpmi/mirrors.cache failed: No such file or 
+> directory
+>
+> Clicking OK sends you back to disk partitioning again.
+>
+> Why should a failed rm halt the install ?
+>
+Switching to VC2 (busybox) and doing a "cp /dev/null 
+/mnt/var/cache/urpmi/mirrors.cache" allows the install to proceed.  "OK" 
+sends you back to disl partitioning, and as long as you don't reformat 
+the root partition (which would delete mirrors.cache), you're good to go.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007261.html b/zarb-ml/mageia-dev/2011-August/007261.html new file mode 100644 index 000000000..48fea2a0d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007261.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] qt4 macros naming + + + + + + + + + +

[Mageia-dev] qt4 macros naming

+ Zé + mmodem00 at gmail.com +
+ Fri Aug 5 19:43:11 CEST 2011 +

+
+ +
Hi,
+
+I have added qt macros with a more correct naming, but the old ones
+continue existing to avoid any breakage.
+
+The new qt4 macros (qt4.macros file):
+
+# New qt4 macros
+%_qt4_datadir           %{_prefix}/lib/qt4
+%_qt4_bindir            %{_qt4_datadir}/bin
+%_qt4_docdir            %{_docdir}/qt4
+%_qt4_libdir            %{_libdir}
+%_qt4_includedir        %{_qt4_datadir}/include
+%_qt4_plugindir         %{_libdir}/qt4/plugins
+%_qt4_demodir           %{_qt4_datadir}/demos
+%_qt4_exampledir        %{_qt4_datadir}/examples
+%_qt4_importdir         %{_qt4_datadir}/imports
+%_qt4_translationdir    %{_qt4_datadir}/translations
+
+If anyone with any suggest suggestion, please help improve
+
+regards,
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007262.html b/zarb-ml/mageia-dev/2011-August/007262.html new file mode 100644 index 000000000..6e878a142 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007262.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 5 19:48:00 CEST 2011 +

+
+ +
Op vrijdag 05 augustus 2011 19:05:43 schreef Luis Daniel Lucio Quiroz:
+> Le Vendredi 05 Août 2011 18:17:15 Maarten Vanraes a écrit :
+> > Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne:
+> > > On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote:
+> > > > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne:
+> > > > > Samba-common is the right package for this. I see no need to
+> > > > > have a
+> > > > > squid- specific subpackage (and then samba-apache,
+> > > > > samba-freeradius,
+> > > > > with the same content, or all virtual packages just pulling
+> > > > > samba-common).
+> > > > > 
+> > > > > Feel free to mess up your squid package by adding suggests on
+> > > > > samba-common, but since installing the right package is
+> > > > > trivially
+> > > > > solved by the admin and is a small portion of the work required,
+> > > > > I
+> > > > > would personally prefer not to increase the default footprint of
+> > > > > any
+> > > > > installation that pulls in squid.
+> > > > 
+> > > > this is really imho an example where conditional suggests could work
+> > > > well: if you have squid already installed and you're installing
+> > > > samba,
+> > > > this subpackage could then be suggested. (and vice versa).
+> > > 
+> > > But, it is irrelevant. samba-common is required by both samba-client
+> > > and samba-server, so you can't install samba without getting
+> > > ntlm_auth.
+> > 
+> > there is definately a misunderstanding here, conditional suggests are not
+> > usefull for requires, only for suggests
+> > 
+> > > This is really about whether squid should pull in any pieces of samba
+> > > by default, and could be solved by adding:
+> > > Suggests: samba-common
+> > > 
+> > > to squid. But, I don't see much value, as this is a small part of the
+> > > work required to get a single-sign on authentication solution for squid
+> > > against AD. The default squid.conf already has example configs showing
+> > > that ntlm_auth is required, and all we are saving the user is a 'urpmf
+> > > ntlm_auth' and a 'urpmi samba-common'. However, there are many
+> > > scenarios squid can be deployed (e.g. SSO with GSSAPI, basic auth with
+> > > LDAP, PAM, NIS etc., no authentication, peer cache only etc.), and I
+> > > don't see a reason to pull in samba-common by default, when it saves
+> > > the admin very little effort.
+> > > 
+> > > Regards,
+> > > Buchan
+> > 
+> > well if it was in a separate package (and not in samba-common), it would
+> > be interesting to have conditional suggests. because then samba would
+> > pull it in; and squid too, without needing samba if you don't have it.
+> > 
+> > but, maybe i'm misunderstanding this thread
+> 
+> That's what i was asking
+> to create a new subpckage  samba-helper-squid to stor ntlm_auth since
+> ntlm_auth is not linked with other lib it can stand by itself in a
+> independend subpackage to make a suggest from squid.  But it seems Buchan
+> refuses.
+> 
+> LD
+
+
+well, it's possible, but since there is no conditional suggests yet, i agree 
+with Buchan. if there was conditional suggests, that would be better...
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007263.html b/zarb-ml/mageia-dev/2011-August/007263.html new file mode 100644 index 000000000..515016364 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007263.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] qt4 macros naming + + + + + + + + + +

[Mageia-dev] qt4 macros naming

+ D.Morgan + dmorganec at gmail.com +
+ Fri Aug 5 20:28:12 CEST 2011 +

+
+ +
On Fri, Aug 5, 2011 at 7:43 PM, Zé <mmodem00 at gmail.com> wrote:
+> Hi,
+>
+> I have added qt macros with a more correct naming, but the old ones
+> continue existing to avoid any breakage.
+>
+> The new qt4 macros (qt4.macros file):
+>
+> # New qt4 macros
+> %_qt4_datadir           %{_prefix}/lib/qt4
+> %_qt4_bindir            %{_qt4_datadir}/bin
+> %_qt4_docdir            %{_docdir}/qt4
+> %_qt4_libdir            %{_libdir}
+> %_qt4_includedir        %{_qt4_datadir}/include
+> %_qt4_plugindir         %{_libdir}/qt4/plugins
+> %_qt4_demodir           %{_qt4_datadir}/demos
+> %_qt4_exampledir        %{_qt4_datadir}/examples
+> %_qt4_importdir         %{_qt4_datadir}/imports
+> %_qt4_translationdir    %{_qt4_datadir}/translations
+>
+> If anyone with any suggest suggestion, please help improve
+>
+> regards,
+> --
+> Zé
+>
+
+you should not do such big commits at once because on your commit you
+have not only changed the macros.
+
+I am not a kde expert but i speak on rpm POV.
+
+Has mikala reviewed all before you commited ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007264.html b/zarb-ml/mageia-dev/2011-August/007264.html new file mode 100644 index 000000000..72c10818d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007264.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Newly added requires not getting satisfied. Bug 2097 + + + + + + + + + +

[Mageia-dev] Newly added requires not getting satisfied. Bug 2097

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Fri Aug 5 20:55:23 CEST 2011 +

+
+ +
+One user has reported in the usenet newsgroup alt.os.linux.mageia,
+that the update for kipi-plugins is failing with
+
+kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied hugin
+
+The purpose of the update was to add a requires on hugin.
+
+When I was qa testing the update, I used urpmi to test that the install
+picked up hugin.
+
+Does mgaapplet only allow requires from the updates respository?
+
+Should hugin be copied to the updates repository?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007265.html b/zarb-ml/mageia-dev/2011-August/007265.html new file mode 100644 index 000000000..eca16bdb7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007265.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Cauldron Install borked + + + + + + + + + +

[Mageia-dev] Cauldron Install borked

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Fri Aug 5 21:12:40 CEST 2011 +

+
+ +
On 5 August 2011 18:24, Frank Griffin <ftg at roadrunner.com> wrote:
+> Doing a fresh install, after partitioning but before package selection (last
+> popup shows "looking for installed packages"), you get an error panel
+> saying:
+>
+> An error occurred
+> rm of /mnt/var/cache/urpmi/mirrors.cache failed: No such file or directory
+>
+> Clicking OK sends you back to disk partitioning again.
+>
+> Why should a failed rm halt the install ?
+
+Just fixed in SVN
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007266.html b/zarb-ml/mageia-dev/2011-August/007266.html new file mode 100644 index 000000000..8585cfb2a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007266.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] Re : Re: new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] Re : Re: new samba-squid subpackage proporsal

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Fri Aug 5 21:19:06 CEST 2011 +

+
+ +
Why condicional suggest?
+All what i'm asking is ti do that subpackage and then i place
+Suggests: samba-squid-helper
+At squid's spec
+
+I don't get your point.
+
+Connectés par MOTOBLUR™
+
+-----Message d'origine-----
+De : Maarten Vanraes <maarten.vanraes at gmail.com>
+À : mageia-dev at mageia.org
+Envoyé : ven., 05 août 2011, 17:48:34 UTC+00:00
+Objet : Re: [Mageia-dev] new samba-squid subpackage proporsal
+
+Op vrijdag 05 augustus 2011 19:05:43 schreef Luis Daniel Lucio Quiroz:
+> Le Vendredi 05 Août 2011 18:17:15 Maarten Vanraes a écrit :
+> > Op woensdag 03 augustus 2011 14:01:16 schreef Buchan Milne:
+> > > On Tuesday, 2 August 2011 22:23:24 Maarten Vanraes wrote:
+> > > > Op dinsdag 02 augustus 2011 17:04:41 schreef Buchan Milne:
+> > > > > Samba-common is the right package for this. I see no need to
+> > > > > have a
+> > > > > squid- specific subpackage (and then samba-apache,
+> > > > > samba-freeradius,
+> > > > > with the same content, or all virtual packages just pulling
+> > > > > samba-common).
+> > > > > 
+> > > > > Feel free to mess up your squid package by adding suggests on
+> > > > > samba-common, but since installing the right package is
+> > > > > trivially
+> > > > > solved by the admin and is a small portion of the work required,
+> > > > > I
+> > > > > would personally prefer not to increase the default footprint of
+> > > > > any
+> > > > > installation that pulls in squid.
+> > > > 
+> > > > this is really imho an example where conditional suggests could work
+> > > > well: if you have squid already installed and you're installing
+> > > > samba,
+> > > > this subpackage could then be suggested. (and vice versa).
+> > > 
+> > > But, it is irrelevant. samba-common is required by both samba-client
+> > > and samba-server, so you can't install samba without getting
+> > > ntlm_auth.
+> > 
+> > there is definately a misunderstanding here, conditional suggests are not
+> > usefull for requires, only for suggests
+> > 
+> > > This is really about whether squid should pull in any pieces of samba
+> > > by default, and could be solved by adding:
+> > > Suggests: samba-common
+> > > 
+> > > to squid. But, I don't see much value, as this is a small part of the
+> > > work required to get a single-sign on authentication solution for squid
+> > > against AD. The default squid.conf already has example configs showing
+> > > that ntlm_auth is required, and all we are saving the user is a 'urpmf
+> > > ntlm_auth' and a 'urpmi samba-common'. However, there are many
+> > > scenarios squid can be deployed (e.g. SSO with GSSAPI, basic auth with
+> > > LDAP, PAM, NIS etc., no authentication, peer cache only etc.), and I
+> > > don't see a reason to pull in samba-common by default, when it saves
+> > > the admin very little effort.
+> > > 
+> > > Regards,
+> > > Buchan
+> > 
+> > well if it was in a separate package (and not in samba-common), it would
+> > be interesting to have conditional suggests. because then samba would
+> > pull it in; and squid too, without needing samba if you don't have it.
+> > 
+> > but, maybe i'm misunderstanding this thread
+> 
+> That's what i was asking
+> to create a new subpckage  samba-helper-squid to stor ntlm_auth since
+> ntlm_auth is not linked with other lib it can stand by itself in a
+> independend subpackage to make a suggest from squid.  But it seems Buchan
+> refuses.
+> 
+> LD
+
+
+well, it's possible, but since there is no conditional suggests yet, i agree 
+with Buchan. if there was conditional suggests, that would be better...
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110805/f407fcf1/attachment-0001.html>
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007267.html b/zarb-ml/mageia-dev/2011-August/007267.html new file mode 100644 index 000000000..1780fecb0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007267.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Newly added requires not getting satisfied. Bug 2097 + + + + + + + + + +

[Mageia-dev] Newly added requires not getting satisfied. Bug 2097

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 5 21:55:37 CEST 2011 +

+
+ +
On Fri, 05 Aug 2011, David W. Hodgins wrote:
+
+>
+> One user has reported in the usenet newsgroup alt.os.linux.mageia,
+> that the update for kipi-plugins is failing with
+>
+> kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied hugin
+
+No problem installing this package for me. Do you have the full error
+message ?
+
+>
+> The purpose of the update was to add a requires on hugin.
+>
+> When I was qa testing the update, I used urpmi to test that the install
+> picked up hugin.
+>
+> Does mgaapplet only allow requires from the updates respository?
+
+No.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007268.html b/zarb-ml/mageia-dev/2011-August/007268.html new file mode 100644 index 000000000..47a1d2e56 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007268.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Newly added requires not getting satisfied. Bug 2097 + + + + + + + + + +

[Mageia-dev] Newly added requires not getting satisfied. Bug 2097

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Fri Aug 5 22:13:25 CEST 2011 +

+
+ +
On Fri, 05 Aug 2011 15:55:37 -0400, nicolas vigier <boklm at mars-attacks.org> wrote:
+
+> On Fri, 05 Aug 2011, David W. Hodgins wrote:
+>> One user has reported in the usenet newsgroup alt.os.linux.mageia,
+>> that the update for kipi-plugins is failing with
+>> kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied hugin
+
+> No problem installing this package for me. Do you have the full error
+> message ?
+
+Just the above.  I'll try to get more info from the user.
+
+>> The purpose of the update was to add a requires on hugin.
+>> When I was qa testing the update, I used urpmi to test that the install
+>> picked up hugin.
+>> Does mgaapplet only allow requires from the updates respository?
+
+> No.
+
+Thanks, I was getting a little worried about that.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007269.html b/zarb-ml/mageia-dev/2011-August/007269.html new file mode 100644 index 000000000..54bdfbb46 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007269.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Newly added requires not getting satisfied. Bug 2097 + + + + + + + + + +

[Mageia-dev] Newly added requires not getting satisfied. Bug 2097

+ Stew Benedict + stewbintn at gmail.com +
+ Fri Aug 5 22:33:59 CEST 2011 +

+
+ +
On 08/05/2011 04:13 PM, David W. Hodgins wrote:
+> On Fri, 05 Aug 2011 15:55:37 -0400, nicolas vigier 
+> <boklm at mars-attacks.org> wrote:
+>
+>> On Fri, 05 Aug 2011, David W. Hodgins wrote:
+>>> One user has reported in the usenet newsgroup alt.os.linux.mageia,
+>>> that the update for kipi-plugins is failing with
+>>> kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied 
+>>> hugin
+>
+>> No problem installing this package for me. Do you have the full error
+>> message ?
+>
+> Just the above.  I'll try to get more info from the user.
+>
+>>> The purpose of the update was to add a requires on hugin.
+>>> When I was qa testing the update, I used urpmi to test that the install
+>>> picked up hugin.
+>>> Does mgaapplet only allow requires from the updates respository?
+>
+>> No.
+>
+> Thanks, I was getting a little worried about that.
+>
+The update tool doesn't pickup requires from core for an update package. 
+Bug was already opened on an earlier update with the same issue (nothing 
+done to fix it yet)
+
+https://bugs.mageia.org/show_bug.cgi?id=2155
+
+Update is still blocked here on a machine if I only use the GUI tools 
+(urpmi of course handles it ok)
+
+
+
+-- 
+Stew Benedict
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007270.html b/zarb-ml/mageia-dev/2011-August/007270.html new file mode 100644 index 000000000..86df1bca7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007270.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Cauldron Install borked + + + + + + + + + +

[Mageia-dev] Cauldron Install borked

+ Frank Griffin + ftg at roadrunner.com +
+ Sat Aug 6 02:43:52 CEST 2011 +

+
+ +
On 08/05/2011 03:12 PM, Thierry Vignaud wrote:
+>
+> Just fixed in SVN
+>
+
+Thanks !
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007271.html b/zarb-ml/mageia-dev/2011-August/007271.html new file mode 100644 index 000000000..955f05526 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007271.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel + + + + + + + + + +

[Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Sat Aug 6 04:56:18 CEST 2011 +

+
+ +
Le Vendredi 05 Août 2011 13:12:20 Florian Hubold a écrit :
+> Am 05.08.2011 11:39, schrieb Thierry Vignaud:
+> > On 5 August 2011 11:03, Luis Daniel Lucio Quiroz<dlucio at okay.com.mx>  
+wrote:
+> >> Well i've only tried in *-desktop kernels
+> >> in
+> >> 
+> >> 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module
+> >> 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in
+> >> pcmcia slot but after that nothing happens,  I've tried loading by
+> >> hand ath5k module, but it doesnt works.  iwconfig or ifconfig -a
+> >> commands doesnt shows nothing eighter.
+> >> 
+> >> Just for your knowledge
+> > 
+> > Please open a bug report instead of sending a mail.
+> > Paste output of "lspcidrake -v|egrep -i 'net|ath'"
+> > Also attach (ie do not paste) your dmesg output to the BR.
+> 
+> There was a similar forum post for atk_htc, it just needed a newer firmware,
+> maybe you can adapt that to ath5k module:
+> https://forums.mageia.org/en/viewtopic.php?f=15&t=842
+
+OK,
+
+before breaking my cauldron,   what RPM shall i update so everybody getes 
+beneficied of this
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007272.html b/zarb-ml/mageia-dev/2011-August/007272.html new file mode 100644 index 000000000..a699d26ff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007272.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel + + + + + + + + + +

[Mageia-dev] my pcmcia atheros network card doesnt work with 3.0x kernel

+ Thomas Backlund + tmb at mageia.org +
+ Sat Aug 6 12:05:28 CEST 2011 +

+
+ +
Luis Daniel Lucio Quiroz skrev 6.8.2011 05:56:
+> Le Vendredi 05 Août 2011 13:12:20 Florian Hubold a écrit :
+>> Am 05.08.2011 11:39, schrieb Thierry Vignaud:
+>>> On 5 August 2011 11:03, Luis Daniel Lucio Quiroz<dlucio at okay.com.mx>
+> wrote:
+>>>> Well i've only tried in *-desktop kernels
+>>>> in
+>>>>
+>>>> 2.6.37.7 and 2.3.37.8 my atheros works perfectly with ath5k module
+>>>> 3.0.0 and 3.0.1rc1 it doesnt works, logs detect something pluged in
+>>>> pcmcia slot but after that nothing happens,  I've tried loading by
+>>>> hand ath5k module, but it doesnt works.  iwconfig or ifconfig -a
+>>>> commands doesnt shows nothing eighter.
+>>>>
+>>>> Just for your knowledge
+>>>
+>>> Please open a bug report instead of sending a mail.
+>>> Paste output of "lspcidrake -v|egrep -i 'net|ath'"
+>>> Also attach (ie do not paste) your dmesg output to the BR.
+>>
+>> There was a similar forum post for atk_htc, it just needed a newer firmware,
+>> maybe you can adapt that to ath5k module:
+>> https://forums.mageia.org/en/viewtopic.php?f=15&t=842
+>
+
+I'll update kernel-firmware-extra (and kernel-firmware) to get the new 
+firmwares for atk_htc available in cauldron...
+
+> OK,
+>
+> before breaking my cauldron,   what RPM shall i update so everybody getes
+> beneficied of this
+>
+> LD
+>
+
+for ath5k there is no firmware to update as it does not load any...
+So we reeally need a bugreport to see what's up...
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007273.html b/zarb-ml/mageia-dev/2011-August/007273.html new file mode 100644 index 000000000..6ef357b96 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007273.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Another Review and Migration + + + + + + + + + +

[Mageia-dev] Another Review and Migration

+ Sam Bailey + cyprix at cyprix.com.au +
+ Sat Aug 6 14:16:18 CEST 2011 +

+
+ +
 Hi everyone,
+
+ Congratulations on all the great work for Mageia 1 (and 2).
+
+ I've written a bit of a review and migration at:
+
+ http://thatsamguy.com/2011/08/mageia-1-migration-and-review/
+
+ Feel free to read and provide comments (either positive or negative!).
+
+ This is the first feature post since changing the site from "Planet 
+ Cyprix" to "that Sam guy".
+
+ Regards,
+
+-- 
+ Sam Bailey
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007274.html b/zarb-ml/mageia-dev/2011-August/007274.html new file mode 100644 index 000000000..c2e6f991b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007274.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Newly added requires not getting satisfied. Bug 2097 + + + + + + + + + +

[Mageia-dev] Newly added requires not getting satisfied. Bug 2097

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Aug 6 16:15:40 CEST 2011 +

+
+ +
Le vendredi 5 août 2011 22:33:59, Stew Benedict a écrit :
+> On 08/05/2011 04:13 PM, David W. Hodgins wrote:
+> > On Fri, 05 Aug 2011 15:55:37 -0400, nicolas vigier
+> > 
+> > <boklm at mars-attacks.org> wrote:
+> >> On Fri, 05 Aug 2011, David W. Hodgins wrote:
+> >>> One user has reported in the usenet newsgroup alt.os.linux.mageia,
+> >>> that the update for kipi-plugins is failing with
+> >>> kipi-plugins-expoblending-1.9.0-3.1.mga1.x86_64 (due to unsatisfied
+> >>> hugin
+> >> 
+> >> No problem installing this package for me. Do you have the full error
+> >> message ?
+> > 
+> > Just the above.  I'll try to get more info from the user.
+> > 
+> >>> The purpose of the update was to add a requires on hugin.
+> >>> When I was qa testing the update, I used urpmi to test that the install
+> >>> picked up hugin.
+> >>> Does mgaapplet only allow requires from the updates respository?
+> >> 
+> >> No.
+> > 
+> > Thanks, I was getting a little worried about that.
+> 
+> The update tool doesn't pickup requires from core for an update package.
+> Bug was already opened on an earlier update with the same issue (nothing
+> done to fix it yet)
+> 
+> https://bugs.mageia.org/show_bug.cgi?id=2155
+> 
+> Update is still blocked here on a machine if I only use the GUI tools
+> (urpmi of course handles it ok)
+
+See also https://bugs.mageia.org/show_bug.cgi?id=2317 which is the technical 
+description of the same problem.
+
+By the way, it would be great if there could be a fix quickly, updates are 
+failing for some time now, which is really not good for the quality feeling of 
+Mageia 1.
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007275.html b/zarb-ml/mageia-dev/2011-August/007275.html new file mode 100644 index 000000000..759be37fc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007275.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Re : Re: new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] Re : Re: new samba-squid subpackage proporsal

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Aug 6 16:18:31 CEST 2011 +

+
+ +
Le vendredi 5 août 2011 21:19:06, Luis Daniel Lucio Quiroz a écrit :
+> Why condicional suggest?
+> All what i'm asking is ti do that subpackage and then i place
+> Suggests: samba-squid-helper
+> At squid's spec
+> 
+> I don't get your point.
+> 
+
+I don't see either the need for a conditional suggest, what I understood is :
+samba-common would require samba-squid-helper
+squid would suggest samba-squid-helper
+
+thus allowing squid to use the helpers without the need for the full samba-
+common package.
+
+Now, bgmilne seems to think that there's no need to split samba-common for 
+that, for a reason that I haven't understood but maybe I don't know the 
+subject enough to understand it.
+
+Best regards
+
+Samuel
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007276.html b/zarb-ml/mageia-dev/2011-August/007276.html new file mode 100644 index 000000000..3861d188f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007276.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Another Review and Migration + + + + + + + + + +

[Mageia-dev] Another Review and Migration

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Aug 6 16:33:29 CEST 2011 +

+
+ +
Le samedi 6 août 2011 14:16:18, Sam Bailey a écrit :
+>  Hi everyone,
+> 
+>  Congratulations on all the great work for Mageia 1 (and 2).
+> 
+>  I've written a bit of a review and migration at:
+> 
+>  http://thatsamguy.com/2011/08/mageia-1-migration-and-review/
+> 
+>  Feel free to read and provide comments (either positive or negative!).
+> 
+>  This is the first feature post since changing the site from "Planet
+>  Cyprix" to "that Sam guy".
+> 
+>  Regards,
+
+Nice review, with context first and then very factual. Nice to see that all 
+upgrades went fine, and now we're waiting for your other contributions, as you 
+said you are willing to help :)
+Do you already know how you would like to contribute ? 
+
+Best regards
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007277.html b/zarb-ml/mageia-dev/2011-August/007277.html new file mode 100644 index 000000000..f69271b81 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007277.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Another Review and Migration + + + + + + + + + +

[Mageia-dev] Another Review and Migration

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Aug 6 19:45:14 CEST 2011 +

+
+ +
Op zaterdag 06 augustus 2011 14:16:18 schreef Sam Bailey:
+>  Hi everyone,
+> 
+>  Congratulations on all the great work for Mageia 1 (and 2).
+> 
+>  I've written a bit of a review and migration at:
+> 
+>  http://thatsamguy.com/2011/08/mageia-1-migration-and-review/
+> 
+>  Feel free to read and provide comments (either positive or negative!).
+> 
+>  This is the first feature post since changing the site from "Planet
+>  Cyprix" to "that Sam guy".
+> 
+>  Regards,
+
+very nice and factual, but perhaps it lack some more info on your personal 
+decision on why mageia, what you tested on Mandriva before making decision, 
+maybe a bit of which leftover packages you wanted to get added to Mageia and 
+perhaps some sort of short conclusion part
+
+do you have some bug on the microphone not working? perhaps coling can try to 
+make it work?
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007278.html b/zarb-ml/mageia-dev/2011-August/007278.html new file mode 100644 index 000000000..e7ac0a274 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007278.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Re : Re: new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] Re : Re: new samba-squid subpackage proporsal

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Aug 6 19:47:44 CEST 2011 +

+
+ +
Op zaterdag 06 augustus 2011 16:18:31 schreef Samuel Verschelde:
+> Le vendredi 5 août 2011 21:19:06, Luis Daniel Lucio Quiroz a écrit :
+> > Why condicional suggest?
+> > All what i'm asking is ti do that subpackage and then i place
+> > Suggests: samba-squid-helper
+> > At squid's spec
+> > 
+> > I don't get your point.
+> 
+> I don't see either the need for a conditional suggest, what I understood is
+> : samba-common would require samba-squid-helper
+> squid would suggest samba-squid-helper
+
+oic, due to it's requirement, that would indeed be superfluous...
+
+mea culpa
+
+> thus allowing squid to use the helpers without the need for the full samba-
+> common package.
+> 
+> Now, bgmilne seems to think that there's no need to split samba-common for
+> that, for a reason that I haven't understood but maybe I don't know the
+> subject enough to understand it.
+> 
+> Best regards
+> 
+> Samuel
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007279.html b/zarb-ml/mageia-dev/2011-August/007279.html new file mode 100644 index 000000000..97581bf95 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007279.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Re : Re: new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] Re : Re: new samba-squid subpackage proporsal

+ andre999 + andr55 at laposte.net +
+ Sat Aug 6 20:20:39 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+> Le vendredi 5 août 2011 21:19:06, Luis Daniel Lucio Quiroz a écrit :
+>> Why condicional suggest?
+>> All what i'm asking is ti do that subpackage and then i place
+>> Suggests: samba-squid-helper
+>> At squid's spec
+>>
+>> I don't get your point.
+>>
+>
+> I don't see either the need for a conditional suggest, what I understood is :
+> samba-common would require samba-squid-helper
+> squid would suggest samba-squid-helper
+>
+> thus allowing squid to use the helpers without the need for the full samba-
+> common package.
+>
+> Now, bgmilne seems to think that there's no need to split samba-common for
+> that, for a reason that I haven't understood but maybe I don't know the
+> subject enough to understand it.
+
+Exactly how I understand it, as well.
+At 50M, samba-common isn't tiny.
+
+If there is reluctance to have a subpackage for squid alone, maybe a subpackage 
+which is a superset for all packages wanting approximately the same components ?
+
+Possibly making this subpackage parallel to samba-common, created from the same 
+srcrpm, with mutual declared conflicts, so the subpackage is only installed if 
+samba-common isn't, and that those installing samba-common install a single 
+package.
+
+Both seem better options than an independant samba-squid-helper package, which 
+would require mutual conflicts with samba-common.
+
+Just some random ideas ...
+
+> Best regards
+>
+> Samuel
+>
+
+Regards :)
+-- 
+André
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007280.html b/zarb-ml/mageia-dev/2011-August/007280.html new file mode 100644 index 000000000..ae16f43e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007280.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] kernel-firmware-extra-20110730-1.mga2.nonfree triggers an older kernel to be installed + + + + + + + + + +

[Mageia-dev] kernel-firmware-extra-20110730-1.mga2.nonfree triggers an older kernel to be installed

+ Zé + mmodem00 at gmail.com +
+ Sat Aug 6 21:43:16 CEST 2011 +

+
+ +
Theres a new kernel-firmware-extra package and when i enter to update
+appeared severall problems, in wich requering an older kernel to
+installed when im using kernel-desktop-3.0.0-1.mga2-1-1.mga2
+
+The output:
+
+~]# LC_ALL=C urpmi --noclean kernel-firmware-extra
+In order to satisfy the
+'kernel-server-2.6.38.7-1.mga|kernel-desktop-2.6.38.7-1.mga|kernel-xen-pvops-2.6.38.7-1
+.mga' dependency, one of the following packages is needed:
+ 1- kernel-desktop-2.6.38.7-1.mga-1-1.mga1.x86_64: Linux Kernel for
+desktop use with x86_64 (to install)
+ 2- kernel-server-2.6.38.7-1.mga-1-1.mga1.x86_64: Linux Kernel for
+server use with x86_64 (to install)
+ 3- kernel-xen-pvops-2.6.38.7-1.mga-1-1.mga1.x86_64:
+%{summary_xen-pvops} (to install)
+What is your choice? (1-3)
+In order to satisfy the
+'kernel-server-2.6.38.7-1.mga|kernel-xen-pvops-2.6.38.7-1.mga'
+dependency, one of the f ollowing packages is needed:
+ 1- kernel-server-2.6.38.7-1.mga-1-1.mga1.x86_64: Linux Kernel for
+server use with x86_64 (to install)
+ 2- kernel-xen-pvops-2.6.38.7-1.mga-1-1.mga1.x86_64:
+%{summary_xen-pvops} (to install)
+What is your choice? (1-2)
+Some requested packages cannot be installed:
+Default-kde4-config-1-17.mga2.noarch (in order to keep
+Default-kde4-config-1-20.mga2.noarch)
+kernel-desktop-2.6.38.7-1.mga-1-1.mga1.x86_64 (due to unsatisfied
+kernel-firmware[>= 20101024-2])
+kernel-firmware-20110314-2.mga1.noarch (due to conflicts with
+kernel-firmware-extra-20110730-1.mga2.nonfree.noa rch)
+kernel-server-2.6.38.7-1.mga-1-1.mga1.x86_64 (due to unsatisfied
+kernel-firmware[>= 20101024-2], trying to prom ote kernel)
+kernel-xen-pvops-2.6.38.7-1.mga-1-1.mga1.x86_64 (due to unsatisfied
+kernel-firmware[>= 20101024-2], trying to p romote kernel)
+mageia-theme-Default-1.5.0.17-2.mga1.noarch (in order to keep
+mageia-theme-Default-1.5.0.17-3.mga2.noarch)
+Continue installation anyway? (Y/n)
+removing package basesystem-1-3.mga1.x86_64 will break your system
+The installation cannot continue because the following packages
+have to be removed for others to be upgraded:
+Default-kde4-config-1-20.mga2.noarch
+ (due to missing mageia-theme,
+  due to missing mageia-theme-kde-background)
+basesystem-1-3.mga1.x86_64
+ (due to missing kernel)
+bootsplash-3.3.5-2.mga1.noarch
+ (due to missing kernel)
+kernel-desktop-2.6.38.8-5.mga2-1-1.mga2.x86_64
+ (due to unsatisfied kernel-firmware >= 20101024-2)
+kernel-desktop-3.0.0-1.mga2-1-1.mga2.x86_64
+ (due to unsatisfied kernel-firmware >= 20101024-2)
+kernel-desktop-latest-3.0.0-1.mga2.x86_64
+ (due to missing kernel-desktop-3.0.0-1.mga2)
+kernel-firmware-20110314-2.mga1.noarch
+ (due to conflicts with kernel-firmware-extra-20110730-1.mga2.nonfree.noarch)
+mageia-theme-Default-1.5.0.17-3.mga2.noarch
+ (due to unsatisfied bootsplash >= 3.3.0,
+  due to missing plymouth-system-theme)
+mageia-theme-kde-background-1.5.0.17-3.mga2.noarch
+ (due to missing mageia-theme)
+ndiswrapper-1.56-4.mga1.x86_64
+ (due to missing kernel)
+plymouth-system-theme-0.8.3-12.mga1.x86_64
+ (due to missing plymouth(system-theme))
+x11-driver-video-1.0.0-35.mga1.x86_64
+ (due to missing x11-driver-video-nouveau)
+x11-driver-video-nouveau-0.0.16-0.20110303.3.mga1.x86_64
+ (due to missing kmod(nouveau))
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007281.html b/zarb-ml/mageia-dev/2011-August/007281.html new file mode 100644 index 000000000..6aaca5075 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007281.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Thunderbird update for Mga 1 + + + + + + + + + +

[Mageia-dev] Thunderbird update for Mga 1

+ Luc Menut + lmenut at free.fr +
+ Sun Aug 7 16:17:01 CEST 2011 +

+
+ +
Hi,
+
+Thunderbird 3.1.10 in Mga 1 has some vulnerabilities and should be updated.
+http://www.mozilla.org/security/known-vulnerabilities/thunderbird31.html
+
+Unlike Firefox 4, the Thunderbird 3.1.* branch seems still maintained by 
+mozilla; 3.1.12 is planned for 16/08/2011 
+https://wiki.mozilla.org/Releases/Thunderbird_3.1.12 .
+
+So we can stay with the 3.1.* branch, and update Thunderbird to 3.1.11 
+(the version that we have in cauldron since 21/06), or try to update to 
+the last version 5.0 (we have a request for Thunderbird 5 in bugzilla 
+https://bugs.mageia.org/show_bug.cgi?id=2088).
+
+Personnaly, I would prefer that we stay for now with 3.1.11 (and 
+probably 3.1.12) in Mga 1, and that we update to Thunderbird 5 only in 
+cauldron, and test it for some weeks.
+
+WDYT?
+
+-- 
+Luc Menut
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007282.html b/zarb-ml/mageia-dev/2011-August/007282.html new file mode 100644 index 000000000..dab6c96b1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007282.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Pierre Jarillon + jarillon at abul.org +
+ Sun Aug 7 16:41:34 CEST 2011 +

+
+ +
Le vendredi 5 août 2011 16:23:19, Florian Hubold a écrit :
+> Am 05.08.2011 14:58, schrieb andre999:
+> > Colin Guthrie a écrit :
+> >> I think srm should just be a tool people use explicitly when they want
+> >> to.
+> >
+> > When I think about it, deleting with a pattern instead of just zeros is
+> > probably only advantageous when a disk is being disposed of -- in which
+> > case srm being a userspace tool is not a disadvantage.
+> >
+> >> Col
+> 
+> Well, if you want to dispose the disk, then i'd use something like Dariks
+>  Boot and Nuke (DBAN):
+> http://www.dban.org/
+> It offers really secure methods of overwriting your data with varying
+>  patterns, and if you want to dispose a whole disk. then maybe an userspace
+>  tool to delete single
+> files is not the best suited tool, IMHO.
+
+Do you know WIPE ? http://wipe.sourceforge.net/
+I don't know if it is the most secured rm, but it could be.
+
+-- 
+Pierre Jarillon - http://pjarillon.free.fr/
+Vice-président de l'ABUL : http://abul.org/
+Microsoft est à l'informatique ce que McDonald est à la gastronomie.
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007283.html b/zarb-ml/mageia-dev/2011-August/007283.html new file mode 100644 index 000000000..946d2c64c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007283.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Thunderbird update for Mga 1 + + + + + + + + + +

[Mageia-dev] Thunderbird update for Mga 1

+ Zézinho + lists.jjorge at free.fr +
+ Sun Aug 7 18:10:57 CEST 2011 +

+
+ +
Em 07-08-2011 16:17, Luc Menut escreveu:
+> Personnaly, I would prefer that we stay for now with 3.1.11 (and 
+> probably 3.1.12) in Mga 1, and that we update to Thunderbird 5 only in 
+> cauldron, and test it for some weeks.
+>
+>
+Sounds normal. I think this is what is expressed by our policy for 
+updates, so this even does not need to be polled.
+
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007284.html b/zarb-ml/mageia-dev/2011-August/007284.html new file mode 100644 index 000000000..bd727c4f5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007284.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Florian Hubold + doktor5000 at arcor.de +
+ Sun Aug 7 23:03:15 CEST 2011 +

+
+ +
Am 07.08.2011 16:41, schrieb Pierre Jarillon:
+> Le vendredi 5 août 2011 16:23:19, Florian Hubold a écrit :
+>> Am 05.08.2011 14:58, schrieb andre999:
+>>> Colin Guthrie a écrit :
+>>>> I think srm should just be a tool people use explicitly when they want
+>>>> to.
+>>> When I think about it, deleting with a pattern instead of just zeros is
+>>> probably only advantageous when a disk is being disposed of -- in which
+>>> case srm being a userspace tool is not a disadvantage.
+>>>
+>>>> Col
+>> Well, if you want to dispose the disk, then i'd use something like Dariks
+>>   Boot and Nuke (DBAN):
+>> http://www.dban.org/
+>> It offers really secure methods of overwriting your data with varying
+>>   patterns, and if you want to dispose a whole disk. then maybe an userspace
+>>   tool to delete single
+>> files is not the best suited tool, IMHO.
+> Do you know WIPE ? http://wipe.sourceforge.net/
+> I don't know if it is the most secured rm, but it could be.
+>
+Yes, and it has the advantage that you don't need to reboot. Good point!
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007285.html b/zarb-ml/mageia-dev/2011-August/007285.html new file mode 100644 index 000000000..97b60ee51 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007285.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] openerp + + + + + + + + + +

[Mageia-dev] openerp

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Sun Aug 7 07:08:17 CEST 2011 +

+
+ +
Funda, and all
+
+Please contact xrg (he uses to be at mandriva forum) for openerp SRPMs, he has 
+a more cool SRPMS not published in site with many more patches
+
+LD
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007286.html b/zarb-ml/mageia-dev/2011-August/007286.html new file mode 100644 index 000000000..b46675022 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007286.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Mon Aug 8 05:32:21 CEST 2011 +

+
+ +
Le Dimanche 07 Août 2011 23:03:15 Florian Hubold a écrit :
+> Am 07.08.2011 16:41, schrieb Pierre Jarillon:
+> > Le vendredi 5 août 2011 16:23:19, Florian Hubold a écrit :
+> >> Am 05.08.2011 14:58, schrieb andre999:
+> >>> Colin Guthrie a écrit :
+> >>>> I think srm should just be a tool people use explicitly when they
+> >>>> want
+> >>>> to.
+> >>> 
+> >>> When I think about it, deleting with a pattern instead of just zeros
+> >>> is
+> >>> probably only advantageous when a disk is being disposed of -- in
+> >>> which
+> >>> case srm being a userspace tool is not a disadvantage.
+> >>> 
+> >>>> Col
+> >> 
+> >> Well, if you want to dispose the disk, then i'd use something like
+> >> Dariks>> 
+> >>   Boot and Nuke (DBAN):
+> >> http://www.dban.org/
+> >> It offers really secure methods of overwriting your data with varying
+> >> 
+> >>   patterns, and if you want to dispose a whole disk. then maybe an
+> >>   userspace tool to delete single
+> >> 
+> >> files is not the best suited tool, IMHO.
+> > 
+> > Do you know WIPE ? http://wipe.sourceforge.net/
+> > I don't know if it is the most secured rm, but it could be.
+> 
+> Yes, and it has the advantage that you don't need to reboot. Good point!
+
+Yes, but more than the tool is how to replace rm command
+
+LD
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007287.html b/zarb-ml/mageia-dev/2011-August/007287.html new file mode 100644 index 000000000..d427990bd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007287.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] RM replacement + + + + + + + + + +

[Mageia-dev] RM replacement

+ andre999 + andr55 at laposte.net +
+ Mon Aug 8 06:28:28 CEST 2011 +

+
+ +
Luis Daniel Lucio Quiroz a écrit :
+> Le Dimanche 07 Août 2011 23:03:15 Florian Hubold a écrit :
+>> Am 07.08.2011 16:41, schrieb Pierre Jarillon:
+>>> Le vendredi 5 août 2011 16:23:19, Florian Hubold a écrit :
+>>>> Am 05.08.2011 14:58, schrieb andre999:
+>>>>> Colin Guthrie a écrit :
+>>>>>> I think srm should just be a tool people use explicitly when they
+>>>>>> want
+>>>>>> to.
+>>>>>
+>>>>> When I think about it, deleting with a pattern instead of just zeros
+>>>>> is
+>>>>> probably only advantageous when a disk is being disposed of -- in
+>>>>> which
+>>>>> case srm being a userspace tool is not a disadvantage.
+>>>>>
+>>>>>> Col
+>>>>
+>>>> Well, if you want to dispose the disk, then i'd use something like
+>>>> Dariks>>
+>>>>    Boot and Nuke (DBAN):
+>>>> http://www.dban.org/
+>>>> It offers really secure methods of overwriting your data with varying
+>>>>
+>>>>    patterns, and if you want to dispose a whole disk. then maybe an
+>>>>    userspace tool to delete single
+>>>>
+>>>> files is not the best suited tool, IMHO.
+>>>
+>>> Do you know WIPE ? http://wipe.sourceforge.net/
+>>> I don't know if it is the most secured rm, but it could be.
+>>
+>> Yes, and it has the advantage that you don't need to reboot. Good point!
+>
+> Yes, but more than the tool is how to replace rm command
+>
+> LD
+
+I think it is useful to question WHY particular files should be securely deleted.
+
+For disposing of a disk, something like DBAN would be an excellent tool.  (WIPE 
+seems a little dated, since a lot of disk technology has changed since 2004.)
+
+For individual files, if the particular file should really be securely disposed 
+of, then maybe training the users disposing of such files to use srm could be a 
+useful approach.  (There would likely be no point in securely deleting most files.)
+
+Then there is always the option of an administrator using srm on items in the 
+trash folders on a regular basis.  This could be done automatically by a shell 
+script, if desired.
+
+A utility that periodically sanitizes free space could be useful, as well.
+
+Changes in the filesystem or the kernel seems the only reliable way to ensure 
+consistantly securely deleting all (or all of a defined subset of) files.
+
+-- 
+André
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007288.html b/zarb-ml/mageia-dev/2011-August/007288.html new file mode 100644 index 000000000..696f9a711 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007288.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ andre999 + andr55 at laposte.net +
+ Mon Aug 8 06:42:56 CEST 2011 +

+
+ +
I'm trying to set up chroot for cauldron, continuing to use mageia release as 
+my main system.  I basically followed the wiki page on chroot.
+
+Everything seemed to install ok, but when I try to run a gui application (such 
+as rpmdrake) under chroot, I get the message :
+
+"No protocol specified
+Cannot be run in console mode."
+
+However doing the same thing when I'm not in chroot has always worked.
+I was hoping to be able to run apps just the same under chroot.
+
+If anyone has an idea what I might be missing, it would be appreciated :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007289.html b/zarb-ml/mageia-dev/2011-August/007289.html new file mode 100644 index 000000000..5a319a9f6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007289.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ Sander Lepik + sander.lepik at eesti.ee +
+ Mon Aug 8 08:09:52 CEST 2011 +

+
+ +
08.08.2011 07:42, andre999 kirjutas:
+>
+> If anyone has an idea what I might be missing, it would be appreciated :)
+>
+This is what i used to get secondary X running: 
+http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fubuntuforums.org%2Farchive%2Findex.php%2Ft-510182.html&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:et:official&client=firefox-a
+
+If you want to use just some application then run sshd with X forwarding 
+on chroot and connect from your main system.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007290.html b/zarb-ml/mageia-dev/2011-August/007290.html new file mode 100644 index 000000000..016ce3608 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007290.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Thunderbird update for Mga 1 + + + + + + + + + +

[Mageia-dev] Thunderbird update for Mga 1

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Aug 8 11:00:24 CEST 2011 +

+
+ +
On Sun, 07 Aug 2011, Luc Menut wrote:
+
+> Hi,
+>
+> Thunderbird 3.1.10 in Mga 1 has some vulnerabilities and should be updated.
+> http://www.mozilla.org/security/known-vulnerabilities/thunderbird31.html
+>
+> Unlike Firefox 4, the Thunderbird 3.1.* branch seems still maintained by 
+> mozilla; 3.1.12 is planned for 16/08/2011 
+> https://wiki.mozilla.org/Releases/Thunderbird_3.1.12 .
+>
+> So we can stay with the 3.1.* branch, and update Thunderbird to 3.1.11 (the 
+> version that we have in cauldron since 21/06), or try to update to the last 
+> version 5.0 (we have a request for Thunderbird 5 in bugzilla 
+> https://bugs.mageia.org/show_bug.cgi?id=2088).
+>
+> Personnaly, I would prefer that we stay for now with 3.1.11 (and probably 
+> 3.1.12) in Mga 1, and that we update to Thunderbird 5 only in cauldron, and 
+> test it for some weeks.
+
+Yes, if updates are available for the 3.1.* branch, we should use this
+version. Updating to newer versions is only an exception allowed when
+the previous version is no longer supported.
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007291.html b/zarb-ml/mageia-dev/2011-August/007291.html new file mode 100644 index 000000000..8b713aaac --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007291.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Problems with dbus + + + + + + + + + +

[Mageia-dev] Problems with dbus

+ JA Magallon + jamagallon at ono.com +
+ Mon Aug 8 18:48:23 CEST 2011 +

+
+ +
On Fri, 5 Aug 2011 15:34:13 +0300
+Ahmad Samir <ahmadsamir3891 at gmail.com> wrote:
+
+> On 5 August 2011 00:23, JA Magallon <jamagallon at ono.com> wrote:
+> > Hi...
+> >
+> > I'm on limited internet connection, so I'll be quick and dirty.
+> > Plz, take a look at this mdv bug:
+> > https://qa.mandriva.com/show_bug.cgi?id=63728
+> >
+> > (copy)
+> > the problem is a bug in
+> > libdbus-glib-1_2 package, it is necessary a Debian patch
+> > http://patch-tracker.debian.org/package/dbus-glib/0.94-4
+> >
+> > I suffer it for Usb modem, and mdv package made it work.
+> > Probably hurts more apps...
+> >
+> 
+> Patch added from upstream GIT
+> https://bugs.freedesktop.org/show_bug.cgi?id=37852 (same patch).
+> 
+> Please test. (I didn't see any rebuild of network*manager-* in Debian,
+> so I am not sure a rebuild is required).
+> 
+
+Sorry for the delay.
+It solved my problems with USB modem, and everything works fine.
+
+> And a bug report would have worked to track the issue.
+> 
+
+Sorry, I was with limited connection capabilities while on holidays...
+Thanks for all.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007292.html b/zarb-ml/mageia-dev/2011-August/007292.html new file mode 100644 index 000000000..cc0ffab6c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007292.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ andre999 + andr55 at laposte.net +
+ Mon Aug 8 19:21:09 CEST 2011 +

+
+ +
Sander Lepik a écrit :
+> 08.08.2011 07:42, andre999 kirjutas:
+>>
+>> If anyone has an idea what I might be missing, it would be appreciated :)
+>>
+> This is what i used to get secondary X running:
+> http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fubuntuforums.org%2Farchive%2Findex.php%2Ft-510182.html&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:et:official&client=firefox-a
+>
+>
+> If you want to use just some application then run sshd with X forwarding
+> on chroot and connect from your main system.
+>
+> --
+> Sander
+
+Thanks for the link :)
+It helps a lot with some explanation of why the given steps are done.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007293.html b/zarb-ml/mageia-dev/2011-August/007293.html new file mode 100644 index 000000000..d9232aa5c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007293.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 9 11:39:45 CEST 2011 +

+
+ +
On 8 August 2011 06:42, andre999 <andr55 at laposte.net> wrote:
+> Everything seemed to install ok, but when I try to run a gui application
+> (such as rpmdrake) under chroot, I get the message :
+>
+> "No protocol specified
+> Cannot be run in console mode."
+
+Which is expected
+
+> If anyone has an idea what I might be missing, it would be appreciated :)
+
+One way to run X11 stuff from a chroot is to run:
+CHROOT=/where/is/my/chroot
+xhost +SI:localuser:root
+mount --bind /tmp/.X11-unix/ $CHROOT/tmp/.X11-unix/
+chroot $CHROOT rpmdrake/gedit/firefox/...
+
+
+If instead you want to allow all local users, you could alternatively
+replace the xhost call by:
+xhost + local:
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007294.html b/zarb-ml/mageia-dev/2011-August/007294.html new file mode 100644 index 000000000..496e1ee9f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007294.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] backporting chromium-browser-stable + + + + + + + + + +

[Mageia-dev] backporting chromium-browser-stable

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 9 12:21:43 CEST 2011 +

+
+ +
Hi
+
+I think we should do a security update of chromium-browser-stable
+that would be a backport of cauldron's chromium-browser-stable.
+WDYT?
+
+See you
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007295.html b/zarb-ml/mageia-dev/2011-August/007295.html new file mode 100644 index 000000000..bb0edaf0d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007295.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] backporting chromium-browser-stable + + + + + + + + + +

[Mageia-dev] backporting chromium-browser-stable

+ Balcaen John + mikala at mageia.org +
+ Tue Aug 9 13:15:02 CEST 2011 +

+
+ +
Le mardi 9 août 2011 07:21:43, Thierry Vignaud a écrit :
+> Hi
+> 
+> I think we should do a security update of chromium-browser-stable
+> that would be a backport of cauldron's chromium-browser-stable.
+> WDYT?
+it should be push as an update and not a backport.
+eventually the beta & unstable could be pushed as backports.
+
+
+
+-- 
+Balcaen John
+Jabber-ID: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007296.html b/zarb-ml/mageia-dev/2011-August/007296.html new file mode 100644 index 000000000..b51b38a5e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007296.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] backporting chromium-browser-stable + + + + + + + + + +

[Mageia-dev] backporting chromium-browser-stable

+ Sander Lepik + sander.lepik at eesti.ee +
+ Tue Aug 9 13:15:39 CEST 2011 +

+
+ +
09.08.2011 13:21, Thierry Vignaud kirjutas:
+> Hi
+>
+> I think we should do a security update of chromium-browser-stable
+> that would be a backport of cauldron's chromium-browser-stable.
+> WDYT?
+>
+> See you
+Finally someone is thinking about it :) Yes, of course! We have version 
+11 when there is version 13 released.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007297.html b/zarb-ml/mageia-dev/2011-August/007297.html new file mode 100644 index 000000000..bd6d4c314 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007297.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] Latest usb_modeswitch b0rked the BS + + + + + + + + + +

[Mageia-dev] Latest usb_modeswitch b0rked the BS

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Aug 9 13:37:17 CEST 2011 +

+
+ +
Hi,
+
+As someone may have seen, the BS is broken. We have identified the cause of
+breakage and will fix it (if we manage to reach someone in sysadmin team).
+Please be patient.. :)
+
+-- 
+Jani Välimaa
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110809/4a41ecb3/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007298.html b/zarb-ml/mageia-dev/2011-August/007298.html new file mode 100644 index 000000000..a2d9f4454 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007298.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] BS is borked + + + + + + + + + +

[Mageia-dev] BS is borked

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 9 14:34:28 CEST 2011 +

+
+ +
BS is borked.
+
+Every build failed on initializing the chroot.
+eg: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110809113922.tv.valstar.8603/log/chroot/
+
+Can someone fixes it and reupload failed uploads?
+
+Thx
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007299.html b/zarb-ml/mageia-dev/2011-August/007299.html new file mode 100644 index 000000000..01d41d904 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007299.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] BS is borked + + + + + + + + + +

[Mageia-dev] BS is borked

+ D.Morgan + dmorganec at gmail.com +
+ Tue Aug 9 15:04:33 CEST 2011 +

+
+ +
i will be available later today if noone do it i will fix the bs
+Can you the list of package we need to push back?
+
+On 8/9/11, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+> BS is borked.
+>
+> Every build failed on initializing the chroot.
+> eg:
+> http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110809113922.tv.valstar.8603/log/chroot/
+>
+> Can someone fixes it and reupload failed uploads?
+>
+> Thx
+>
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007300.html b/zarb-ml/mageia-dev/2011-August/007300.html new file mode 100644 index 000000000..b677325c8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007300.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] backporting chromium-browser-stable + + + + + + + + + +

[Mageia-dev] backporting chromium-browser-stable

+ Pascal Terjan + pterjan at gmail.com +
+ Tue Aug 9 15:10:17 CEST 2011 +

+
+ +
On Tue, Aug 9, 2011 at 12:21, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+> Hi
+>
+> I think we should do a security update of chromium-browser-stable
+> that would be a backport of cauldron's chromium-browser-stable.
+> WDYT?
+
+Yes
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007301.html b/zarb-ml/mageia-dev/2011-August/007301.html new file mode 100644 index 000000000..6f0e18538 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007301.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Latest usb_modeswitch b0rked the BS + + + + + + + + + +

[Mageia-dev] Latest usb_modeswitch b0rked the BS

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Aug 9 16:21:51 CEST 2011 +

+
+ +
2011/8/9 Jani Välimaa <jani.valimaa at gmail.com>:
+> Hi,
+>
+> As someone may have seen, the BS is broken. We have identified the cause of
+> breakage and will fix it (if we manage to reach someone in sysadmin team).
+> Please be patient.. :)
+>
+
+Should be OK now..
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007302.html b/zarb-ml/mageia-dev/2011-August/007302.html new file mode 100644 index 000000000..23c2d90ab --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007302.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] BS is borked + + + + + + + + + +

[Mageia-dev] BS is borked

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Tue Aug 9 16:23:13 CEST 2011 +

+
+ +
2011/8/9 D.Morgan <dmorganec at gmail.com>:
+> i will be available later today if noone do it i will fix the bs
+> Can you the list of package we need to push back?
+>
+> On 8/9/11, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
+>> BS is borked.
+>>
+>>
+>
+
+The BS should be ok now, thx to pterjan.
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007303.html b/zarb-ml/mageia-dev/2011-August/007303.html new file mode 100644 index 000000000..098de8c11 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007303.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Latest usb_modeswitch b0rked the BS + + + + + + + + + +

[Mageia-dev] Latest usb_modeswitch b0rked the BS

+ Thomas Backlund + tmb at mageia.org +
+ Tue Aug 9 16:23:48 CEST 2011 +

+
+ +
Jani Välimaa skrev 9.8.2011 17:21:
+> 2011/8/9 Jani Välimaa<jani.valimaa at gmail.com>:
+>> Hi,
+>>
+>> As someone may have seen, the BS is broken. We have identified the cause of
+>> breakage and will fix it (if we manage to reach someone in sysadmin team).
+>> Please be patient.. :)
+>>
+>
+> Should be OK now..
+
+We really should start blocking submissions when (build)requires are not 
+satisfied.
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007304.html b/zarb-ml/mageia-dev/2011-August/007304.html new file mode 100644 index 000000000..be3e4edac --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007304.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Upgrade in cauldron is broken + + + + + + + + + +

[Mageia-dev] Upgrade in cauldron is broken

+ Zé + mmodem00 at gmail.com +
+ Tue Aug 9 23:20:29 CEST 2011 +

+
+ +
Upgrade in cauldron is broken, check the output:
+
+~]# LC_ALL=C urpmi --noclean --auto-select
+In order to satisfy the 'libpeas-gtk-1.0.so.0()(64bit)' dependency,
+one of the following packages is needed:
+ 1- lib64peas-gtk1.0_0-1.1.1-1.mga2.x86_64: Library plugin handling UI
+part (to install)
+ 2- lib64peas-gtk0-1.1.0-3.mga2.x86_64: Library plugin handling UI
+part (to install)
+What is your choice? (1-2)
+In order to satisfy the 'libpeas-1.0.so.0()(64bit)' dependency, one of
+the following packages is needed:
+ 1- lib64peas0-1.1.0-3.mga2.x86_64: Library plugin handling (to install)
+ 2- lib64peas1.0_0-1.1.1-1.mga2.x86_64: Library plugin handling (to install)
+What is your choice? (1-2)
+In order to satisfy the 'packagekit-gui' dependency, one of the
+following packages is needed:
+ 1- gnome-packagekit-common-3.1.3-1.mga2.x86_64: Common files and
+services for GNOME PackageKit (to install)
+ 2- kpackagekit-common-0.6.3.3-2.mga1.x86_64: Common files and
+services for KDE PackageKit (to install)
+What is your choice? (1-2)
+Some requested packages cannot be installed:
+gobject-introspection-1.29.16-3.mga2.x86_64 (due to conflicts with
+gobject-introspection-1.29.16-1.mga2.x86_64)
+kipi-plugins-1.9.0-4.mga2.x86_64 (due to conflicts with
+kipi-plugins-2.0.0-1.mga2.x86_64)
+lib64kipiplugins1-1.9.0-4.mga2.x86_64 (due to unsatisfied
+kipi-plugins[== 1:1.9.0-4.mga2])
+lib64pulsezeroconf0-0.9.23-1.mga2.x86_64 (due to unsatisfied
+libpulsecommon-0.9.23.so()(64bit))
+Continue installation anyway? (Y/n)
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007305.html b/zarb-ml/mageia-dev/2011-August/007305.html new file mode 100644 index 000000000..0f6c126cf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007305.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Upgrade in cauldron is broken + + + + + + + + + +

[Mageia-dev] Upgrade in cauldron is broken

+ Zé + mmodem00 at gmail.com +
+ Tue Aug 9 23:27:15 CEST 2011 +

+
+ +
2011/8/9 Zé <mmodem00 at gmail.com>:
+> Upgrade in cauldron is broken, check the output:
+>
+> ~]# LC_ALL=C urpmi --noclean --auto-select
+> In order to satisfy the 'libpeas-gtk-1.0.so.0()(64bit)' dependency,
+> one of the following packages is needed:
+>  1- lib64peas-gtk1.0_0-1.1.1-1.mga2.x86_64: Library plugin handling UI
+> part (to install)
+>  2- lib64peas-gtk0-1.1.0-3.mga2.x86_64: Library plugin handling UI
+> part (to install)
+> What is your choice? (1-2)
+> In order to satisfy the 'libpeas-1.0.so.0()(64bit)' dependency, one of
+> the following packages is needed:
+>  1- lib64peas0-1.1.0-3.mga2.x86_64: Library plugin handling (to install)
+>  2- lib64peas1.0_0-1.1.1-1.mga2.x86_64: Library plugin handling (to install)
+> What is your choice? (1-2)
+> In order to satisfy the 'packagekit-gui' dependency, one of the
+> following packages is needed:
+>  1- gnome-packagekit-common-3.1.3-1.mga2.x86_64: Common files and
+> services for GNOME PackageKit (to install)
+>  2- kpackagekit-common-0.6.3.3-2.mga1.x86_64: Common files and
+> services for KDE PackageKit (to install)
+> What is your choice? (1-2)
+> Some requested packages cannot be installed:
+> gobject-introspection-1.29.16-3.mga2.x86_64 (due to conflicts with
+> gobject-introspection-1.29.16-1.mga2.x86_64)
+> kipi-plugins-1.9.0-4.mga2.x86_64 (due to conflicts with
+> kipi-plugins-2.0.0-1.mga2.x86_64)
+> lib64kipiplugins1-1.9.0-4.mga2.x86_64 (due to unsatisfied
+> kipi-plugins[== 1:1.9.0-4.mga2])
+> lib64pulsezeroconf0-0.9.23-1.mga2.x86_64 (due to unsatisfied
+> libpulsecommon-0.9.23.so()(64bit))
+> Continue installation anyway? (Y/n)
+>
+> --
+> Zé
+>
+
+Ignore this thread, i forgot to answer in last question, its all
+warning about the packages that are going to be removed, all is fine.
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007306.html b/zarb-ml/mageia-dev/2011-August/007306.html new file mode 100644 index 000000000..086238a7f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007306.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] help packaging lilypond + + + + + + + + + +

[Mageia-dev] help packaging lilypond

+ Thomas Spuhler + thomas at btspuhler.com +
+ Wed Aug 10 06:41:59 CEST 2011 +

+
+ +
Thanks for fixing the spec file and submit the package.
+I have a comment and a few questions. First the comment.
+an experienced packager telling someone like me (and others not so experienced 
+packagers)  why the package build failed that built just a few month ago would 
+have helped learning how to fix things. Now the package is built and I still 
+don't know what the error message meant.
+
+why can the scrollkeepr script be removed as not required when it was required 
+not so long ago and other distributions use it too. It supposed to be there if 
+you have omf files, and yes lilypond-doc has such files
+
+Can you please explain this in more details? I would appreciate it.
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007307.html b/zarb-ml/mageia-dev/2011-August/007307.html new file mode 100644 index 000000000..271bde26f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007307.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] help packaging lilypond + + + + + + + + + +

[Mageia-dev] help packaging lilypond

+ andre999 + andr55 at laposte.net +
+ Wed Aug 10 07:30:57 CEST 2011 +

+
+ +
Thomas Spuhler a écrit :
+> Thanks for fixing the spec file and submit the package.
+> I have a comment and a few questions. First the comment.
+> an experienced packager telling someone like me (and others not so experienced
+> packagers)  why the package build failed that built just a few month ago would
+> have helped learning how to fix things. Now the package is built and I still
+> don't know what the error message meant.
+>
+> why can the scrollkeepr script be removed as not required when it was required
+> not so long ago and other distributions use it too. It supposed to be there if
+> you have omf files, and yes lilypond-doc has such files
+>
+> Can you please explain this in more details? I would appreciate it.
+
+The short answer is filetriggers, which are automatically invoked by the build 
+system when the need is detected.
+You can find them at /var/lib/rpm/filetriggers/.
+
+There is a script for the scrollkeeper function.  It was actually replaced by 
+rarian some years ago, but the old name was kept.  And now filetriggers 
+automatically invoke the appropriate script when the need for this function is 
+detected.
+
+Mageia has aggressively cleaned spec files of packages, to remove references to 
+scripts no longer required.  This makes the spec files a lot easier to 
+maintain.  Mandriva (from which we forked) contained a lot of unnecessary 
+script references.  This is probably true of many distros.  As well, note that 
+each distro has their own set of filetriggers.
+So look at our packager wikis, Mageia specs for similar packages, and don't 
+hesitate to ask questions.
+
+Regards :)
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007308.html b/zarb-ml/mageia-dev/2011-August/007308.html new file mode 100644 index 000000000..29ae3e869 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007308.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] help packaging lilypond + + + + + + + + + +

[Mageia-dev] help packaging lilypond

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Wed Aug 10 08:33:20 CEST 2011 +

+
+ +
2011/8/10 Thomas Spuhler <thomas at btspuhler.com>:
+> Thanks for fixing the spec file and submit the package.
+> I have a comment and a few questions. First the comment.
+> an experienced packager telling someone like me (and others not so experienced
+> packagers)  why the package build failed that built just a few month ago would
+> have helped learning how to fix things. Now the package is built and I still
+> don't know what the error message meant.
+
+The build failed because now there are some checks which prevents
+uploading "erroneus" packages. Check for empty %post and %preun is one
+of those added checks. There's no such macro as %update_scrollkeeper
+(or  %clean_scrollkeeper) so that's why your build failed. See 'rpm
+--eval %update_scrollkeeper'
+
+>
+> why can the scrollkeepr script be removed as not required when it was required
+> not so long ago and other distributions use it too. It supposed to be there if
+> you have omf files, and yes lilypond-doc has such files
+>
+
+It was me who removed the scrollkeeper reqs as I only looked at %files
+section and noticed there was no %{_datadir}/omf/ entry. The
+filetriggers looks
+
+> Can you please explain this in more details? I would appreciate it.
+>
+
+Sure
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007309.html b/zarb-ml/mageia-dev/2011-August/007309.html new file mode 100644 index 000000000..4423edf8a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007309.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] help packaging lilypond + + + + + + + + + +

[Mageia-dev] help packaging lilypond

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Wed Aug 10 09:03:17 CEST 2011 +

+
+ +
2011/8/10 Jani Välimaa <jani.valimaa at gmail.com>:
+> 2011/8/10 Thomas Spuhler <thomas at btspuhler.com>:
+>> Thanks for fixing the spec file and submit the package.
+>> I have a comment and a few questions. First the comment.
+>> an experienced packager telling someone like me (and others not so experienced
+>> packagers)  why the package build failed that built just a few month ago would
+>> have helped learning how to fix things. Now the package is built and I still
+>> don't know what the error message meant.
+>
+> The build failed because now there are some checks which prevents
+> uploading "erroneus" packages. Check for empty %post and %preun is one
+> of those added checks. There's no such macro as %update_scrollkeeper
+> (or  %clean_scrollkeeper) so that's why your build failed. See 'rpm
+> --eval %update_scrollkeeper'
+>
+>>
+>> why can the scrollkeepr script be removed as not required when it was required
+>> not so long ago and other distributions use it too. It supposed to be there if
+>> you have omf files, and yes lilypond-doc has such files
+>>
+>
+> It was me who removed the scrollkeeper reqs as I only looked at %files
+> section and noticed there was no %{_datadir}/omf/ entry. The
+> filetriggers looks
+>
+
+Oopsie, somehow managed to push the send button.. Anyways, the
+filetriggers only looks .omf files from /usr/share/omf/ and now after
+checking I see in lilypond they're hiding in somewhere else and out of
+filetriggers reach. I think the fix would be moving them to a correct
+place to be "available" for filetriggers (and add back reqs I
+removed).
+
+>> Can you please explain this in more details? I would appreciate it.
+>>
+>
+> Sure
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007310.html b/zarb-ml/mageia-dev/2011-August/007310.html new file mode 100644 index 000000000..ebfc64cc6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007310.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ andre999 + andr55 at laposte.net +
+ Wed Aug 10 09:03:42 CEST 2011 +

+
+ +
Thierry Vignaud a écrit :
+> On 8 August 2011 06:42, andre999<andr55 at laposte.net>  wrote:
+>> Everything seemed to install ok, but when I try to run a gui application
+>> (such as rpmdrake) under chroot, I get the message :
+>>
+>> "No protocol specified
+>> Cannot be run in console mode."
+>
+> Which is expected
+>
+>> If anyone has an idea what I might be missing, it would be appreciated :)
+>
+> One way to run X11 stuff from a chroot is to run:
+> CHROOT=/where/is/my/chroot
+> xhost +SI:localuser:root
+> mount --bind /tmp/.X11-unix/ $CHROOT/tmp/.X11-unix/
+> chroot $CHROOT rpmdrake/gedit/firefox/...
+>
+> If instead you want to allow all local users, you could alternatively
+> replace the xhost call by:
+> xhost + local:
+
+Thanks for your detailed response.
+It lets me run everything.
+(Just chroot $CHROOT
+  gives me a terminal in chroot, which is what I wanted.)
+
+How do I restrict a chroot session to non-root privileges, so I can safely do 
+things like build packages locally ?
+I tried logging into my account, but it doesn't seem to work.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007311.html b/zarb-ml/mageia-dev/2011-August/007311.html new file mode 100644 index 000000000..6b5943ad0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007311.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 10 09:24:57 CEST 2011 +

+
+ +
On 10 August 2011 09:03, andre999 <andr55 at laposte.net> wrote:
+> Thanks for your detailed response.
+> It lets me run everything.
+> (Just chroot $CHROOT
+>  gives me a terminal in chroot, which is what I wanted.)
+>
+> How do I restrict a chroot session to non-root privileges, so I can safely
+> do things like build packages locally ?
+> I tried logging into my account, but it doesn't seem to work.
+
+Just use iurt for that...
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007312.html b/zarb-ml/mageia-dev/2011-August/007312.html new file mode 100644 index 000000000..45231837b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007312.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] new samba-squid subpackage proporsal

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Wed Aug 10 11:57:40 CEST 2011 +

+
+ +
On Friday, 5 August 2011 19:05:43 Luis Daniel Lucio Quiroz wrote:
+
+> That's what i was asking
+> to create a new subpckage  samba-helper-squid to stor ntlm_auth since
+> ntlm_auth is not linked with other lib it can stand by itself in a
+> independend subpackage to make a suggest from squid.
+
+??
+
+For a working solution, you need:
+-ntlm_auth (currently in samba-common)
+-winbindd (currently in samba-winbind)
+-net (to join the domain, currently in samba-common)
+-/etc/samba/smb.conf (currently in samba-common)
+
+Please compare the output of 'ldd /usr/bin/ntlm_auth /usr/sbin/winbindd 
+/usr/bin/net' and 'rpm -qR samba-common samba-winbind'. You will notice that 
+there are really no unnecessary dependencies:
+
+Let me do it for you:
+
+$ rpm -qR samba-common samba-winbind|awk -F '(' '/^lib/ {print $1}'|sort -u > 
+/tmp/samba-common-libs
+$ ldd /usr/bin/net /usr/bin/ntlm_auth /usr/sbin/winbindd | awk '/lib/ {print 
+$1}'|sort -u > /tmp/ntlm_auth_libs
+$ diff -u /tmp/samba-common-libs /tmp/ntlm_auth_libs 
+--- /tmp/samba-common-libs      2011-08-10 11:41:43.000000000 +0200
++++ /tmp/ntlm_auth_libs 2011-08-10 11:41:45.000000000 +0200
+@@ -1,18 +1,24 @@
++/lib64/ld-linux-x86-64.so.2
+ libcap.so.2
+ libcom_err.so.2
++libcrypto.so.1.0.0
+ libc.so.6
+ libdl.so.2
+ libgssapi_krb5.so.2
+ libk5crypto.so.3
+ libkrb5.so.3
++libkrb5support.so.0
+ liblber-2.4.so.2
+ libldap-2.4.so.2
++libncurses.so.5
+ libnsl.so.1
+-libpam.so.0
+ libpopt.so.0
++libpthread.so.0
+ libreadline.so.6
+ libresolv.so.2
+ librt.so.1
++libsasl2.so.2
++libssl.so.1.0.0
+ libtalloc.so.2
+ libtdb.so.1
+ libwbclient.so.0
+
+
+(All we find is that we could theoretically have ntlm_auth and winbindd 
+without libpam, but, well, you can't easily have a system without it anyway 
+...)
+
+Feel free to make squid suggest samba-winbind, but there is very little 
+benefit to splitting ntlm_auth out of samba-common. To use it for SSO against 
+AD, you will need /usr/bin/net to join the domain, and you will need an 
+smb.conf file. Both of these are in samba-common. Then you will probably need 
+samba-winbind for winbindd. About the only things we can do to have *any* 
+impact at all on the footprint of squid+ntlm_auth would be to:
+
+1)move rpcclient, smbcacls, smbcquotas and smbtree out of samba-common (e.g. 
+RH has these in samba-client, but these tools are more useful on servers than 
+e.g. smbspool, so I would prefer it to be a package that doesn't require 
+pulling in all the contents of samba-client)
+2)split winbindd/ntlm_auth/nss_winbind/pam_winbind (RH has winbindd and 
+nltm_auth in samba-winbind, and nss_winbind and pam_winbind in samba-winbind-
+clients). But, nss_winbind and pam_winbind together are under 100kB, and 
+winbindd is 7.8MB, so again there is little benefit.
+
+Nothing else makes any sense.
+
+But, since ntlm_auth is commonly used in at least 3 different scenarios with 3 
+different packages *in the distribution*, making a *squid-specific* package is 
+just ridiculous.
+
+I am open to useful, logical proposals, see above. However, there are some 
+issues (e.g. pam_winbind and nss_winbind aren't really that useful 
+individually, they are typically used together, hence RH shipping them 
+together in samba-winbind-clients), so please discuss the issues in advance, 
+after having at least having familiarised yourself with *all* the tools in 
+question.
+
+Regards,
+Buchan
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007313.html b/zarb-ml/mageia-dev/2011-August/007313.html new file mode 100644 index 000000000..90c456350 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007313.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Re : Re: new samba-squid subpackage proporsal + + + + + + + + + +

[Mageia-dev] Re : Re: new samba-squid subpackage proporsal

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Wed Aug 10 12:13:13 CEST 2011 +

+
+ +
On Saturday, 6 August 2011 20:20:39 andre999 wrote:
+> Samuel Verschelde a écrit :
+> > Le vendredi 5 août 2011 21:19:06, Luis Daniel Lucio Quiroz a écrit :
+> >> Why condicional suggest?
+> >> All what i'm asking is ti do that subpackage and then i place
+> >> Suggests: samba-squid-helper
+> >> At squid's spec
+> >> 
+> >> I don't get your point.
+> > 
+> > I don't see either the need for a conditional suggest, what I understood
+> > is : samba-common would require samba-squid-helper
+> > squid would suggest samba-squid-helper
+> > 
+> > thus allowing squid to use the helpers without the need for the full
+> > samba- common package.
+> > 
+> > Now, bgmilne seems to think that there's no need to split samba-common
+> > for that, for a reason that I haven't understood but maybe I don't know
+> > the subject enough to understand it.
+
+My point is that splitting ntlm_auth out samba-common would make no 
+difference, as:
+-ntlm_auth requires smb.conf, in samba-common
+-ntlm_auth (at least for this scenario) requires samba-winbind, which requires 
+smb.conf, which is in samba-common
+-/usr/bin/net is required (at least once) to join the domain, it is in samba-
+common
+
+> Exactly how I understand it, as well.
+> At 50M, samba-common isn't tiny.
+
+Unfortunately, due to samba's migration to auto-generated code based on IDL 
+files, binaries have been growing substantially. It may be worthwhile to split 
+other less commonly used binaries out of samba-common.
+
+But, the purpose samba-common serves, having binaries and configuration files 
+which are *required* by many different scenarios, should not be changed to fit 
+squid. We could migrate ntlm_auth out of samba-common, but whatever package it 
+is in would require samba-common anyway ...
+
+> If there is reluctance to have a subpackage for squid alone, maybe a
+> subpackage which is a superset for all packages wanting approximately the
+> same components ?
+
+Why specific to squid, when 3 packages in the distribution are commonly used 
+with ntlm_auth?
+
+> Possibly making this subpackage parallel to samba-common, created from the
+> same srcrpm, with mutual declared conflicts, so the subpackage is only
+> installed if samba-common isn't, and that those installing samba-common
+> install a single package.
+
+What is the cost/benefit of this?
+
+> Both seem better options than an independant samba-squid-helper package,
+> which would require mutual conflicts with samba-common.
+> 
+> Just some random ideas ...
+
+I would like to understand the motivation first. What are we trying to 
+achieve, besides more work for the samba maintainer?
+
+If we are trying to reduce the disk footprint of a squid+ntlm_auth setup, the 
+best approach is to move some binaries out of samba-common.
+
+Regards,
+Buchan
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007314.html b/zarb-ml/mageia-dev/2011-August/007314.html new file mode 100644 index 000000000..35e5aa627 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007314.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Aug 10 12:52:50 CEST 2011 +

+
+ +
On Wed, 10 Aug 2011, andre999 wrote:
+
+>
+> How do I restrict a chroot session to non-root privileges, so I can safely 
+> do things like build packages locally ?
+> I tried logging into my account, but it doesn't seem to work.
+
+Create an account inside the chroot.
+
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007315.html b/zarb-ml/mageia-dev/2011-August/007315.html new file mode 100644 index 000000000..1491fa16d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007315.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] help packaging lilypond + + + + + + + + + +

[Mageia-dev] help packaging lilypond

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 10 18:20:41 CEST 2011 +

+
+ +
Le mercredi 10 août 2011 à 01:30 -0400, andre999 a écrit :
+> Thomas Spuhler a écrit :
+> > Thanks for fixing the spec file and submit the package.
+> > I have a comment and a few questions. First the comment.
+> > an experienced packager telling someone like me (and others not so experienced
+> > packagers)  why the package build failed that built just a few month ago would
+> > have helped learning how to fix things. Now the package is built and I still
+> > don't know what the error message meant.
+> >
+> > why can the scrollkeepr script be removed as not required when it was required
+> > not so long ago and other distributions use it too. It supposed to be there if
+> > you have omf files, and yes lilypond-doc has such files
+> >
+> > Can you please explain this in more details? I would appreciate it.
+> 
+> The short answer is filetriggers, which are automatically invoked by the build 
+> system when the need is detected.
+> You can find them at /var/lib/rpm/filetriggers/.
+> 
+> There is a script for the scrollkeeper function.  It was actually replaced by 
+> rarian some years ago, but the old name was kept.  And now filetriggers 
+> automatically invoke the appropriate script when the need for this function is 
+> detected.
+> 
+> Mageia has aggressively cleaned spec files of packages, to remove references to 
+> scripts no longer required.  This makes the spec files a lot easier to 
+> maintain.  Mandriva (from which we forked) contained a lot of unnecessary 
+> script references.  This is probably true of many distros.  As well, note that 
+> each distro has their own set of filetriggers.
+
+In fact, only mandriva and mageia has the filetrigger patch to rpm,
+iirc, even if dmorgan is pushing this upstream. 
+
+and having this done upstream would help to have a common set of
+scripts.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007318.html b/zarb-ml/mageia-dev/2011-August/007318.html new file mode 100644 index 000000000..56e907fee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007318.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Kira + elegant.pegasus at gmail.com +
+ Fri Aug 5 10:04:54 CEST 2011 +

+
+ +
在 Wed, 03 Aug 2011 20:27:16 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:
+> Also please run this as your regular user, not root.
+>
+> You should also ensure that no applications are running that are using
+> the /dev/snd/pcm* devices, e.g. with the fuser command above, you should
+> kill off amarok before trying to start PA.
+>
+> Cheers
+>
+> Col
+>
+>
+New result after running in normal user...
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: report.txt
+URL: </pipermail/mageia-dev/attachments/20110805/d7b6f96a/attachment-0001.txt>
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007319.html b/zarb-ml/mageia-dev/2011-August/007319.html new file mode 100644 index 000000000..4dea24fad --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007319.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM summit at Plumbers 2011

+ Steve McIntyre + steve.mcintyre at linaro.org +
+ Tue Aug 9 20:15:34 CEST 2011 +

+
+ +
Hi folks,
+
+Following on from the founding of the cross-distro ARM mailing list,
+I'd like to propose an ARM summit at this year's Linux Plumbers
+conference [1]. I'm hoping for a slot on Thursday evening, but this
+remains to be confirmed at this point.
+
+We had some lively discussion about the state of ARM Linux distros at
+the Linaro Connect [2] event in Cambridge last week. It rapidly became
+clear that some of the topics we discussed deserve a wider audience,
+so we're suggesting a meetup at Plumbers for that bigger
+discussion. The initial proposed agenda is:
+
+ * ARM hard-float
+   + What is it and why does it matter?
+   + How can distributions keep compatible (i.e. gcc triplet to
+     describe the port)?
+
+ * Adding support for ARM as an architecture to the Linux Standard
+   Base (LSB)
+   + Does it matter?
+   + What's needed?
+
+ * FHS - multi-arch coming soon, how do we proceed?
+
+ * 3D support on ARM platforms
+   + Open GL vs. GLES - which is appropriate?
+
+but I'm sure that other people will think of more issues they'd like
+to discuss. :-)
+
+If you wish to attend, please reply to the cross-distro list and let
+us know to expect you. Make sure you're registered to attend Plumbers
+Conf, and get your travel and accommodation organised ASAP.
+
+[1] http://www.linuxplumbersconf.org/2011/
+[2] http://connect.linaro.org/
+
+Cheers,
+--
+Steve McIntyre                                steve.mcintyre at linaro.org
+<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
+
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007320.html b/zarb-ml/mageia-dev/2011-August/007320.html new file mode 100644 index 000000000..c97d732e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007320.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] help packaging lilypond + + + + + + + + + +

[Mageia-dev] help packaging lilypond

+ Thomas Spuhler + thomas at btspuhler.com +
+ Thu Aug 11 04:37:50 CEST 2011 +

+
+ +
On Tuesday, August 09, 2011 10:30:57 pm andre999 wrote:
+> Thomas Spuhler a écrit :
+> > Thanks for fixing the spec file and submit the package.
+> > I have a comment and a few questions. First the comment.
+> > an experienced packager telling someone like me (and others not so
+> > experienced packagers)  why the package build failed that built just a
+> > few month ago would have helped learning how to fix things. Now the
+> > package is built and I still don't know what the error message meant.
+> > 
+> > why can the scrollkeepr script be removed as not required when it was
+> > required not so long ago and other distributions use it too. It supposed
+> > to be there if you have omf files, and yes lilypond-doc has such files
+> > 
+> > Can you please explain this in more details? I would appreciate it.
+> 
+> The short answer is filetriggers, which are automatically invoked by the
+> build system when the need is detected.
+> You can find them at /var/lib/rpm/filetriggers/.
+> 
+> There is a script for the scrollkeeper function.  It was actually replaced
+> by rarian some years ago, but the old name was kept.  And now filetriggers
+> automatically invoke the appropriate script when the need for this
+> function is detected.
+
+So not need to call them in the spec file?
+> 
+> Mageia has aggressively cleaned spec files of packages, to remove
+> references to scripts no longer required.  This makes the spec files a lot
+> easier to maintain.  Mandriva (from which we forked) contained a lot of
+> unnecessary script references.  This is probably true of many distros.  As
+> well, note that each distro has their own set of filetriggers.
+> So look at our packager wikis, Mageia specs for similar packages, and don't
+> hesitate to ask questions.
+
+Where is this wiki. There si not lingk from mageia wiki.
+> 
+> Regards :)
+
+Thanks a lot for these explanations. I'' come back with more questions about 
+php-pear mysterious automatic requires that are wrong (got around them with a 
+define _exceptions hack)
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007321.html b/zarb-ml/mageia-dev/2011-August/007321.html new file mode 100644 index 000000000..ff749d6d1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007321.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] help packaging lilypond + + + + + + + + + +

[Mageia-dev] help packaging lilypond

+ Thomas Spuhler + thomas at btspuhler.com +
+ Thu Aug 11 05:46:13 CEST 2011 +

+
+ +
On Wednesday, August 10, 2011 12:03:17 am Jani Välimaa wrote:
+> 2011/8/10 Jani Välimaa <jani.valimaa at gmail.com>:
+> > 2011/8/10 Thomas Spuhler <thomas at btspuhler.com>:
+> >> Thanks for fixing the spec file and submit the package.
+> >> I have a comment and a few questions. First the comment.
+> >> an experienced packager telling someone like me (and others not so
+> >> experienced packagers)  why the package build failed that built just a
+> >> few month ago would have helped learning how to fix things. Now the
+> >> package is built and I still don't know what the error message meant.
+> > 
+> > The build failed because now there are some checks which prevents
+> > uploading "erroneus" packages. Check for empty %post and %preun is one
+> > of those added checks. There's no such macro as %update_scrollkeeper
+> > (or  %clean_scrollkeeper) so that's why your build failed. See 'rpm
+> > --eval %update_scrollkeeper'
+> > 
+> >> why can the scrollkeepr script be removed as not required when it was
+> >> required not so long ago and other distributions use it too. It
+> >> supposed to be there if you have omf files, and yes lilypond-doc has
+> >> such files
+> > 
+> > It was me who removed the scrollkeeper reqs as I only looked at %files
+> > section and noticed there was no %{_datadir}/omf/ entry. The
+> > filetriggers looks
+> 
+> Oopsie, somehow managed to push the send button.. Anyways, the
+> filetriggers only looks .omf files from /usr/share/omf/ and now after
+> checking I see in lilypond they're hiding in somewhere else and out of
+> filetriggers reach. I think the fix would be moving them to a correct
+> place to be "available" for filetriggers (and add back reqs I
+> removed).
+> 
+> >> Can you please explain this in more details? I would appreciate it.
+> > 
+> > Sure
+
+I guess the current build works. I have been a user for a long time and 
+haven't seen any problems.
+The relase version should have come out on the 8th. as soon as it shows up, 
+will build it.
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007322.html b/zarb-ml/mageia-dev/2011-August/007322.html new file mode 100644 index 000000000..737b318a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007322.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 11 14:16:57 CEST 2011 +

+
+ +
'Twas brillig, and Kira at 05/08/11 10:04 did gyre and gimble:
+> E: alsa-mixer.c: Assertion 'a_options' failed at modules/alsa/alsa-mixer.c:2893, function enumeration_is_subset(). Aborting.
+
+Ahh yes. This is fixed upstream[1], so I'll push a new package shortly.
+
+Col
+
+1.
+http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=5bfcb5d8a09bf5c726d4aea6fb04533007c24143
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007323.html b/zarb-ml/mageia-dev/2011-August/007323.html new file mode 100644 index 000000000..a196b65d6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007323.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Kira + elegant.pegasus at gmail.com +
+ Thu Aug 11 14:22:37 CEST 2011 +

+
+ +
在 Thu, 11 Aug 2011 20:16:57 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:
+
+> 'Twas brillig, and Kira at 05/08/11 10:04 did gyre and gimble:
+>> E: alsa-mixer.c: Assertion 'a_options' failed at  
+>> modules/alsa/alsa-mixer.c:2893, function enumeration_is_subset().  
+>> Aborting.
+>
+> Ahh yes. This is fixed upstream[1], so I'll push a new package shortly.
+>
+> Col
+>
+> 1.
+> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=5bfcb5d8a09bf5c726d4aea6fb04533007c24143
+>
+
+In the new build, this problem is solved? I have voice back now.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007324.html b/zarb-ml/mageia-dev/2011-August/007324.html new file mode 100644 index 000000000..72df6d48f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007324.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 11 15:39:34 CEST 2011 +

+
+ +
'Twas brillig, and Kira at 11/08/11 14:22 did gyre and gimble:
+> In the new build, this problem is solved? I have voice back now.
+
+Actually yeah, I think the latest available package has this fix in already.
+
+I've just submitted another build with some more fixes in. If you still
+have problems let me know, otherwise I'll assume all is well
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007325.html b/zarb-ml/mageia-dev/2011-August/007325.html new file mode 100644 index 000000000..4483ae28f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007325.html @@ -0,0 +1,64 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Thu Aug 11 15:58:56 CEST 2011 +

+
+ +
Just a short notice:
+I have to apologize, I did not have the time to test and give feedback
+lately, I promise to get back to this issue and nag you with my
+problems!
+
+-- 
+wobo
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007326.html b/zarb-ml/mageia-dev/2011-August/007326.html new file mode 100644 index 000000000..5cc9cbd9c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007326.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] Audio Warning: New PulseAudio test release on the way.... + + + + + + + + + +

[Mageia-dev] Audio Warning: New PulseAudio test release on the way....

+ Kira + elegant.pegasus at gmail.com +
+ Thu Aug 11 16:32:29 CEST 2011 +

+
+ +
在 Thu, 11 Aug 2011 21:39:34 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:
+
+> 'Twas brillig, and Kira at 11/08/11 14:22 did gyre and gimble:
+>> In the new build, this problem is solved? I have voice back now.
+>
+> Actually yeah, I think the latest available package has this fix in  
+> already.
+>
+> I've just submitted another build with some more fixes in. If you still
+> have problems let me know, otherwise I'll assume all is well
+>
+> Col
+>
+It works just fine, thanks.
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007327.html b/zarb-ml/mageia-dev/2011-August/007327.html new file mode 100644 index 000000000..5a748b62d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007327.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [132682] + + + + + + + + + +

[Mageia-dev] [132682]

+ D.Morgan + dmorganec at gmail.com +
+ Thu Aug 11 17:30:59 CEST 2011 +

+
+ +
On Thu, Aug 11, 2011 at 5:24 PM,  <root at mageia.org> wrote:
+> Revision 132682 Author ze Date 2011-08-11 17:24:06 +0200 (Thu, 11 Aug 2011)
+>
+> Log Message
+>
+> - version 0.9.26
+> - and libtool strikes again... (use autogen.sh)
+> - avoid using useless macros
+> - proper way to avoid static files
+> - list files for a correct uninstall
+> - arrange spec
+>
+> Modified Paths
+
+Have you asked mikala before updating this ?
+Does Soprano still build with it ? i remember having reverted
+previously because this broke soprano build.  ( this was requested by
+mikala )
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007328.html b/zarb-ml/mageia-dev/2011-August/007328.html new file mode 100644 index 000000000..ab0d4ab98 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007328.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [132682] + + + + + + + + + +

[Mageia-dev] [132682]

+ Balcaen John + mikala at mageia.org +
+ Thu Aug 11 18:01:11 CEST 2011 +

+
+ +
Le Jeudi 11 Août 2011 17:30:59 D.Morgan a écrit :
+> On Thu, Aug 11, 2011 at 5:24 PM,  <root at mageia.org> wrote:
+> > Revision 132682 Author ze Date 2011-08-11 17:24:06 +0200 (Thu, 11
+> > Aug 2011)
+> > 
+> > Log Message
+> > 
+> > - version 0.9.26
+> > - and libtool strikes again... (use autogen.sh)
+> > - avoid using useless macros
+> > - proper way to avoid static files
+> > - list files for a correct uninstall
+> > - arrange spec
+> > 
+> > Modified Paths
+> 
+> Have you asked mikala before updating this ?
+> Does Soprano still build with it ? i remember having reverted
+> previously because this broke soprano build.  ( this was requested by
+> mikala )
+Well i'm sure Ze did test this locally before of course, since he asked 
+me several question regarding iurt so i'm sure that he's testing now 
+locally at least the build in a iurt chroot so he won't push a package 
+on the BS that might failed (excepted  some rpmlints rejection of course 
+but that can happen to everyone) , but just in case i'm not sure that he 
+tested the rpm with nepomuk btw (there's several changes on soprano 
+regarding rasqal/raptor  but it's more for KDE SC/Framework 4.8 and 
+since we're not swichting to KDE 4.8 currently.
+
+
+PS: yeah ze  i'm sorta back online  ;o)
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007329.html b/zarb-ml/mageia-dev/2011-August/007329.html new file mode 100644 index 000000000..7bcdbb9ce --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007329.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [132694] build against iodbc + + + + + + + + + +

[Mageia-dev] [132694] build against iodbc

+ Balcaen John + mikala at mageia.org +
+ Thu Aug 11 20:01:09 CEST 2011 +

+
+ +
Le Jeudi 11 Août 2011 19:33:45 root at mageia.org a écrit :
+> Revision: 132694
+> Author:   fwang
+> Date:     2011-08-11 19:33:44 +0200 (Thu, 11 Aug 2011)
+> Log Message:
+> -----------
+> build against iodbc
+[...]
+Could you please provide a correct commit message & not only a part 
+which does not reflect the change you did on the spec ?
+here you did also add virtuoso-devel as a BR, remove another 
+buildrequires, changes  the %setup ,%build & %install part , changes 
+also the %files list...
+So from my point of view your commit message does not really show what 
+you did on the package...
+
+
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007330.html b/zarb-ml/mageia-dev/2011-August/007330.html new file mode 100644 index 000000000..dc310ac0f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007330.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Secret Maryo Chronicles + + + + + + + + + +

[Mageia-dev] Secret Maryo Chronicles

+ Samuel Verschelde + stormi at laposte.net +
+ Fri Aug 12 15:32:14 CEST 2011 +

+
+ +
Le lundi 1 août 2011 15:01:31, José Jorge a écrit :
+> hi,
+> 
+> I have started importing the game Secret Maryo Chronicles, which was
+> already in Mandriva: http://svnweb.mageia.org/packages/cauldron/smc/
+> 
+> As I am a padawan, I asked it's submit to stormi, which as a good mentor
+> carefully found that it is not in Fedora because they feel it can be sued
+> by Nintendo. Still, Debian has accepted it after some content was changed
+> :
+> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405441
+> As of 2010, we can see in their forum that they were still replacing some
+> graphics with less sue-able ones:
+> http://www.secretmaryo.org/phpBB3/viewtopic.php?p=18333#p18333
+> http://www.secretmaryo.org/phpBB3/viewtopic.php?f=1&t=3495
+> 
+> Now the question :  shall we import this game into Mageia?
+> 
+> Thanks for your attention.
+> 
+> Zézinho
+
+Given that debian ships it, that no one objected on this list, and that the 
+upstream really tries to differentiate the game from the Super Mario series, 
+I'll push it.
+
+Samuel
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007331.html b/zarb-ml/mageia-dev/2011-August/007331.html new file mode 100644 index 000000000..80895a58a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007331.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [RPM] cauldron core/release smokekde-4.7.0-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release smokekde-4.7.0-2.mga2

+ John Balcaen + mikala at mageia.org +
+ Sat Aug 13 11:28:09 CEST 2011 +

+
+ +
2011/8/13 Mageia Team <buildsystem-daemon at mageia.org>:
+> Name        : smokekde                     Relocations: (not relocatable)
+> Version     : 4.7.0                             Vendor: Mageia.Org
+> Release     : 2.mga2                        Build Date: Sat Aug 13 08:48:41 2011
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Graphical desktop/KDE         Source RPM: (none)
+> Size        : 52873                            License: GPL
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.kde.org
+> Summary     : KDE4 bindings for SMOKE
+> Description :
+> KDE4 bindings for SMOKE (Scripting Meta Object Kompiler Engine)
+>
+> fwang <fwang> 1:4.7.0-2.mga2:
+> + Revision: 132945
+> - disable kdepim support
+> - try enable kdepimlibs support
+Until the segfault of smokegen is fixed it's useless to enable/disable
+the kdepimlibs support in smokekde.
+(Please note that you can also test locally without commiting and
+pushing a package which will failed.)
+
+Regards
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007332.html b/zarb-ml/mageia-dev/2011-August/007332.html new file mode 100644 index 000000000..8c4558a14 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007332.html @@ -0,0 +1,169 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sat Aug 13 19:57:15 CEST 2011 +

+
+ +
On 13 August 2011 16:01, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> tv <tv> 1.4.4-1.mga2:
+> + Revision: 132986
+> - new release
+
+For the record, this should be pushed as a security update (CVE-2011-2895):
+
+(Which I cannot do myself:
+
+mgarepo submit  --define section=core/updates_testing -t 1
+Submitting libxfont at revision 132986
+URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/libxfont
+error: command failed: ssh pkgsubmit.mageia.org
+/usr/local/bin/submit_package -t 1 --define
+sid=b20025dc-e76d-4ed7-aab1-60365f8e8427 --define
+section=core/updates_testing -r 132986
+svn+ssh://svn.mageia.org/svn/packages/cauldron/libxfont
+error: svn://svn.mageia.org/svn/packages/cauldron/libxfont is not
+allowed for this target
+
+Are we forced to branch?
+
+---------- Forwarded message ----------
+From: Alan Coopersmith <alan.coopersmith at oracle.com>
+Date: 11 August 2011 01:06
+Subject: [ANNOUNCE] libXfont 1.4.4
+To: xorg-announce at lists.freedesktop.org
+Cc: xorg at lists.freedesktop.org
+
+
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+libXfont provides the core of the legacy X11 font system, handling the
+index files (fonts.dir, fonts.alias, fonts.scale), the various font file
+formats, and rasterizing them.   It is used by the X servers, the
+X Font Server (xfs), and some font utilities (bdftopcf for instance),
+but should not be used by normal X11 clients.  X11 clients access fonts
+via either the new API's in libXft, or the legacy API's in libX11.
+
+The major change in this release is a fix for:
+
+   LZW decompress: fix for CVE-2011-2895
+
+   Specially crafted LZW stream can crash an application using libXfont
+   that is used to open untrusted font files.  With X server, this may
+   allow privilege escalation when exploited
+
+More information about this security issue can be found in the advisory at:
+http://lists.freedesktop.org/archives/xorg-announce/2011-August/001721.html
+
+
+Alan Coopersmith (2):
+     Sun's copyrights belong to Oracle now
+     Fix memory leak in allocation failure path of BitmapOpenScalable()
+
+Gaetan Nadon (4):
+     config: HTML file generation: use the installed copy of xorg.css
+     config: remove AC_PROG_CC as it overrides AC_PROG_C_C99
+     config: comment, minor upgrade, quote and layout configure.ac
+     doc: use common makefile for developers documentation
+
+Matthieu Herrb (1):
+     libXfont 1.4.4
+
+Paulo Zanoni (1):
+     Use docbookx.dtd version 4.3 for all docs
+
+Thomas Hoger (1):
+     LZW decompress: fix for CVE-2011-2895
+
+git tag: libXfont-1.4.4
+
+http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.4.4.tar.bz2
+MD5:  f9942bc818d39094d7295b156a729393
+SHA1: 189dd7a3756cb80bcf41b779bf05ec3c366e3041
+SHA256: a2065f5f66882f7a9cb0eb674e16d284da48e449af443eda272e99832be8239a
+
+http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.4.4.tar.gz
+MD5:  21312cee1347deaca18453f70c272ab0
+SHA1: e5db2aaf6f35a28efdb0ef24e8839a5cd8f7d84d
+SHA256: c52a978748d12ba0bbf54e60542e8e2ae5b624821e02b78cd2dc30b2aa9bb804
+
+
+- --
+       -Alan Coopersmith-        alan.coopersmith at oracle.com
+        Oracle Solaris Platform Engineering: X Window System
+
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2.0.17 (SunOS)
+Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
+
+iEYEARECAAYFAk5DDw0ACgkQovueCB8tEw6HwQCaA46BZnpP5Uvt9qkmmdE/u5o6
+SsMAn1DK3Y8nIeu0fqL5WsgRL9oztlcs
+=BD1h
+-----END PGP SIGNATURE-----
+_______________________________________________
+xorg-announce mailing list
+xorg-announce at lists.freedesktop.org
+http://lists.freedesktop.org/mailman/listinfo/xorg-announce
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007333.html b/zarb-ml/mageia-dev/2011-August/007333.html new file mode 100644 index 000000000..93daef805 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007333.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Sat Aug 13 20:04:22 CEST 2011 +

+
+ +
Thierry Vignaud skrev 13.8.2011 20:57:
+> On 13 August 2011 16:01, Mageia Team<buildsystem-daemon at mageia.org>  wrote:
+>> tv<tv>  1.4.4-1.mga2:
+>> + Revision: 132986
+>> - new release
+>
+> For the record, this should be pushed as a security update (CVE-2011-2895):
+>
+> (Which I cannot do myself:
+>
+> mgarepo submit  --define section=core/updates_testing -t 1
+> Submitting libxfont at revision 132986
+> URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/libxfont
+> error: command failed: ssh pkgsubmit.mageia.org
+> /usr/local/bin/submit_package -t 1 --define
+> sid=b20025dc-e76d-4ed7-aab1-60365f8e8427 --define
+> section=core/updates_testing -r 132986
+> svn+ssh://svn.mageia.org/svn/packages/cauldron/libxfont
+> error: svn://svn.mageia.org/svn/packages/cauldron/libxfont is not
+> allowed for this target
+>
+> Are we forced to branch?
+>
+
+You must use the updates branch in svn:
+svn://svn.mageia.org/svn/packages/updates/1/libxfont
+
+and submit the update from there...
+
+--
+Thomas
+
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007334.html b/zarb-ml/mageia-dev/2011-August/007334.html new file mode 100644 index 000000000..3b3ed8d98 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007334.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sat Aug 13 20:23:18 CEST 2011 +

+
+ +
On 13 August 2011 20:04, Thomas Backlund <tmb at mageia.org> wrote:
+>> Are we forced to branch?
+>
+> You must use the updates branch in svn:
+> svn://svn.mageia.org/svn/packages/updates/1/libxfont
+>
+> and submit the update from there...
+
+So we're forced to branch indeed.
+In mdv, we could push rpmdrake & the like directly from cooker branch
+to previous releases.
+Not a big deal though.
+
+Though it may not be that easy to copy a new releases
+to an update branch with binrepos.
+Is there a tool in order to do so?
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007335.html b/zarb-ml/mageia-dev/2011-August/007335.html new file mode 100644 index 000000000..cc4038ec8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007335.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] You have a new message on Badoo! Check it out now... + + + + + + + + + +

[Mageia-dev] You have a new message on Badoo! Check it out now...

+ Badoo + noreply at badoo.com +
+ Sat Aug 13 21:43:25 CEST 2011 +

+
+ +
Kristoffer Grundström har skickat ett meddelande till dig...
+
+Innehållet och dess avsändare kommer endast att visas till dig och kan raderas närhelst du vill. Du kan även svara ögonblickligen genom vår message exchange system. För att se vad som har skrivits kan du helt enkelt klicka på följande länk:
+http://eu1.badoo.com/0162210640/in/.S.fo.7aVx0/?lang_id=70&m=21&mid=4e46d3d2000000000046000057a1258d
+Några fler personer som ihärdigt väntar:
+Xxxx. spiros (Roma, Italien)
+Addictnigth (Roma, Italien)
+Max (Roma, Italien)
+
+http://eu1.badoo.com/0162210640/in/.S.fo.7aVx0/?lang_id=70&m=21&mid=4e46d3d2000000000046000057a1258d
+
+Fungerar inte länken? Prova kopiera länken till adressfältet på din webbläsare.
+
+Dett e-mail är en del av vår leveransprocess av meddelandet som skickats från Kristoffer Grundström. Om du felaktigt tagit emot detta e-mail, vänligen ignorera detta.  Inom kort kommer meddelandet att rederas från vår databas.
+
+Ha det så kul!
+The Badoo Team
+
+
+
+Du har mottagit detta brev eftersom en Badoo-medlem skrivit ett meddelande till dig på Badoo. Detta är ett automatiserat utskick. Svar på detta brev bevakas ej och kommer därför inte heller att besvaras. Om du i fortsättningen inte vill ta emot fler meddelanden från Badoo, vänligen informera oss:
+http://eu1.badoo.com/impersonation.phtml?lang_id=70&mail_code=21&email=mageia-dev%40mageia.org&secret=&block_code=bfb71e&m=21&mid=4e46d3d2000000000046000057a1258d
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110813/b1d22453/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007336.html b/zarb-ml/mageia-dev/2011-August/007336.html new file mode 100644 index 000000000..5ca1a78d0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007336.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2

+ D.Morgan + dmorganec at gmail.com +
+ Sun Aug 14 01:09:25 CEST 2011 +

+
+ +
On Sat, Aug 13, 2011 at 8:23 PM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 13 August 2011 20:04, Thomas Backlund <tmb at mageia.org> wrote:
+>>> Are we forced to branch?
+>>
+>> You must use the updates branch in svn:
+>> svn://svn.mageia.org/svn/packages/updates/1/libxfont
+>>
+>> and submit the update from there...
+>
+> So we're forced to branch indeed.
+> In mdv, we could push rpmdrake & the like directly from cooker branch
+> to previous releases.
+> Not a big deal though.
+>
+> Though it may not be that easy to copy a new releases
+> to an update branch with binrepos.
+> Is there a tool in order to do so?
+>
+i don't think such tool exist, but i think this could be a good idea.
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007337.html b/zarb-ml/mageia-dev/2011-August/007337.html new file mode 100644 index 000000000..8d91c106f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007337.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Flash Player 11 Beta 2 available + + + + + + + + + +

[Mageia-dev] Flash Player 11 Beta 2 available

+ Michael Altizer + xiche at verizon.net +
+ Sun Aug 14 04:57:35 CEST 2011 +

+
+ +
The old link to the Beta 1 tarball no longer works, FYI.  Attached the 
+spec changes against flash-player-plugin11 for Beta 2 (tested here on 
+x86_64).
+-------------- next part --------------
+An embedded and charset-unspecified text was scrubbed...
+Name: flash-player-plugin11-beta2.diff
+URL: </pipermail/mageia-dev/attachments/20110813/12f0d04e/attachment-0001.ksh>
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007338.html b/zarb-ml/mageia-dev/2011-August/007338.html new file mode 100644 index 000000000..04b4e9cb5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007338.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [RPM] cauldron core/release smc-1.9-4.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release smc-1.9-4.mga2

+ Samuel Verschelde + stormi at laposte.net +
+ Sun Aug 14 11:16:15 CEST 2011 +

+
+ +
Le dimanche 14 août 2011 10:13:32, Mageia Team a écrit :
+> Name        : smc                          Relocations: (not relocatable)
+> Version     : 1.9                               Vendor: Mageia.Org
+> Release     : 4.mga2                        Build Date: Sun Aug 14 09:54:28
+> 2011 Install Date: (not installed)               Build Host: ecosse
+> Group       : Games/Arcade                  Source RPM: (none)
+> Size        : 86201122                         License: GPLv3+
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.secretmaryo.org/
+> Summary     : Secret Maryo Chronicles - a 2D platform game in classic style
+> Description :
+> Secret Maryo Chronicles is an open source two-dimensional platform
+> game with a style designed similar to classic sidescroller games. It
+> utilizes the platform independent library SDL and an OpenGL
+> accelerated graphics renderer developed in C++.
+> 
+> fwang <fwang> 1.9-4.mga2:
+> + Revision: 133049
+> - br gettext
+> - fix build with boost-mt
+> 
+>   + stormi <stormi>
+>     - clean spec
+> 
+>   + zezinho <zezinho>
+>     - imported package smc
+
+Fixing this BR was part of an apprentice task...
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007339.html b/zarb-ml/mageia-dev/2011-August/007339.html new file mode 100644 index 000000000..ad810c675 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007339.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Flash Player 11 Beta 2 available + + + + + + + + + +

[Mageia-dev] Flash Player 11 Beta 2 available

+ Florian Hubold + doktor5000 at arcor.de +
+ Sun Aug 14 12:04:45 CEST 2011 +

+
+ +
Am 14.08.2011 04:57, schrieb Michael Altizer:
+> The old link to the Beta 1 tarball no longer works, FYI.  Attached the spec 
+> changes against flash-player-plugin11 for Beta 2 (tested here on x86_64).
+You're late, already reported 3 days ago:
+https://bugs.mageia.org/show_bug.cgi?id=2411
+:)
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007340.html b/zarb-ml/mageia-dev/2011-August/007340.html new file mode 100644 index 000000000..711d86f87 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007340.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] can't migrate machines to MGA. + + + + + + + + + +

[Mageia-dev] can't migrate machines to MGA.

+ JPB + jpierre.benoit at free.fr +
+ Sun Aug 14 17:13:13 CEST 2011 +

+
+ +
since yesterday I have the following problem(may have existed before).
+-------------------------------------------------------------
+# LC_ALL=C urpmi.addmedia --distrib --mirrorlist 
+http://mirrors.mageia.org/api/mageia.1.i586.list                                     
+adding medium "Core Release2"                                           
+adding medium "Core Release Debug2" (ignored by default)                
+adding medium "Core Updates2"                                           
+adding medium "Core Updates Debug2" (ignored by default)                
+adding medium "Core Updates Testing2" (ignored by default)              
+adding medium "Core Updates Testing Debug2" (ignored by default)        
+adding medium "Core Backports2" (ignored by default)                    
+adding medium "Core Backports Debug2" (ignored by default)              
+adding medium "Core Backports Testing2" (ignored by default)            
+adding medium "Core Backports Testing Debug2" (ignored by default)      
+adding medium "Nonfree Release2"                                        
+adding medium "Nonfree Release Debug2" (ignored by default)             
+adding medium "Nonfree Updates2"                                        
+adding medium "Nonfree Updates Debug2" (ignored by default)             
+adding medium "Nonfree Updates Testing2" (ignored by default)
+adding medium "Nonfree Updates Testing Debug2" (ignored by default)
+adding medium "Nonfree Backports2" (ignored by default)
+adding medium "Nonfree Backports Debug2" (ignored by default)
+adding medium "Nonfree Backports Testing2" (ignored by default)
+adding medium "Nonfree Backports Testing Debug2" (ignored by default)
+adding medium "Tainted Release2" (ignored by default)
+adding medium "Tainted Release Debug2" (ignored by default)
+adding medium "Tainted Updates2" (ignored by default)
+adding medium "Tainted Updates Debug2" (ignored by default)
+adding medium "Tainted Updates Testing2" (ignored by default)
+adding medium "Tainted Updates Testing Debug2" (ignored by default)
+adding medium "Tainted Backports2" (ignored by default)
+adding medium "Tainted Backports Debug2" (ignored by default)
+adding medium "Tainted Backports Testing2" (ignored by default)
+adding medium "Tainted Backports Testing Debug2" (ignored by default)
+    http://mirrors.mageia.org/api/mageia.1.i586.list: 
+media/core/release/media_info/20110530-193512-synthesis.hdlist.cz
+retrieval of [https://distrib-
+coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586/media/core/release/media_info/synthesis.hdlist.cz] 
+failed (md5sum mismatch)
+problem reading synthesis file of medium "Core Release2"
+[root at localhost ~]# 
+--------------------------------------------------------------
+and noting is added to urpmi.cfg
+Is this known?
+Is it the right place to report?
+ps: I have tried populating urpmi.cfg with data from a already migrated 
+machine but still have problems
+
+JPB
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110814/1ccb9527/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007341.html b/zarb-ml/mageia-dev/2011-August/007341.html new file mode 100644 index 000000000..5a480a02e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007341.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Flash Player 11 Beta 2 available + + + + + + + + + +

[Mageia-dev] Flash Player 11 Beta 2 available

+ Michael Altizer + xiche at verizon.net +
+ Sun Aug 14 17:45:09 CEST 2011 +

+
+ +
On 08/14/2011 06:04 AM, Florian Hubold wrote:
+> Am 14.08.2011 04:57, schrieb Michael Altizer:
+>> The old link to the Beta 1 tarball no longer works, FYI.  Attached 
+>> the spec changes against flash-player-plugin11 for Beta 2 (tested 
+>> here on x86_64).
+> You're late, already reported 3 days ago:
+> https://bugs.mageia.org/show_bug.cgi?id=2411
+> :)
+>
+Ah, my mistake.  Not sure what happened to my subscription to the bugs 
+list. :)
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007342.html b/zarb-ml/mageia-dev/2011-August/007342.html new file mode 100644 index 000000000..e319ba5b1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007342.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Aug 15 10:53:42 CEST 2011 +

+
+ +
'Twas brillig, and D.Morgan at 14/08/11 00:09 did gyre and gimble:
+> On Sat, Aug 13, 2011 at 8:23 PM, Thierry Vignaud
+> <thierry.vignaud at gmail.com> wrote:
+>> On 13 August 2011 20:04, Thomas Backlund <tmb at mageia.org> wrote:
+>>>> Are we forced to branch?
+>>>
+>>> You must use the updates branch in svn:
+>>> svn://svn.mageia.org/svn/packages/updates/1/libxfont
+>>>
+>>> and submit the update from there...
+>>
+>> So we're forced to branch indeed.
+>> In mdv, we could push rpmdrake & the like directly from cooker branch
+>> to previous releases.
+>> Not a big deal though.
+>>
+>> Though it may not be that easy to copy a new releases
+>> to an update branch with binrepos.
+>> Is there a tool in order to do so?
+>>
+> i don't think such tool exist, but i think this could be a good idea.
+
+I wrote this script the other day... but it's a bit rubbish, still might
+save some manual commands.
+
+Of course an option in mgarepo would be nicer.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: copy-mga-svn.sh
+Type: application/x-sh
+Size: 1380 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110815/29c3ee82/attachment.sh>
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007343.html b/zarb-ml/mageia-dev/2011-August/007343.html new file mode 100644 index 000000000..4f6db69c5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007343.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnutls-3.0.0-1.mga2

+ Pascal Terjan + pterjan at gmail.com +
+ Mon Aug 15 12:59:44 CEST 2011 +

+
+ +
On Wed, Aug 3, 2011 at 22:35, D.Morgan <dmorganec at gmail.com> wrote:
+> On Wed, Aug 3, 2011 at 11:16 PM, Balcaen John <mikala at mageia.org> wrote:
+>> Le Mercredi 3 Août 2011 22:43:21 D.Morgan a écrit :
+>> [...]
+>>>
+>>> what ? the error here is about PA not to gnutls
+>> She's talking about the
+>> « WARNING: no socket to connect to  »
+>> warning i guess.
+>>
+>> Regards,
+>>
+>> --
+>> Balcaen John
+>>
+>
+> ah and this is gnutls errors ?
+>
+> Just for the infos after the last cauldron update aria seems to works
+> fine. ( except the « WARNING: no socket to connect to  » errors that i
+> don't understand for the moment.
+>
+> but it "works" ;)
+
+It seems this message comes from the gnome-keyring pkcs11 module
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007344.html b/zarb-ml/mageia-dev/2011-August/007344.html new file mode 100644 index 000000000..55b2aefde --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007344.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] nepomuk ldap error + + + + + + + + + +

[Mageia-dev] nepomuk ldap error

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Mon Aug 15 17:18:43 CEST 2011 +

+
+ +
[/usr/bin/nepomukservicestub] /usr/bin/nepomukindexer: symbol lookup error: 
+/usr/lib64/libldap-2.4.so.2: undefined symbol: ldap_int_tls_destroy
+
+
+maybe a rebuild?
+
+LD
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007345.html b/zarb-ml/mageia-dev/2011-August/007345.html new file mode 100644 index 000000000..9c48ec289 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007345.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] tomld - 1 click security on Linux using MAC + + + + + + + + + +

[Mageia-dev] tomld - 1 click security on Linux using MAC

+ Horvath Andras + han at log69.com +
+ Mon Aug 15 16:27:55 CEST 2011 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+Dear Developers,
+
+I've come to know about the fact on #ubuntu-hardened IRC today that
+you're using Tomoyo as your choice of MAC solution in Mageia (fix me).
+I thought You might be interested in my project.
+
+I've been developing an open source security related automatic MAC
+configuration solution using Tomoyo for over half a year now. I'm
+getting close to release my first stable version. This is a 1-click
+solution without any user interaction.
+
+Requirements:
+http://log69.com/help_en.html#15
+
+I still have no wider user base testing it and still find smaller bugs
+from time to time. Therefore I'm "spamming" some IRC channels and
+mailing lists to let people know about my project and so try to get my
+code stabilized as fast as possible.
+
+My site:
+http://log69.com/tomld_en.html
+
+Screenshots:
+http://log69.com/images/tomld.png
+http://log69.com/images/tomld2.png
+http://log69.com/images/tomld3.png
+
+Video about installation:
+http://www.youtube.com/watch?v=FC9-7AkiLSM
+http://log69.com/extras/tomld039_ubuntu1104_install.ogv
+
+I'm already using and testing it in smaller production environments.
+
+I appreciate any feedback or opinions on the topic.
+
+
+Best Regards,
+
+Andras Horvath
+(Hungary)
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.10 (GNU/Linux)
+
+iEYEARECAAYFAk5JLOsACgkQAx9+mHylNBhdlQCbBJfeV4JGlzXiflsZkXBz3x9J
+S08AnjjnHf5mu4Mu6hJl+3R2LDcC6psv
+=cgH6
+-----END PGP SIGNATURE-----
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007346.html b/zarb-ml/mageia-dev/2011-August/007346.html new file mode 100644 index 000000000..8cabb008c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007346.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] You are not in mga-packagers group + + + + + + + + + +

[Mageia-dev] You are not in mga-packagers group

+ Gerardo + gejobj at gmail.com +
+ Tue Aug 16 11:42:01 CEST 2011 +

+
+ +
+Hello.
+
+I am trying to comit a package from svn to pkgsubmit (mgarepo submit 
+packagename) and I get this error: 'You are not in mga-packagers group'
+
+Is there any admin that can help me? ;-)
+
+
+Thanks
+Bye.
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007347.html b/zarb-ml/mageia-dev/2011-August/007347.html new file mode 100644 index 000000000..589b897a0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007347.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] You are not in mga-packagers group + + + + + + + + + +

[Mageia-dev] You are not in mga-packagers group

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Aug 16 13:50:57 CEST 2011 +

+
+ +
On Tue, 16 Aug 2011, Gerardo wrote:
+
+> 
+> Hello.
+> 
+> I am trying to comit a package from svn to pkgsubmit (mgarepo submit 
+> packagename) and I get this error: 'You are not in mga-packagers group'
+
+To commit, or submit ?
+
+> 
+> Is there any admin that can help me? ;-)
+
+What is your login ?
+
+Apprentice cannot submit packages, they need to ask their mentor to do
+it after reviewing their changes.
+
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007348.html b/zarb-ml/mageia-dev/2011-August/007348.html new file mode 100644 index 000000000..4dbd9cc84 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007348.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] You are not in mga-packagers group + + + + + + + + + +

[Mageia-dev] You are not in mga-packagers group

+ Gerardo + gejobj at gmail.com +
+ Tue Aug 16 13:58:32 CEST 2011 +

+
+ +
On Martes, 16 de Agosto de 2011 13:50:57 nicolas vigier escribió:
+> On Tue, 16 Aug 2011, Gerardo wrote:
+> > Hello.
+> > 
+> > I am trying to comit a package from svn to pkgsubmit (mgarepo submit
+> > packagename) and I get this error: 'You are not in mga-packagers group'
+> 
+> To commit, or submit ?
+> 
+
+I can commit to svn but I can not submit to build system with 'mgarepo submit 
+package' command.
+
+> > Is there any admin that can help me? ;-)
+> 
+> What is your login ?
+> 
+
+My login is 'gejo'
+
+> Apprentice cannot submit packages, they need to ask their mentor to do
+> it after reviewing their changes.
+
+
+Regards.
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007349.html b/zarb-ml/mageia-dev/2011-August/007349.html new file mode 100644 index 000000000..7cc47a78c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007349.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] You are not in mga-packagers group + + + + + + + + + +

[Mageia-dev] You are not in mga-packagers group

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 16 15:15:54 CEST 2011 +

+
+ +
Le mardi 16 août 2011 à 13:58 +0200, Gerardo a écrit :
+> On Martes, 16 de Agosto de 2011 13:50:57 nicolas vigier escribió:
+> > On Tue, 16 Aug 2011, Gerardo wrote:
+> > > Hello.
+> > > 
+> > > I am trying to comit a package from svn to pkgsubmit (mgarepo submit
+> > > packagename) and I get this error: 'You are not in mga-packagers group'
+> > 
+> > To commit, or submit ?
+> > 
+> 
+> I can commit to svn but I can not submit to build system with 'mgarepo submit 
+> package' command.
+
+Yes, you have to ask to juan to review the change and submit for you.
+Once he is happy, he can ask to have you become packager.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007350.html b/zarb-ml/mageia-dev/2011-August/007350.html new file mode 100644 index 000000000..8f2ff3f7c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007350.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Anne nicolas + ennael at mageia.org +
+ Tue Aug 16 15:21:22 CEST 2011 +

+
+ +
Hi there
+
+Back online. We are planning our next meeting for 24th of august, 19h
+UTC on #mageia-dev. In between we will work on some burning subjects
+(backports incis meetiluded) so that we can take final decisions
+during this meeting.
+
+As usual and as it's a long time we did not have any meeting, you can
+propose some topics to be added. We will need a review on current
+mentoring (André ?) and secteam (Stew ?).
+
+Thanks for advance
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007351.html b/zarb-ml/mageia-dev/2011-August/007351.html new file mode 100644 index 000000000..8f085ed3b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007351.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Anne nicolas + ennael at mageia.org +
+ Tue Aug 16 15:26:23 CEST 2011 +

+
+ +
2011/8/16 Anne nicolas <ennael at mageia.org>:
+> Hi there
+>
+> Back online. We are planning our next meeting for 24th of august, 19h
+> UTC on #mageia-dev. In between we will work on some burning subjects
+> (backports incis meetiluded) so that we can take final decisions
+> during this meeting.
+
+hum "(backports included)". Need to go back to vacations...
+
+>
+> As usual and as it's a long time we did not have any meeting, you can
+> propose some topics to be added. We will need a review on current
+> mentoring (André ?) and secteam (Stew ?).
+>
+> Thanks for advance
+> Cheers
+>
+> --
+> Anne
+> http://www.mageia.org
+>
+
+
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007352.html b/zarb-ml/mageia-dev/2011-August/007352.html new file mode 100644 index 000000000..2870c04ec --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007352.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ philippe makowski + makowski.mageia at gmail.com +
+ Tue Aug 16 15:54:48 CEST 2011 +

+
+ +
2011/8/16 Anne nicolas <ennael at mageia.org>:
+>
+> Back online. We are planning our next meeting for 24th of august, 19h
+> UTC on #mageia-dev.
+
+sorry, I won't be there
+have a nice meeting
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007353.html b/zarb-ml/mageia-dev/2011-August/007353.html new file mode 100644 index 000000000..f857b93de --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007353.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Tue Aug 16 16:11:40 CEST 2011 +

+
+ +
On Tue, Aug 16, 2011 at 03:54:48PM +0200, philippe makowski wrote:
+> 2011/8/16 Anne nicolas <ennael at mageia.org>:
+> >
+> > Back online. We are planning our next meeting for 24th of august, 19h
+> > UTC on #mageia-dev.
+> 
+> sorry, I won't be there
+> have a nice meeting
+I will in the south during this week, but i'll try to be here with 3G! 
+-- 
+Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
+IRC: Kharec (irc.freenode.net)
+Software/Hardware geek 
+Conceptor
+Magnum's Coordinator/editor (http://magnum.tuxfamily.org)
+Mageia and Mandriva contributor
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110816/36af8f59/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007354.html b/zarb-ml/mageia-dev/2011-August/007354.html new file mode 100644 index 000000000..2cbb58716 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007354.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] You are not in mga-packagers group + + + + + + + + + +

[Mageia-dev] You are not in mga-packagers group

+ Gerardo + gejobj at gmail.com +
+ Tue Aug 16 17:09:54 CEST 2011 +

+
+ +
On Martes, 16 de Agosto de 2011 15:15:54 Michael Scherer escribió:
+> Le mardi 16 août 2011 à 13:58 +0200, Gerardo a écrit :
+> > On Martes, 16 de Agosto de 2011 13:50:57 nicolas vigier escribió:
+> > > On Tue, 16 Aug 2011, Gerardo wrote:
+> > > > Hello.
+> > > > 
+> > > > I am trying to comit a package from svn to pkgsubmit (mgarepo submit
+> > > > packagename) and I get this error: 'You are not in mga-packagers
+> > > > group'
+> > > 
+> > > To commit, or submit ?
+> > 
+> > I can commit to svn but I can not submit to build system with 'mgarepo
+> > submit package' command.
+> 
+> Yes, you have to ask to juan to review the change and submit for you.
+> Once he is happy, he can ask to have you become packager.
+
+Perfect.
+
+Juan is checking my svn commit and later he will send it to build system.
+
+Thanks ^_^
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007355.html b/zarb-ml/mageia-dev/2011-August/007355.html new file mode 100644 index 000000000..dae35ad81 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007355.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Stew Benedict + stewbintn at gmail.com +
+ Tue Aug 16 19:25:23 CEST 2011 +

+
+ +
On 08/16/2011 09:21 AM, Anne nicolas wrote:
+> Hi there
+>
+> Back online. We are planning our next meeting for 24th of august, 19h
+> UTC on #mageia-dev. In between we will work on some burning subjects
+> (backports incis meetiluded) so that we can take final decisions
+> during this meeting.
+>
+> As usual and as it's a long time we did not have any meeting, you can
+> propose some topics to be added. We will need a review on current
+> mentoring (André ?) and secteam (Stew ?).
+>
+> Thanks for advance
+> Cheers
+>
+I most likely will not be in attendance, as that day is my wife's birthday.
+
+As for secteam status, it's still a team of one. I have been lax in 
+making new bug reports while dozens of emails come in daily of other 
+distro updates and vulnerabilities. Bugs I did file several weeks ago 
+still sit in NEW state, not moving :(
+At this point, I'm not sure how much time I personally will be able to 
+commit in the upcoming months as real life has again served up some 
+challenges.
+
+-- 
+Stew Benedict
+
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007356.html b/zarb-ml/mageia-dev/2011-August/007356.html new file mode 100644 index 000000000..aa8abb6f8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007356.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] The triage team. + + + + + + + + + +

[Mageia-dev] The triage team.

+ Raphaël Jadot + ashledombos at hodo.fr +
+ Wed Aug 17 00:04:11 CEST 2011 +

+
+ +
2011/7/26 Marcello Anni <marcello.anni at alice.it>:
+>> Hello,
+>>
+>> Due to time constraints I have to leave the bug triage team. I'll
+>> still try to keep up with the bugs list when I have  the time but
+>> won't be able primarily work on it.
+>>
+>> Thanks.
+>>
+>> --
+>> Ahmad Samir
+>
+Hi ahmad, and thanks a lot for your GREAT work :)
+
+>
+>  thank you for your work, ahmad! btw, is there anyone who takes care about
+> this task? it is really important...
+>
+>
+> cheers,
+> Marcello
+>
+
+
+
+-- 
+RJ
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007357.html b/zarb-ml/mageia-dev/2011-August/007357.html new file mode 100644 index 000000000..9f0280114 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007357.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] [Fwd: [Mageia-discuss] Bugsquad team organisation] + + + + + + + + + +

[Mageia-dev] [Fwd: [Mageia-discuss] Bugsquad team organisation]

+ Manuel Hiebel + manuel+ml at hiebel.eu +
+ Wed Aug 17 00:13:21 CEST 2011 +

+
+ +
-------- Message transféré --------
+De: Remco Rijnders <remco at webconquest.com>
+Reply-to: Mageia general discussions <mageia-discuss at mageia.org>
+À: mageia-bugsquad at mageia.org
+Cc: Mageia general discussions <mageia-discuss at mageia.org>
+Sujet: [Mageia-discuss] Bugsquad team organisation
+Date: Tue, 16 Aug 2011 19:31:13 +0200
+
+Dear all,
+
+One of the more important but often overlooked tasks for projects like 
+Mageia is the handling of bug reports received and follow up given to 
+them. Quick resolution of reported problems and the proper routing of 
+these reports is important to help Mageia improve in quality and grow in 
+mindshare within the larger Linux community.
+
+Since Mageia started over 2400 bugs and other issues needing our attention 
+have been filed in our bugzilla ( http://bugs.mageia.org/ ). A very 
+impressive job has been done so far by the various members of the bugsquad 
+and the packagers and sysadmins who have had reports assigned to them. 
+Most impressive has been the bulk of work that Ahmad did by himself since 
+the bugsquad got started under his leadership. Due to time constraints he 
+unfortunately announced last month that he had to step down from this 
+position. Since that time the bugsquad team has been without a leader and 
+a representative for that team within the Mageia council.
+
+Through this email I hope to solicit some help for and interest in this 
+team (hence the Cc to the Mageia discuss list) as well as to discuss 
+within the team (on the bugsquad mailing list) where we want to go with it 
+and if anyone is willing to take over the lead for this team.
+
+Should you have any interest in the bugsquad team, please see the page on 
+our wiki for information on the triage team and how to join the mailing 
+list. The address for that is 
+http://www.mageia.org/wiki/doku.php?id=triage
+
+In order to keep the discussion in one place, I'd appreciate it if follow 
+ups to this message solely go to the bugsquad list.
+
+I'm interested in hearing your thoughts.
+
+Thank you for your time and attention, thank you Ahmad for all the hard 
+work done so far!
+
+Sincere regards,
+
+Remco
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007358.html b/zarb-ml/mageia-dev/2011-August/007358.html new file mode 100644 index 000000000..75fb62af2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007358.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Juan Luis Baptiste + juan.baptiste at gmail.com +
+ Wed Aug 17 16:34:34 CEST 2011 +

+
+ +
Hi,
+
+I'm trying to push one of my apprentice's packages to the BS, but is
+failing with this message I don't understand:
+
+[juancho at centella knutclient]$ mgarepo submit knutclient
+Fetching revision...
+URL: svn+ssh://svn.mageia.org/svn/packages/cauldron/knutclient
+Commit: 134182 | juancho | Fixed mkrel for initial submit.
+Implicit target: cauldron
+No handlers could be found for logger "mgarepo"
+error: command failed: ssh pkgsubmit.mageia.org
+/usr/local/bin/submit_package -t cauldron --define
+sid=81fe2bc7-9706-46d0-ab2b-1c6721a749d0 -r 134182
+svn+ssh://svn.mageia.org/svn/packages/cauldron/knutclient
+A    /var/lib/schedbot/repsys/tmp/tmpjpY8HL/SOURCES-bin
+error: Failed to upload svn://svn.mageia.org/svn/packages/cauldron/knutclient:
+Executing perl -I/usr/share/mga-youri-submit/lib
+/usr/share/mga-youri-submit/bin/youri-submit --config
+/etc/youri/submit-todo.conf --define user=juancho --define
+sid=81fe2bc7-9706-46d0-ab2b-1c6721a749d0 cauldron
+/var/lib/schedbot/repsys/srpms/@134182:knutclient-1.0.4-1.mga2.src.rpm
+(sudo_user juancho)
+Warning: Can't guess destination: section missing, defaulting to core/release
+Deprecated method, use as_string now at
+/usr/share/mga-youri-submit/lib/Youri/Submit/Check/ACL.pm line 32
+Deprecated method, use as_file() now at
+/usr/share/mga-youri-submit/lib/Youri/Submit/Check/Host.pm line 32
+Initializing repository
+Warning: Looking for any section with a package knutclient of any version
+Deprecated method, use as_string now at
+/usr/lib/perl5/site_perl/5.10.1/Youri/Repository/Mageia.pm line 457
+Submission errors, aborting:
+- knutclient-1.0.4-1.mga2.src:
+ - summary-ended-with-dot C KNutClient is a visual KDE4 client for UPS
+systems using NUT - Network UPS Tools.
+
+
+Can anyone give us a hand ?
+
+Thanks.
+
+-- 
+JLB
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007359.html b/zarb-ml/mageia-dev/2011-August/007359.html new file mode 100644 index 000000000..6c25d733a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007359.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Aug 17 16:39:44 CEST 2011 +

+
+ +
On Wed, 17 Aug 2011, Juan Luis Baptiste wrote:
+
+> Hi,
+> 
+> I'm trying to push one of my apprentice's packages to the BS, but is
+> failing with this message I don't understand:
+
+The summary ending with a dot ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007360.html b/zarb-ml/mageia-dev/2011-August/007360.html new file mode 100644 index 000000000..894d1d7ec --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007360.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Aug 17 16:44:24 CEST 2011 +

+
+ +
Am 17.08.2011 16:39, schrieb nicolas vigier:
+> On Wed, 17 Aug 2011, Juan Luis Baptiste wrote:
+>
+>> Hi,
+>>
+>> I'm trying to push one of my apprentice's packages to the BS, but is
+>> failing with this message I don't understand:
+> The summary ending with a dot ?
+>
+>
+Maybe you should check the SPEC with rpmlint -i,
+would have told ya before, and also what the fix is
+
+;)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007361.html b/zarb-ml/mageia-dev/2011-August/007361.html new file mode 100644 index 000000000..03c89ff46 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007361.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Juan Luis Baptiste + juan.baptiste at gmail.com +
+ Wed Aug 17 17:04:49 CEST 2011 +

+
+ +
On Wed, Aug 17, 2011 at 9:44 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+>>
+> Maybe you should check the SPEC with rpmlint -i,
+> would have told ya before, and also what the fix is
+>
+
+I did run rpmlint to the spec file and that error about the dot didn't
+came up (on Mandriva, don't have my Mageia install at hand).
+
+
+-- 
+JLB
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007362.html b/zarb-ml/mageia-dev/2011-August/007362.html new file mode 100644 index 000000000..f82745be1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007362.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Juan Luis Baptiste + juan.baptiste at gmail.com +
+ Wed Aug 17 17:02:39 CEST 2011 +

+
+ +
On Wed, Aug 17, 2011 at 9:39 AM, nicolas vigier <boklm at mars-attacks.org> wrote:
+>> I'm trying to push one of my apprentice's packages to the BS, but is
+>> failing with this message I don't understand:
+>
+> The summary ending with a dot ?
+>
+
+Thank you Nicolas, that was it :)
+
+
+-- 
+JLB
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007363.html b/zarb-ml/mageia-dev/2011-August/007363.html new file mode 100644 index 000000000..f6a636fdf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007363.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Juan Luis Baptiste + juan.baptiste at gmail.com +
+ Wed Aug 17 17:06:51 CEST 2011 +

+
+ +
On Wed, Aug 17, 2011 at 9:34 AM, Juan Luis Baptiste
+<juan.baptiste at gmail.com> wrote:
+>  - summary-ended-with-dot C KNutClient is a visual KDE4 client for UPS
+> systems using NUT - Network UPS Tools.
+>
+
+Ahh how blind I'm I, I didn't see this when I read the error !!
+
+Well I'll pay more attention next time ;)
+
+
+-- 
+JLB
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007364.html b/zarb-ml/mageia-dev/2011-August/007364.html new file mode 100644 index 000000000..8c2716abf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007364.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Aug 17 17:15:15 CEST 2011 +

+
+ +
Am 17.08.2011 17:04, schrieb Juan Luis Baptiste:
+> On Wed, Aug 17, 2011 at 9:44 AM, Florian Hubold<doktor5000 at arcor.de>  wrote:
+>> Maybe you should check the SPEC with rpmlint -i,
+>> would have told ya before, and also what the fix is
+>>
+> I did run rpmlint to the spec file and that error about the dot didn't
+> came up (on Mandriva, don't have my Mageia install at hand).
+>
+>
+This error was always reported by rpmlint. Maybe you just have no policy
+installed? Check for rpmlint-mandriva-policy on Mandriva and rpmlint-mageia-policy
+for Mageia. Sadly the policy is not even suggested when installing rpmlint :(
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007365.html b/zarb-ml/mageia-dev/2011-August/007365.html new file mode 100644 index 000000000..3dfd2741d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007365.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 17 18:27:18 CEST 2011 +

+
+ +
Le mercredi 17 août 2011 à 10:06 -0500, Juan Luis Baptiste a écrit :
+> On Wed, Aug 17, 2011 at 9:34 AM, Juan Luis Baptiste
+> <juan.baptiste at gmail.com> wrote:
+> >  - summary-ended-with-dot C KNutClient is a visual KDE4 client for UPS
+> > systems using NUT - Network UPS Tools.
+> >
+> 
+> Ahh how blind I'm I, I didn't see this when I read the error !!
+> 
+> Well I'll pay more attention next time ;)
+
+We could also start to fix the useless noise such as "deprecated foo"
+and "no handler foo". And also remove the warning about "defaulting to
+core/release".
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007366.html b/zarb-ml/mageia-dev/2011-August/007366.html new file mode 100644 index 000000000..c31d90ddf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007366.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Juan Luis Baptiste + juan.baptiste at gmail.com +
+ Wed Aug 17 19:23:15 CEST 2011 +

+
+ +
On Wed, Aug 17, 2011 at 10:15 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+>>
+> This error was always reported by rpmlint. Maybe you just have no policy
+> installed? Check for rpmlint-mandriva-policy on Mandriva and
+> rpmlint-mageia-policy
+> for Mageia. Sadly the policy is not even suggested when installing rpmlint
+> :(
+>
+
+I have it installed on Mandriva 2010.2 but still it didn't show that warning :(
+
+
+Cheers,
+-- 
+JLB
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007367.html b/zarb-ml/mageia-dev/2011-August/007367.html new file mode 100644 index 000000000..116e3d27d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007367.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Florian Hubold + doktor5000 at arcor.de +
+ Wed Aug 17 19:59:16 CEST 2011 +

+
+ +
Am 17.08.2011 19:23, schrieb Juan Luis Baptiste:
+> On Wed, Aug 17, 2011 at 10:15 AM, Florian Hubold<doktor5000 at arcor.de>  wrote:
+>> This error was always reported by rpmlint. Maybe you just have no policy
+>> installed? Check for rpmlint-mandriva-policy on Mandriva and
+>> rpmlint-mageia-policy
+>> for Mageia. Sadly the policy is not even suggested when installing rpmlint
+>> :(
+>>
+> I have it installed on Mandriva 2010.2 but still it didn't show that warning :(
+>
+>
+> Cheers,
+Unfortunately, you're right.
+But it definitely used to report that error, and because of that
+since back in the days i know those mistakes in-and-out. :)
+
+For Summary: you should pay attention to the following things:
+- 79 characters maximum
+- not ending with a dot
+- first character uppercased
+- first character no a space
+- should not include the programs name, so it looks nice in rpmdrake
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007368.html b/zarb-ml/mageia-dev/2011-August/007368.html new file mode 100644 index 000000000..b920f0094 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007368.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Juan Luis Baptiste + juan.baptiste at gmail.com +
+ Wed Aug 17 20:17:59 CEST 2011 +

+
+ +
On Wed, Aug 17, 2011 at 12:59 PM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Am 17.08.2011 19:23, schrieb Juan Luis Baptiste:
+>>
+> Unfortunately, you're right.
+> But it definitely used to report that error, and because of that
+> since back in the days i know those mistakes in-and-out. :)
+>
+> For Summary: you should pay attention to the following things:
+> - 79 characters maximum
+> - not ending with a dot
+> - first character uppercased
+> - first character no a space
+> - should not include the programs name, so it looks nice in rpmdrake
+>
+
+Thanks for the recommendations :)
+
+-- 
+JLB
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007369.html b/zarb-ml/mageia-dev/2011-August/007369.html new file mode 100644 index 000000000..31aabb11a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007369.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 17 21:19:59 CEST 2011 +

+
+ +
Le mercredi 17 août 2011 à 12:23 -0500, Juan Luis Baptiste a écrit :
+> On Wed, Aug 17, 2011 at 10:15 AM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> >>
+> > This error was always reported by rpmlint. Maybe you just have no policy
+> > installed? Check for rpmlint-mandriva-policy on Mandriva and
+> > rpmlint-mageia-policy
+> > for Mageia. Sadly the policy is not even suggested when installing rpmlint
+> > :(
+> >
+> 
+> I have it installed on Mandriva 2010.2 but still it didn't show that warning :(
+
+It work here :
+
+$ rpmlint facter-1.5.8-2.1mdv2010.2.src.rpm | grep summ 
+facter.src: W: summary-ended-with-dot C Ruby module for collecting
+simple facts about a host operating system.
+
+$ rpm -q rpmlint   
+rpmlint-0.95-1mdv2010.1
+
+And the warning is here since 2004 :
+https://qa.mandriva.com/show_bug.cgi?id=12520
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007370.html b/zarb-ml/mageia-dev/2011-August/007370.html new file mode 100644 index 000000000..826626266 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007370.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Juan Luis Baptiste + juan.baptiste at gmail.com +
+ Wed Aug 17 22:15:05 CEST 2011 +

+
+ +
On Wed, Aug 17, 2011 at 2:19 PM, Michael Scherer <misc at zarb.org> wrote:
+> It work here :
+>
+> $ rpmlint facter-1.5.8-2.1mdv2010.2.src.rpm | grep summ
+> facter.src: W: summary-ended-with-dot C Ruby module for collecting
+> simple facts about a host operating system.
+>
+> $ rpm -q rpmlint
+> rpmlint-0.95-1mdv2010.1
+>
+> And the warning is here since 2004 :
+> https://qa.mandriva.com/show_bug.cgi?id=12520
+>
+
+I did it against the spec file, not the src package, and in that case
+it didn't appear.
+
+-- 
+JLB
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007371.html b/zarb-ml/mageia-dev/2011-August/007371.html new file mode 100644 index 000000000..dd26e52bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007371.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Error submitting a package: Failed to upload to svn + + + + + + + + + +

[Mageia-dev] Error submitting a package: Failed to upload to svn

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 17 22:51:37 CEST 2011 +

+
+ +
Le mercredi 17 août 2011 à 15:15 -0500, Juan Luis Baptiste a écrit :
+> On Wed, Aug 17, 2011 at 2:19 PM, Michael Scherer <misc at zarb.org> wrote:
+> > It work here :
+> >
+> > $ rpmlint facter-1.5.8-2.1mdv2010.2.src.rpm | grep summ
+> > facter.src: W: summary-ended-with-dot C Ruby module for collecting
+> > simple facts about a host operating system.
+> >
+> > $ rpm -q rpmlint
+> > rpmlint-0.95-1mdv2010.1
+> >
+> > And the warning is here since 2004 :
+> > https://qa.mandriva.com/show_bug.cgi?id=12520
+> >
+> 
+> I did it against the spec file, not the src package, and in that case
+> it didn't appear.
+
+Yup, that's normal, the spec parser was added mainly to help people to
+integrate with eclipse. Unfortunately, we cannot realistically parse the
+spec like rpm ( even if I think a good enough result was achevied with
+newer perl binding ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007372.html b/zarb-ml/mageia-dev/2011-August/007372.html new file mode 100644 index 000000000..650ca2faf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007372.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Ecosse ( rpm builder ) is disabled for the moment + + + + + + + + + +

[Mageia-dev] Ecosse ( rpm builder ) is disabled for the moment

+ Michael Scherer + misc at zarb.org +
+ Thu Aug 18 01:49:46 CEST 2011 +

+
+ +
Hi,
+
+Thomas disabled ecosse, one of our 2 builder ( and the slower one IIRC
+), to test if the harddrive is having problem, following various issues
+we had. So expect some delay when building your rpms.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007373.html b/zarb-ml/mageia-dev/2011-August/007373.html new file mode 100644 index 000000000..1143b7209 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007373.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree + + + + + + + + + +

[Mageia-dev] [RPM] cauldron nonfree/release flash-player-plugin11-11.0.1.60-0.b1.071311.1.mga2.nonfree

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Thu Aug 18 03:56:32 CEST 2011 +

+
+ +
On 18.07.2011 20:28, Anssi Hannula wrote:
+> On 18.07.2011 17:14, Ahmad Samir wrote:
+>> On 18 July 2011 14:13, Balcaen John <mikala at mageia.org> wrote:
+>>> On Monday 18 July 2011 12:33:34 Colin Guthrie wrote:
+>>>> 'Twas brillig, and Ahmad Samir at 18/07/11 12:01 did gyre and gimble:
+>>>>>> Does it complain about this if one removes the kcm module?
+>>>>>
+>>>>> I tested a while ago, we'd have to remove both the kcm module .so and
+>>>>> .desktop files; I am OK with that, the GTK+ tool provides the same
+>>>>> exact functionalities and is desktop-agnostic (i.e. it won't pull any
+>>>>> extra deps AFAICS).
+>>>>
+>>>> I presume this is all just going into a flash-player-kde package rather
+>>>> than nuked completely?
+>>> Is it possible to create this package on the fly?
+>>> because last time we talked about that on the bug report (
+>>> https://bugs.mageia.org/show_bug.cgi?id=1275 ) it was not.
+>>>
+>>> --
+>>> Balcaen John
+>>>
+>>
+>> You're right, I forgot about that limitation.
+>>
+>> @Colin: so, no we can't :)
+> 
+> Actually, it is possible, with some added complexity (extraction of the
+> KDE files from the file downloaded by the main pkg in the -kde subpkg
+> %post script.
+> 
+> I'll look into it.
+
+Finally done, let's see how much it breaks.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007374.html b/zarb-ml/mageia-dev/2011-August/007374.html new file mode 100644 index 000000000..2cfa22c9e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007374.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree? + + + + + + + + + +

[Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree?

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Thu Aug 18 17:34:14 CEST 2011 +

+
+ +
On 05.06.2011 02:31, Anssi Hannula wrote:
+> Hi!
+> 
+> Currently our flash-player-plugin pkg is only built on 32-bit, as the
+> 64-bit adobe build is still horribly out of date.
+> 
+> However, this is problematic for 64-bit users, as installing the 32-bit
+> flash-player-plugin is cumbersome as nonfree32 media is not added on
+> 64-bit (and adding it would not be very nice, as the media list is
+> already way too cluttered).
+> 
+> One option would be to build a x86_64 package that actually contains the
+> 32-bit flash player (and note that in description), with a dependency on
+> nspluginwrapper. When a proper 64-bit build is released by adobe, it
+> would be replaced with the 64-bit player.
+> 
+> Do you think this should be done, or would it add too much confusion?
+
+Since there wasn't any big opposition to this, I'll be submitting it
+shortly. Feel free to complain now :)
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007375.html b/zarb-ml/mageia-dev/2011-August/007375.html new file mode 100644 index 000000000..bb3aa6a3d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007375.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree? + + + + + + + + + +

[Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree?

+ Kira + elegant.pegasus at gmail.com +
+ Thu Aug 18 17:39:02 CEST 2011 +

+
+ +
在 Thu, 18 Aug 2011 23:34:14 +0800, Anssi Hannula  
+<anssi.hannula at iki.fi>寫道:
+
+> On 05.06.2011 02:31, Anssi Hannula wrote:
+>> Hi!
+>>
+>> Currently our flash-player-plugin pkg is only built on 32-bit, as the
+>> 64-bit adobe build is still horribly out of date.
+>>
+>> However, this is problematic for 64-bit users, as installing the 32-bit
+>> flash-player-plugin is cumbersome as nonfree32 media is not added on
+>> 64-bit (and adding it would not be very nice, as the media list is
+>> already way too cluttered).
+>>
+>> One option would be to build a x86_64 package that actually contains the
+>> 32-bit flash player (and note that in description), with a dependency on
+>> nspluginwrapper. When a proper 64-bit build is released by adobe, it
+>> would be replaced with the 64-bit player.
+>>
+>> Do you think this should be done, or would it add too much confusion?
+>
+> Since there wasn't any big opposition to this, I'll be submitting it
+> shortly. Feel free to complain now :)
+>
+Isn't there a new 64-bit version os flash player?
+
+Do you mean to have 2 packages in which contains 2 kinds of flash-player,
+
+or just the one with 32 bit exists?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007376.html b/zarb-ml/mageia-dev/2011-August/007376.html new file mode 100644 index 000000000..3635d5d22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007376.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Possible failure in our update process + + + + + + + + + +

[Mageia-dev] Possible failure in our update process

+ John Balcaen + mikala at mageia.org +
+ Thu Aug 18 17:46:06 CEST 2011 +

+
+ +
Hello,
+
+I noticed a problem with our update process thanks to bug #2450 [1]
+Here we pushed a update to kipi-plugins package (due to a missing
+requires) but the update ends up in a totally broken installation for
+the end user which was not noticed by me (first in fault) & later by
+QA.
+
+Currently every package built for updates are done against
+core/release, core/updates and core/updates_testing, here when i
+pushed kipi-plugins update, KDE 4.6.5 was already available in
+core/updates_testing so as expected kipi-plugins get linked against
+KDE 4.6.5 & not against KDE 4.6.3 (available in core/release)
+Since most of actors of the QA are simply installing all packages from
+core/updates_testing  (like me) none of us noticed that it would break
+ without KDE 4.6.5 installed and when probably for first updates
+people are using a « fresh Mageia 1» , with several packages in
+updates_testing in the same moment we can't really expect them to
+removed or reinstall/restore a Mageia 1 for every package available in
+testing.
+
+A workaround (which could also ease work for QA people) would be to
+have some temporary repositories as suggested by bolkm on irc, it
+could be based on SRPM package name but for some project like KDE  it
+would need more hacks since RPMS needed to be builded in a specific
+order.
+
+The QA user will be able to simply add a new media (like
+urpmi.addmedia $mirror/core/updates_testing/packagetotest/ ) so it
+will be more easy to test a package & *only* this one.
+
+Another solution is to rebuild the package when moving in on
+core/updates_release but in that case the package tested by QA is of
+course not the same as the one available previously in testing.
+
+What do you think ?
+
+
+
+
+
+
+
+[1] https://bugs.mageia.org/show_bug.cgi?id=2450
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007377.html b/zarb-ml/mageia-dev/2011-August/007377.html new file mode 100644 index 000000000..f848068d4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007377.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] Possible failure in our update process + + + + + + + + + +

[Mageia-dev] Possible failure in our update process

+ Michael Scherer + misc at zarb.org +
+ Thu Aug 18 18:03:00 CEST 2011 +

+
+ +
Le jeudi 18 août 2011 à 12:46 -0300, John Balcaen a écrit :
+> Hello,
+> 
+> I noticed a problem with our update process thanks to bug #2450 [1]
+> Here we pushed a update to kipi-plugins package (due to a missing
+> requires) but the update ends up in a totally broken installation for
+> the end user which was not noticed by me (first in fault) & later by
+> QA.
+> 
+> Currently every package built for updates are done against
+> core/release, core/updates and core/updates_testing, here when i
+> pushed kipi-plugins update, KDE 4.6.5 was already available in
+> core/updates_testing so as expected kipi-plugins get linked against
+> KDE 4.6.5 & not against KDE 4.6.3 (available in core/release)
+> Since most of actors of the QA are simply installing all packages from
+> core/updates_testing  (like me) none of us noticed that it would break
+>  without KDE 4.6.5 installed and when probably for first updates
+> people are using a « fresh Mageia 1» , with several packages in
+> updates_testing in the same moment we can't really expect them to
+> removed or reinstall/restore a Mageia 1 for every package available in
+> testing.
+>
+> A workaround (which could also ease work for QA people) would be to
+> have some temporary repositories as suggested by bolkm on irc, it
+> could be based on SRPM package name but for some project like KDE  it
+> would need more hacks since RPMS needed to be builded in a specific
+> order.
+> 
+> The QA user will be able to simply add a new media (like
+> urpmi.addmedia $mirror/core/updates_testing/packagetotest/ ) so it
+> will be more easy to test a package & *only* this one.
+> 
+> Another solution is to rebuild the package when moving in on
+> core/updates_release but in that case the package tested by QA is of
+> course not the same as the one available previously in testing.
+> 
+> What do you think ?
+
+I fail to understand, if kde 4.6.5 was a bugfix only of kde 4.6.3, then
+what kind of change would break kipi ? 
+
+If there is a ABI break, then it should not go to updates.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007378.html b/zarb-ml/mageia-dev/2011-August/007378.html new file mode 100644 index 000000000..f9108264f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007378.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Aug 18 19:22:29 CEST 2011 +

+
+ +
Hello,
+
+A new version of mgarepo is being uploaded on mirrors. As repository for
+storing binary files has been changed on server, this new version is now
+required to continue updating packages.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007379.html b/zarb-ml/mageia-dev/2011-August/007379.html new file mode 100644 index 000000000..aaa248fc9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007379.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree? + + + + + + + + + +

[Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree?

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Thu Aug 18 19:24:40 CEST 2011 +

+
+ +
On 18.08.2011 18:39, Kira wrote:
+> 在 Thu, 18 Aug 2011 23:34:14 +0800, Anssi Hannula <anssi.hannula at iki.fi>
+> 寫道:
+> 
+>> On 05.06.2011 02:31, Anssi Hannula wrote:
+>>> Hi!
+>>>
+>>> Currently our flash-player-plugin pkg is only built on 32-bit, as the
+>>> 64-bit adobe build is still horribly out of date.
+>>>
+>>> However, this is problematic for 64-bit users, as installing the 32-bit
+>>> flash-player-plugin is cumbersome as nonfree32 media is not added on
+>>> 64-bit (and adding it would not be very nice, as the media list is
+>>> already way too cluttered).
+>>>
+>>> One option would be to build a x86_64 package that actually contains the
+>>> 32-bit flash player (and note that in description), with a dependency on
+>>> nspluginwrapper. When a proper 64-bit build is released by adobe, it
+>>> would be replaced with the 64-bit player.
+>>>
+>>> Do you think this should be done, or would it add too much confusion?
+>>
+>> Since there wasn't any big opposition to this, I'll be submitting it
+>> shortly. Feel free to complain now :)
+>>
+> Isn't there a new 64-bit version os flash player?
+
+Not a stable one.
+
+> Do you mean to have 2 packages in which contains 2 kinds of flash-player,
+> 
+> or just the one with 32 bit exists?
+
+The x86_64 flash-player-plugin package contains stable 32-bit Flash Player.
+
+The x86_64 flash-player-plugin11 package contains the 64-bit Flash
+Player 64-bit Beta.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007380.html b/zarb-ml/mageia-dev/2011-August/007380.html new file mode 100644 index 000000000..ae9267337 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007380.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree? + + + + + + + + + +

[Mageia-dev] Providing 32-bit flash-player-plugin in x86_64 nonfree?

+ Kira + elegant.pegasus at gmail.com +
+ Thu Aug 18 19:28:00 CEST 2011 +

+
+ +
在 Fri, 19 Aug 2011 01:24:40 +0800, Anssi Hannula  
+<anssi.hannula at iki.fi>寫道:
+
+> On 18.08.2011 18:39, Kira
+>> Do you mean to have 2 packages in which contains 2 kinds of  
+>> flash-player,
+>>
+>> or just the one with 32 bit exists?
+>
+> The x86_64 flash-player-plugin package contains stable 32-bit Flash  
+> Player.
+>
+> The x86_64 flash-player-plugin11 package contains the 64-bit Flash
+> Player 64-bit Beta.
+>
+Thanks for clarification.
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007381.html b/zarb-ml/mageia-dev/2011-August/007381.html new file mode 100644 index 000000000..b691c02c1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007381.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Possible failure in our update process + + + + + + + + + +

[Mageia-dev] Possible failure in our update process

+ Balcaen John + mikala at mageia.org +
+ Thu Aug 18 19:28:35 CEST 2011 +

+
+ +
Le Jeudi 18 Août 2011 18:03:00 Michael Scherer a écrit :
+[..]
+> 
+> I fail to understand, if kde 4.6.5 was a bugfix only of kde 4.6.3,
+> then what kind of change would break kipi ?
+> 
+> If there is a ABI break, then it should not go to updates.
+It's not an ABI break strictly, but more that since kipiplugins was 
+built against KDE 4.6.5 is checking for KDE version >= 4.6.5 .
+kipi-plugins from core/release is going to work with KDE SC 4.6.5
+ 
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007382.html b/zarb-ml/mageia-dev/2011-August/007382.html new file mode 100644 index 000000000..61e089cbe --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007382.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Aug 18 20:37:48 CEST 2011 +

+
+ +
On Thu, 18 Aug 2011, nicolas vigier wrote:
+
+> Hello,
+> 
+> A new version of mgarepo is being uploaded on mirrors. As repository for
+> storing binary files has been changed on server, this new version is now
+> required to continue updating packages.
+
+There is also some small changes :
+ - mgarepo upload will upload the file (only if not already done), and
+   update the file sha1.lst. But will not commit automatically the updated
+   sha1.lst file.
+ - mgarepo del will remove the file from sha1.lst but will not commit
+   it. You can also edit sha1.lst yourself without using mgarepo del.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007383.html b/zarb-ml/mageia-dev/2011-August/007383.html new file mode 100644 index 000000000..a8db48ace --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007383.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Aug 18 20:49:14 CEST 2011 +

+
+ +
On Mon, 15 Aug 2011, Colin Guthrie wrote:
+
+> 'Twas brillig, and D.Morgan at 14/08/11 00:09 did gyre and gimble:
+> > On Sat, Aug 13, 2011 at 8:23 PM, Thierry Vignaud
+> > <thierry.vignaud at gmail.com> wrote:
+> >> On 13 August 2011 20:04, Thomas Backlund <tmb at mageia.org> wrote:
+> >>>> Are we forced to branch?
+> >>>
+> >>> You must use the updates branch in svn:
+> >>> svn://svn.mageia.org/svn/packages/updates/1/libxfont
+> >>>
+> >>> and submit the update from there...
+> >>
+> >> So we're forced to branch indeed.
+> >> In mdv, we could push rpmdrake & the like directly from cooker branch
+> >> to previous releases.
+> >> Not a big deal though.
+> >>
+> >> Though it may not be that easy to copy a new releases
+> >> to an update branch with binrepos.
+> >> Is there a tool in order to do so?
+> >>
+> > i don't think such tool exist, but i think this could be a good idea.
+> 
+> I wrote this script the other day... but it's a bit rubbish, still might
+> save some manual commands.
+> 
+> Of course an option in mgarepo would be nicer.
+
+Copy of binrepos is not needed anymore. So a simple copy of files from
+svn/packages/cauldron/[package] to svn/packages/updates/1/[package]
+should be enough now.
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007384.html b/zarb-ml/mageia-dev/2011-August/007384.html new file mode 100644 index 000000000..c6f2c8762 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007384.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Aug 18 21:08:46 CEST 2011 +

+
+ +
Op donderdag 18 augustus 2011 20:37:48 schreef nicolas vigier:
+> On Thu, 18 Aug 2011, nicolas vigier wrote:
+> > Hello,
+> > 
+> > A new version of mgarepo is being uploaded on mirrors. As repository for
+> > storing binary files has been changed on server, this new version is now
+> > required to continue updating packages.
+> 
+> There is also some small changes :
+>  - mgarepo upload will upload the file (only if not already done), and
+>    update the file sha1.lst. But will not commit automatically the updated
+>    sha1.lst file.
+>  - mgarepo del will remove the file from sha1.lst but will not commit
+>    it. You can also edit sha1.lst yourself without using mgarepo del.
+
+Can i get a mandriva build? and is mgarepo also backported for mageia1?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007385.html b/zarb-ml/mageia-dev/2011-August/007385.html new file mode 100644 index 000000000..becbe682a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007385.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ andre999 + andr55 at laposte.net +
+ Thu Aug 18 21:54:24 CEST 2011 +

+
+ +
Anne nicolas a écrit :
+> 2011/8/16 Anne nicolas<ennael at mageia.org>:
+>> Hi there
+>>
+>> Back online. We are planning our next meeting for 24th of august, 19h
+>> UTC on #mageia-dev. In between we will work on some burning subjects
+>> (backports incis meetiluded) so that we can take final decisions
+>> during this meeting.
+>
+> hum "(backports included)". Need to go back to vacations...
+[je pensais que j'ai perdu mon latin ;)  Nous sommes tous là ... ]
+
+>>
+>> As usual and as it's a long time we did not have any meeting, you can
+>> propose some topics to be added. We will need a review on current
+>> mentoring (André ?) and secteam (Stew ?).
+
+I intend to be there :)
+BTW, I added a section on conversion at the end of the web:wiki page.
+(After modifying the packager-mentoring page tables to accommode conversion.)
+Let me know if I should put it on a separate page (or ?).
+
+I'm also interested in helping with the documentation.
+It might be a good idea to discuss : our packager pages in the new wiki.
+
+>> Thanks for advance
+>> Cheers
+>>
+>> --
+>> Anne
+>> http://www.mageia.org
+>>
+
+Regards :)
+-- 
+André
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007386.html b/zarb-ml/mageia-dev/2011-August/007386.html new file mode 100644 index 000000000..80980d0b9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007386.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Thomas Lottmann + skipercooker at gmail.com +
+ Fri Aug 19 12:10:13 CEST 2011 +

+
+ +
Le 16/08/2011 15:21, Anne nicolas a écrit :
+> Hi there
+>
+> Back online. We are planning our next meeting for 24th of august, 19h
+> UTC on #mageia-dev. In between we will work on some burning subjects
+> (backports incis meetiluded) so that we can take final decisions
+> during this meeting.
+>
+> As usual and as it's a long time we did not have any meeting, you can
+> propose some topics to be added. We will need a review on current
+> mentoring (André ?) and secteam (Stew ?).
+>
+> Thanks for advance
+> Cheers
+>
+I will be there as well. :-)
+
+I'm looking forward to start the documentation project.
+
+Thomas.
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007387.html b/zarb-ml/mageia-dev/2011-August/007387.html new file mode 100644 index 000000000..1220aa2e3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007387.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 19 13:54:45 CEST 2011 +

+
+ +
On Thu, 18 Aug 2011, Maarten Vanraes wrote:
+
+> Op donderdag 18 augustus 2011 20:37:48 schreef nicolas vigier:
+> > On Thu, 18 Aug 2011, nicolas vigier wrote:
+> > > Hello,
+> > > 
+> > > A new version of mgarepo is being uploaded on mirrors. As repository for
+> > > storing binary files has been changed on server, this new version is now
+> > > required to continue updating packages.
+> > 
+> > There is also some small changes :
+> >  - mgarepo upload will upload the file (only if not already done), and
+> >    update the file sha1.lst. But will not commit automatically the updated
+> >    sha1.lst file.
+> >  - mgarepo del will remove the file from sha1.lst but will not commit
+> >    it. You can also edit sha1.lst yourself without using mgarepo del.
+> 
+> Can i get a mandriva build? and is mgarepo also backported for mageia1?
+
+misc updated the package on cooker, and it is in mageia 1 updates_testing :
+https://bugs.mageia.org/show_bug.cgi?id=2458
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007388.html b/zarb-ml/mageia-dev/2011-August/007388.html new file mode 100644 index 000000000..bf981fa9c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007388.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] KDE & Qt Roadmap for mageia + + + + + + + + + +

[Mageia-dev] KDE & Qt Roadmap for mageia

+ Balcaen John + mikala at mageia.org +
+ Fri Aug 19 13:56:29 CEST 2011 +

+
+ +
Hello,
+
+For next Mageia 2, we're currently aiming to release KDE SC 4.7.x  & 
+eventually  KDE SC/Framework 4.8(depending of KDE Roadmap which is still 
+not available for KDE SC 4.8 cf 
+http://techbase.kde.org/Schedules/KDE4/4.8_Feature_Plan
+ ).
+Due to missing roadmap we're not going to push KDE SC 4.8 until RC1 but 
+also we won't push any beta of Qt 4.8 sticking with Qt 4.7.x
+
+Ze is working on qtwebkit 2.2.x currently and will probably push it soon  
+as standalone package (qtwebkit will not be disable in Qt 4.7 of 
+course).
+
+We're also working on the wiki to create some kde related pages.
+
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007389.html b/zarb-ml/mageia-dev/2011-August/007389.html new file mode 100644 index 000000000..09eb71752 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007389.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] KDE & Qt Roadmap for mageia + + + + + + + + + +

[Mageia-dev] KDE & Qt Roadmap for mageia

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Aug 19 14:23:07 CEST 2011 +

+
+ +
Am 19.08.2011 13:56, schrieb Balcaen John:
+> Hello,
+>
+> For next Mageia 2, we're currently aiming to release KDE SC 4.7.x&
+> eventually  KDE SC/Framework 4.8(depending of KDE Roadmap which is still
+> not available for KDE SC 4.8 cf
+> http://techbase.kde.org/Schedules/KDE4/4.8_Feature_Plan
+>   ).
+> Due to missing roadmap we're not going to push KDE SC 4.8 until RC1 but
+> also we won't push any beta of Qt 4.8 sticking with Qt 4.7.x
+>
+> Ze is working on qtwebkit 2.2.x currently and will probably push it soon
+> as standalone package (qtwebkit will not be disable in Qt 4.7 of
+> course).
+>
+> We're also working on the wiki to create some kde related pages.
+>
+>
+> Regards,
+>
+Nice to see some packaging roadmap!
+Would be nice if you post the links to those wiki pages so other KDE users 
+could help you ;)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007390.html b/zarb-ml/mageia-dev/2011-August/007390.html new file mode 100644 index 000000000..b779c0474 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007390.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] KDE & Qt Roadmap for mageia + + + + + + + + + +

[Mageia-dev] KDE & Qt Roadmap for mageia

+ John Balcaen + mikala at mageia.org +
+ Fri Aug 19 15:05:37 CEST 2011 +

+
+ +
2011/8/19 Florian Hubold <doktor5000 at arcor.de>:
+[...]
+>>
+>> We're also working on the wiki to create some kde related pages.
+>>
+>>
+>> Regards,
+>>
+> Nice to see some packaging roadmap!
+> Would be nice if you post the links to those wiki pages so other KDE users
+> could help you ;)
+>
+Currently we have at least thoses pages on the wiki :
+
+http://www.mageia.org/wiki/doku.php?id=kde4_todo
+http://www.mageia.org/wiki/doku.php?id=kde4_packaging_policy
+http://www.mageia.org/wiki/doku.php?id=kde4_build
+
+in fact (you can surely help of course) we need to create a general
+page ( kde4 probably) with general informations about kde & linking to
+others pages
+
+the kde4_todo could probably merged in the « Goal » section of the
+packaging_policy page
+
+the kde4_build was partially wrote by me to have somewhere the build
+order for  kde  (some people might want for example build kde SC 4.7
+for mageia 1 or mandriva 2010.2 & can use it for that).
+It should have important dependencies for , links to spec, upstream
+www, explanation & reason of use for a patch etc etc
+We could probably use links here to sophie or mageia app db to get the
+files list (instead of writing them) etc etc
+
+So as you can see there's a lot of works to do ;o)
+
+
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007391.html b/zarb-ml/mageia-dev/2011-August/007391.html new file mode 100644 index 000000000..b4f7f1e1f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007391.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Shlomi Fish + shlomif at shlomifish.org +
+ Fri Aug 19 19:48:50 CEST 2011 +

+
+ +
Hi,
+
+On Tue, 16 Aug 2011 15:21:22 +0200
+Anne nicolas <ennael at mageia.org> wrote:
+
+> Hi there
+> 
+> Back online. We are planning our next meeting for 24th of august, 19h
+> UTC on #mageia-dev. In between we will work on some burning subjects
+> (backports incis meetiluded) so that we can take final decisions
+> during this meeting.
+> 
+> As usual and as it's a long time we did not have any meeting, you can
+> propose some topics to be added. We will need a review on current
+> mentoring (André ?) and secteam (Stew ?).
+> 
+
+Well, one thing that had bitten me twice is that with my ATI Radeon HD cards,
+the Mageia installations from the dual CD were unusable on two computers
+I tried due to the lack of the "radeon-firmware" package. After I installed
+that package, and  rebuilt the initrds, then the problems were solved. Still,
+it didn't look good at all.
+
+Is this fact peculiar to the dual CD, and is better in the DVDs or do we not
+use radeon-firmeware by default globally? I'd like this discussed in the next
+meeting.
+
+Regards,
+
+	Shlomi Fish
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+"Star Trek: We, the Living Dead" - http://shlom.in/st-wtld
+
+Microsoft — making it all make sense. Ours.
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007392.html b/zarb-ml/mageia-dev/2011-August/007392.html new file mode 100644 index 000000000..190e67119 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007392.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Aug 19 20:27:33 CEST 2011 +

+
+ +
Am 19.08.2011 19:48, schrieb Shlomi Fish:
+> Hi,
+>
+> On Tue, 16 Aug 2011 15:21:22 +0200
+> Anne nicolas<ennael at mageia.org>  wrote:
+>
+>> Hi there
+>>
+>> Back online. We are planning our next meeting for 24th of august, 19h
+>> UTC on #mageia-dev. In between we will work on some burning subjects
+>> (backports incis meetiluded) so that we can take final decisions
+>> during this meeting.
+>>
+>> As usual and as it's a long time we did not have any meeting, you can
+>> propose some topics to be added. We will need a review on current
+>> mentoring (André ?) and secteam (Stew ?).
+>>
+> Well, one thing that had bitten me twice is that with my ATI Radeon HD cards,
+> the Mageia installations from the dual CD were unusable on two computers
+> I tried due to the lack of the "radeon-firmware" package. After I installed
+> that package, and  rebuilt the initrds, then the problems were solved. Still,
+> it didn't look good at all.
+>
+> Is this fact peculiar to the dual CD, and is better in the DVDs or do we not
+> use radeon-firmeware by default globally? I'd like this discussed in the next
+> meeting.
+>
+> Regards,
+>
+> 	Shlomi Fish
+>
+I'd like to add another thing to the meeting topics:
+The discussion about non-free / tainted, which lasted really long,
+but AFAICS there is no concensus or decision, and the discussion
+has effectively reached a standstill. My tries to get this going again have not 
+succeeded so far.
+
+For reference, have a look at those:
+https://www.mageia.org/pipermail/mageia-dev/2011-July/006382.html
+https://www.mageia.org/pipermail/mageia-dev/2011-July/007001.html
+
+
+For some people the situation seems really clear, also to me,
+this viewpoint is what tmb expressed in his mail:
+https://www.mageia.org/pipermail/mageia-dev/2011-July/006560.html
+
+
+But in the end we need a definitive decision.
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007393.html b/zarb-ml/mageia-dev/2011-August/007393.html new file mode 100644 index 000000000..90e6dd593 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007393.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Sander Lepik + sander.lepik at eesti.ee +
+ Fri Aug 19 20:42:09 CEST 2011 +

+
+ +
16.08.2011 16:21, Anne nicolas kirjutas:
+> Hi there
+>
+> Back online. We are planning our next meeting for 24th of august, 19h
+> UTC on #mageia-dev. In between we will work on some burning subjects
+> (backports incis meetiluded) so that we can take final decisions
+> during this meeting.
+>
+> As usual and as it's a long time we did not have any meeting, you can
+> propose some topics to be added. We will need a review on current
+> mentoring (André ?) and secteam (Stew ?).
+>
+> Thanks for advance
+> Cheers
+>
+Another topic proposal:
+http://check.mageia.org/dependencies.html
+This is getting slightly out of hand.
+
+First there is some fixing to do (for example: "horde-prefs found in incorrect media
+core.x86_64 (allowed core.i586)" - a lot of such errors, who's gonna fix them?)
+Secondly there was proposal not to allow in those packages that have unmet requires (for
+example awn-amarok-minsec which needs avant-window-navigator). If the package can't be used
+there is no reason to submit it or allow it in the repos.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007394.html b/zarb-ml/mageia-dev/2011-August/007394.html new file mode 100644 index 000000000..75b7d4cf0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007394.html @@ -0,0 +1,75 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 19 20:57:01 CEST 2011 +

+
+ +
Op vrijdag 19 augustus 2011 20:27:33 schreef Florian Hubold:
+> Am 19.08.2011 19:48, schrieb Shlomi Fish:
+[...]
+> But in the end we need a definitive decision.
+
+i think for some of the topics we do need a definitive decision, so +1
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007395.html b/zarb-ml/mageia-dev/2011-August/007395.html new file mode 100644 index 000000000..d3e20d6d7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007395.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Samuel Verschelde + stormi at laposte.net +
+ Fri Aug 19 23:50:26 CEST 2011 +

+
+ +
Le jeudi 18 août 2011 19:22:29, nicolas vigier a écrit :
+> Hello,
+> 
+> A new version of mgarepo is being uploaded on mirrors. As repository for
+> storing binary files has been changed on server, this new version is now
+> required to continue updating packages.
+
+Can you give us more explanations about the server-side changes, and the 
+impacts it can have, especially when using svn directly in existing local 
+checkouts ? And if the changes are big enough so that the local checkouts are 
+not usable anymore (probably the case if the repository changed), state it and 
+tell us what to do with them (erase them and checkout again with the latest 
+version of mgarepo ?)
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110819/1819c4f3/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007396.html b/zarb-ml/mageia-dev/2011-August/007396.html new file mode 100644 index 000000000..2fed91abf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007396.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 19 23:54:26 CEST 2011 +

+
+ +
On Thu, 18 Aug 2011, nicolas vigier wrote:
+
+> On Thu, 18 Aug 2011, nicolas vigier wrote:
+> 
+> > Hello,
+> > 
+> > A new version of mgarepo is being uploaded on mirrors. As repository for
+> > storing binary files has been changed on server, this new version is now
+> > required to continue updating packages.
+> 
+> There is also some small changes :
+>  - mgarepo upload will upload the file (only if not already done), and
+>    update the file sha1.lst. But will not commit automatically the updated
+>    sha1.lst file.
+>  - mgarepo del will remove the file from sha1.lst but will not commit
+>    it. You can also edit sha1.lst yourself without using mgarepo del.
+
+An other change is that you may need to edit your ssh config to use
+your mageia username on binrepo.mageia.org.
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007397.html b/zarb-ml/mageia-dev/2011-August/007397.html new file mode 100644 index 000000000..dedc529df --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007397.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Thomas Backlund + tmb at mageia.org +
+ Sat Aug 20 00:02:22 CEST 2011 +

+
+ +
Samuel Verschelde skrev 20.8.2011 00:50:
+> Le jeudi 18 août 2011 19:22:29, nicolas vigier a écrit :
+>
+>  > Hello,
+>
+>  >
+>
+>  > A new version of mgarepo is being uploaded on mirrors. As repository for
+>
+>  > storing binary files has been changed on server, this new version is now
+>
+>  > required to continue updating packages.
+>
+>
+> Can you give us more explanations about the server-side changes, and the
+> impacts it can have, especially when using svn directly in existing
+> local checkouts ? And if the changes are big enough so that the local
+> checkouts are not usable anymore (probably the case if the repository
+> changed), state it and tell us what to do with them (erase them and
+> checkout again with the latest version of mgarepo ?)
+
+No need to redo the checkout...
+
+just move the binaries from SOURCES-bin to SOURCES (replacing the 
+symlinks) and remove the SOURCES-bin dir and keep on working
+
+--
+Thomas
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007398.html b/zarb-ml/mageia-dev/2011-August/007398.html new file mode 100644 index 000000000..6ac6e37cf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007398.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ andre999 + andr55 at laposte.net +
+ Sat Aug 20 07:02:36 CEST 2011 +

+
+ +
Florian Hubold a écrit :
+> Am 19.08.2011 19:48, schrieb Shlomi Fish:
+>> Hi,
+>>
+>> On Tue, 16 Aug 2011 15:21:22 +0200
+>> Anne nicolas<ennael at mageia.org>  wrote:
+>>
+>>> Hi there
+>>>
+>>> Back online. We are planning our next meeting for 24th of august, 19h
+>>> UTC on #mageia-dev. In between we will work on some burning subjects
+>>> (backports incis meetiluded) so that we can take final decisions
+>>> during this meeting.
+>>>
+>>> As usual and as it's a long time we did not have any meeting, you can
+>>> propose some topics to be added. We will need a review on current
+>>> mentoring (André ?) and secteam (Stew ?).
+>>>
+>> Well, one thing that had bitten me twice is that with my ATI Radeon 
+>> HD cards,
+>> the Mageia installations from the dual CD were unusable on two computers
+>> I tried due to the lack of the "radeon-firmware" package. After I 
+>> installed
+>> that package, and  rebuilt the initrds, then the problems were 
+>> solved. Still,
+>> it didn't look good at all.
+>>
+>> Is this fact peculiar to the dual CD, and is better in the DVDs or do 
+>> we not
+>> use radeon-firmeware by default globally? I'd like this discussed in 
+>> the next
+>> meeting.
+>>
+>> Regards,
+>>
+>>     Shlomi Fish
+>>
+> I'd like to add another thing to the meeting topics:
+> The discussion about non-free / tainted, which lasted really long,
+> but AFAICS there is no concensus or decision, and the discussion
+> has effectively reached a standstill. My tries to get this going again 
+> have not succeeded so far.
+>
+> For reference, have a look at those:
+> https://www.mageia.org/pipermail/mageia-dev/2011-July/006382.html
+> https://www.mageia.org/pipermail/mageia-dev/2011-July/007001.html
+>
+>
+> For some people the situation seems really clear, also to me,
+> this viewpoint is what tmb expressed in his mail:
+> https://www.mageia.org/pipermail/mageia-dev/2011-July/006560.html
+>
+> But in the end we need a definitive decision.
+>
+In the last reference, tmb responded to my post by noting that the 
+original mirror policy put _all_ packages subject to patents or similar 
+restrictions in some countries in "tainted".
+
+Since then, I have noticed that packages in non-free are tagged 
+"non-free" (in the file name), and almost all packages in "tainted" are 
+tagged "tainted".
+
+So a simple solution, considering that the consensus is to keep a third 
+repository, is to tag all packages subject to both conditions as both 
+"non-free" and "tainted".
+And leave them in the "tainted" repository.
+We could even have a filter to avoid showing "non-free" items in the 
+"tainted" repo, for those so concerned.
+In any case, if we put both tags for such packages, "non-free" would 
+always show up in the package name (under "revision" in rpmdrake).
+
+BTW, I think it was an excellent idea to tag the packages with their 
+repo/classification, if not in "core".
+(I still think we could have a better name than "tainted", since there 
+is nothing intrinsically wrong with the packages.)
+
+-- 
+André
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007399.html b/zarb-ml/mageia-dev/2011-August/007399.html new file mode 100644 index 000000000..fad9aced8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007399.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ D.Morgan + dmorganec at gmail.com +
+ Sat Aug 20 15:34:52 CEST 2011 +

+
+ +
On Sat, Aug 20, 2011 at 3:22 PM,  <root at mageia.org> wrote:
+> Revision 134638 Author shadow95 Date 2011-08-20 15:22:52 +0200 (Sat, 20 Aug
+> 2011)
+>
+> Log Message
+>
+> - clean spec
+>
+> Modified Paths
+>
+> cauldron/gcstar/current/SPECS/gcstar.spec
+>
+> Modified: cauldron/gcstar/current/SPECS/gcstar.spec
+> ===================================================================
+> --- cauldron/gcstar/current/SPECS/gcstar.spec	2011-08-20 13:17:33 UTC (rev
+> 134637)
+> +++ cauldron/gcstar/current/SPECS/gcstar.spec	2011-08-20 13:22:52 UTC (rev
+> 134638)
+> @@ -24,15 +24,16 @@
+>  %setup -q -n %{name}
+>
+>  %install
+> -%{__mkdir_p} %{buildroot}%{_prefix}
+> -%{__install} -d %{buildroot}%{_bindir}
+> -%{__install} bin/gcstar %{buildroot}%{_bindir}
+> -%{__install} -d %{buildroot}%{_prefix}/lib
+> -%{__cp} -a lib/gcstar %{buildroot}%{_prefix}/lib
+> -%{__install} -d %{buildroot}%{_datadir}
+> -%{__cp} -a share/* %{buildroot}%{_datadir}
+> -%{__install} -d %{buildroot}%{_mandir}/man1
+> -%{__install} man/%{name}.1 %{buildroot}%{_mandir}/man1/%{name}.1
+> +rm -rf %{buildroot}
+> +mkdir -p %{buildroot}%{_prefix}
+> +install -d %{buildroot}%{_bindir}
+> +install bin/gcstar %{buildroot}%{_bindir}
+> +install -d %{buildroot}%{_prefix}/lib
+> +cp -a lib/gcstar %{buildroot}%{_prefix}/lib
+> +install -d %{buildroot}%{_datadir}
+> +cp -a share/* %{buildroot}%{_datadir}
+> +install -d %{buildroot}%{_mandir}/man1
+> +install man/%{name}.1 %{buildroot}%{_mandir}/man1/%{name}.1
+
+
+Why do you clean by removing rpm macros ?  what was wrong with them ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007400.html b/zarb-ml/mageia-dev/2011-August/007400.html new file mode 100644 index 000000000..f9432aa92 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007400.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Bertaux Xavier + bertauxx at yahoo.fr +
+ Sat Aug 20 15:42:30 CEST 2011 +

+
+ +
Le 20/08/2011 15:34, D.Morgan a écrit :
+> On Sat, Aug 20, 2011 at 3:22 PM,  <root at mageia.org> wrote:
+>> Revision 134638 Author shadow95 Date 2011-08-20 15:22:52 +0200 (Sat, 20 Aug
+>> 2011)
+>>
+>> Log Message
+>>
+>> - clean spec
+>>
+>> Modified Paths
+>>
+>
+> Why do you clean by removing rpm macros ?  what was wrong with them ?
+
+Hi,
+
+sorry I'm apprentice packager !
+So on all spec Mageia that I've seen, macro %{_install} and macro
+%{_mkdir_p} are not used, but if it's better, I can remake that.
+Which difference in install and %{_install} and mkdir -p and %{_mkdir_p} ?
+
+Xavier
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007401.html b/zarb-ml/mageia-dev/2011-August/007401.html new file mode 100644 index 000000000..14c4ed75c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007401.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Michael Scherer + misc at zarb.org +
+ Sat Aug 20 18:31:26 CEST 2011 +

+
+ +
Le vendredi 19 août 2011 à 23:50 +0200, Samuel Verschelde a écrit :
+> Le jeudi 18 août 2011 19:22:29, nicolas vigier a écrit :
+> > Hello,
+> > 
+> > A new version of mgarepo is being uploaded on mirrors. As repository for
+> > storing binary files has been changed on server, this new version is now
+> > required to continue updating packages.
+> 
+> Can you give us more explanations about the server-side changes, and the 
+> impacts it can have, especially when using svn directly in existing local 
+> checkouts ?
+
+For server side change, I would report you on this thread :
+https://www.mageia.org/pipermail/mageia-sysadm/2011-July/003717.html
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007402.html b/zarb-ml/mageia-dev/2011-August/007402.html new file mode 100644 index 000000000..fe3081210 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007402.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Aug 20 19:13:21 CEST 2011 +

+
+ +
Le samedi 20 août 2011 18:31:26, Michael Scherer a écrit :
+> Le vendredi 19 août 2011 à 23:50 +0200, Samuel Verschelde a écrit :
+> > Le jeudi 18 août 2011 19:22:29, nicolas vigier a écrit :
+> > > Hello,
+> > > 
+> > > A new version of mgarepo is being uploaded on mirrors. As repository
+> > > for storing binary files has been changed on server, this new version
+> > > is now required to continue updating packages.
+> > 
+> > Can you give us more explanations about the server-side changes, and the
+> > impacts it can have, especially when using svn directly in existing local
+> > checkouts ?
+> 
+> For server side change, I would report you on this thread :
+> https://www.mageia.org/pipermail/mageia-sysadm/2011-July/003717.html
+
+Thanks. I read this thread previously but not everyone reads the sysadmin 
+mailing list and I wasn't sure those were the changes the update covers.
+
+However, I still think that a real announce on the thread would be useful, 
+explaining the new repo structure, and what it changes to our daily tasks (and 
+what doesn't change. Currently we can only guess). For example, I don't know 
+if it changes the way to send new sources to Mageia 1 updates. Ideally we 
+would have got such a mail before the change :)
+
+Best regards
+
+Samuel Verschelde
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110820/00dc1036/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007403.html b/zarb-ml/mageia-dev/2011-August/007403.html new file mode 100644 index 000000000..e18c6a324 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007403.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Aug 20 19:14:26 CEST 2011 +

+
+ +
Le samedi 20 août 2011 00:02:22, Thomas Backlund a écrit :
+> Samuel Verschelde skrev 20.8.2011 00:50:
+> > Le jeudi 18 août 2011 19:22:29, nicolas vigier a écrit :
+> >  > Hello,
+> >  > 
+> >  > 
+> >  > 
+> >  > A new version of mgarepo is being uploaded on mirrors. As repository
+> >  > for
+> >  > 
+> >  > storing binary files has been changed on server, this new version is
+> >  > now
+> >  > 
+> >  > required to continue updating packages.
+> > 
+> > Can you give us more explanations about the server-side changes, and the
+> > impacts it can have, especially when using svn directly in existing
+> > local checkouts ? And if the changes are big enough so that the local
+> > checkouts are not usable anymore (probably the case if the repository
+> > changed), state it and tell us what to do with them (erase them and
+> > checkout again with the latest version of mgarepo ?)
+> 
+> No need to redo the checkout...
+> 
+> just move the binaries from SOURCES-bin to SOURCES (replacing the
+> symlinks) and remove the SOURCES-bin dir and keep on working
+> 
+
+Given the number of local checkouts I have I think it will be faster to erase 
+them (no local changes) and checkout them again :)
+
+Samuel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110820/c04730cc/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007404.html b/zarb-ml/mageia-dev/2011-August/007404.html new file mode 100644 index 000000000..6bbe8899d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007404.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] In case of problem with new binrepos + + + + + + + + + +

[Mageia-dev] In case of problem with new binrepos

+ Michael Scherer + misc at zarb.org +
+ Sat Aug 20 19:50:06 CEST 2011 +

+
+ +
If you see some errors like this :
+
+[misc at takara mgarepo] $ mgarepo co octave
+A    octave/SOURCES
+A    octave/SOURCES/octave-2.1.36-emac.lisp
+A    octave/SOURCES/octave-3.4.2-curl.patch
+A    octave/SOURCES/octave-3.4.2-link.patch
+A    octave/SOURCES/sha1.lst
+A    octave/SOURCES/octave-3.4.2-i586-hack.patch
+A    octave/SPECS
+A    octave/SPECS/octave.spec
+Révision 134652 extraite.
+--2011-08-20 19:46:37--
+http://binrepo.mageia.org//2629dbbcf05bda8854fd5293c5629521a11b1102
+Résolution de binrepo.mageia.org (binrepo.mageia.org)... 212.85.158.147,
+2a02:2178:2:7::3
+Connexion vers binrepo.mageia.org (binrepo.mageia.org)|
+212.85.158.147|:80...connecté.
+requête HTTP transmise, en attente de la réponse...404 Not Found
+2011-08-20 19:46:37 ERREUR 404: Not Found.
+
+error: Could not download file
+http://binrepo.mageia.org//2629dbbcf05bda8854fd5293c5629521a11b1102
+
+
+The solution is usually something like that :
+[misc at takara octave] $ svn diff -c 134653
+Index: SOURCES/sha1.lst
+===================================================================
+--- SOURCES/sha1.lst	(révision 134652)
++++ SOURCES/sha1.lst	(révision 134653)
+@@ -1,2 +1 @@
+-2629dbbcf05bda8854fd5293c5629521a11b1102  octave-3.4.1.tar.bz2
+ 12cac29ef7d1ab8374980e1e2fd14637b2f15ba5  octave-3.4.2.tar.bz2
+
+
+Ie, make sure that sha1.lst is correct and do not list too much file,
+especially older file that were incorrectly removed.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007405.html b/zarb-ml/mageia-dev/2011-August/007405.html new file mode 100644 index 000000000..22c62ffcc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007405.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Läs ditt meddelande innan det tas bort! + + + + + + + + + +

[Mageia-dev] Läs ditt meddelande innan det tas bort!

+ Badoo + noreply at badoo.com +
+ Sun Aug 21 04:07:19 CEST 2011 +

+
+ +
Läs ditt meddelandet från Kristoffer Grundström innan det tas bort!
+
+För att läsa följande meddelande, följ länken:
+http://eu1.badoo.com/0162210640/in/.S.fo.7aVx0/?lang_id=70&m=65&mid=4e5068460000000000460000b2c30642
+
+Några fler personer som ihärdigt väntar:
+Pedro (Vizeu, Portugal)
+Ana (Lamego, Portugal)
+Xxxx. spiros (Roma, Italien)
+
+http://eu1.badoo.com/0162210640/in/.S.fo.7aVx0/?lang_id=70&m=65&mid=4e5068460000000000460000b2c30642
+
+Fungerar inte länken? Kopiera följande länk till adressfältet på din webbläsare.
+
+Detta e-mail är en del av leverans rapporten som skickats av Kristoffer Grundström. om du skulle  ha mottagit detta e-mail av misstag, var snäll ignorera. Efter en kort stund kommer meddelandet ha raderats från vårat system.
+
+Ha det så roligt!
+The Badoo Team
+
+
+
+Du har mottagit detta brev eftersom en Badoo-medlem skrivit ett meddelande till dig på Badoo. Detta är ett automatiserat utskick. Svar på detta brev bevakas ej och kommer därför inte heller att besvaras. Om du i fortsättningen inte vill ta emot fler meddelanden från Badoo, vänligen informera oss:
+http://eu1.badoo.com/impersonation.phtml?lang_id=70&mail_code=65&email=mageia-dev%40mageia.org&secret=&block_code=bfb71e&m=65&mid=4e5068460000000000460000b2c30642
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110821/31262013/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007406.html b/zarb-ml/mageia-dev/2011-August/007406.html new file mode 100644 index 000000000..2d0db35f2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007406.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release libxfont-1.4.4-1.mga2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sun Aug 21 15:31:38 CEST 2011 +

+
+ +
'Twas brillig, and nicolas vigier at 18/08/11 19:49 did gyre and gimble:
+> On Mon, 15 Aug 2011, Colin Guthrie wrote:
+> 
+>> 'Twas brillig, and D.Morgan at 14/08/11 00:09 did gyre and gimble:
+>>> On Sat, Aug 13, 2011 at 8:23 PM, Thierry Vignaud
+>>> <thierry.vignaud at gmail.com> wrote:
+>>>> On 13 August 2011 20:04, Thomas Backlund <tmb at mageia.org> wrote:
+>>>>>> Are we forced to branch?
+>>>>>
+>>>>> You must use the updates branch in svn:
+>>>>> svn://svn.mageia.org/svn/packages/updates/1/libxfont
+>>>>>
+>>>>> and submit the update from there...
+>>>>
+>>>> So we're forced to branch indeed.
+>>>> In mdv, we could push rpmdrake & the like directly from cooker branch
+>>>> to previous releases.
+>>>> Not a big deal though.
+>>>>
+>>>> Though it may not be that easy to copy a new releases
+>>>> to an update branch with binrepos.
+>>>> Is there a tool in order to do so?
+>>>>
+>>> i don't think such tool exist, but i think this could be a good idea.
+>>
+>> I wrote this script the other day... but it's a bit rubbish, still might
+>> save some manual commands.
+>>
+>> Of course an option in mgarepo would be nicer.
+> 
+> Copy of binrepos is not needed anymore. So a simple copy of files from
+> svn/packages/cauldron/[package] to svn/packages/updates/1/[package]
+> should be enough now.
+
+Yay for a nicer binrepo :D
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007407.html b/zarb-ml/mageia-dev/2011-August/007407.html new file mode 100644 index 000000000..f2811c245 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007407.html @@ -0,0 +1,162 @@ + + + + [Mageia-dev] In case of problem with new binrepos + + + + + + + + + +

[Mageia-dev] In case of problem with new binrepos

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sun Aug 21 15:40:08 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 20/08/11 18:50 did gyre and gimble:
+> If you see some errors like this :
+> 
+> [misc at takara mgarepo] $ mgarepo co octave
+> A    octave/SOURCES
+> A    octave/SOURCES/octave-2.1.36-emac.lisp
+> A    octave/SOURCES/octave-3.4.2-curl.patch
+> A    octave/SOURCES/octave-3.4.2-link.patch
+> A    octave/SOURCES/sha1.lst
+> A    octave/SOURCES/octave-3.4.2-i586-hack.patch
+> A    octave/SPECS
+> A    octave/SPECS/octave.spec
+> Révision 134652 extraite.
+> --2011-08-20 19:46:37--
+> http://binrepo.mageia.org//2629dbbcf05bda8854fd5293c5629521a11b1102
+> Résolution de binrepo.mageia.org (binrepo.mageia.org)... 212.85.158.147,
+> 2a02:2178:2:7::3
+> Connexion vers binrepo.mageia.org (binrepo.mageia.org)|
+> 212.85.158.147|:80...connecté.
+> requête HTTP transmise, en attente de la réponse...404 Not Found
+> 2011-08-20 19:46:37 ERREUR 404: Not Found.
+> 
+> error: Could not download file
+> http://binrepo.mageia.org//2629dbbcf05bda8854fd5293c5629521a11b1102
+> 
+> 
+> The solution is usually something like that :
+> [misc at takara octave] $ svn diff -c 134653
+> Index: SOURCES/sha1.lst
+> ===================================================================
+> --- SOURCES/sha1.lst	(révision 134652)
+> +++ SOURCES/sha1.lst	(révision 134653)
+> @@ -1,2 +1 @@
+> -2629dbbcf05bda8854fd5293c5629521a11b1102  octave-3.4.1.tar.bz2
+>  12cac29ef7d1ab8374980e1e2fd14637b2f15ba5  octave-3.4.2.tar.bz2
+> 
+> 
+> Ie, make sure that sha1.lst is correct and do not list too much file,
+> especially older file that were incorrectly removed.
+
+Hmmm,
+
+In the gstreamer0.10-plugins-good package the sha1.txt file contained
+two binaries. This is incorrect, but it seems only one of the binaries
+was actually imported.
+
+http://svnweb.mageia.org/packages/cauldron/gstreamer0.10-plugins-good/current/SOURCES/sha1.lst?revision=110655&view=markup
+
+
+>From your explanation above, I guess this is this just a result of the
+sha1.txt file getting out of sync with the actual contents of the
+binrepos SVN?
+
+I can obviously fix this pretty easily, so it's no big deal. Just curious.
+
+Col
+
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007408.html b/zarb-ml/mageia-dev/2011-August/007408.html new file mode 100644 index 000000000..baf208a30 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007408.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sun Aug 21 15:44:32 CEST 2011 +

+
+ +
'Twas brillig, and Bertaux Xavier at 20/08/11 14:42 did gyre and gimble:
+> Le 20/08/2011 15:34, D.Morgan a écrit :
+>> On Sat, Aug 20, 2011 at 3:22 PM,  <root at mageia.org> wrote:
+>>> Revision 134638 Author shadow95 Date 2011-08-20 15:22:52 +0200 (Sat, 20 Aug
+>>> 2011)
+>>>
+>>> Log Message
+>>>
+>>> - clean spec
+>>>
+>>> Modified Paths
+>>>
+>>
+>> Why do you clean by removing rpm macros ?  what was wrong with them ?
+> 
+> Hi,
+> 
+> sorry I'm apprentice packager !
+> So on all spec Mageia that I've seen, macro %{_install} and macro
+> %{_mkdir_p} are not used, but if it's better, I can remake that.
+> Which difference in install and %{_install} and mkdir -p and %{_mkdir_p} ?
+
+I do have to wonder why those macros are used... it seems quite trivial
+to use the actual commands directly and that ultimately increases
+portability (which maybe isn't a major concern, but all the same)
+
+What are the general thoughts on this?
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007409.html b/zarb-ml/mageia-dev/2011-August/007409.html new file mode 100644 index 000000000..314a979ff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007409.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] Planning next meeting + + + + + + + + + +

[Mageia-dev] Planning next meeting

+ Angelo Naselli + anaselli at linux.it +
+ Sun Aug 21 15:45:57 CEST 2011 +

+
+ +
Hi,
+> Back online. We are planning our next meeting for 24th of august, 19h
+> UTC on #mageia-dev. 
+I cannot attend, i'm still on holidays :)
+> In between we will work on some burning subjects
+> (backports incis meetiluded) so that we can take final decisions
+> during this meeting.
+The bad is that i can't be there for that decision...
+The good is that i can always say i was not there for that 
+decision :p
+
+See you
+	Angelo
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 198 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20110821/21a7e1ab/attachment.asc>
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007410.html b/zarb-ml/mageia-dev/2011-August/007410.html new file mode 100644 index 000000000..2e16a72ec --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007410.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] In case of problem with new binrepos + + + + + + + + + +

[Mageia-dev] In case of problem with new binrepos

+ nicolas vigier + boklm at mars-attacks.org +
+ Sun Aug 21 15:52:08 CEST 2011 +

+
+ +
On Sun, 21 Aug 2011, Colin Guthrie wrote:
+
+> 
+> Hmmm,
+> 
+> In the gstreamer0.10-plugins-good package the sha1.txt file contained
+> two binaries. This is incorrect, but it seems only one of the binaries
+> was actually imported.
+> 
+> http://svnweb.mageia.org/packages/cauldron/gstreamer0.10-plugins-good/current/SOURCES/sha1.lst?revision=110655&view=markup
+> 
+> 
+> >From your explanation above, I guess this is this just a result of the
+> sha1.txt file getting out of sync with the actual contents of the
+> binrepos SVN?
+
+Yes, the file gst-plugins-good-0.10.26.tar.bz2 had been removed from the
+binrepos SVN (so it was not imported on the new binrepo), but for some
+reason was not removed from sha1.lst. The previous version of mgarepo
+did not make an error when a file was listed in sha1.lst but was not in
+the binrepos SVN, so this kind of problem in sha1.lst was not noticed.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007411.html b/zarb-ml/mageia-dev/2011-August/007411.html new file mode 100644 index 000000000..6058c456b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007411.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] jgraphx downgrade + + + + + + + + + +

[Mageia-dev] jgraphx downgrade

+ grenoya + grenoya at zarb.org +
+ Sun Aug 21 16:51:29 CEST 2011 +

+
+ +
Hello,
+Due to compatibility problem with Scilab, the packages jgraphx and 
+jgraphx-javadoc have been downgraded.
+
+In order not to add a epoch, the rpms of version 1.7.0.6 have been 
+removed from mirrors. But if you had them on your cauldron, you will 
+have to remove them manually, in order to install 1.4.1.0 version.
+
+regards
+Claire
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007412.html b/zarb-ml/mageia-dev/2011-August/007412.html new file mode 100644 index 000000000..78bf8f69b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007412.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ andre999 + andr55 at laposte.net +
+ Sun Aug 21 21:43:03 CEST 2011 +

+
+ +
Colin Guthrie a écrit :
+> 'Twas brillig, and Bertaux Xavier at 20/08/11 14:42 did gyre and gimble:
+>> Le 20/08/2011 15:34, D.Morgan a écrit :
+>>> On Sat, Aug 20, 2011 at 3:22 PM,<root at mageia.org>  wrote:
+>>>> Revision 134638 Author shadow95 Date 2011-08-20 15:22:52 +0200 (Sat, 20 Aug
+>>>> 2011)
+>>>>
+>>>> Log Message
+>>>>
+>>>> - clean spec
+>>>>
+>>>> Modified Paths
+>>>>
+>>>
+>>> Why do you clean by removing rpm macros ?  what was wrong with them ?
+>>
+>> Hi,
+>>
+>> sorry I'm apprentice packager !
+>> So on all spec Mageia that I've seen, macro %{_install} and macro
+>> %{_mkdir_p} are not used, but if it's better, I can remake that.
+>> Which difference in install and %{_install} and mkdir -p and %{_mkdir_p} ?
+>
+> I do have to wonder why those macros are used... it seems quite trivial
+> to use the actual commands directly and that ultimately increases
+> portability (which maybe isn't a major concern, but all the same)
+>
+> What are the general thoughts on this?
+>
+> Col
+
+I agree -- as long as there are appropriate filetriggers to deal with things 
+like attributing ownership of created parent directories, etc.
+(Which if I'm not mistaken, should not belong to the packages in question.  If 
+that is wanted, the directory should be explicitly created.)
+
+Considering that, one should be able to do simply
+mkdir ... which defaults to mkdir -p ...
+and
+cp ... which defaults to cp -a ...
+since that is what would normally be wanted.
+There would be less room for error.
+Of course, this should be documented in the packager wiki as well.
+
+My 2 cents :)
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007413.html b/zarb-ml/mageia-dev/2011-August/007413.html new file mode 100644 index 000000000..093e6f57e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007413.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ Zé + mmodem00 at gmail.com +
+ Mon Aug 22 00:16:24 CEST 2011 +

+
+ +
Hi,
+
+Theres been a private discussion regarding the macro correct layout, if
+%{foo} or %foo.
+
+This rised when in the wiki page
+http://mageia.org/wiki/doku.php?id=kde4_packaging_policy i changed the spec
+layout from %foo into %{foo} to be as a reference point, in wich mikala has
+reverted back to %foo, and this discussion has taken other porportions so i
+would like your opinions regarding this.
+
+I have pointed that for a wiki page should be proper to use %{...} to avoid
+doubts specially in beginners minds, since in some situations we need really
+to use the {} delimitations.
+In wich its recommendation its focused in this cute PDF from redhat website:
+
+http://www.redhat.com/promo/summit/2008/downloads/pdf/Wednesday_130pm_Tom_Callaway_OSS.pdf
+
+Im not refering that now we should use only %{...}, that usage can be
+handled from the user prespective (for example in my specs locally i
+generally dont use delimitations), some like others dont.
+
+As we also see in rpm macros document
+http://www.rpm.org/wiki/PackagerDocs/Macros that we can use both, but in all
+rpm docs and config files the common usage its with delimitations.
+
+regards,
+-- 
+Zé
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110821/bbd8a663/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007414.html b/zarb-ml/mageia-dev/2011-August/007414.html new file mode 100644 index 000000000..ebc525b83 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007414.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Aug 22 00:27:59 CEST 2011 +

+
+ +
'Twas brillig, and Zé at 21/08/11 23:16 did gyre and gimble:
+> Hi,
+> 
+> Theres been a private discussion regarding the macro correct layout, if
+> %{foo} or %foo.
+> 
+> This rised when in the wiki
+> page http://mageia.org/wiki/doku.php?id=kde4_packaging_policy i changed
+> the spec layout from %foo into %{foo} to be as a reference point, in
+> wich mikala has reverted back to %foo, and this discussion has taken
+> other porportions so i would like your opinions regarding this.
+> 
+> I have pointed that for a wiki page should be proper to use %{...} to
+> avoid doubts specially in beginners minds, since in some situations we
+> need really to use the {} delimitations.
+> In wich its recommendation its focused in this cute PDF from redhat website:
+> 
+> http://www.redhat.com/promo/summit/2008/downloads/pdf/Wednesday_130pm_Tom_Callaway_OSS.pdf
+> 
+> Im not refering that now we should use only %{...}, that usage can be
+> handled from the user prespective (for example in my specs locally i
+> generally dont use delimitations), some like others dont.
+> 
+> As we also see in rpm macros
+> document http://www.rpm.org/wiki/PackagerDocs/Macros that we can use
+> both, but in all rpm docs and config files the common usage its with
+> delimitations.
+
+FWIW, personally I tend to use delimiters also.
+
+I prefer it as it feels more like strict typing.... I know it's not but
+I always like to make things totally and unequivocally explicit all the
+same.
+
+I tend to do this in my bash scripts and even in PHP scripts too (tho'
+annoyingly the PHP delimiters go outside of the variable identifier
+unlike in RPM macros and bash, so it's syntactically a little different
+but the same principles apply).
+
+Cheers
+
+Col
+
+
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007415.html b/zarb-ml/mageia-dev/2011-August/007415.html new file mode 100644 index 000000000..b87487cd2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007415.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 22 00:43:32 CEST 2011 +

+
+ +
Le Sunday 21 August 2011 23:16:24 Zé a écrit :
+> Hi,
+> 
+> Theres been a private discussion regarding the macro correct layout,
+> if %{foo} or %foo.
+> 
+> This rised when in the wiki page
+> http://mageia.org/wiki/doku.php?id=kde4_packaging_policy i changed the
+> spec layout from %foo into %{foo} to be as a reference point, in wich
+> mikala has reverted back to %foo, and this discussion has taken other
+> porportions so i would like your opinions regarding this.
+> 
+> I have pointed that for a wiki page should be proper to use %{...} to
+> avoid doubts specially in beginners minds, since in some situations
+> we need really to use the {} delimitations.
+> In wich its recommendation its focused in this cute PDF from redhat
+> website:
+> 
+> http://www.redhat.com/promo/summit/2008/downloads/pdf/Wednesday_130pm_
+> Tom_Callaway_OSS.pdf
+Maybe we can recall the situation & check on *this* SPEC layout where 
+the %{} is useful ?
+We're not even supposed to use macro with - (where indeed the use of %{} 
+) so as i said before for *our* KDE spec layout & KDE spec layout the 
+*default* spec should use %foo & not %{foo}, it's of course does not 
+prevent the use of %{foo} for people but we won't rewrite all specs like 
+you did for Qt4 just because you want to do it without asking first.
+
+Also could you explain why what was just a minor problem (when you 
+changed without even asking us our opinion) become suddently a *major* 
+problem which need suddenly a mail on -dev because i was not agree with 
+you.
+
+I'm in a general impression that in fact you don't care at all about my 
+opinion and if i'm not agree with you that's mean i'm just wrong...
+Yeah i still remember that you wrote on irc that i'm just too young to 
+maintain KDE at all, that you're really a *old* packager with *years* 
+and *years* of packaging, that's you're talking a lot with upstream when 
+i'm not etc etc ....
+
+Maybe you can still push a little bit more and i'll simply quit since 
+it's probably what you're looking for since several months...
+
+
+
+P.S: yeah i started to have enough now...
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007416.html b/zarb-ml/mageia-dev/2011-August/007416.html new file mode 100644 index 000000000..8492fbb78 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007416.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ D.Morgan + dmorganec at gmail.com +
+ Mon Aug 22 00:49:34 CEST 2011 +

+
+ +
On Mon, Aug 22, 2011 at 12:27 AM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> 'Twas brillig, and Zé at 21/08/11 23:16 did gyre and gimble:
+>> Hi,
+>>
+>> Theres been a private discussion regarding the macro correct layout, if
+>> %{foo} or %foo.
+>>
+>> This rised when in the wiki
+>> page http://mageia.org/wiki/doku.php?id=kde4_packaging_policy i changed
+>> the spec layout from %foo into %{foo} to be as a reference point, in
+>> wich mikala has reverted back to %foo, and this discussion has taken
+>> other porportions so i would like your opinions regarding this.
+>>
+>> I have pointed that for a wiki page should be proper to use %{...} to
+>> avoid doubts specially in beginners minds, since in some situations we
+>> need really to use the {} delimitations.
+>> In wich its recommendation its focused in this cute PDF from redhat website:
+>>
+>> http://www.redhat.com/promo/summit/2008/downloads/pdf/Wednesday_130pm_Tom_Callaway_OSS.pdf
+>>
+>> Im not refering that now we should use only %{...}, that usage can be
+>> handled from the user prespective (for example in my specs locally i
+>> generally dont use delimitations), some like others dont.
+>>
+>> As we also see in rpm macros
+>> document http://www.rpm.org/wiki/PackagerDocs/Macros that we can use
+>> both, but in all rpm docs and config files the common usage its with
+>> delimitations.
+>
+> FWIW, personally I tend to use delimiters also.
+>
+> I prefer it as it feels more like strict typing.... I know it's not but
+> I always like to make things totally and unequivocally explicit all the
+> same.
+>
+> I tend to do this in my bash scripts and even in PHP scripts too (tho'
+> annoyingly the PHP delimiters go outside of the variable identifier
+> unlike in RPM macros and bash, so it's syntactically a little different
+> but the same principles apply).
+>
+> Cheers
+>
+
+Me, i use both ( this depend if the rpm i work in had it or not ) but
+for new rpm i use %foo.
+
+But i don't see a need to add a policy for %{foo} against %foo.
+
+I don't understand Ze mail, he ask to use %{foo} and imposed it by
+changing in a spec file stating "  i changed the spec layout from %foo
+into %{foo} to be as a reference point, " and then in the same mail i
+read "for example in my specs locally i generally dont use
+delimitations".
+
+why this mail if you personnaly don't really care about the question ?
+just because mikala wasn't agree with you ?
+
+P.S: yeah i started to have enough now... ( too )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007417.html b/zarb-ml/mageia-dev/2011-August/007417.html new file mode 100644 index 000000000..8b5f89202 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007417.html @@ -0,0 +1,161 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ andre999 + andr55 at laposte.net +
+ Mon Aug 22 01:29:02 CEST 2011 +

+
+ +
D.Morgan a écrit :
+> On Mon, Aug 22, 2011 at 12:27 AM, Colin Guthrie<mageia at colin.guthr.ie>  wrote:
+>> 'Twas brillig, and Zé at 21/08/11 23:16 did gyre and gimble:
+>>> Hi,
+>>>
+>>> Theres been a private discussion regarding the macro correct layout, if
+>>> %{foo} or %foo.
+>>>
+>>> This rised when in the wiki
+>>> page http://mageia.org/wiki/doku.php?id=kde4_packaging_policy i changed
+>>> the spec layout from %foo into %{foo} to be as a reference point, in
+>>> wich mikala has reverted back to %foo, and this discussion has taken
+>>> other porportions so i would like your opinions regarding this.
+>>>
+>>> I have pointed that for a wiki page should be proper to use %{...} to
+>>> avoid doubts specially in beginners minds, since in some situations we
+>>> need really to use the {} delimitations.
+>>> In wich its recommendation its focused in this cute PDF from redhat website:
+>>>
+>>> http://www.redhat.com/promo/summit/2008/downloads/pdf/Wednesday_130pm_Tom_Callaway_OSS.pdf
+>>>
+>>> Im not refering that now we should use only %{...}, that usage can be
+>>> handled from the user prespective (for example in my specs locally i
+>>> generally dont use delimitations), some like others dont.
+>>>
+>>> As we also see in rpm macros
+>>> document http://www.rpm.org/wiki/PackagerDocs/Macros that we can use
+>>> both, but in all rpm docs and config files the common usage its with
+>>> delimitations.
+>>
+>> FWIW, personally I tend to use delimiters also.
+>>
+>> I prefer it as it feels more like strict typing.... I know it's not but
+>> I always like to make things totally and unequivocally explicit all the
+>> same.
+>>
+>> I tend to do this in my bash scripts and even in PHP scripts too (tho'
+>> annoyingly the PHP delimiters go outside of the variable identifier
+>> unlike in RPM macros and bash, so it's syntactically a little different
+>> but the same principles apply).
+>>
+>> Cheers
+>>
+>
+> Me, i use both ( this depend if the rpm i work in had it or not ) but
+> for new rpm i use %foo.
+>
+> But i don't see a need to add a policy for %{foo} against %foo.
+>
+> I don't understand Ze mail, he ask to use %{foo} and imposed it by
+> changing in a spec file stating "  i changed the spec layout from %foo
+> into %{foo} to be as a reference point, " and then in the same mail i
+> read "for example in my specs locally i generally dont use
+> delimitations".
+>
+> why this mail if you personnaly don't really care about the question ?
+> just because mikala wasn't agree with you ?
+>
+> P.S: yeah i started to have enough now... ( too )
+>
+being still officially an apprentice, I've been told to use %{...}, but don't 
+see a problem with omitting where it's not necessary.
+For existing specs, I don't see a big need to change things.
+As long as it's there where it's really needed.
+Let's go with the flow, it's not like it is something that is visible outside 
+the spec file.
+
+It would be nice to have it clearly documented as to when it is strictly 
+necessary -- and why.  As well as giving a preferred style, if any.
+(If that hasn't already been done, of course.)
+
+My 2 cents :)
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007418.html b/zarb-ml/mageia-dev/2011-August/007418.html new file mode 100644 index 000000000..4e86aba97 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007418.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Mageia "1.01" ISO with updated packages? + + + + + + + + + +

[Mageia-dev] Mageia "1.01" ISO with updated packages?

+ You-Cheng Hsieh + yochenhsieh at gmail.com +
+ Mon Aug 22 05:16:29 CEST 2011 +

+
+ +
Hello,
+
+The KDE 4.6.5 packages just appeared for Mageia 1 updates, and it
+takes some times to update them all for users with slower connection.
+I would like to suggest, if there's no such plan, is it possible we
+could update Mageia1 ISO with updated packages so that users don't
+need to download a large amount of packages after they just installed
+Mageia1?
+
+Packages wanted to be included in Mageia "1.01":
+kde 4.6.5 (available in updates)
+kernel 2.6.38.8 (available in updates)
+firefox 6 (in updates_testing)
+libreoffice 3.3.4 (not available for update? Mageia 1 has 3.3.2.2)
+
+Regards,
+
+You-Cheng Hsieh
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007419.html b/zarb-ml/mageia-dev/2011-August/007419.html new file mode 100644 index 000000000..b7635789a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007419.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] java-1.6.0-openjdk SIGSEV + + + + + + + + + +

[Mageia-dev] java-1.6.0-openjdk SIGSEV

+ Zé + mmodem00 at gmail.com +
+ Mon Aug 22 07:04:31 CEST 2011 +

+
+ +
Hi.
+
+I have have lost java and when tried to run some java tool it simply
+outputed SIGSEV
+With new version updates seams java-openjdk needs to be rebuild.
+
+-- 
+Zé
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007420.html b/zarb-ml/mageia-dev/2011-August/007420.html new file mode 100644 index 000000000..26fac63ac --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007420.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] java-1.6.0-openjdk SIGSEV + + + + + + + + + +

[Mageia-dev] java-1.6.0-openjdk SIGSEV

+ D.Morgan + dmorganec at gmail.com +
+ Mon Aug 22 07:10:03 CEST 2011 +

+
+ +
On Mon, Aug 22, 2011 at 7:04 AM, Zé <mmodem00 at gmail.com> wrote:
+> Hi.
+>
+> I have have lost java and when tried to run some java tool it simply
+> outputed SIGSEV
+> With new version updates seams java-openjdk needs to be rebuild.
+>
+> --
+> Zé
+>
+
+Please do a bugreport like for other bugs.
+( with more "'infos" )
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007421.html b/zarb-ml/mageia-dev/2011-August/007421.html new file mode 100644 index 000000000..ddb9965a4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007421.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Problems setting up chroot + + + + + + + + + +

[Mageia-dev] Problems setting up chroot

+ Zé + mmodem00 at gmail.com +
+ Mon Aug 22 07:29:22 CEST 2011 +

+
+ +
2011/8/10 Thierry Vignaud <thierry.vignaud at gmail.com>:
+> On 10 August 2011 09:03, andre999 <andr55 at laposte.net> wrote:
+>> Thanks for your detailed response.
+>> It lets me run everything.
+>> (Just chroot $CHROOT
+>>  gives me a terminal in chroot, which is what I wanted.)
+>>
+>> How do I restrict a chroot session to non-root privileges, so I can safely
+>> do things like build packages locally ?
+>> I tried logging into my account, but it doesn't seem to work.
+>
+> Just use iurt for that...
+>
+
+It could be very usefull to create a wiki page describing all iurt
+steps and options and provide examples.
+
+And im not refering to
+http://mageia.org/wiki/doku.php?id=mentoring_start that haves a small
+reference in the end of the page.
+
+-- 
+Zé
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007422.html b/zarb-ml/mageia-dev/2011-August/007422.html new file mode 100644 index 000000000..02a85d8d6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007422.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Mageia "1.01" ISO with updated packages? + + + + + + + + + +

[Mageia-dev] Mageia "1.01" ISO with updated packages?

+ Anne nicolas + ennael at mageia.org +
+ Mon Aug 22 08:54:43 CEST 2011 +

+
+ +
Le 22 août 2011 05:16, "You-Cheng Hsieh" <yochenhsieh at gmail.com> a écrit :
+>
+> Hello,
+>
+> The KDE 4.6.5 packages just appeared for Mageia 1 updates, and it
+> takes some times to update them all for users with slower connection.
+> I would like to suggest, if there's no such plan, is it possible we
+> could update Mageia1 ISO with updated packages so that users don't
+> need to download a large amount of packages after they just installed
+> Mageia1?
+>
+> Packages wanted to be included in Mageia "1.01":
+> kde 4.6.5 (available in updates)
+> kernel 2.6.38.8 (available in updates)
+> firefox 6 (in updates_testing)
+> libreoffice 3.3.4 (not available for update? Mageia 1 has 3.3.2.2)
+
+This is a great idea indeed but we have for now bigger priorities for
+packagers  and qa team. Still à lot of updates pending to be done
+
+>
+> Regards,
+>
+> You-Cheng Hsieh
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110822/8a4f3fec/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007423.html b/zarb-ml/mageia-dev/2011-August/007423.html new file mode 100644 index 000000000..31ade3fb7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007423.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Mageia "1.01" ISO with updated packages? + + + + + + + + + +

[Mageia-dev] Mageia "1.01" ISO with updated packages?

+ Kira + elegant.pegasus at gmail.com +
+ Mon Aug 22 08:58:44 CEST 2011 +

+
+ +
在 Mon, 22 Aug 2011 14:54:43 +0800, Anne nicolas <ennael at mageia.org>寫道:
+>
+> This is a great idea indeed but we have for now bigger priorities for
+> packagers  and qa team. Still à lot of updates pending to be done
+>
+Is there an automated iso creating process like what openSUSE studio  
+offers?
+
+Maybe not that powerful which can let you customize almost everything, but
+
+something like debian which weekly/monthly produce a new iso ?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007424.html b/zarb-ml/mageia-dev/2011-August/007424.html new file mode 100644 index 000000000..ba511cc6a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007424.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Mageia "1.01" ISO with updated packages? + + + + + + + + + +

[Mageia-dev] Mageia "1.01" ISO with updated packages?

+ Anne nicolas + ennael at mageia.org +
+ Mon Aug 22 09:01:30 CEST 2011 +

+
+ +
2011/8/22 Kira <elegant.pegasus at gmail.com>:
+> 在 Mon, 22 Aug 2011 14:54:43 +0800, Anne nicolas <ennael at mageia.org>寫道:
+>>
+>> This is a great idea indeed but we have for now bigger priorities for
+>> packagers  and qa team. Still à lot of updates pending to be done
+>>
+> Is there an automated iso creating process like what openSUSE studio offers?
+>
+> Maybe not that powerful which can let you customize almost everything, but
+>
+> something like debian which weekly/monthly produce a new iso ?
+
+This is on todo list for cauldron only. On stable one, it would
+require QA, we cannot provide stable versions isos without any QA
+>
+
+
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007425.html b/zarb-ml/mageia-dev/2011-August/007425.html new file mode 100644 index 000000000..057d8e070 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007425.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Mon Aug 22 11:57:02 CEST 2011 +

+
+ +
Hello,
+
+This is just a heads up to suggest that we officially adopt a policy of
+moving to NetworkManager after systemd becomes our default (and likely
+only) init system - i.e. likely for mga3.
+
+As you may know, GNOME is moving towards a systemd user session and
+systemd itself is very much aligning itself to be the one true init
+system on linux.
+
+I also have it on good authority that many of the features lacking in
+NetworkManager (such as bridging configuration) will be available in the
+not too distant future and many other more advanced networking features
+such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and
+several other nice features will ultimately be possible too.
+
+So with all this in mind, I think the writing is very much on the wall
+with regards to the future integration of NetworkManager into the
+desktop. I believe we will be able to concentrate our resources better
+by going along with the rest of the world in this regard. I have
+personally switched to it now (as I do not need advanced features of
+draknetcenter et al) as a step towards this.
+
+It would be nice if other users did this to ensure that integration is
+suitably up to par.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007426.html b/zarb-ml/mageia-dev/2011-August/007426.html new file mode 100644 index 000000000..0747d890f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007426.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Mon Aug 22 12:57:23 CEST 2011 +

+
+ +
On 22/08/2011 11:57, Colin Guthrie wrote:
+> I also have it on good authority that many of the features lacking in
+> NetworkManager (such as bridging configuration) will be available in the
+> not too distant future and many other more advanced networking features
+> such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and
+> several other nice features will ultimately be possible too.
+While I don't care about configuration wizards, I do about initscripts. 
+How are you supposed to configure a server in some automated manner 
+without plain-old configuration files ?
+-- 
+BOFH excuse #161:
+
+monitor VLF leakage
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007427.html b/zarb-ml/mageia-dev/2011-August/007427.html new file mode 100644 index 000000000..530e3207e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007427.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Kira + elegant.pegasus at gmail.com +
+ Mon Aug 22 13:08:26 CEST 2011 +

+
+ +
在 Mon, 22 Aug 2011 17:57:02 +0800, Colin Guthrie  
+<mageia at colin.guthr.ie>寫道:
+
+> Hello,
+>
+> I also have it on good authority that many of the features lacking in
+> NetworkManager (such as bridging configuration) will be available in the
+> not too distant future and many other more advanced networking features
+> such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and
+> several other nice features will ultimately be possible too.
+>
+> So with all this in mind, I think the writing is very much on the wall
+> with regards to the future integration of NetworkManager into the
+> desktop. I believe we will be able to concentrate our resources better
+> by going along with the rest of the world in this regard. I have
+> personally switched to it now (as I do not need advanced features of
+> draknetcenter et al) as a step towards this.
+>
+So what can draknet do while NM can't?
+
+If such a thing exist, I think abandon draknet is not a good idea,
+
+since it's much more integrate into MCC. Also, is it possible to
+
+combine them up, like using draknet to support manage the connection
+
+, letting NM replace the role of net_applet?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007428.html b/zarb-ml/mageia-dev/2011-August/007428.html new file mode 100644 index 000000000..6a3e6c8ce --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007428.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Balcaen John + mikala at mageia.org +
+ Mon Aug 22 13:44:01 CEST 2011 +

+
+ +
Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+> On 22/08/2011 11:57, Colin Guthrie wrote:
+> > I also have it on good authority that many of the features lacking
+> > in NetworkManager (such as bridging configuration) will be
+> > available in the not too distant future and many other more
+> > advanced networking features such as fast-start DHCP,
+> > per-interface DNS, 4-8's DNS fallback and several other nice
+> > features will ultimately be possible too.
+> While I don't care about configuration wizards, I do about
+> initscripts. How are you supposed to configure a server in some
+> automated manner without plain-old configuration files ?
+If i'm not wrong you can still drop plain text files in 
+/etc/NetworkManager/system-connections/
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007429.html b/zarb-ml/mageia-dev/2011-August/007429.html new file mode 100644 index 000000000..3adc6ac27 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007429.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Aug 22 13:59:05 CEST 2011 +

+
+ +
On 11/08/21 19:29 -0400, andre999 wrote:
+> It would be nice to have it clearly documented as to when it is
+> strictly necessary -- and why.  As well as giving a preferred style,
+> if any.
+> (If that hasn't already been done, of course.)
+
+in mdv time, i think the convention was to use %{} for variables, and %
+for macro that do sthg. that's why i'm using this in perl modules spec
+files:
+
+    version: %perl_convert_version %{upstream_version}
+
+regards,
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007430.html b/zarb-ml/mageia-dev/2011-August/007430.html new file mode 100644 index 000000000..63fa96728 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007430.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] [1882] include microcode.ko in installer image + + + + + + + + + +

[Mageia-dev] [1882] include microcode.ko in installer image

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Aug 22 14:02:50 CEST 2011 +

+
+ +
On 22 August 2011 13:33,  <root at mageia.org> wrote:
+> Revision 1882 Author tv Date 2011-08-22 13:33:07 +0200 (Mon, 22 Aug 2011)
+>
+> Log Message
+>
+> include microcode.ko in installer image
+
+which means I need to upload drakx-i-images !!!!
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007431.html b/zarb-ml/mageia-dev/2011-August/007431.html new file mode 100644 index 000000000..59fcd7b0d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007431.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Michael scherer + misc at zarb.org +
+ Mon Aug 22 14:14:48 CEST 2011 +

+
+ +
On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote:
+> Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+> > On 22/08/2011 11:57, Colin Guthrie wrote:
+> > > I also have it on good authority that many of the features lacking
+> > > in NetworkManager (such as bridging configuration) will be
+> > > available in the not too distant future and many other more
+> > > advanced networking features such as fast-start DHCP,
+> > > per-interface DNS, 4-8's DNS fallback and several other nice
+> > > features will ultimately be possible too.
+> > While I don't care about configuration wizards, I do about
+> > initscripts. How are you supposed to configure a server in some
+> > automated manner without plain-old configuration files ?
+> If i'm not wrong you can still drop plain text files in 
+> /etc/NetworkManager/system-connections/
+
+Provided you want to do nothing fancy like bridge, vlan and 
+others stuff that are used by sysadmins. 
+
+And provided of course that you do not care about breaking upgrade
+path. 
+
+I would personnaly not move until Fedora at least did for some 
+releases. We are not here to experiment on our users, they are not
+guinea pigs. 
+-- 
+Michael Scherer 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007432.html b/zarb-ml/mageia-dev/2011-August/007432.html new file mode 100644 index 000000000..90e1940e4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007432.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Aug 22 14:32:31 CEST 2011 +

+
+ +
On 22 August 2011 11:57, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> This is just a heads up to suggest that we officially adopt a policy of
+> moving to NetworkManager after systemd becomes our default (and likely
+> only) init system - i.e. likely for mga3.
+>
+> As you may know, GNOME is moving towards a systemd user session and
+> systemd itself is very much aligning itself to be the one true init
+> system on linux.
+>
+> I also have it on good authority that many of the features lacking in
+> NetworkManager (such as bridging configuration) will be available in the
+> not too distant future and many other more advanced networking features
+> such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and
+> several other nice features will ultimately be possible too.
+>
+> So with all this in mind, I think the writing is very much on the wall
+> with regards to the future integration of NetworkManager into the
+> desktop. I believe we will be able to concentrate our resources better
+> by going along with the rest of the world in this regard. I have
+> personally switched to it now (as I do not need advanced features of
+> draknetcenter et al) as a step towards this.
+
+err... drakx-net's code is heavily used by other tools such as:
+- drakx-installer
+- mgaonline
+- ...
+
+So I think we still want to keep drakx-net
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007433.html b/zarb-ml/mageia-dev/2011-August/007433.html new file mode 100644 index 000000000..873fb7ba0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007433.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Mon Aug 22 15:59:49 CEST 2011 +

+
+ +
On 20 August 2011 00:02, Thomas Backlund <tmb at mageia.org> wrote:
+> No need to redo the checkout...
+>
+> just move the binaries from SOURCES-bin to SOURCES (replacing the symlinks)
+> and remove the SOURCES-bin dir and keep on working
+
+"mgarepo up" should do that...
+
+btw as the config file was tagged as config(noreplace), upgrade breaks until one
+fix his config file.
+not that a big deal but that should be warned, or config(noreplace) should be
+replaced by config()
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007434.html b/zarb-ml/mageia-dev/2011-August/007434.html new file mode 100644 index 000000000..644d5203a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007434.html @@ -0,0 +1,143 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Mon Aug 22 23:39:36 CEST 2011 +

+
+ +
Op maandag 22 augustus 2011 13:08:26 schreef Kira:
+> 在 Mon, 22 Aug 2011 17:57:02 +0800, Colin Guthrie
+> 
+> <mageia at colin.guthr.ie>寫道:
+> > Hello,
+> > 
+> > I also have it on good authority that many of the features lacking in
+> > NetworkManager (such as bridging configuration) will be available in the
+> > not too distant future and many other more advanced networking features
+> > such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and
+> > several other nice features will ultimately be possible too.
+> > 
+> > So with all this in mind, I think the writing is very much on the wall
+> > with regards to the future integration of NetworkManager into the
+> > desktop. I believe we will be able to concentrate our resources better
+> > by going along with the rest of the world in this regard. I have
+> > personally switched to it now (as I do not need advanced features of
+> > draknetcenter et al) as a step towards this.
+> 
+> So what can draknet do while NM can't?
+> 
+> If such a thing exist, I think abandon draknet is not a good idea,
+> 
+> since it's much more integrate into MCC. Also, is it possible to
+> 
+> combine them up, like using draknet to support manage the connection
+> 
+> , letting NM replace the role of net_applet?
+
+imho, the tools that are now available don't really work well together, ie: if 
+you use multiple of those tools, likely they don't show correct status, etc...
+
+personally, i've used net_applet always and i would like to keep this.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007435.html b/zarb-ml/mageia-dev/2011-August/007435.html new file mode 100644 index 000000000..329cf57ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007435.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ andre999 + andr55 at laposte.net +
+ Mon Aug 22 23:58:45 CEST 2011 +

+
+ +
Jerome Quelin a écrit :
+> On 11/08/21 19:29 -0400, andre999 wrote:
+>> It would be nice to have it clearly documented as to when it is
+>> strictly necessary -- and why.  As well as giving a preferred style,
+>> if any.
+>> (If that hasn't already been done, of course.)
+>
+> in mdv time, i think the convention was to use %{} for variables, and %
+> for macro that do sthg. that's why i'm using this in perl modules spec
+> files:
+>
+>      version: %perl_convert_version %{upstream_version}
+>
+> regards,
+> jérôme
+>
+That's what I was told to do by my mentor.
+Maybe a little awkward adding the {...}, but worth the clarity.
+Especially in a context like perl, it would make it a lot easier to follow the 
+code.  (Particulary for someone not totally familiar with perl, like myself.)
+So that has my vote :)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007436.html b/zarb-ml/mageia-dev/2011-August/007436.html new file mode 100644 index 000000000..77c14ada1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007436.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ andre999 + andr55 at laposte.net +
+ Tue Aug 23 00:02:35 CEST 2011 +

+
+ +
A post by jquelin reminded me of something that would be nice to see, for 
+potential contributors to Mageia code (like myself).
+
+It would be useful to have brief documentation for Mageia perl routines, which 
+would describe the inputs required (function, range of values, etc) and the 
+purpose of each routine.
+This would be good to have in a separate document, so (potential) hackers could 
+have an overview of the various routines and their functions.  I know that with 
+time one can learn this, but it would provide a quickstart for those who would 
+like to contribute to the drak* tools for example.  A simple text file would 
+suffice, since that would give the flexibility to put it wherever wanted on the 
+screen while examining other perl code which uses these routines.
+
+I'm talking about a concise programmer's guide, and not something suitable for 
+end-users.  And not something describing the perl language itself, for which 
+there are plenty of references.
+
+This could be done with python as well.  I mention perl since that is what most 
+of the drak* tools are written in.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007437.html b/zarb-ml/mageia-dev/2011-August/007437.html new file mode 100644 index 000000000..bddadec48 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007437.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Bruno Cornec + Bruno.Cornec at hp.com +
+ Tue Aug 23 05:06:47 CEST 2011 +

+
+ +
andre999 said on Mon, Aug 22, 2011 at 06:02:35PM -0400:
+
+> It would be useful to have brief documentation for Mageia perl
+> routines, which would describe the inputs required (function, range
+> of values, etc) and the purpose of each routine.
+
+Why not use just pod ? That way doc and code could easily remain in sync
+and man pages produced easily (or a doc)
+
+Bruno.
+-- 
+Open Source & Linux Profession Lead EMEA           / http://opensource.hp.com
+HP/Intel/Red Hat Open Source Solutions Initiative  / http://www.hpintelco.net
+http://www.HyPer-Linux.org  http://mondorescue.org http://project-builder.org
+La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007438.html b/zarb-ml/mageia-dev/2011-August/007438.html new file mode 100644 index 000000000..67dbb99e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007438.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 23 09:32:12 CEST 2011 +

+
+ +
On 22/08/2011 15:59, Thierry Vignaud wrote:
+> btw as the config file was tagged as config(noreplace), upgrade breaks until one
+> fix his config file.
+> not that a big deal but that should be warned, or config(noreplace) should be
+> replaced by config()
+One could expect than packagers know how configuration files are 
+managed, and there is no point in circumventing usual packaging policy 
+here 'just to help'.
+
+-- 
+BOFH excuse #183:
+
+filesystem not big enough for Jumbo Kernel Patch
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007439.html b/zarb-ml/mageia-dev/2011-August/007439.html new file mode 100644 index 000000000..112d179ad --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007439.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 23 09:34:11 CEST 2011 +

+
+ +
On 23/08/2011 00:02, andre999 wrote:
+> I'm talking about a concise programmer's guide, and not something
+> suitable for end-users. And not something describing the perl language
+> itself, for which there are plenty of references.
+That's been asked for for just 10 years now. As long as no one 
+volonteers to do it, it's unlikely to happen.
+
+-- 
+BOFH excuse #125:
+
+we just switched to Sprint.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007440.html b/zarb-ml/mageia-dev/2011-August/007440.html new file mode 100644 index 000000000..903d47adf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007440.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 23 09:47:20 CEST 2011 +

+
+ +
On 22/08/2011 23:58, andre999 wrote:
+> Especially in a context like perl, it would make it a lot easier to
+> follow the code. (Particulary for someone not totally familiar with
+> perl, like myself.)
+> So that has my vote :)
+This is an rpm macro, not perl code. Underlying implementation doesn't 
+matter here.
+-- 
+BOFH excuse #429:
+
+Temporal anomaly
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007441.html b/zarb-ml/mageia-dev/2011-August/007441.html new file mode 100644 index 000000000..a1643e1d6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007441.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 10:30:52 CEST 2011 +

+
+ +
'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble:
+> On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote:
+>> Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+>>> On 22/08/2011 11:57, Colin Guthrie wrote:
+>>>> I also have it on good authority that many of the features lacking
+>>>> in NetworkManager (such as bridging configuration) will be
+>>>> available in the not too distant future and many other more
+>>>> advanced networking features such as fast-start DHCP,
+>>>> per-interface DNS, 4-8's DNS fallback and several other nice
+>>>> features will ultimately be possible too.
+>>> While I don't care about configuration wizards, I do about
+>>> initscripts. How are you supposed to configure a server in some
+>>> automated manner without plain-old configuration files ?
+>> If i'm not wrong you can still drop plain text files in 
+>> /etc/NetworkManager/system-connections/
+> 
+> Provided you want to do nothing fancy like bridge, vlan and 
+> others stuff that are used by sysadmins. 
+
+As I said in my initial email, but was not clear. All of these things
+will be supported in a much nicer way in the near future.
+
+But yes, Fedora will switch and we can follow, but it would be nice to
+be at the fore front here if possible.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007442.html b/zarb-ml/mageia-dev/2011-August/007442.html new file mode 100644 index 000000000..509b9372d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007442.html @@ -0,0 +1,159 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 10:47:18 CEST 2011 +

+
+ +
'Twas brillig, and Maarten Vanraes at 22/08/11 22:39 did gyre and gimble:
+> imho, the tools that are now available don't really work well together, ie: if 
+> you use multiple of those tools, likely they don't show correct status, etc...
+
+So combining home-grown solutions with those integrated into the DEs
+(both GNOME and KDE are integrating with NM in a more complete way these
+days) is a way to solve this problem? I don't think so personally. I
+think we should very much embrace what the common consensus on other
+distros is and stop living in a little bubble. I appreciate the quality
+of the tools developed in the past but without someone really pushing
+them they are just going to stagnate. It's a real shame as these tools
+were best of bread - really easy to use and looked good, but this has
+changed now. NM is much nicer to use these days and has been properly
+integrated into the DEs.
+
+> personally, i've used net_applet always and i would like to keep this.
+
+Sure, if it's patched to integrate into GNOME shell as nicely as NM then
+I'd say it's an option. If it provides the same DBus interfaces that NM
+does (or will) support such that applications can tell what type of
+connection you are on (i.e. to enable features such as not downloading
+package updates on your expensive, metered 3G connection) then it's
+certainly possible to continue to support an alternative to NM. Who is
+actually going to do that work tho'? Considering the bug about breaking
+your wifi configuration (using WEP rather than the configured WPA2) has
+not been fixed[1] since before mga1 was out, I'm not confident that
+anyone is even looking into the actual bugs here let alone adding new
+features. I feel we have to be some what practical about resources here
+and if we are going to work on features do it in a way that benefits the
+wider community - i.e. by contributing to NM, not just playing catch up.
+
+
+
+Col
+
+1. https://bugs.mageia.org/show_bug.cgi?id=1263 I had to manually edit
+wpa_supplicant.conf several times when at the Desktop Summit and WLAN
+hopping after using the GUI - it's not exactly a shining example of good
+integration.
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007443.html b/zarb-ml/mageia-dev/2011-August/007443.html new file mode 100644 index 000000000..97893bd1e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007443.html @@ -0,0 +1,187 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 10:55:07 CEST 2011 +

+
+ +
'Twas brillig, and Thierry Vignaud at 22/08/11 13:32 did gyre and gimble:
+> On 22 August 2011 11:57, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>> This is just a heads up to suggest that we officially adopt a policy of
+>> moving to NetworkManager after systemd becomes our default (and likely
+>> only) init system - i.e. likely for mga3.
+>>
+>> As you may know, GNOME is moving towards a systemd user session and
+>> systemd itself is very much aligning itself to be the one true init
+>> system on linux.
+>>
+>> I also have it on good authority that many of the features lacking in
+>> NetworkManager (such as bridging configuration) will be available in the
+>> not too distant future and many other more advanced networking features
+>> such as fast-start DHCP, per-interface DNS, 4-8's DNS fallback and
+>> several other nice features will ultimately be possible too.
+>>
+>> So with all this in mind, I think the writing is very much on the wall
+>> with regards to the future integration of NetworkManager into the
+>> desktop. I believe we will be able to concentrate our resources better
+>> by going along with the rest of the world in this regard. I have
+>> personally switched to it now (as I do not need advanced features of
+>> draknetcenter et al) as a step towards this.
+> 
+> err... drakx-net's code is heavily used by other tools such as:
+> - drakx-installer
+> - mgaonline
+> - ...
+> 
+> So I think we still want to keep drakx-net
+
+Perhaps, but then a more interesting question is "what bits of drakx-net
+are used in mgaonline and drax-installer?" Just stating that they are
+used there as a reason to keep it isn't really a good argument IMO.
+
+Asbestos is used in fire retardant wall insulation, but it's not a good
+argument to keep it considering the world has moved on and we now know
+the dangers of working with that material.
+
+
+So what does mgaonline need to work with drakx-net? Does it just need to
+know if you are online or not? If so why not use NM's dbus service to do
+that? It could eventually know whether you are on a paid/metered
+connection (this is not yet supported by NM but there has been some talk
+about it) or a "free" connection - a fast vs. slow connection etc. It
+could make intelligent, informed decisions, not just "is the user online
+- no matter how crappily?"
+
+Then of course the wider question... should mgaonline be deprecated in
+favour of more integrated options suck as package-kit? Should we focus
+resources on that? This is IMO a more open question, even if I do feel
+the writing is ultimately on the wall here too.
+
+I'd very much like to use much more standard things. I think some of the
+mdv tools were differentiators in the past but those days are pretty
+much slipping by. Some of the tools are still best of bread, but things
+like network management and handling updates etc. is perhaps something
+that has no progressed to the stage that us having independent update
+mechanisms is a hindrance to users rather than a benefit.
+
+It's all too easy to get stuck in a rut and get emotionally attached to
+such things (I do it all the time in my day job) but sometimes it helps
+to look at things from a slightly detached view point.
+
+Cheers
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007444.html b/zarb-ml/mageia-dev/2011-August/007444.html new file mode 100644 index 000000000..192ce3b51 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007444.html @@ -0,0 +1,129 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 23 11:10:25 CEST 2011 +

+
+ +
Le mardi 23 août 2011 à 09:30 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble:
+> > On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote:
+> >> Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+> >>> On 22/08/2011 11:57, Colin Guthrie wrote:
+> >>>> I also have it on good authority that many of the features lacking
+> >>>> in NetworkManager (such as bridging configuration) will be
+> >>>> available in the not too distant future and many other more
+> >>>> advanced networking features such as fast-start DHCP,
+> >>>> per-interface DNS, 4-8's DNS fallback and several other nice
+> >>>> features will ultimately be possible too.
+> >>> While I don't care about configuration wizards, I do about
+> >>> initscripts. How are you supposed to configure a server in some
+> >>> automated manner without plain-old configuration files ?
+> >> If i'm not wrong you can still drop plain text files in 
+> >> /etc/NetworkManager/system-connections/
+> > 
+> > Provided you want to do nothing fancy like bridge, vlan and 
+> > others stuff that are used by sysadmins. 
+> 
+> As I said in my initial email, but was not clear. All of these things
+> will be supported in a much nicer way in the near future.
+
+But so far, this is not supported. And since we have said we do not
+remove non systemd from Mageia 2
+( https://www.mageia.org/pipermail/mageia-dev/2011-July/006701.html ) ,
+I think we cannot take systemd for granted before mageia 3. 
+
+And precisely, because we are not gonna keep only systemd for mageia 2,
+we cannot depreciate network script.
+
+> But yes, Fedora will switch and we can follow, but it would be nice to
+> be at the fore front here if possible.
+
+Would we have too much ressources, maybe. But so far, there is already
+enough work on http://check.mageia.org/ to keep people busy, and I do
+not really see the need to add more breakage and shiny stuff when we are
+far from being able to take care of what we already have.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007445.html b/zarb-ml/mageia-dev/2011-August/007445.html new file mode 100644 index 000000000..62f5f4676 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007445.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 23 11:33:50 CEST 2011 +

+
+ +
On 23/08/2011 10:30, Colin Guthrie wrote:
+> 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble:
+>> On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote:
+>>> Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+>>>> On 22/08/2011 11:57, Colin Guthrie wrote:
+>>>>> I also have it on good authority that many of the features lacking
+>>>>> in NetworkManager (such as bridging configuration) will be
+>>>>> available in the not too distant future and many other more
+>>>>> advanced networking features such as fast-start DHCP,
+>>>>> per-interface DNS, 4-8's DNS fallback and several other nice
+>>>>> features will ultimately be possible too.
+>>>> While I don't care about configuration wizards, I do about
+>>>> initscripts. How are you supposed to configure a server in some
+>>>> automated manner without plain-old configuration files ?
+>>> If i'm not wrong you can still drop plain text files in
+>>> /etc/NetworkManager/system-connections/
+>>
+>> Provided you want to do nothing fancy like bridge, vlan and
+>> others stuff that are used by sysadmins.
+>
+> As I said in my initial email, but was not clear. All of these things
+> will be supported in a much nicer way in the near future.
+Well, even if supported, I do feel much more confident in shell scripts 
+I can read, understand and easily fix if needed to fit my own needs, 
+than in a native binary.
+
+How would removing initscripts support helps enhancing networkmanager 
+integration ?
+-- 
+BOFH excuse #208:
+
+Your mail is being routed through Germany ... and they're censoring us.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007446.html b/zarb-ml/mageia-dev/2011-August/007446.html new file mode 100644 index 000000000..02358b36d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007446.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Aug 23 11:37:14 CEST 2011 +

+
+ +
On Tue, 23 Aug 2011, Guillaume Rousse wrote:
+
+> On 22/08/2011 15:59, Thierry Vignaud wrote:
+>> btw as the config file was tagged as config(noreplace), upgrade breaks until one
+>> fix his config file.
+>> not that a big deal but that should be warned, or config(noreplace) should be
+>> replaced by config()
+> One could expect than packagers know how configuration files are managed, 
+> and there is no point in circumventing usual packaging policy here 'just to 
+> help'.
+
+And what is the "usual packaging policy" ?
+
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007447.html b/zarb-ml/mageia-dev/2011-August/007447.html new file mode 100644 index 000000000..72935f333 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007447.html @@ -0,0 +1,151 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 12:01:56 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 23/08/11 10:10 did gyre and gimble:
+> Le mardi 23 août 2011 à 09:30 +0100, Colin Guthrie a écrit :
+>> 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble:
+>>> On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote:
+>>>> Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+>>>>> On 22/08/2011 11:57, Colin Guthrie wrote:
+>>>>>> I also have it on good authority that many of the features lacking
+>>>>>> in NetworkManager (such as bridging configuration) will be
+>>>>>> available in the not too distant future and many other more
+>>>>>> advanced networking features such as fast-start DHCP,
+>>>>>> per-interface DNS, 4-8's DNS fallback and several other nice
+>>>>>> features will ultimately be possible too.
+>>>>> While I don't care about configuration wizards, I do about
+>>>>> initscripts. How are you supposed to configure a server in some
+>>>>> automated manner without plain-old configuration files ?
+>>>> If i'm not wrong you can still drop plain text files in 
+>>>> /etc/NetworkManager/system-connections/
+>>>
+>>> Provided you want to do nothing fancy like bridge, vlan and 
+>>> others stuff that are used by sysadmins. 
+>>
+>> As I said in my initial email, but was not clear. All of these things
+>> will be supported in a much nicer way in the near future.
+> 
+> But so far, this is not supported. And since we have said we do not
+> remove non systemd from Mageia 2
+> ( https://www.mageia.org/pipermail/mageia-dev/2011-July/006701.html ) ,
+> I think we cannot take systemd for granted before mageia 3. 
+
+Yup, that's why I mentioned mageia 3 in my initial mail.
+
+> And precisely, because we are not gonna keep only systemd for mageia 2,
+> we cannot depreciate network script.
+
+Oh yeah, I'm not proposing any of this for mga2...
+
+>> But yes, Fedora will switch and we can follow, but it would be nice to
+>> be at the fore front here if possible.
+> 
+> Would we have too much ressources, maybe. But so far, there is already
+> enough work on http://check.mageia.org/ to keep people busy, and I do
+> not really see the need to add more breakage and shiny stuff when we are
+> far from being able to take care of what we already have.
+
+Well, fixing the existing stuff or switching to new shiney things with
+no doubt (different) breakages, is much of a muchness IMO. Sure it does
+take some initial work, but also allows us to get fixes from other
+parties rather than having to fix everything ourselves which is, overall
+a net positive in terms of resources.
+
+Col
+
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007448.html b/zarb-ml/mageia-dev/2011-August/007448.html new file mode 100644 index 000000000..2253f7c59 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007448.html @@ -0,0 +1,165 @@ + + + + [Mageia-dev] %{foo} vs. %foo + + + + + + + + + +

[Mageia-dev] %{foo} vs. %foo

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Aug 23 12:02:30 CEST 2011 +

+
+ +
Am 22.08.2011 01:29, schrieb andre999:
+> D.Morgan a écrit :
+>> On Mon, Aug 22, 2011 at 12:27 AM, Colin Guthrie<mageia at colin.guthr.ie>  wrote:
+>>> 'Twas brillig, and Zé at 21/08/11 23:16 did gyre and gimble:
+>>>> Hi,
+>>>>
+>>>> Theres been a private discussion regarding the macro correct layout, if
+>>>> %{foo} or %foo.
+>>>>
+>>>> This rised when in the wiki
+>>>> page http://mageia.org/wiki/doku.php?id=kde4_packaging_policy i changed
+>>>> the spec layout from %foo into %{foo} to be as a reference point, in
+>>>> wich mikala has reverted back to %foo, and this discussion has taken
+>>>> other porportions so i would like your opinions regarding this.
+>>>>
+>>>> I have pointed that for a wiki page should be proper to use %{...} to
+>>>> avoid doubts specially in beginners minds, since in some situations we
+>>>> need really to use the {} delimitations.
+>>>> In wich its recommendation its focused in this cute PDF from redhat website:
+>>>>
+>>>> http://www.redhat.com/promo/summit/2008/downloads/pdf/Wednesday_130pm_Tom_Callaway_OSS.pdf 
+>>>>
+>>>>
+>>>> Im not refering that now we should use only %{...}, that usage can be
+>>>> handled from the user prespective (for example in my specs locally i
+>>>> generally dont use delimitations), some like others dont.
+>>>>
+>>>> As we also see in rpm macros
+>>>> document http://www.rpm.org/wiki/PackagerDocs/Macros that we can use
+>>>> both, but in all rpm docs and config files the common usage its with
+>>>> delimitations.
+>>>
+>>> FWIW, personally I tend to use delimiters also.
+>>>
+>>> I prefer it as it feels more like strict typing.... I know it's not but
+>>> I always like to make things totally and unequivocally explicit all the
+>>> same.
+>>>
+>>> I tend to do this in my bash scripts and even in PHP scripts too (tho'
+>>> annoyingly the PHP delimiters go outside of the variable identifier
+>>> unlike in RPM macros and bash, so it's syntactically a little different
+>>> but the same principles apply).
+>>>
+>>> Cheers
+>>>
+>>
+>> Me, i use both ( this depend if the rpm i work in had it or not ) but
+>> for new rpm i use %foo.
+>>
+>> But i don't see a need to add a policy for %{foo} against %foo.
+>>
+>> I don't understand Ze mail, he ask to use %{foo} and imposed it by
+>> changing in a spec file stating "  i changed the spec layout from %foo
+>> into %{foo} to be as a reference point, " and then in the same mail i
+>> read "for example in my specs locally i generally dont use
+>> delimitations".
+>>
+>> why this mail if you personnaly don't really care about the question ?
+>> just because mikala wasn't agree with you ?
+>>
+>> P.S: yeah i started to have enough now... ( too )
+>>
+> being still officially an apprentice, I've been told to use %{...}, but don't 
+> see a problem with omitting where it's not necessary.
+> For existing specs, I don't see a big need to change things.
+> As long as it's there where it's really needed.
+> Let's go with the flow, it's not like it is something that is visible outside 
+> the spec file.
+>
+> It would be nice to have it clearly documented as to when it is strictly 
+> necessary -- and why.  As well as giving a preferred style, if any.
+> (If that hasn't already been done, of course.)
+>
+> My 2 cents :)
+Actually, what about the "System Macros vs. User-Definable Macros"
+section in http://www.mageia.org/wiki/doku.php?id=spec_syntax ?
+I don't get this whole discussion, as it seems to be defined really clear, no?
+
+But also i'd like to see SPECIFIC cases, where curly braces must be used,
+and for what exact reason. Argumenting "should be used, looks better" or
+"should not be used, i was told" is not the right way, seems to me.
+
+Regards
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007449.html b/zarb-ml/mageia-dev/2011-August/007449.html new file mode 100644 index 000000000..71d975695 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007449.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 12:26:25 CEST 2011 +

+
+ +
'Twas brillig, and Guillaume Rousse at 23/08/11 10:33 did gyre and gimble:
+> On 23/08/2011 10:30, Colin Guthrie wrote:
+>> 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble:
+>>> On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote:
+>>>> Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+>>>>> On 22/08/2011 11:57, Colin Guthrie wrote:
+>>>>>> I also have it on good authority that many of the features lacking
+>>>>>> in NetworkManager (such as bridging configuration) will be
+>>>>>> available in the not too distant future and many other more
+>>>>>> advanced networking features such as fast-start DHCP,
+>>>>>> per-interface DNS, 4-8's DNS fallback and several other nice
+>>>>>> features will ultimately be possible too.
+>>>>> While I don't care about configuration wizards, I do about
+>>>>> initscripts. How are you supposed to configure a server in some
+>>>>> automated manner without plain-old configuration files ?
+>>>> If i'm not wrong you can still drop plain text files in
+>>>> /etc/NetworkManager/system-connections/
+>>>
+>>> Provided you want to do nothing fancy like bridge, vlan and
+>>> others stuff that are used by sysadmins.
+>>
+>> As I said in my initial email, but was not clear. All of these things
+>> will be supported in a much nicer way in the near future.
+
+
+> Well, even if supported, I do feel much more confident in shell scripts
+>
+> I can read, understand and easily fix if needed to fit my own needs,
+> than in a native binary.
+
+This is a endless argument but one which will ultimately not be
+sustainable I fear. I do sympathise, but by the same token, I also want
+a modern, fast and efficient system too, so I'm kinda torn. I understand
+C code pretty well generally and while I can't just "less" the program
+on my machine it's not too hard to get the source code and pick through
+it when I need to (which is very rarely in reality) so I think both my
+need for curiosity is satisfied and while I accept the "on-site
+hackability" does get negatively impacted, the larger number of users
+using a standard system should result in less problems overall and thus
+less need to hack in the first place... this won't always be true, but
+I'm happy with that trade off.
+
+> How would removing initscripts support helps enhancing networkmanager
+> integration ?
+
+Because the current philosophy of the Unix legacy is lots of individual
+utils from various packages cobbled together with some glue shell
+scripting code... and it's dying.
+
+The things that these individual tools implement are a few relatively
+simply commands to the kernel and it doesn't make sense to do all this
+in shell. It makes much more sense to do all these jobs in efficient
+code that runs *quickly* without forking hundreds of times. The code is
+still perfectly visible and easily hackable, but now things are much
+more robust and efficient.
+
+It's also the case that people *talk* about doing stuff lots, but very
+rarely actually *do* it. People have talked about tidying up the init
+system for years, and they've talked about improving the networking
+support for years but these just go in circles and never really result
+in real progress. For the first time in a long time, things are actually
+being *done* about this and in doing so we can take advantage of a lot
+of the modern features of Linux. It's exciting and it means that the
+support in the GUI frontends for network management become much more
+standardised and less varying over different distros. The fact that
+distros all tweak things and do "homebrew" for network management means
+that for tools like network manager to support all distros they have to
+do a whole bunch of weird shit to work on RH vs Mandrvia. vs Suse, vs
+Ubuntu etc. etc. By ripping out the cruft and replacing it with standard
+binaries, you get consistency at the expense of the all the variations
+but IMO this is a good thing - everyone benefits from a larger community
+working on the same thing - more eyes, less bugs, more features.
+
+So, removing the variations in different distros init methods and
+network management tools, is very clearly enabling better network
+manager integration.
+
+Hope that explains it a bit (tho' I'm typing quickly because I'm "at
+work", so sorry if it doesn't read super clearly!)
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007450.html b/zarb-ml/mageia-dev/2011-August/007450.html new file mode 100644 index 000000000..ef1e9db24 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007450.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] New version of mgarepo + + + + + + + + + +

[Mageia-dev] New version of mgarepo

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 23 13:14:27 CEST 2011 +

+
+ +
On 23/08/2011 11:37, nicolas vigier wrote:
+> On Tue, 23 Aug 2011, Guillaume Rousse wrote:
+>
+>> On 22/08/2011 15:59, Thierry Vignaud wrote:
+>>> btw as the config file was tagged as config(noreplace), upgrade breaks until one
+>>> fix his config file.
+>>> not that a big deal but that should be warned, or config(noreplace) should be
+>>> replaced by config()
+>> One could expect than packagers know how configuration files are managed,
+>> and there is no point in circumventing usual packaging policy here 'just to
+>> help'.
+>
+> And what is the "usual packaging policy" ?
+config(noreplace)
+
+-- 
+BOFH excuse #113:
+
+Root nameservers are out of sync
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007451.html b/zarb-ml/mageia-dev/2011-August/007451.html new file mode 100644 index 000000000..d820fe7e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007451.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 23 13:16:32 CEST 2011 +

+
+ +
On 23/08/2011 12:26, Colin Guthrie wrote:
+>> How would removing initscripts support helps enhancing networkmanager
+>> integration ?
+>
+> Because the current philosophy of the Unix legacy is lots of individual
+> utils from various packages cobbled together with some glue shell
+> scripting code... and it's dying.
+>
+> The things that these individual tools implement are a few relatively
+> simply commands to the kernel and it doesn't make sense to do all this
+> in shell. It makes much more sense to do all these jobs in efficient
+> code that runs *quickly* without forking hundreds of times. The code is
+> still perfectly visible and easily hackable, but now things are much
+> more robust and efficient.
+Booting faster makes sense on desktops, not on servers. My general 
+impression in this new trend (systemd, networkmanager, etc...) is the 
+need to compete with proprietary system (macos, windows) on end-user 
+segment, at the cost of genericity and simplicity.
+-- 
+BOFH excuse #104:
+
+backup tape overwritten with copy of system manager's favourite CD
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007452.html b/zarb-ml/mageia-dev/2011-August/007452.html new file mode 100644 index 000000000..ca8c8e2aa --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007452.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 15:28:36 CEST 2011 +

+
+ +
On 23 August 2011 13:16, Guillaume Rousse <guillomovitch at gmail.com> wrote:
+>> The things that these individual tools implement are a few relatively
+>> simply commands to the kernel and it doesn't make sense to do all this
+>> in shell. It makes much more sense to do all these jobs in efficient
+>> code that runs *quickly* without forking hundreds of times. The code is
+>> still perfectly visible and easily hackable, but now things are much
+>> more robust and efficient.
+>
+> Booting faster makes sense on desktops, not on servers. My general
+> impression in this new trend (systemd, networkmanager, etc...) is the need
+> to compete with proprietary system (macos, windows) on end-user segment, at
+> the cost of genericity and simplicity.
+
+Indeed.
+What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to
+setup the machine is worthless.
+On the server side, we still manage RHEL networking through old style
+ifcfg* config files
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007453.html b/zarb-ml/mageia-dev/2011-August/007453.html new file mode 100644 index 000000000..72c515c2e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007453.html @@ -0,0 +1,163 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 15:30:45 CEST 2011 +

+
+ +
'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble:
+> On 23/08/2011 12:26, Colin Guthrie wrote:
+>>> How would removing initscripts support helps enhancing networkmanager
+>>> integration ?
+>>
+>> Because the current philosophy of the Unix legacy is lots of individual
+>> utils from various packages cobbled together with some glue shell
+>> scripting code... and it's dying.
+>>
+>> The things that these individual tools implement are a few relatively
+>> simply commands to the kernel and it doesn't make sense to do all this
+>> in shell. It makes much more sense to do all these jobs in efficient
+>> code that runs *quickly* without forking hundreds of times. The code is
+>> still perfectly visible and easily hackable, but now things are much
+>> more robust and efficient.
+>
+> Booting faster makes sense on desktops, not on servers.
+
+Agreed, but on servers additional capabilities are added that I very
+much care about (much more than I care about boot speed on my laptop if
+I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who
+cares about that!). I'm actually much more excited about systemd on the
+server than I am on a desktop.
+
+The cgroup management and the ability to restart network services
+without losing a single connection is a revelation for me. I will no
+longer worry about restarting apache because it might mess up a
+webservice request or similar. And if I get rooted and find rogue
+processes running, I'll be able to know exactly what service actually
+started that process which is incredibly useful when dealing with the
+mess left by intrusions.
+
+> My general
+> impression in this new trend (systemd, networkmanager, etc...) is the
+> need to compete with proprietary system (macos, windows) on end-user
+> segment, at the cost of genericity and simplicity.
+
+I think the simplicity argument is bogus. You are (IMO) confusing
+simplicity with ease of readability. Sure you can read through a script,
+but the process of starting and maintaining services now becomes
+*standard*. I don't have to read scripts for every single one of the
+1000s of init'ed services, I just need to understand the process of
+services management in general and I can pretty much work with
+everything. When you appreciate that, you'll see that systemd makes
+things much simpler overall. Sure you can't read a script, but that, in
+itself, has nothing to do with simplicity. Individual scripts tweaking
+certain things and adding secret arguments and such like is far, far
+more complex than a unified and defined way of working.
+
+And yes, if we're honest, MacOS has a far superior boot system in
+launchd and the networking support is also better with it's fast-start
+DHCP and other such nice things.
+
+I'm not suggesting network manager on servers here FWIW, but I think
+your reluctance to change should be massively outweighed by the benefits
+these changes bring, both to the server platform and to desktop systems.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007454.html b/zarb-ml/mageia-dev/2011-August/007454.html new file mode 100644 index 000000000..9c32a4955 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007454.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 15:34:19 CEST 2011 +

+
+ +
On 23 August 2011 10:55, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>> err... drakx-net's code is heavily used by other tools such as:
+>> - drakx-installer
+>> - mgaonline
+>> - ...
+>>
+>> So I think we still want to keep drakx-net
+>
+> Perhaps, but then a more interesting question is "what bits of drakx-net
+> are used in mgaonline and drax-installer?" Just stating that they are
+> used there as a reason to keep it isn't really a good argument IMO.
+
+drakx-installer uses most of interesting bits of drakx-net (ake network
+detection & set up, ...)
+
+> Asbestos is used in fire retardant wall insulation, but it's not a good
+> argument to keep it considering the world has moved on and we now know
+> the dangers of working with that material.
+
+OK, give me the NM patches for the installer :-)
+Seriously, without trolling, we just cannot drop drakx-net until we got
+something else for the installer.
+Dunno what does anaconda these days btw?
+
+> So what does mgaonline need to work with drakx-net? Does it just need to
+> know if you are online or not? If so why not use NM's dbus service to do
+> that? It could eventually know whether you are on a paid/metered
+> connection (this is not yet supported by NM but there has been some talk
+> about it) or a "free" connection - a fast vs. slow connection etc. It
+> could make intelligent, informed decisions, not just "is the user online
+> - no matter how crappily?"
+
+mgaonline has less needs, basically detecting network connectivity
+but those are shared with the installer, so even if the lower level
+part would change, there's no readon not to have a common perl
+layer hiding the low level bits instead of making both interfaces NM
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007455.html b/zarb-ml/mageia-dev/2011-August/007455.html new file mode 100644 index 000000000..e8cd94f54 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007455.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 15:37:03 CEST 2011 +

+
+ +
'Twas brillig, and Thierry Vignaud at 23/08/11 14:28 did gyre and gimble:
+> What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to
+> setup the machine is worthless.
+
+Agreed, but I've addressed why other features make systemd a *much* more
+attractive option on the server in my previous reply so I won't repeat
+it here. People suggesting that systemd is purely about boot speed and
+ignoring all the other things mean they've either not researched the
+topic they are discussing or are deliberately using irrelevant
+"benefits" for a given area of discussion to suggest that it doesn't
+help at all in that area. I prefer to talk about things contextually. I
+also don't really care about boot speed on the server, but that's not
+the point.
+
+> On the server side, we still manage RHEL networking through old style
+> ifcfg* config files
+
+I suspect something similar will still be the case even in the near
+future, but said script files will be much simpler and more standard
+(ultimately ini syntax, rather than shell syntax) and the tools that
+interpret those static configurations will also become much simpler (no
+more masses of shell script glueing together a myriad of binaries).
+
+I don't know the full details of how this will look yet, but I am at no
+point suggesting that network manager itself will be used on the server.
+All I'm saying is that things will be changing in both cases.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007456.html b/zarb-ml/mageia-dev/2011-August/007456.html new file mode 100644 index 000000000..f483a69b5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007456.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Thomas Backlund + tmb at mageia.org +
+ Tue Aug 23 15:37:49 CEST 2011 +

+
+ +
Thierry Vignaud skrev 23.8.2011 16:28:
+> On 23 August 2011 13:16, Guillaume Rousse<guillomovitch at gmail.com>  wrote:
+>>> The things that these individual tools implement are a few relatively
+>>> simply commands to the kernel and it doesn't make sense to do all this
+>>> in shell. It makes much more sense to do all these jobs in efficient
+>>> code that runs *quickly* without forking hundreds of times. The code is
+>>> still perfectly visible and easily hackable, but now things are much
+>>> more robust and efficient.
+>>
+>> Booting faster makes sense on desktops, not on servers. My general
+>> impression in this new trend (systemd, networkmanager, etc...) is the need
+>> to compete with proprietary system (macos, windows) on end-user segment, at
+>> the cost of genericity and simplicity.
+>
+> Indeed.
+> What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to
+> setup the machine is worthless.
+
+Heh,
+
+I remember a SGI guy on LKML a while back complaining that it took
+~2 hours to boot one of their _big_ servers (4096 cpus, a few TB RAM).
+
+After a patch that fixed the "bug", it brought the boot time down to 30 
+minutes and he was happy again :)
+
+--
+Thomas
+
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007457.html b/zarb-ml/mageia-dev/2011-August/007457.html new file mode 100644 index 000000000..3b4ff4111 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007457.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 15:40:55 CEST 2011 +

+
+ +
On 23 August 2011 09:34, Guillaume Rousse <guillomovitch at gmail.com> wrote:
+>> I'm talking about a concise programmer's guide, and not something
+>> suitable for end-users. And not something describing the perl language
+>> itself, for which there are plenty of references.
+>
+> That's been asked for for just 10 years now. As long as no one volonteers to
+> do it, it's unlikely to happen.
+
+"code is doc" (c) pixel
+Seriously I'm not against that.
+Most lower level stuff is already documented in MDK::Common.
+But I think it would just be better to open bugs again the proper packages.
+Which one jquelin is reffering to?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007458.html b/zarb-ml/mageia-dev/2011-August/007458.html new file mode 100644 index 000000000..9231aec14 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007458.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 15:42:21 CEST 2011 +

+
+ +
'Twas brillig, and Thomas Backlund at 23/08/11 14:37 did gyre and gimble:
+> Thierry Vignaud skrev 23.8.2011 16:28:
+>> On 23 August 2011 13:16, Guillaume Rousse<guillomovitch at gmail.com> 
+>> wrote:
+>>>> The things that these individual tools implement are a few relatively
+>>>> simply commands to the kernel and it doesn't make sense to do all this
+>>>> in shell. It makes much more sense to do all these jobs in efficient
+>>>> code that runs *quickly* without forking hundreds of times. The code is
+>>>> still perfectly visible and easily hackable, but now things are much
+>>>> more robust and efficient.
+>>>
+>>> Booting faster makes sense on desktops, not on servers. My general
+>>> impression in this new trend (systemd, networkmanager, etc...) is the
+>>> need
+>>> to compete with proprietary system (macos, windows) on end-user
+>>> segment, at
+>>> the cost of genericity and simplicity.
+>>
+>> Indeed.
+>> What's more gaining 20s on a server when the IBM uefi/firmware take
+>> *minutes* to
+>> setup the machine is worthless.
+> 
+> Heh,
+> 
+> I remember a SGI guy on LKML a while back complaining that it took
+> ~2 hours to boot one of their _big_ servers (4096 cpus, a few TB RAM).
+> 
+> After a patch that fixed the "bug", it brought the boot time down to 30
+> minutes and he was happy again :)
+
+
+Wowsers. I bet systemd could get that down to like 29 minutes and 30
+seconds :p
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007459.html b/zarb-ml/mageia-dev/2011-August/007459.html new file mode 100644 index 000000000..a316b65c0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007459.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 15:42:09 CEST 2011 +

+
+ +
On 23 August 2011 15:37, Thomas Backlund <tmb at mageia.org> wrote:
+>> Indeed.
+>> What's more gaining 20s on a server when the IBM uefi/firmware take
+>> *minutes* to
+>> setup the machine is worthless.
+>
+> I remember a SGI guy on LKML a while back complaining that it took
+> ~2 hours to boot one of their _big_ servers (4096 cpus, a few TB RAM).
+>
+> After a patch that fixed the "bug", it brought the boot time down to 30
+> minutes and he was happy again :)
+
+I remember that one :-)
+But no one in the communauty can do anything about IBM's UEFI...
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007460.html b/zarb-ml/mageia-dev/2011-August/007460.html new file mode 100644 index 000000000..beb4f6a3e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007460.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 15:44:37 CEST 2011 +

+
+ +
On 21 August 2011 15:44, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> I do have to wonder why those macros are used... it seems quite trivial
+> to use the actual commands directly and that ultimately increases
+> portability (which maybe isn't a major concern, but all the same)
+>
+> What are the general thoughts on this?
+
+As a 12+ years maintainer of mdv/mdv/mga, I think most spec don't use those.
+They don't bring anything anyway.
+If only, we could standardize on the most usefull macros between distro at first
+(eg %make vs make %{?_smp_mflags})
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007461.html b/zarb-ml/mageia-dev/2011-August/007461.html new file mode 100644 index 000000000..41988c900 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007461.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 23 15:45:31 CEST 2011 +

+
+ +
'Twas brillig, and Thierry Vignaud at 23/08/11 14:34 did gyre and gimble:
+> On 23 August 2011 10:55, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>>> err... drakx-net's code is heavily used by other tools such as:
+>>> - drakx-installer
+>>> - mgaonline
+>>> - ...
+>>>
+>>> So I think we still want to keep drakx-net
+>>
+>> Perhaps, but then a more interesting question is "what bits of drakx-net
+>> are used in mgaonline and drax-installer?" Just stating that they are
+>> used there as a reason to keep it isn't really a good argument IMO.
+> 
+> drakx-installer uses most of interesting bits of drakx-net (ake network
+> detection & set up, ...)
+> 
+>> Asbestos is used in fire retardant wall insulation, but it's not a good
+>> argument to keep it considering the world has moved on and we now know
+>> the dangers of working with that material.
+> 
+> OK, give me the NM patches for the installer :-)
+
+If I get time, I think it would be worth looking at. Obviously (just
+like in one of my replies) I'm far better at *talking* than *doing* too :D
+
+> Seriously, without trolling, we just cannot drop drakx-net until we got
+> something else for the installer.
+> Dunno what does anaconda these days btw?
+
+Not sure. I'll have to take a look at that, but it would be interesting
+to see if it's more integrated into NM now.
+
+>> So what does mgaonline need to work with drakx-net? Does it just need to
+>> know if you are online or not? If so why not use NM's dbus service to do
+>> that? It could eventually know whether you are on a paid/metered
+>> connection (this is not yet supported by NM but there has been some talk
+>> about it) or a "free" connection - a fast vs. slow connection etc. It
+>> could make intelligent, informed decisions, not just "is the user online
+>> - no matter how crappily?"
+> 
+> mgaonline has less needs, basically detecting network connectivity
+> but those are shared with the installer, so even if the lower level
+> part would change, there's no readon not to have a common perl
+> layer hiding the low level bits instead of making both interfaces NM
+
+Agreed. Perhaps my terminology is incorrect here. I'm not against such
+an abstraction layer and even maintaining a if (nm) { new() } else {
+old(); } approach for a release or two depending on need.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007462.html b/zarb-ml/mageia-dev/2011-August/007462.html new file mode 100644 index 000000000..cacf1837c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007462.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Jerome Quelin + jquelin at gmail.com +
+ Tue Aug 23 15:46:44 CEST 2011 +

+
+ +
On 11/08/23 15:40 +0200, Thierry Vignaud wrote:
+> Which one jquelin is reffering to?
+
+none. i'm maintaining perl & perl modules for mageia, but am not a drak*
+contributor.
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007463.html b/zarb-ml/mageia-dev/2011-August/007463.html new file mode 100644 index 000000000..eab6a6e77 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007463.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ grenoya + grenoya at zarb.org +
+ Tue Aug 23 16:23:06 CEST 2011 +

+
+ +
Le 23/08/11 15:44, Thierry Vignaud a écrit :
+> On 21 August 2011 15:44, Colin Guthrie<mageia at colin.guthr.ie>  wrote:
+>> I do have to wonder why those macros are used... it seems quite trivial
+>> to use the actual commands directly and that ultimately increases
+>> portability (which maybe isn't a major concern, but all the same)
+>>
+>> What are the general thoughts on this?
+>
+> As a 12+ years maintainer of mdv/mdv/mga, I think most spec don't use those.
+> They don't bring anything anyway.
+> If only, we could standardize on the most usefull macros between distro at first
+> (eg %make vs make %{?_smp_mflags})
+
+'%foo' commands are wrappers.
+Like '%make' is a wrapper for "make -j4" (parralel compilation on 4 nodes)
+It can be quicker to build with the command, but in some cases (I met 
+some) it brakes the build.
+
+ From my point of view (I am not packager since long) commands are great 
+tools, it eases our work a lot :)
+So I agree with Tv: we should use them every time it is possible. At 
+least the most commons.
+
+
+Claire
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007464.html b/zarb-ml/mageia-dev/2011-August/007464.html new file mode 100644 index 000000000..c055390dc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007464.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 23 16:43:38 CEST 2011 +

+
+ +
Le mardi 23 août 2011 à 16:23 +0200, grenoya a écrit :
+> Le 23/08/11 15:44, Thierry Vignaud a écrit :
+> > On 21 August 2011 15:44, Colin Guthrie<mageia at colin.guthr.ie>  wrote:
+> >> I do have to wonder why those macros are used... it seems quite trivial
+> >> to use the actual commands directly and that ultimately increases
+> >> portability (which maybe isn't a major concern, but all the same)
+> >>
+> >> What are the general thoughts on this?
+> >
+> > As a 12+ years maintainer of mdv/mdv/mga, I think most spec don't use those.
+> > They don't bring anything anyway.
+> > If only, we could standardize on the most usefull macros between distro at first
+> > (eg %make vs make %{?_smp_mflags})
+> 
+> '%foo' commands are wrappers.
+> Like '%make' is a wrapper for "make -j4" (parralel compilation on 4 nodes)
+> It can be quicker to build with the command, but in some cases (I met 
+> some) it brakes the build.
+> 
+>  From my point of view (I am not packager since long) commands are great 
+> tools, it eases our work a lot :)
+> So I agree with Tv: we should use them every time it is possible. At 
+> least the most commons.
+
+the problem is that we are not sure when there is a wrapper, and when
+there is one and it doesn't nothing more, they obscure the fact that rpm
+is just a shell script + metadata.  I think for some people, this look
+like magic :)
+
+So when the macro do something more, yes we need to use it.
+If not, and if we want to follow others distribution, we should take a
+look at their policy 
+
+I found the one of Fedora on
+http://fedoraproject.org/wiki/Packaging:Guidelines#Macros , and
+basically, they say "use rm rather than %{_rm}". 
+
+If someone can find the one of Suse or others, that would help use to
+see if a consensus emerge
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007465.html b/zarb-ml/mageia-dev/2011-August/007465.html new file mode 100644 index 000000000..d45806e71 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007465.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 23 16:54:31 CEST 2011 +

+
+ +
Le mardi 23 août 2011 à 11:01 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and Michael Scherer at 23/08/11 10:10 did gyre and gimble:
+> > Le mardi 23 août 2011 à 09:30 +0100, Colin Guthrie a écrit :
+> >> 'Twas brillig, and Michael scherer at 22/08/11 13:14 did gyre and gimble:
+> >>> On Mon, Aug 22, 2011 at 08:44:01AM -0300, Balcaen John wrote:
+> >>>> Le Monday 22 August 2011 12:57:23 Guillaume Rousse a écrit :
+> >>>>> On 22/08/2011 11:57, Colin Guthrie wrote:
+> >>>>>> I also have it on good authority that many of the features lacking
+> >>>>>> in NetworkManager (such as bridging configuration) will be
+> >>>>>> available in the not too distant future and many other more
+> >>>>>> advanced networking features such as fast-start DHCP,
+> >>>>>> per-interface DNS, 4-8's DNS fallback and several other nice
+> >>>>>> features will ultimately be possible too.
+> >>>>> While I don't care about configuration wizards, I do about
+> >>>>> initscripts. How are you supposed to configure a server in some
+> >>>>> automated manner without plain-old configuration files ?
+> >>>> If i'm not wrong you can still drop plain text files in 
+> >>>> /etc/NetworkManager/system-connections/
+> >>>
+> >>> Provided you want to do nothing fancy like bridge, vlan and 
+> >>> others stuff that are used by sysadmins. 
+> >>
+> >> As I said in my initial email, but was not clear. All of these things
+> >> will be supported in a much nicer way in the near future.
+> > 
+> > But so far, this is not supported. And since we have said we do not
+> > remove non systemd from Mageia 2
+> > ( https://www.mageia.org/pipermail/mageia-dev/2011-July/006701.html ) ,
+> > I think we cannot take systemd for granted before mageia 3. 
+> 
+> Yup, that's why I mentioned mageia 3 in my initial mail.
+
+Oups, I misread :/
+
+Then my answer is "we didn't even released 2, so let's keep discussion
+about 3 for later"
+
+( seriously, it didn't even occurs to me that we would start discussing
+3 right now )
+
+Personnaly, I think that would be good to have something better than
+current initscripts and shell based approach for managing network
+( since we already manage the network with ifplugd, having a daemon is
+not a so big problem, and I am sure we could have a mode where the
+daemon apply the configuration and then disappear, if that make people
+less nervous ). But I would really make sure that people agree with the
+change. I would rather avoid having the same type of discussion than on
+fedora-devel 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007466.html b/zarb-ml/mageia-dev/2011-August/007466.html new file mode 100644 index 000000000..37ef0fb1a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007466.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 23 17:15:44 CEST 2011 +

+
+ +
Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit :
+
+> What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to
+> setup the machine is worthless.
+> On the server side, we still manage RHEL networking through old style
+> ifcfg* config files
+
+Some people do actually use vms, where boot speed could be important if
+created on demand ( and where the reactivity would warrant something
+more than "shell script", and where a better API to get interface
+information wuld be nice ).
+
+We can still have configuration in plain text file ( even if I
+personally think that using shell based configuration is not the best
+way to do that ), so there is some confusion.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007467.html b/zarb-ml/mageia-dev/2011-August/007467.html new file mode 100644 index 000000000..1e4fb7bd8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007467.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Marja van Waes + mvw2011 at xs4all.nl +
+ Tue Aug 23 17:22:12 CEST 2011 +

+
+ +
Op 23-08-11 16:43, Michael Scherer schreef:
+
+>
+> So when the macro do something more, yes we need to use it.
+> If not, and if we want to follow others distribution, we should take a
+> look at their policy
+>
+> I found the one of Fedora on
+> http://fedoraproject.org/wiki/Packaging:Guidelines#Macros , and
+> basically, they say "use rm rather than %{_rm}".
+>
+> If someone can find the one of Suse or others, that would help use to
+> see if a consensus emerge
+>
+Is this: http://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros
+what you're looking for?
+
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007468.html b/zarb-ml/mageia-dev/2011-August/007468.html new file mode 100644 index 000000000..999b9c03e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007468.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 17:34:56 CEST 2011 +

+
+ +
On 23 August 2011 16:43, Michael Scherer <misc at zarb.org> wrote:
+> I found the one of Fedora on
+> http://fedoraproject.org/wiki/Packaging:Guidelines#Macros , and
+> basically, they say "use rm rather than %{_rm}".
+
+And then a mass update commit like the ones I did before enforcing
+new rpmlint checks back @mdv
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007469.html b/zarb-ml/mageia-dev/2011-August/007469.html new file mode 100644 index 000000000..91a4313d2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007469.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 17:49:06 CEST 2011 +

+
+ +
On 23 August 2011 17:15, Michael Scherer <misc at zarb.org> wrote:
+>> What's more gaining 20s on a server when the IBM uefi/firmware take *minutes* to
+>> setup the machine is worthless.
+>> On the server side, we still manage RHEL networking through old style
+>> ifcfg* config files
+>
+> Some people do actually use vms, where boot speed could be important if
+> created on demand ( and where the reactivity would warrant something
+> more than "shell script", and where a better API to get interface
+> information wuld be nice ).
+
+Booting a VM on such servers is nearly instaneous despite still using
+shell scripts for network :-)
+Anyway I do favor migrating to systemd.
+As for NM, if we don't want to maintain both drakx-net & NM, we'll
+have to work.
+I can help, but we'll need someone on the NM side:
+- what parts of NM to integrate into stage2
+- how to integrate drakx-net code with NM
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007470.html b/zarb-ml/mageia-dev/2011-August/007470.html new file mode 100644 index 000000000..1f3df5085 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007470.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 23 17:49:53 CEST 2011 +

+
+ +
On 23 August 2011 15:46, Jerome Quelin <jquelin at gmail.com> wrote:
+> On 11/08/23 15:40 +0200, Thierry Vignaud wrote:
+>> Which one jquelin is reffering to?
+>
+> none. i'm maintaining perl & perl modules for mageia, but am not a drak*
+> contributor.
+
+OK, I was mistaken by "a post by jquelin reminded me of something that
+would be nice to see"
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007471.html b/zarb-ml/mageia-dev/2011-August/007471.html new file mode 100644 index 000000000..293a30637 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007471.html @@ -0,0 +1,140 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Tue Aug 23 19:49:36 CEST 2011 +

+
+ +
Op dinsdag 23 augustus 2011 10:47:18 schreef Colin Guthrie:
+> 'Twas brillig, and Maarten Vanraes at 22/08/11 22:39 did gyre and gimble:
+> > imho, the tools that are now available don't really work well together,
+> > ie: if you use multiple of those tools, likely they don't show correct
+> > status, etc...
+> 
+> So combining home-grown solutions with those integrated into the DEs
+> (both GNOME and KDE are integrating with NM in a more complete way these
+> days) is a way to solve this problem? I don't think so personally. I
+> think we should very much embrace what the common consensus on other
+> distros is and stop living in a little bubble. I appreciate the quality
+> of the tools developed in the past but without someone really pushing
+> them they are just going to stagnate. It's a real shame as these tools
+> were best of bread - really easy to use and looked good, but this has
+> changed now. NM is much nicer to use these days and has been properly
+> integrated into the DEs.
+
+well, imho, the last time i tried NM it didn't work and net_applet did.
+
+> > personally, i've used net_applet always and i would like to keep this.
+> 
+> Sure, if it's patched to integrate into GNOME shell as nicely as NM then
+> I'd say it's an option. If it provides the same DBus interfaces that NM
+> does (or will) support such that applications can tell what type of
+> connection you are on (i.e. to enable features such as not downloading
+> package updates on your expensive, metered 3G connection) then it's
+> certainly possible to continue to support an alternative to NM. Who is
+> actually going to do that work tho'? Considering the bug about breaking
+> your wifi configuration (using WEP rather than the configured WPA2) has
+> not been fixed[1] since before mga1 was out, I'm not confident that
+> anyone is even looking into the actual bugs here let alone adding new
+> features. I feel we have to be some what practical about resources here
+> and if we are going to work on features do it in a way that benefits the
+> wider community - i.e. by contributing to NM, not just playing catch up.
+
+i don't care about gnome shell or gnome 3 or whichever. for me net_applet is 
+the best one yet and i don't have this WPA2 bug that you seem to speak of.
+
+also, i need the openvpn functionalities of the net_applet. as long as NM 
+doesn't provide everything and is welltested, i'm not sure it should replace 
+something that's been very long working like the net_applet.
+
+allthough i'm sure net_applet could be improved, sure.
+
+personally i'd like an applet that shows up multiple times for each connection 
+one with a different icon, so it's nicely visible and you can shut down 
+whichever you want.
+
+> Col
+> 
+> 1. https://bugs.mageia.org/show_bug.cgi?id=1263 I had to manually edit
+> wpa_supplicant.conf several times when at the Desktop Summit and WLAN
+> hopping after using the GUI - it's not exactly a shining example of good
+> integration.
+
+yes, but i'm using several different WPA2 connections, and i configured them 
+once and now if i'm at that particular location, it works... 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007472.html b/zarb-ml/mageia-dev/2011-August/007472.html new file mode 100644 index 000000000..791b15468 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007472.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] [RPM] cauldron core/release gnome-tweak-tool-3.1.0-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release gnome-tweak-tool-3.1.0-2.mga2

+ Balcaen John + mikala at mageia.org +
+ Tue Aug 23 20:50:52 CEST 2011 +

+
+ +
Le Mardi 23 Août 2011 17:10:06 Mageia Team a écrit :
+> Name        : gnome-tweak-tool             Relocations: (not
+> relocatable) Version     : 3.1.0                             Vendor:
+> Mageia.Org Release     : 2.mga2                        Build Date:
+> Tue Aug 23 17:08:37 2011 Install Date: (not installed)              
+> Build Host: jonund Group       : Graphical desktop/GNOME       Source
+> RPM: (none) Size        : 194279                           License:
+> GPLv3 Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://live.gnome.org/GnomeTweakTool
+> Summary     : A tool to customize advanced GNOME 3 options
+> Description :
+> GNOME Tweak Tool is an application for changing the advanced settings
+> of GNOME 3.
+> 
+> Features:
+> * Install and switch gnome-shell themes
+> * Switch GTK+ themes
+> * Switch icon themes
+> * Change
+>   - The user-interface and title bar fonts
+>   - Icons in menus and buttons
+>   - Behavior on laptop lid close
+>   - Shell font size
+>   - File manager desktop icons
+>   - Title bar click action
+>   - Shell clock to show date
+>   - Font hinting
+>   - Font anti-aliasing
+> 
+> fwang <fwang> 3.1.0-2.mga2:
+> + Revision: 134986
+> - br gnome-common
+> - add upstream patch to build with pygobject3
+> - drop invalid category
+> - new version 3.1.0
+
+This package can be installed/upgraded  :
+
+
+requiring python-gi[>= 2.90.2] for gnome-tweak-tool-3.1.0-2.mga2.x86_64                                                                                                                 
+chosen python-gi-2.90.2-1.mga2.x86_64 for python-gi[>= 2.90.2]                                                                                                                          
+selecting python-gi-2.90.2-1.mga2.x86_64                                                                                                                                                
+requiring libpyglib-gi-2.0-python.so.0()
+(64bit),typelib("),typelib("gobject"),typelib("import),typelib(GObject"),typelib(ImportError('When),typelib(Please),typelib(all),typelib(change),typelib(gi),typelib(gobject"),typelib(import),typelib(like),typelib(modules),typelib(must),typelib(not),typelib(occurrences),typelib(of),typelib(raise),typelib(static),typelib(to),typelib(using),typelib(you) 
+for python-gi-2.90.2-1.mga2.x86_64                                                                                                                             
+no packages match typelib(ImportError('When) (it is either in skip.list 
+or already rejected)                                                                                            
+unselecting python-gi-2.90.2-1.mga2.x86_64                                                                                                                                              
+unselecting gnome-tweak-tool-3.1.0-2.mga2.x86_64                                                                                                                                        
+adding a reason to already rejected package python-
+gi-2.90.2-1.mga2.x86_64: unsatisfied typelib(ImportError('When)  
+
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007473.html b/zarb-ml/mageia-dev/2011-August/007473.html new file mode 100644 index 000000000..6f6f9806c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007473.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] Proposals to improve the triage + + + + + + + + + +

[Mageia-dev] Proposals to improve the triage

+ Manuel Hiebel + manuel+ml at hiebel.eu +
+ Tue Aug 23 22:35:53 CEST 2011 +

+
+ +
Hi,
+
+I wrote this mail to discuss what we can do, to make triage more
+efficient. Indeed there is a big part of the bugs that are assigned to
+bugsquad.
+
+The majority of the rpms has not maintenairs.
+For example, to who can we assign installer bug? there is not
+maintainers for drakx-installer-*
+(on bugsquad Thierry told me that he read the bug on the saved search
+https://bugs.mageia.org/userprefs.cgi?tab=saved-searches and that he is
+alone in the team, but so for the component "Installer" in assigned to
+bugsquad)
+The same for Gnome bugs, like nautilus, or other DE (xfce, lxde) and
+package
+Should we add in CC the packager ? 
+
+Some bug can be easily fixed. Like 'Mandriva Linux' in strings of some
+text file, or other. For them, Dmorgan created the tag Junior_Job.
+(https://bugs.mageia.org/describekeywords.cgi) seems similar to easyfix
+by Redhat.I have add a saved the search "Junior_Job", for now there is
+only two bugs, but we can sure other.
+For other we need add missing rpm. dkms-syntek as example for no UVC
+Webcam.
+
+What can we do for reduce the number of Bugs ?
+
+Agressivily assign bugs to latest package uploader?
+I am not sure that all packager (for example: ennael 300rpms or dmorgan
+1000rpms uploaded) can/will work on their rpms's bugs.
+
+Have a list of people who can help in solving some bugs ? Gnome2,
+Gnome3,
+KDE4, XFCE, Drakxtools, Kernel, Web application, Audio, Video card,
+Firmware, etc.
+
+Maybe we can also create an alias for a group of package ? like
+gnome3-maint AT groups.mageia.org, kde-maint, drakx-maint, etc.
+
+We can finally post a mail 10 "bugs" a day. 5 bugs with the choice of
+the id and the priority or a mix with bugs easily solvable and 5 package
+request.
+(or in a smaller proportion and frequency).
+
+Regards,
+-- 
+Manuel Hiebel (leuhmanu)
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007474.html b/zarb-ml/mageia-dev/2011-August/007474.html new file mode 100644 index 000000000..16e79c9cd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007474.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] Proposals to improve the triage + + + + + + + + + +

[Mageia-dev] Proposals to improve the triage

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 23 22:58:16 CEST 2011 +

+
+ +
Le mardi 23 août 2011 à 22:35 +0200, Manuel Hiebel a écrit :
+> Hi,
+> 
+> I wrote this mail to discuss what we can do, to make triage more
+> efficient. Indeed there is a big part of the bugs that are assigned to
+> bugsquad.
+> 
+> The majority of the rpms has not maintenairs.
+> For example, to who can we assign installer bug? there is not
+> maintainers for drakx-installer-*
+
+Then we can assign the package to thierry.
+
+> (on bugsquad Thierry told me that he read the bug on the saved search
+> https://bugs.mageia.org/userprefs.cgi?tab=saved-searches and that he is
+> alone in the team, but so for the component "Installer" in assigned to
+> bugsquad)
+> The same for Gnome bugs, like nautilus, or other DE (xfce, lxde) and
+> package
+> Should we add in CC the packager ? 
+> 
+> Some bug can be easily fixed. Like 'Mandriva Linux' in strings of some
+> text file, or other. For them, Dmorgan created the tag Junior_Job.
+> (https://bugs.mageia.org/describekeywords.cgi) seems similar to easyfix
+> by Redhat.I have add a saved the search "Junior_Job", for now there is
+> only two bugs, but we can sure other.
+> For other we need add missing rpm. dkms-syntek as example for no UVC
+> Webcam.
+> 
+> What can we do for reduce the number of Bugs ?
+
+Try to delete some of them randomly ?
+
+
+> Agressivily assign bugs to latest package uploader?
+> I am not sure that all packager (for example: ennael 300rpms or dmorgan
+> 1000rpms uploaded) can/will work on their rpms's bugs.
+> 
+> Have a list of people who can help in solving some bugs ? Gnome2,
+> Gnome3,
+> KDE4, XFCE, Drakxtools, Kernel, Web application, Audio, Video card,
+> Firmware, etc.
+> 
+> Maybe we can also create an alias for a group of package ? like
+> gnome3-maint AT groups.mageia.org, kde-maint, drakx-maint, etc.
+
+The problem is not really assigning that having people to fix them.
+And if we do not have the information of who maintain a rpm, having a
+alias will not make the information appear by magic :/ 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007475.html b/zarb-ml/mageia-dev/2011-August/007475.html new file mode 100644 index 000000000..99590a944 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007475.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Proposals to improve the triage + + + + + + + + + +

[Mageia-dev] Proposals to improve the triage

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Aug 23 23:40:24 CEST 2011 +

+
+ +
Am 23.08.2011 22:58, schrieb Michael Scherer:
+> Le mardi 23 août 2011 à 22:35 +0200, Manuel Hiebel a écrit :
+>>
+>> What can we do for reduce the number of Bugs ?
+> Try to delete some of them randomly ?
+Yeah, sounds doable, let's go this way
+O_o
+>> We can finally post a mail 10 "bugs" a day. 5 bugs with the choice of
+>> the id and the priority or a mix with bugs easily solvable and 5 package
+>> request.
+>> (or in a smaller proportion and frequency).
+That's actually a really good idea, i like the second proposal.
+5 package requests for the apprentices, and 5 bugs for everyone, or something 
+like that.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007476.html b/zarb-ml/mageia-dev/2011-August/007476.html new file mode 100644 index 000000000..f03632f7d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007476.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 23 23:48:31 CEST 2011 +

+
+ +
On 23/08/2011 17:34, Thierry Vignaud wrote:
+> And then a mass update commit like the ones I did before enforcing
+> new rpmlint checks back @mdv
+Argh, jbj-speak...
+-- 
+BOFH excuse #4:
+
+static from nylon underwear
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007477.html b/zarb-ml/mageia-dev/2011-August/007477.html new file mode 100644 index 000000000..3eea4ac55 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007477.html @@ -0,0 +1,123 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ andre999 + andr55 at laposte.net +
+ Wed Aug 24 08:31:51 CEST 2011 +

+
+ +
Thierry Vignaud a écrit :
+> On 23 August 2011 15:46, Jerome Quelin<jquelin at gmail.com>  wrote:
+>> On 11/08/23 15:40 +0200, Thierry Vignaud wrote:
+>>> Which one jquelin is reffering to?
+>>
+>> none. i'm maintaining perl&  perl modules for mageia, but am not a drak*
+>> contributor.
+>
+> OK, I was mistaken by "a post by jquelin reminded me of something that
+> would be nice to see"
+>
+my fault ... a comment he made about something unrelated reminded me of this idea.
+I've been wanting to contribute to drak* for some time.
+(but readily distracted by other things)
+
+Something like :
+----
+routine: foo(parm1, parm2, ...)
+path: .../{filename}
+purpose: ...
+parm1 = ...
+parm2 = ...
+----
+  for each routine, without any details of internals.
+(Essentially, what does the black box do.)
+The path is useful if more than one function has the same name, as well as 
+examining internals if wanted.
+
+Basically I was thinking of Mageia-specific perl routines.
+I started deciphering rpmdrake back on mdv, and did a cludge to rearrange the 
+main screen, but not being familiar with the invoked routines was a big 
+handicap for doing more.
+You gave me some useful tips at the time.
+
+I could make a script to extract the routine names + paths, but at least one 
+line of comment in the perl code right after the routine name would be very 
+useful.  (It could be just before - but that would be harder to extract.)
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007478.html b/zarb-ml/mageia-dev/2011-August/007478.html new file mode 100644 index 000000000..fc052a816 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007478.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [Mageia-bugsquad] proposals to improve the triage + + + + + + + + + +

[Mageia-dev] [Mageia-bugsquad] proposals to improve the triage

+ D.Morgan + dmorganec at gmail.com +
+ Wed Aug 24 08:51:12 CEST 2011 +

+
+ +
On Tue, Aug 23, 2011 at 6:20 PM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 23 August 2011 17:57, Manuel Hiebel <manuel+ml at hiebel.eu> wrote:
+>>> > What can we do for reduce the number of Bugs ?
+>>> Agressivily assign bugs to latest package uploader?
+>> I am not sure that all packager (for example: ennael 300rpms or dmorgan
+>> 1000rpm uploaded) can work their rpms's bugs.
+>
+> well we could also:
+> - send a mail about the new bugs once a day to mageia-dev
+> - and/or send a summary mail about the easy bugs once a day
+
+we could also do some "bug week triage" asking for help to
+contributors, making testers tests some bugs.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007479.html b/zarb-ml/mageia-dev/2011-August/007479.html new file mode 100644 index 000000000..97869d923 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007479.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] [Mageia-bugsquad] proposals to improve the triage + + + + + + + + + +

[Mageia-dev] [Mageia-bugsquad] proposals to improve the triage

+ Sander Lepik + sander.lepik at eesti.ee +
+ Wed Aug 24 08:58:38 CEST 2011 +

+
+ +
24.08.2011 09:51, D.Morgan kirjutas:
+> On Tue, Aug 23, 2011 at 6:20 PM, Thierry Vignaud
+> <thierry.vignaud at gmail.com>  wrote:
+>> On 23 August 2011 17:57, Manuel Hiebel<manuel+ml at hiebel.eu>  wrote:
+>>>>> What can we do for reduce the number of Bugs ?
+>>>> Agressivily assign bugs to latest package uploader?
+>>> I am not sure that all packager (for example: ennael 300rpms or dmorgan
+>>> 1000rpm uploaded) can work their rpms's bugs.
+>> well we could also:
+>> - send a mail about the new bugs once a day to mageia-dev
+>> - and/or send a summary mail about the easy bugs once a day
+> we could also do some "bug week triage" asking for help to
+> contributors, making testers tests some bugs.
+And we still have a lot of packages that are owned by mysterious nobody :)
+$ mgarepo maintdb get|grep nobody|wc -l
+5113
+
+Maybe packagers should take a look at their packages and if they are 
+still owned by nobody then grab them.
+
+Another problem (at least for me) is that maintainer from maintdb can't 
+be connected to bugzilla user. Should we create some database that 
+connects maintdb account with bugzilla account so that bugs can be assigned?
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007480.html b/zarb-ml/mageia-dev/2011-August/007480.html new file mode 100644 index 000000000..6fd040eac --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007480.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Wed Aug 24 09:07:36 CEST 2011 +

+
+ +
On Tuesday, 23 August 2011 17:15:44 Michael Scherer wrote:
+> Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit :
+> > What's more gaining 20s on a server when the IBM uefi/firmware take
+> > *minutes* to setup the machine is worthless.
+> > On the server side, we still manage RHEL networking through old style
+> > ifcfg* config files
+> 
+> Some people do actually use vms, where boot speed could be important if
+> created on demand ( and where the reactivity would warrant something
+> more than "shell script", and where a better API to get interface
+> information wuld be nice ).
+
+We have netcf in the distribution ...
+
+https://fedorahosted.org/netcf
+
+(required for network configuration from virt-manager).
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007481.html b/zarb-ml/mageia-dev/2011-August/007481.html new file mode 100644 index 000000000..2be8e1f26 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007481.html @@ -0,0 +1,182 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Wed Aug 24 09:19:03 CEST 2011 +

+
+ +
On Tuesday, 23 August 2011 15:30:45 Colin Guthrie wrote:
+> 'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble:
+> > On 23/08/2011 12:26, Colin Guthrie wrote:
+> >>> How would removing initscripts support helps enhancing networkmanager
+> >>> integration ?
+> >> 
+> >> Because the current philosophy of the Unix legacy is lots of individual
+> >> utils from various packages cobbled together with some glue shell
+> >> scripting code... and it's dying.
+> >> 
+> >> The things that these individual tools implement are a few relatively
+> >> simply commands to the kernel and it doesn't make sense to do all this
+> >> in shell. It makes much more sense to do all these jobs in efficient
+> >> code that runs *quickly* without forking hundreds of times. The code is
+> >> still perfectly visible and easily hackable, but now things are much
+> >> more robust and efficient.
+> > 
+> > Booting faster makes sense on desktops, not on servers.
+> 
+> Agreed, but on servers additional capabilities are added that I very
+> much care about (much more than I care about boot speed on my laptop if
+> I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who
+> cares about that!). I'm actually much more excited about systemd on the
+> server than I am on a desktop.
+> 
+> The cgroup management
+
+We don't even have libcgroup or equivalent in the distribution yet ... so I 
+would say is is a bit premature to show this as an advantage IMHO ...
+
+> and the ability to restart network services
+> without losing a single connection is a revelation for me.
+
+Have all the services got support for this yet?
+
+> I will no
+> longer worry about restarting apache because it might mess up a
+> webservice request or similar. And if I get rooted and find rogue
+> processes running, I'll be able to know exactly what service actually
+> started that process which is incredibly useful when dealing with the
+> mess left by intrusions.
+> 
+> > My general
+> > impression in this new trend (systemd, networkmanager, etc...) is the
+> > need to compete with proprietary system (macos, windows) on end-user
+> > segment, at the cost of genericity and simplicity.
+> 
+> I think the simplicity argument is bogus. You are (IMO) confusing
+> simplicity with ease of readability. Sure you can read through a script,
+> but the process of starting and maintaining services now becomes
+> *standard*. I don't have to read scripts for every single one of the
+> 1000s of init'ed services,
+
+I really don't read the scripts for every service, but quite often I do need 
+to adjust some setting catered for in the script, so I read 
+/etc/sysconfig/foo, and adjust it there.
+
+Although I have read a number of the systemd blogs, there are still some 
+unanswered questions. Such as, what should happen to utility functions in the 
+init scripts (e.g. 'service apache configtest' or 'service ldap check'), or 
+other checks that are done in the init script before starting the service 
+(such as ensuring ownership of files by the ldap user, which is a common trap 
+users fall into after doing an import, or re-indexing).
+
+> I just need to understand the process of
+> services management in general and I can pretty much work with
+> everything.
+
+Surely 'service foo {start|stop|restart|reload}' is also a generic approach to 
+services management?
+
+> When you appreciate that, you'll see that systemd makes
+> things much simpler overall. Sure you can't read a script, but that, in
+> itself, has nothing to do with simplicity. Individual scripts tweaking
+> certain things and adding secret arguments and such like is far, far
+> more complex than a unified and defined way of working.
+
+But, sometimes they are required, and what is the replacement for the 
+functionality?
+
+> And yes, if we're honest, MacOS has a far superior boot system in
+> launchd and the networking support is also better with it's fast-start
+> DHCP and other such nice things.
+
+And MacOS has good server market share?
+
+> I'm not suggesting network manager on servers here FWIW, but I think
+> your reluctance to change should be massively outweighed by the benefits
+> these changes bring, both to the server platform and to desktop systems.
+
+The rest of the discussion in this mail by now was about systemd. For 
+NetworkManager, I have some more questions.
+
+At present, a number of my machines have scripts that hook into the network 
+scripts. For example, one to update the bind forwarders from the DNS IPs 
+returned by pppd when the interface comes up. On another machine, a script 
+that unloads the wireless broadband driver when the interface goes down (I 
+think this modem has buggy firmware). Then, there are the existing scripts 
+shipped in the distribution (e.g. to reload squid).
+
+In the NetworkManager world, are all of these taken care of? If not, and I 
+have to script them myself, now I guess I have to hook in to NM via dbus?
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007482.html b/zarb-ml/mageia-dev/2011-August/007482.html new file mode 100644 index 000000000..fae495b02 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007482.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Wed Aug 24 09:24:40 CEST 2011 +

+
+ +
On Wednesday, 24 August 2011 08:31:51 andre999 wrote:
+> Thierry Vignaud a écrit :
+> > On 23 August 2011 15:46, Jerome Quelin<jquelin at gmail.com>  wrote:
+> >> On 11/08/23 15:40 +0200, Thierry Vignaud wrote:
+> >>> Which one jquelin is reffering to?
+> >> 
+> >> none. i'm maintaining perl&  perl modules for mageia, but am not a drak*
+> >> contributor.
+> > 
+> > OK, I was mistaken by "a post by jquelin reminded me of something that
+> > would be nice to see"
+> 
+> my fault ... a comment he made about something unrelated reminded me of
+> this idea. I've been wanting to contribute to drak* for some time.
+> (but readily distracted by other things)
+> 
+> Something like :
+> ----
+> routine: foo(parm1, parm2, ...)
+> path: .../{filename}
+> purpose: ...
+> parm1 = ...
+> parm2 = ...
+> ----
+>   for each routine, without any details of internals.
+> (Essentially, what does the black box do.)
+> The path is useful if more than one function has the same name, as well as
+> examining internals if wanted.
+> 
+> Basically I was thinking of Mageia-specific perl routines.
+> I started deciphering rpmdrake back on mdv, and did a cludge to rearrange
+> the main screen, but not being familiar with the invoked routines was a
+> big handicap for doing more.
+> You gave me some useful tips at the time.
+> 
+> I could make a script to extract the routine names + paths, but at least
+> one line of comment in the perl code right after the routine name would be
+> very useful.  (It could be just before - but that would be harder to
+> extract.)
+
+Please use POD for this, the perldoc tool can extract it, no need to write 
+something to do it. The POD can be interleaved with the code (so it can be 
+both the comment and the documentation).
+
+Of course, it might also be an idea to refactor libDrakX (use a unique 
+namespace etc.).
+
+Regards,
+Buchan
+
+Regards,
+Buchan
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007483.html b/zarb-ml/mageia-dev/2011-August/007483.html new file mode 100644 index 000000000..6c4782dcb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007483.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 24 10:12:42 CEST 2011 +

+
+ +
Le mercredi 24 août 2011 à 09:07 +0200, Buchan Milne a écrit :
+> On Tuesday, 23 August 2011 17:15:44 Michael Scherer wrote:
+> > Le mardi 23 août 2011 à 15:28 +0200, Thierry Vignaud a écrit :
+> > > What's more gaining 20s on a server when the IBM uefi/firmware take
+> > > *minutes* to setup the machine is worthless.
+> > > On the server side, we still manage RHEL networking through old style
+> > > ifcfg* config files
+> > 
+> > Some people do actually use vms, where boot speed could be important if
+> > created on demand ( and where the reactivity would warrant something
+> > more than "shell script", and where a better API to get interface
+> > information wuld be nice ).
+> 
+> We have netcf in the distribution ...
+
+look at who imported it :)
+
+> https://fedorahosted.org/netcf
+> 
+> (required for network configuration from virt-manager).
+
+We also do have augeas, that could help on the same type of problem. 
+
+But none of them react to interface change and while libvirt (for
+example ) can use netcf, there is still cases where it do /proc parsing
+with all the fragility and code duplication it implies ( like in
+networkCheckRouteCollision )
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007484.html b/zarb-ml/mageia-dev/2011-August/007484.html new file mode 100644 index 000000000..c443fb365 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007484.html @@ -0,0 +1,301 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 24 11:46:33 CEST 2011 +

+
+ +
Le mercredi 24 août 2011 à 09:19 +0200, Buchan Milne a écrit :
+> On Tuesday, 23 August 2011 15:30:45 Colin Guthrie wrote:
+> > 'Twas brillig, and Guillaume Rousse at 23/08/11 12:16 did gyre and gimble:
+> > > On 23/08/2011 12:26, Colin Guthrie wrote:
+> > >>> How would removing initscripts support helps enhancing networkmanager
+> > >>> integration ?
+> > >> 
+> > >> Because the current philosophy of the Unix legacy is lots of individual
+> > >> utils from various packages cobbled together with some glue shell
+> > >> scripting code... and it's dying.
+> > >> 
+> > >> The things that these individual tools implement are a few relatively
+> > >> simply commands to the kernel and it doesn't make sense to do all this
+> > >> in shell. It makes much more sense to do all these jobs in efficient
+> > >> code that runs *quickly* without forking hundreds of times. The code is
+> > >> still perfectly visible and easily hackable, but now things are much
+> > >> more robust and efficient.
+> > > 
+> > > Booting faster makes sense on desktops, not on servers.
+> > 
+> > Agreed, but on servers additional capabilities are added that I very
+> > much care about (much more than I care about boot speed on my laptop if
+> > I'm honest - with my SSD I'm looking at a 1 or 2 second boots - who
+> > cares about that!). I'm actually much more excited about systemd on the
+> > server than I am on a desktop.
+> > 
+> > The cgroup management
+> 
+> We don't even have libcgroup or equivalent in the distribution yet ... so I 
+> would say is is a bit premature to show this as an advantage IMHO ...
+
+Well, we now have it :)
+( ok almost, I need to fix the initscript, and also need to check if
+there is nothing to update, like the /cgroup directory ) 
+
+
+> > and the ability to restart network services
+> > without losing a single connection is a revelation for me.
+> 
+> Have all the services got support for this yet?
+
+While I am not sure how it work, if it use the socket activation system,
+only supported services would have it. Fedora/Opensuse is likely pushing
+their patch upstream for that, and I think the goal is to convert as
+much as possible daemon. So I guess it would be ok in the time frame of
+the change ( ie in 1 year or more ) and for the majority of the daemons.
+
+But I think we should check how it work first to see what can support
+it.
+
+> > I think the simplicity argument is bogus. You are (IMO) confusing
+> > simplicity with ease of readability. Sure you can read through a script,
+> > but the process of starting and maintaining services now becomes
+> > *standard*. I don't have to read scripts for every single one of the
+> > 1000s of init'ed services,
+> 
+> I really don't read the scripts for every service, but quite often I do need 
+> to adjust some setting catered for in the script, so I read 
+> /etc/sysconfig/foo, and adjust it there.
+
+If the initscript support it, which is usually far from being uniform.
+Systemd permit to set regular settings more easily, like environment,
+nice level, user, group, chroot, cpu/io/etc scheduling, capability, etc.
+See http://0pointer.de/public/systemd-man/systemd.exec.html
+
+What kind of setting do you need to adjust and that you couldn't from a
+initscript by passing options to the binary or by setting a environment
+interpreted by the daemon ?
+
+> Although I have read a number of the systemd blogs, there are still some 
+> unanswered questions. Such as, what should happen to utility functions in the 
+> init scripts (e.g. 'service apache configtest' or 'service ldap check'), or 
+> other checks that are done in the init script before starting the service 
+> (such as ensuring ownership of files by the ldap user, which is a common trap 
+> users fall into after doing an import, or re-indexing).
+
+While I am not sure of the answer ( I know that people have already
+asked that on fedora ml, but it seems to become a trolling fest on the
+topic from time to time, and it is too depressing for me to read them ),
+there is ExecStartPre= to run arbitrary commands before the main
+command. This can be used to make sure permission are ok.
+
+I am not sure however this help for the case of the check. I guess then
+a wrapper to run the server, and splitting the check in it own binary
+would be enough ? That would still work, due to the usage of cgroup.
+
+I didn't found any information on that, so maybe Colin can answer, or
+then see on the systemd ml.
+
+> > I just need to understand the process of
+> > services management in general and I can pretty much work with
+> > everything.
+> 
+> Surely 'service foo {start|stop|restart|reload}' is also a generic approach to 
+> services management?
+
+When the initscript implement it fully, for a unspecified version of
+"fully". Having to integrate some of them in puppet showed that not
+everybody did ( like some missing restart ), and this caused subtle
+issues requiring customisation, and make our life more difficult than it
+should be as packagers and as sysadmins.
+
+> > When you appreciate that, you'll see that systemd makes
+> > things much simpler overall. Sure you can't read a script, but that, in
+> > itself, has nothing to do with simplicity. Individual scripts tweaking
+> > certain things and adding secret arguments and such like is far, far
+> > more complex than a unified and defined way of working.
+> 
+> But, sometimes they are required, and what is the replacement for the 
+> functionality?
+
+before, you edited /etc/sysconfig/ file to add the argument to a
+environnement variable that was either added to the command line
+directly, or that was checked in shell to add a argument ( with each
+distribution having its own semantic ), or that was directly interpreted
+by the binary .
+
+after, you edit a file similar to a .ini to add the argument to the
+binary, in the line Exec=, or you just add the env var in a file
+dedicated to get environnement ( and that file could even be
+the /etc/sysconfig/ file that you adjusted before ). 
+
+Most case seems covered, do you have a case where this would not work ?
+
+( and in which case we would have to just use the previous initscript as
+we did before )
+
+> > And yes, if we're honest, MacOS has a far superior boot system in
+> > launchd and the networking support is also better with it's fast-start
+> > DHCP and other such nice things.
+> 
+> And MacOS has good server market share?
+
+Market share on server of mac os is irrelevant to the fact it has a
+better boot system.
+
+We cannot say that people used Unix because shell scripts were so good,
+since that's also what OSX used before 10.4. 
+
+Current shell scripts are error prone, take ressources, and requires
+kludge breaking from time to time. While I do not really care about the
+ressources taken by shell script, I am more concerned about the kludge.
+Just on our servers, we faced :
+- bind, that need to sleep before being restarted, that caused several
+outage on our infrastructure due to puppet ( and us ) not knowing this.
+Puppet use by default stop/start to restart a service, since not all
+initscripts have a restart command, and there is no sane way to know if
+it support it ( at least, not a way to would work reliabiliy with some
+vendor provided crappy scripts ).
+ 
+- sympa, that requires postgresql to be up before it can start or it
+block the boot. ( so my vms were not starting, while it worked by chance
+on real hardware ). While the missing requires in unfortunate and would
+not have been avoided by systemd, the fact it block the boot was rather
+more annoying and would likely have worked better ( not sure why pinit
+didn't work as it should :/ )
+
+- puppet, with stupid error like this one :
+https://qa.mandriva.com/show_bug.cgi?id=40414 . By not requiring to
+write code to do that, a init system like systemd reduce the number of
+potential bugs, since there is less line of code. 
+
+Vincent Danen wanted to push runit on mandriva ( and did so on annvix )
+years ago, for features that systemd also offers ( such as automated
+system restarting ). 
+
+So i think there is place and even a need for something better than
+current initscripts.
+
+> > I'm not suggesting network manager on servers here FWIW, but I think
+> > your reluctance to change should be massively outweighed by the benefits
+> > these changes bring, both to the server platform and to desktop systems.
+> 
+> The rest of the discussion in this mail by now was about systemd. For 
+> NetworkManager, I have some more questions.
+> 
+> At present, a number of my machines have scripts that hook into the network 
+> scripts. For example, one to update the bind forwarders from the DNS IPs 
+> returned by pppd when the interface comes up. On another machine, a script 
+> that unloads the wireless broadband driver when the interface goes down (I 
+> think this modem has buggy firmware). Then, there are the existing scripts 
+> shipped in the distribution (e.g. to reload squid).
+> 
+> In the NetworkManager world, are all of these taken care of? If not, and I 
+> have to script them myself, now I guess I have to hook in to NM via dbus?
+
+>From what I see :
+
+$ ls /etc/NetworkManager/dispatcher.d 
+00-netreport  04-iscsi  05-netfs  10-sendmail  11-dhclient
+
+$ cat  /etc/NetworkManager/dispatcher.d/10-sendmail
+#!/bin/sh
+
+case "$2" in
+	up|down|vpn-up|vpn-down)
+		/sbin/service sendmail reload || :
+		;;
+esac
+
+- squid reloading, others scripts
+If the action for most of them is to be reloaded when a interface
+change, this is also already covered by the dispatcher.d directory.
+For the rest, it will depend on what it need, and nothing forbid us from
+adding compatibility scripts for the migration.
+
+
+- wireless broadband unloading
+While there is lots of efforts to support buggy hardware, I am not sure
+that nm does it by default. yet, this would be trivial to do
+with /etc/NetworkManager/dispatcher.d , where script are run each time a
+interface goes up, or down ( or vpn, or when the hostname change )
+
+
+- pppd to update bind resolver
+I think the current dispatcher do not give you the information about
+resolver directly, so you have to parse /etc/resolv.conf for yourself. 
+However, there is a experimental plugin in nm to use and manage bind as
+a local caching resolver, the goal is to make it do dnssec validation (
+http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations )
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007485.html b/zarb-ml/mageia-dev/2011-August/007485.html new file mode 100644 index 000000000..00386025f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007485.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 24 12:24:04 CEST 2011 +

+
+ +
Le mardi 23 août 2011 à 17:22 +0200, Marja van Waes a écrit :
+> Op 23-08-11 16:43, Michael Scherer schreef:
+> 
+> >
+> > So when the macro do something more, yes we need to use it.
+> > If not, and if we want to follow others distribution, we should take a
+> > look at their policy
+> >
+> > I found the one of Fedora on
+> > http://fedoraproject.org/wiki/Packaging:Guidelines#Macros , and
+> > basically, they say "use rm rather than %{_rm}".
+> >
+> > If someone can find the one of Suse or others, that would help use to
+> > see if a consensus emerge
+> >
+> Is this: http://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros
+> what you're looking for?
+> 
+
+Nope, but this is interesting none the less, especialy new ways to
+torture packager^W^W increase quality of the distribution with others
+rpmlint checks :
+http://en.opensuse.org/openSUSE:Packaging_checks#rpmlint_checks_in_openSUSE
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007486.html b/zarb-ml/mageia-dev/2011-August/007486.html new file mode 100644 index 000000000..34e389fb1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007486.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Eugeni Dodonov + eugeni at dodonov.net +
+ Wed Aug 24 13:19:11 CEST 2011 +

+
+ +
On Wed, Aug 24, 2011 at 04:24, Buchan Milne <bgmilne at staff.telkomsa.net>wrote:
+
+> Of course, it might also be an idea to refactor libDrakX (use a unique
+> namespace etc.).
+>
+
+This decade-old task still awaits the lost^w brave souls to take it.... :)
+
+-- 
+Eugeni Dodonov
+http://eugeni.dodonov.net/
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110824/27f48295/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007487.html b/zarb-ml/mageia-dev/2011-August/007487.html new file mode 100644 index 000000000..5f2e920d0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007487.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 24 13:28:36 CEST 2011 +

+
+ +
On 24 August 2011 08:31, andre999 <andr55 at laposte.net> wrote:
+>>>> Which one jquelin is reffering to?
+>>>
+>>> none. i'm maintaining perl&  perl modules for mageia, but am not a drak*
+>>> contributor.
+>>
+>> OK, I was mistaken by "a post by jquelin reminded me of something that
+>> would be nice to see"
+>>
+> my fault ... a comment he made about something unrelated reminded me of this
+> idea.
+> I've been wanting to contribute to drak* for some time.
+> (but readily distracted by other things)
+
+You can start by looking for easy bugs, propose a patch and we'll do peer review
+like we did in the past on the install@ ml (maybe should we set up a
+new one here
+at mga as well as set up perl_checker mails again in order to auto catch bugs)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007488.html b/zarb-ml/mageia-dev/2011-August/007488.html new file mode 100644 index 000000000..173a7df04 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007488.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ D.Morgan + dmorganec at gmail.com +
+ Wed Aug 24 13:32:37 CEST 2011 +

+
+ +
On Wed, Aug 24, 2011 at 1:28 PM, Thierry Vignaud
+<thierry.vignaud at gmail.com> wrote:
+> On 24 August 2011 08:31, andre999 <andr55 at laposte.net> wrote:
+>>>>> Which one jquelin is reffering to?
+>>>>
+>>>> none. i'm maintaining perl&  perl modules for mageia, but am not a drak*
+>>>> contributor.
+>>>
+>>> OK, I was mistaken by "a post by jquelin reminded me of something that
+>>> would be nice to see"
+>>>
+>> my fault ... a comment he made about something unrelated reminded me of this
+>> idea.
+>> I've been wanting to contribute to drak* for some time.
+>> (but readily distracted by other things)
+>
+> You can start by looking for easy bugs, propose a patch and we'll do peer review
+> like we did in the past on the install@ ml (maybe should we set up a
+> new one here
+> at mga as well as set up perl_checker mails again in order to auto catch bugs)
+>
+
+i want my reviewboard. Such a tool is on my loooooooooooooooong todo :)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007489.html b/zarb-ml/mageia-dev/2011-August/007489.html new file mode 100644 index 000000000..af5bc820e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007489.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Wed Aug 24 14:05:57 CEST 2011 +

+
+ +
On 24/08/2011 13:28, Thierry Vignaud wrote:
+> at mga as well as set up perl_checker mails again in order to auto catch bugs)
+perl_checker doesn't catch bugs, but violations to an hard-coded coding 
+style policy, which is quite different...
+-- 
+BOFH excuse #174:
+
+Backbone adjustment
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007490.html b/zarb-ml/mageia-dev/2011-August/007490.html new file mode 100644 index 000000000..b1819c012 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007490.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 24 17:27:16 CEST 2011 +

+
+ +
On 23 August 2011 23:48, Guillaume Rousse <guillomovitch at gmail.com> wrote:
+>> And then a mass update commit like the ones I did before enforcing
+>> new rpmlint checks back @mdv
+>
+> Argh, jbj-speak...
+
+err, vaporware^h^h^h^hsays != say'n do
+
+Unlike jbj, I did fix all spec files before I enabled new rpmling
+checks as blockers
+for the package upload.
+It did improve the quality (eg: no more packages with broken requires due to
+unexpanded macros in require tags, ...)
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007491.html b/zarb-ml/mageia-dev/2011-August/007491.html new file mode 100644 index 000000000..226bd666a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007491.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Suggest summary documentation of Mageia perl routines + + + + + + + + + +

[Mageia-dev] Suggest summary documentation of Mageia perl routines

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 24 17:35:53 CEST 2011 +

+
+ +
On 24 August 2011 14:05, Guillaume Rousse <guillomovitch at gmail.com> wrote:
+>> at mga as well as set up perl_checker mails again in order to auto catch
+>> bugs)
+>
+> perl_checker doesn't catch bugs, but violations to an hard-coded coding
+> style policy, which is quite different...
+
+Please only speak about what you used.
+If you don't believe me, just look at the drakx SVN's log[1], we fixed
+quite a lot bugs
+because of perl_checker:
+- corrupted variable names,
+- too many or not enough (missing) arguments in function calls,
+- ...
+
+We routinely run it before commiting, thus catching small issues
+before releasing them.
+
+It doesn't fix everything but it does save quite a lot of pain.
+
+Latest example is in rpmdrake where new mdv devs upload a plain broken release
+whereas it's now quite a lot more difficult now that I've make
+perl_checker run prior
+to that:
+http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft?view=revision&sortby=date&revision=271213
+http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpmdrake/current/SPECS/rpmdrake.spec?r1=572521&r2=587847
+
+[1] (though we lost one year of changelog due to server issues)
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007492.html b/zarb-ml/mageia-dev/2011-August/007492.html new file mode 100644 index 000000000..988defdb6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007492.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Packagers meeting tonight + + + + + + + + + +

[Mageia-dev] Packagers meeting tonight

+ Anne nicolas + ennael at mageia.org +
+ Wed Aug 24 18:02:28 CEST 2011 +

+
+ +
Hi there
+
+So as planned last week, we will have a meeting tonight at 19h UTC on
+"mageia-dev.
+
+Topics:
+
+- Backports policy to be finalized
+- Packagers charter to improve organization
+- Secteam review
+- Mentoring review
+- Triage team proposals
+
+Cheers !
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007493.html b/zarb-ml/mageia-dev/2011-August/007493.html new file mode 100644 index 000000000..e4420d0b9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007493.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer? + + + + + + + + + +

[Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer?

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Wed Aug 24 22:48:51 CEST 2011 +

+
+ +
I've told it must be here
+-------------- next part --------------
+An embedded message was scrubbed...
+From: Luis Daniel Lucio Quiroz <dlucio at okay.com.mx>
+Subject: [Mageia-discuss] PROPOSAL: so, you are already contributor,
+	do you want to be maintainer?
+Date: Wed, 24 Aug 2011 15:16:25 -0500
+Size: 5446
+URL: </pipermail/mageia-dev/attachments/20110824/34db9215/attachment-0001.mht>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007494.html b/zarb-ml/mageia-dev/2011-August/007494.html new file mode 100644 index 000000000..2e30841bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007494.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 24 23:40:23 CEST 2011 +

+
+ +
Le mercredi 24 août 2011 à 17:27 +0200, Thierry Vignaud a écrit :
+> On 23 August 2011 23:48, Guillaume Rousse <guillomovitch at gmail.com> wrote:
+> >> And then a mass update commit like the ones I did before enforcing
+> >> new rpmlint checks back @mdv
+> >
+> > Argh, jbj-speak...
+> 
+> err, vaporware^h^h^h^hsays != say'n do
+> 
+> Unlike jbj, I did fix all spec files before I enabled new rpmling
+> checks as blockers
+> for the package upload.
+
+that's very nice, I just do send long emails with my super power so
+people do not read it fully and enable the check, and then say "it was
+decided and no one complained, so we enabled it", and let others do the
+work :)
+
+( speaking of which, opensuse has lots of rpmlint modules :
+http://gitorious.org/opensuse/rpmlint-checks/ )
+-- 
+Michael Scherer
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007495.html b/zarb-ml/mageia-dev/2011-August/007495.html new file mode 100644 index 000000000..50f9e3a06 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007495.html @@ -0,0 +1,190 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Aug 25 02:50:20 CEST 2011 +

+
+ +
Hi,
+
+I was told that QA Team's work's visibility needs to be improved, so as a team 
+member I'll try to give you some sort of status report.
+
+QA team currently mainly works on Mageia 1 updates testing and validation. We 
+managed to gather various volunteers, and while we probably need still more 
+volunteers, at least there's already a lot of work being done and updates are 
+being pushed.
+
+
+*** Updates pushed ***
+
+Since the updates media opened, 65 updates have been pushed (in terms of 
+packages, a lot more since an update can contain several packages).
+- June: 9, including nvidia drivers and system-config-printer
+- July: 46, including kernel, sun's java, iptables, flash-player-plugin, 
+kernel, logrotate...
+- August: 25 as of today, including KDE SC 4.6.5, libreoffice, flash-player-
+plugin
+
+The number of real bugfix or security updates is approximatively 3/5 of those, 
+because we also pushed new packages that were present in Mandriva 2010.2 but 
+absent from Mageia 1, as the policy permits (exception for Mageia 1):
+
+There is a mailing list where updates are announced, which is what I used to 
+count the updates for this report. 
+See https://ml.mageia.org/wwsympa-wrapper.fcgi/arc/updates-announce
+
+
+*** Pending updates ***
+
+Right now there are 16 pending update candidates (in fact 18, but I excluded 
+one that is not ready to be tested, and one which is in fact a backport 
+request waiting for the backports media to open). See 
+https://bugs.mageia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=waiting%20for%20QA%20test&sharer_id=22
+
+5 are recent (assigned to QA for less than one week) and being taken care of
+
+The others are less recent (more than one week, sometimes even more than one 
+month) :
+- 7 are waiting for packager input, QA testing having uncovered bugs and/or 
+raised questions
+- 2 have been in need for testing for several weeks, here QA team must wake up 
+:)
+- 1 has been validated by QA one month ago, but was assigned to security team 
+following updates policy for security fixes, and got not answer. We have to 
+improve either the policy or the security team here (or both).
+- 1 is ready to go, we just have to tag it as such and pass it to the 
+sysadmins
+- the last one is firefox: this is probably the longer pending update (started 
+as firefox 5, now is firefox 6), and that with the higher visibility for users. 
+I would like to let dmorgan and those involved in its testing comment about it 
+: what caused such a long delay ? I'm not trying to blame anybody, especially 
+dmorgan who did most (it not all) of the hard work: I'm genuinely curious 
+about the causes of this delay so that we can explain it to our users, to 
+ourselves and above all learn from it.
+
+
+*** Short analysis (my opinion) ***
+
+Most updates passed to QA went fine, quite well tested. There's still a lot to 
+improve in the QA team's work, but right now we kind of manage to handle the 
+update candidates. Updates are probably not as thoroughly tested as we would 
+like to and often we have to trust that the bugs the upstream project claims 
+to have fixed are fixed. But we always try to check that there are no 
+regressions.
+
+What can delay an update is mostly:
+
+- bugs or other problems found during testing. An exchange starts between the 
+packager and the QA team and it can become very long. The above report shows 
+that currently there are more reports waiting for the packager's return than 
+waiting for QA feedback.
+
+- testers not knowing what to test, thus giving their time to other bug 
+reports. We can't know every package as well as the packagers know them. When 
+the packager provides good test cases, it can speed up the process 
+drastically.
+
+- lack of testers (not the majority for the current pending updates). It 
+happens mostly when we need testers with specific configurations or hardware.
+
+Here stops my own analysis, let the rest of the packagers and testers give 
+their views :)
+
+
+*** Need a broader view ***
+
+This report would be more complete with information about current and past 
+open bugs on Mageia 1 (and pending security issues), but this would go farther 
+than the purpose of this QA team report. 
+
+I'll let the triage team give us its report about pending bugs, and someone 
+(stewb ?) tell us about pending security issues.
+
+Best regards
+
+Samuel Verschelde
+ 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007496.html b/zarb-ml/mageia-dev/2011-August/007496.html new file mode 100644 index 000000000..e77cd57ae --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007496.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Aug 25 02:59:00 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 02:50:20, Samuel Verschelde a écrit :
+> Hi,
+> 
+> I was told that QA Team's work's visibility needs to be improved, so as a
+> team member I'll try to give you some sort of status report.
+> 
+> QA team currently mainly works on Mageia 1 updates testing and validation.
+> We managed to gather various volunteers, and while we probably need still
+> more volunteers, at least there's already a lot of work being done and
+> updates are being pushed.
+> 
+> 
+> *** Updates pushed ***
+> 
+> Since the updates media opened, 65 updates have been pushed (in terms of
+> packages, a lot more since an update can contain several packages).
+> - June: 9, including nvidia drivers and system-config-printer
+> - July: 46, including kernel, sun's java, iptables, flash-player-plugin,
+> kernel, logrotate...
+> - August: 25 as of today, including KDE SC 4.6.5, libreoffice,
+> flash-player- plugin
+
+People knowing how to add 3 numbers (ie, not me) would have noticed that there 
+were 80 updates, not 65.
+
+Best regards
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007497.html b/zarb-ml/mageia-dev/2011-August/007497.html new file mode 100644 index 000000000..3fe2e91c3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007497.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Packagers meeting tonight + + + + + + + + + +

[Mageia-dev] Packagers meeting tonight

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Thu Aug 25 07:52:54 CEST 2011 +

+
+ +
Am Mittwoch, 24. August 2011, 18:02:28 schrieb Anne nicolas:
+> Hi there
+> 
+> So as planned last week, we will have a meeting tonight at 19h UTC on
+> "mageia-dev.
+Oups..
+
+Sorry, I forgot. I will read up in the logs.
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007498.html b/zarb-ml/mageia-dev/2011-August/007498.html new file mode 100644 index 000000000..e9a033a92 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007498.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Thu Aug 25 08:50:36 CEST 2011 +

+
+ +
On 24 August 2011 23:40, Michael Scherer <misc at zarb.org> wrote:
+>> >> And then a mass update commit like the ones I did before enforcing
+>> >> new rpmlint checks back @mdv
+>> >
+>> > Argh, jbj-speak...
+>>
+>> err, vaporware^h^h^h^hsays != say'n do
+>>
+>> Unlike jbj, I did fix all spec files before I enabled new rpmlint
+>> checks as blockers
+>> for the package upload.
+>
+> that's very nice, I just do send long emails with my super power so
+> people do not read it fully and enable the check, and then say "it was
+> decided and no one complained, so we enabled it", and let others do the
+> work :)
+
+Err... Sorry I didn't meant to embarrass you, I was just defending against
+the unfair jbj comparison
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007499.html b/zarb-ml/mageia-dev/2011-August/007499.html new file mode 100644 index 000000000..9fbcc4a76 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007499.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Remco Rijnders + remco at webconquest.com +
+ Thu Aug 25 08:56:05 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 08:50:36AM +0200, Thierry wrote in
+<CAONrEtZU98xB4=qVfQtH3wok-Nmj4mHcP7UyrjOFqxcN_RamNA at mail.gmail.com>:
+>On 24 August 2011 23:40, Michael Scherer <misc at zarb.org> wrote:
+>>
+>> that's very nice, I just do send long emails with my super power so
+>> people do not read it fully and enable the check, and then say "it was
+>> decided and no one complained, so we enabled it", and let others do the
+>> work :)
+>
+>Err... Sorry I didn't meant to embarrass you, I was just defending against
+>the unfair jbj comparison
+
+So, isn't Jon Bon Jovi like totally passé?
+
+Remco
+(I guess I don't get the jbj reference)
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110825/53c08991/attachment.asc>
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007500.html b/zarb-ml/mageia-dev/2011-August/007500.html new file mode 100644 index 000000000..c1a19dc03 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007500.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Packagers meeting tonight + + + + + + + + + +

[Mageia-dev] Packagers meeting tonight

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Thu Aug 25 09:01:04 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011 01:52:54 -0400, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+
+> Sorry, I forgot. I will read up in the logs.
+> Oliver
+
+Where?  Due to a real life event, I had to close my
+connection during the meeting.  I haven't been able
+to find the logs of that meeting.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007501.html b/zarb-ml/mageia-dev/2011-August/007501.html new file mode 100644 index 000000000..c5c8ff4aa --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007501.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Packagers meeting tonight + + + + + + + + + +

[Mageia-dev] Packagers meeting tonight

+ Oliver Burger + oliver.bgr at googlemail.com +
+ Thu Aug 25 09:17:58 CEST 2011 +

+
+ +
Am Donnerstag, 25. August 2011, 09:01:04 schrieb David W. Hodgins:
+> On Thu, 25 Aug 2011 01:52:54 -0400, Oliver Burger 
+<oliver.bgr at googlemail.com> wrote:
+> > Sorry, I forgot. I will read up in the logs.
+> > Oliver
+> 
+> Where?  Due to a real life event, I had to close my
+> connection during the meeting.  I haven't been able
+> to find the logs of that meeting.
+> 
+It's at the same place as all the other logs...
+http://meetbot.mageia.org/mageia-dev/2011/
+
+Oliver
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007502.html b/zarb-ml/mageia-dev/2011-August/007502.html new file mode 100644 index 000000000..428643da6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007502.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Michael Scherer + misc at zarb.org +
+ Thu Aug 25 09:18:06 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 à 08:50 +0200, Thierry Vignaud a écrit :
+> On 24 August 2011 23:40, Michael Scherer <misc at zarb.org> wrote:
+> >> >> And then a mass update commit like the ones I did before enforcing
+> >> >> new rpmlint checks back @mdv
+> >> >
+> >> > Argh, jbj-speak...
+> >>
+> >> err, vaporware^h^h^h^hsays != say'n do
+> >>
+> >> Unlike jbj, I did fix all spec files before I enabled new rpmlint
+> >> checks as blockers
+> >> for the package upload.
+> >
+> > that's very nice, I just do send long emails with my super power so
+> > people do not read it fully and enable the check, and then say "it was
+> > decided and no one complained, so we enabled it", and let others do the
+> > work :)
+> 
+> Err... Sorry I didn't meant to embarrass you, I was just defending against
+> the unfair jbj comparison
+
+I was not embarassed, I just share my method for more efficiency :)
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007503.html b/zarb-ml/mageia-dev/2011-August/007503.html new file mode 100644 index 000000000..8fc92f469 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007503.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [134638] - clean spec + + + + + + + + + +

[Mageia-dev] [134638] - clean spec

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Thu Aug 25 09:39:07 CEST 2011 +

+
+ +
On 25/08/2011 08:50, Thierry Vignaud wrote:
+> Err... Sorry I didn't meant to embarrass you, I was just defending against
+> the unfair jbj comparison
+The comparison was only about the ugly '@mdv' usage, and was perfectly 
+fair :)
+
+
+-- 
+BOFH excuse #383:
+
+Your processor has taken a ride to Heaven's Gate on the UFO behind 
+Hale-Bopp's comet.
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007504.html b/zarb-ml/mageia-dev/2011-August/007504.html new file mode 100644 index 000000000..cb069a41d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007504.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] Packagers meeting tonight + + + + + + + + + +

[Mageia-dev] Packagers meeting tonight

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Thu Aug 25 09:50:58 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011 03:17:58 -0400, Oliver Burger <oliver.bgr at googlemail.com> wrote:
+
+> It's at the same place as all the other logs...
+> http://meetbot.mageia.org/mageia-dev/2011/
+
+Thanks for that, but that seems to be the summary only,
+not the full log.  Is that available?
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007505.html b/zarb-ml/mageia-dev/2011-August/007505.html new file mode 100644 index 000000000..8b1489490 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007505.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] Packagers meeting tonight + + + + + + + + + +

[Mageia-dev] Packagers meeting tonight

+ Remco Rijnders + remco at webconquest.com +
+ Thu Aug 25 09:53:35 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 03:50:58AM -0400, David wrote in
+<op.v0req8cnn7mcit at hodgins.homeip.net>:
+>>It's at the same place as all the other logs...
+>>http://meetbot.mageia.org/mageia-dev/2011/
+>
+>Thanks for that, but that seems to be the summary only,
+>not the full log.  Is that available?
+
+Yup... 
+http://meetbot.mageia.org/mageia-dev/2011/mageia-dev.2011-08-24-19.07.log.html
+
+See also the link at the top of the summary :)
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110825/abd400ee/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007506.html b/zarb-ml/mageia-dev/2011-August/007506.html new file mode 100644 index 000000000..b644ae005 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007506.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] Something wrong with binrepo? + + + + + + + + + +

[Mageia-dev] Something wrong with binrepo?

+ Funda Wang + fundawang at gmail.com +
+ Thu Aug 25 10:28:03 CEST 2011 +

+
+ +
$ mgarepo --version
+mgarepo 1.10.1
+
+$ mgarepo upload git-1.7.6.1.tar.bz2
+fatal: unrecognized command '/usr/local/bin/wrapper.upload-bin
+git-1.7.6.1.tar.bz2'
+error: command failed: ssh binrepo.mageia.org
+/usr/local/bin/wrapper.upload-bin git-1.7.6.1.tar.bz2
+fatal: unrecognized command '/usr/local/bin/wrapper.upload-bin
+git-1.7.6.1.tar.bz2'
+
+$ cat /etc/mgarepo.conf
+# see man 8 mgarepo for a description on configuration options
+[global]
+repository = svn+ssh://svn.mageia.org/svn/packages/
+trunk-dir = cauldron/
+
+## uncomment it in case you don't have a account in the Mageia build system:
+#mirror = http://svn.mageia.org/svn/packages/cauldron/
+
+[log]
+oldurl = svn+ssh://svn.mageia.org/svn/packages/misc
+
+[helper]
+create-srpm = /usr/local/bin/submit_package
+upload-srpm = /usr/local/bin/youri.devel
+maintdb = /usr/local/bin/wrapper.maintdb
+upload-bin = /usr/local/bin/wrapper.upload-bin
+
+[submit]
+host = pkgsubmit.mageia.org
+default = Cauldron
+
+[binrepo]
+download_url = http://binrepo.mageia.org/
+upload_host = binrepo.mageia.org
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007507.html b/zarb-ml/mageia-dev/2011-August/007507.html new file mode 100644 index 000000000..c30305137 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007507.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update. + + + + + + + + + +

[Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update.

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Thu Aug 25 11:03:42 CEST 2011 +

+
+ +
My apologies for previously mixing up the roles of the sysadmin
+team, and the council, in asking for a decision to be made.
+
+Anyways, as I mentioned in the packagers meeting, before I had to
+leave, due to other things going on,
+https://bugs.mageia.org/show_bug.cgi?id=2317
+needs to be solved quickly, as it is blocking several other updates.
+
+I used to see "broken updates" from time to time, in Mandriva, and
+never understood how those updates could get pushed.  Now I do
+understand.
+
+The problem with the current way things are being done, is that, if
+a user tries to install an update, and that update requires a
+dependency that the user doesn't already have installed, and is the
+update is not in the updates repository, the update will fail.
+
+The problem showed up with an update to kipi-plugins-expoblending
+https://bugs.mageia.org/show_bug.cgi?id=2097
+where the purpose of the update was to add a requires on hugin.
+
+The update passed qa because I used urpmi to install it, rather then
+mgaapplet.
+
+In that case, the problem was solved by an update (really just a copy)
+of hugin, to the updates repository.
+
+I finally understood why broken updates become available.  The mgaapplet
+uses "urpmi.update --update", which will not resolve dependencies from
+repositories other then those marked as updates, in /etc/urpmi/urpmi.cfg.
+
+There are two methods to try to fix this.
+
+The Mandriva way, where all dependencies of any update also get copied
+to the Updates Testing repository, and then pushed together to Updates,
+or, change mgaapplet to use "urpmi --auto-update", instead of
+"urpmi.update --update".
+
+In my opinion, the Mandriva way is too easy to lead to broken updates.
+It lead to broken updates often enough, the half dozen "new to linux"
+people I currently support rely on me to install updates, as it's too
+confusing for them to sort out.
+
+If the packager, and the qa team already have the dependencies installed,
+they won't realize the problem will exist for users (or if they use
+urpmi, and don't pay attention to which repository the package is being
+installed from).
+
+There is also the problem with duplicating packages from Core Release
+to Updates Testing, and then Updates.  An automated solution to ensure
+all dependencies are available would effectively duplicate Core Release
+in Core Updates Testing, and in Core Updates, (and in tainted, and in
+non-free).  Determining which requires might not already be installed
+in the users system, therefore needing to be available in updates is
+not simple.  Especially while we support upgrading from Mandriva, where
+the update for a dependency may have been blocked, due to Mageia not
+yet having the package available.
+
+The problem with using "urpmi --auto-select" is that it increases i/o
+and cpu usage for every execution of the check for updates by mgaapplet.
+On my 6 year old system 5 seconds for "urpmi.update --update" versus
+24 seconds for "urpmi --auto-select", when the system is up-to-date.
+
+If the Mandriva way is kept, we must ensure all needed dependencies
+are available in Updates (Testing too).  In addition, all packager must
+be willing to copy the dependencies from Core Release to Core Updates
+Testing, and the sysadmin team must push them.
+
+If changing mgaapplet is chosen, that must be given a very high priority.
+
+Either way, a decision is needed quickly.
+
+Thanks, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007508.html b/zarb-ml/mageia-dev/2011-August/007508.html new file mode 100644 index 000000000..c69874345 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007508.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update. + + + + + + + + + +

[Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update.

+ nicolas vigier + boklm at mars-attacks.org +
+ Thu Aug 25 11:47:45 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011, David W. Hodgins wrote:
+
+>
+> The problem with using "urpmi --auto-select" is that it increases i/o
+> and cpu usage for every execution of the check for updates by mgaapplet.
+
+No, it doesn't need to use all repositories to check for updates. It can
+use "urpmq --updates --auto-select" to see what updates are available,
+and only use all repositories to install them.
+
+> On my 6 year old system 5 seconds for "urpmi.update --update" versus
+> 24 seconds for "urpmi --auto-select", when the system is up-to-date.
+
+It's not doing the same thing, so this comparison doesn't mean anything.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007509.html b/zarb-ml/mageia-dev/2011-August/007509.html new file mode 100644 index 000000000..e9ab66c68 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007509.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] Something wrong with binrepo? + + + + + + + + + +

[Mageia-dev] Something wrong with binrepo?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 25 12:57:29 CEST 2011 +

+
+ +
'Twas brillig, and Funda Wang at 25/08/11 09:28 did gyre and gimble:
+> $ mgarepo --version
+> mgarepo 1.10.1
+> 
+> $ mgarepo upload git-1.7.6.1.tar.bz2
+> fatal: unrecognized command '/usr/local/bin/wrapper.upload-bin
+> git-1.7.6.1.tar.bz2'
+> error: command failed: ssh binrepo.mageia.org
+> /usr/local/bin/wrapper.upload-bin git-1.7.6.1.tar.bz2
+> fatal: unrecognized command '/usr/local/bin/wrapper.upload-bin
+> git-1.7.6.1.tar.bz2'
+> 
+> $ cat /etc/mgarepo.conf
+> # see man 8 mgarepo for a description on configuration options
+> [global]
+> repository = svn+ssh://svn.mageia.org/svn/packages/
+> trunk-dir = cauldron/
+> 
+> ## uncomment it in case you don't have a account in the Mageia build system:
+> #mirror = http://svn.mageia.org/svn/packages/cauldron/
+> 
+> [log]
+> oldurl = svn+ssh://svn.mageia.org/svn/packages/misc
+> 
+> [helper]
+> create-srpm = /usr/local/bin/submit_package
+> upload-srpm = /usr/local/bin/youri.devel
+> maintdb = /usr/local/bin/wrapper.maintdb
+> upload-bin = /usr/local/bin/wrapper.upload-bin
+> 
+> [submit]
+> host = pkgsubmit.mageia.org
+> default = Cauldron
+> 
+> [binrepo]
+> download_url = http://binrepo.mageia.org/
+> upload_host = binrepo.mageia.org
+
+
+Don't know if it would cause this error, but is your ssh config correct
+such that you use the right username+key for the host binrepo.mageia.org?
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007510.html b/zarb-ml/mageia-dev/2011-August/007510.html new file mode 100644 index 000000000..077b72789 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007510.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 25 13:17:51 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 24/08/11 10:46 did gyre and gimble:
+>> At present, a number of my machines have scripts that hook into the network 
+>> scripts. For example, one to update the bind forwarders from the DNS IPs 
+>> returned by pppd when the interface comes up. On another machine, a script 
+>> that unloads the wireless broadband driver when the interface goes down (I 
+>> think this modem has buggy firmware). Then, there are the existing scripts 
+>> shipped in the distribution (e.g. to reload squid).
+
+Just on this point in particular (as Misc has pretty much covered
+everything I would say and more!), the need to do this will likely go
+away very soon.
+
+I don't know the full ins and outs here but AFAIK, there was/are various
+uses of dnsmasq in Network Manager to provide caching DNS (which I
+presume is the basic need with bind+forwarders).
+
+
+In the not too distant future there will be a new resolved that will
+slot into nsswitch that will handle DNS lookups much more gracefully
+(i.e. basically replacing "dns" module). Combine that with appropriate
+caching from nscd and you should be fine generally for caching DNS
+lookups and reacting to server changes when moving network around etc.
+
+I don't have all the details here, but this kind of infrastructure will
+be a lot simpler and more robust.
+
+Of course there may be need to do the whole bind thing and that, in
+itself, should still be possible.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007511.html b/zarb-ml/mageia-dev/2011-August/007511.html new file mode 100644 index 000000000..6fd13f846 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007511.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer? + + + + + + + + + +

[Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer?

+ Jerome Quelin + jquelin at gmail.com +
+ Thu Aug 25 13:35:23 CEST 2011 +

+
+ +
On 11/08/24 15:48 -0500, Luis Daniel Lucio Quiroz wrote:
+> e) a top of 70 packages to maintain is a good limit for people, there is no 
+> sense people that maintains 500 packages. we call this single poing of 
+> failure.
+
+i beg to differ:
+
+    $ mgarepo maintdb get|grep jquelin|wc -l
+    2505
+
+i'm *really* updating those packages by myself, with the help of some
+scripts (i blogged about magpie, and also posted here). and i'm not
+aware of anyone really using perl for dev on mageia to object that i'm
+doing a bad job...
+
+now, kharec is joining me as perl stack maintainer, and i have
+an apprentice willing to join perl maintainance fun as well. so i guess
+it alleviates your spof argument...
+
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007512.html b/zarb-ml/mageia-dev/2011-August/007512.html new file mode 100644 index 000000000..7b0dbc921 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007512.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Stew Benedict + stewbintn at gmail.com +
+ Thu Aug 25 14:09:26 CEST 2011 +

+
+ +
On 08/24/2011 08:50 PM, Samuel Verschelde wrote:
+> Hi,
+>
+> I was told that QA Team's work's visibility needs to be improved, so as a team
+> member I'll try to give you some sort of status report.
+
+> - 1 has been validated by QA one month ago, but was assigned to security team
+> following updates policy for security fixes, and got not answer. We have to
+> improve either the policy or the security team here (or both).
+Do you have a pointer to this bug? I'm not finding it in bugzilla. I'm 
+not sure what I can do with it once assigned back to secteam, aside from 
+write an advisory text. I don't have admin rights to release it, etc. 
+(afaik). It was basically my understanding that the secteam role is to 
+initiate the bug, provide patches, POC, and advisory text and the 
+maintainer do the update and pass it on to QA. I've stopped even 
+intiating because they are just sitting there in the new/unassigned 
+state. some for 2 months or more now. While a shiny new KDE is nice, not 
+pushing updates for published vulnerabilities makes us look bad, imho.
+
+
+-- 
+Stew Benedict
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007513.html b/zarb-ml/mageia-dev/2011-August/007513.html new file mode 100644 index 000000000..747b95955 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007513.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Something wrong with binrepo? + + + + + + + + + +

[Mageia-dev] Something wrong with binrepo?

+ Funda Wang + fundawang at gmail.com +
+ Thu Aug 25 14:36:07 CEST 2011 +

+
+ +
2011/8/25 Colin Guthrie <mageia at colin.guthr.ie>:
+> Don't know if it would cause this error, but is your ssh config correct
+> such that you use the right username+key for the host binrepo.mageia.org?
+It seems yes, `ssh binrepo.mageia.org` works as expected.
+
+>
+> Col
+>
+> --
+>
+> Colin Guthrie
+> mageia(at)colin.guthr.ie
+> http://colin.guthr.ie/
+>
+> Day Job:
+>  Tribalogic Limited [http://www.tribalogic.net/]
+> Open Source:
+>  Mageia Contributor [http://www.mageia.org/]
+>  PulseAudio Hacker [http://www.pulseaudio.org/]
+>  Trac Hacker [http://trac.edgewall.org/]
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007514.html b/zarb-ml/mageia-dev/2011-August/007514.html new file mode 100644 index 000000000..0ae11af20 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007514.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ D.Morgan + dmorganec at gmail.com +
+ Thu Aug 25 15:07:05 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 2:09 PM, Stew Benedict <stewbintn at gmail.com> wrote:
+> On 08/24/2011 08:50 PM, Samuel Verschelde wrote:
+>>
+>> Hi,
+>>
+>> I was told that QA Team's work's visibility needs to be improved, so as a
+>> team
+>> member I'll try to give you some sort of status report.
+>
+>> - 1 has been validated by QA one month ago, but was assigned to security
+>> team
+>> following updates policy for security fixes, and got not answer. We have
+>> to
+>> improve either the policy or the security team here (or both).
+>
+> Do you have a pointer to this bug? I'm not finding it in bugzilla. I'm not
+> sure what I can do with it once assigned back to secteam, aside from write
+> an advisory text. I don't have admin rights to release it, etc. (afaik). It
+> was basically my understanding that the secteam role is to initiate the bug,
+> provide patches, POC, and advisory text and the maintainer do the update and
+> pass it on to QA. I've stopped even intiating because they are just sitting
+> there in the new/unassigned state. some for 2 months or more now. While a
+> shiny new KDE is nice, not pushing updates for published vulnerabilities
+> makes us look bad, imho.
+
+i agree on this point, and this is really something we need to improve quickly
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007515.html b/zarb-ml/mageia-dev/2011-August/007515.html new file mode 100644 index 000000000..1b4bc3649 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007515.html @@ -0,0 +1,154 @@ + + + + [Mageia-dev] cauldron core/release udev-173-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release udev-173-1.mga2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 25 16:18:50 CEST 2011 +

+
+ +
'Twas brillig, and Mageia Team at 25/08/11 09:56 did gyre and gimble:
+> Name        : udev                         Relocations: (not relocatable)
+> Version     : 173                               Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Thu Aug 25 10:54:41 2011
+> Install Date: (not installed)               Build Host: jonund
+> Group       : System/Configuration/Hardware   Source RPM: (none)
+> Size        : 745928                           License: GPLv2
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug
+> Summary     : A userspace implementation of devfs
+> Description :
+> Udev is an implementation of devfs/devfsd in userspace using sysfs and
+> /sbin/hotplug. It requires a 2.6 kernel to run properly.
+> 
+> Like devfs, udev dynamically creates and removes device nodes from /dev/.
+> It responds to /sbin/hotplug device events.
+> 
+> misc <misc> 173-1.mga2:
+> + Revision: 135235
+> - fix description ( rpmlint error )
+> 
+>   + tv <tv>
+>     - fix file list
+>     - new release
+>     - rediff patch 0
+
+So, with the new udev, it seems that udev-acl is removed. This is a step
+towards systemd which now handles all the ACL application.
+
+Do we really want this new udev now? If so, then we really need to step
+up the systemd integration. Things are mostly working fine for me
+without udev-acls, but even with the systemd package as presently
+available, I have to edit my /etc/pamd.d/system-auth file to include the
+pam_systemd stuff - see my earlier message to this list about that.
+
+
+This is a *big* change. Do we really want to do that just now? (believe
+me I'm all for it, but I suspect the consequences of udev-acl being
+removed from udev were not fully appreciated when it was updated).
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007516.html b/zarb-ml/mageia-dev/2011-August/007516.html new file mode 100644 index 000000000..abdd35fd9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007516.html @@ -0,0 +1,148 @@ + + + + [Mageia-dev] cauldron core/release udev-173-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release udev-173-1.mga2

+ D.Morgan + dmorganec at gmail.com +
+ Thu Aug 25 16:22:23 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 4:18 PM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> 'Twas brillig, and Mageia Team at 25/08/11 09:56 did gyre and gimble:
+>> Name        : udev                         Relocations: (not relocatable)
+>> Version     : 173                               Vendor: Mageia.Org
+>> Release     : 1.mga2                        Build Date: Thu Aug 25 10:54:41 2011
+>> Install Date: (not installed)               Build Host: jonund
+>> Group       : System/Configuration/Hardware   Source RPM: (none)
+>> Size        : 745928                           License: GPLv2
+>> Signature   : (none)
+>> Packager    : Mageia Team <http://www.mageia.org>
+>> URL         : ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug
+>> Summary     : A userspace implementation of devfs
+>> Description :
+>> Udev is an implementation of devfs/devfsd in userspace using sysfs and
+>> /sbin/hotplug. It requires a 2.6 kernel to run properly.
+>>
+>> Like devfs, udev dynamically creates and removes device nodes from /dev/.
+>> It responds to /sbin/hotplug device events.
+>>
+>> misc <misc> 173-1.mga2:
+>> + Revision: 135235
+>> - fix description ( rpmlint error )
+>>
+>>   + tv <tv>
+>>     - fix file list
+>>     - new release
+>>     - rediff patch 0
+>
+> So, with the new udev, it seems that udev-acl is removed. This is a step
+> towards systemd which now handles all the ACL application.
+>
+> Do we really want this new udev now? If so, then we really need to step
+> up the systemd integration. Things are mostly working fine for me
+> without udev-acls, but even with the systemd package as presently
+> available, I have to edit my /etc/pamd.d/system-auth file to include the
+> pam_systemd stuff - see my earlier message to this list about that.
+
+what about doing like fedora ?
+
+
+
+%post
+# Make sure pam_systemd is enabled
+if ! /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ; then
+        /usr/sbin/authconfig --update --nostart >/dev/null 2>&1 || :
+
+        # Try harder
+        /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ||
+/usr/sbin/authconfig --updateall --nostart >/dev/null 2>&1 || :
+fi
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007517.html b/zarb-ml/mageia-dev/2011-August/007517.html new file mode 100644 index 000000000..5fb32ba66 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007517.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] systemd + ACL: Why it is broken. + + + + + + + + + +

[Mageia-dev] systemd + ACL: Why it is broken.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 25 16:26:42 CEST 2011 +

+
+ +
Ping!
+
+Any thoughts on the below email?
+
+Seeing as udev 173 has landed which removes supoprt for udev-acl, we
+need to either back out 173 (or rebuild with udev-acl support) or we
+need to use systemd with the below changes officially blessed!
+
+Col
+
+'Twas brillig, and Colin Guthrie at 04/08/11 18:43 did gyre and gimble:
+> Hi,
+> 
+> OK, so the reason that device ACLs are kinda broken with systemd is
+> because the acl stuff is being done twice, once via udev and again via
+> systemd.... but sadly systemd gets it wrong as it's not aware of the
+> user session, see:
+> systemd-loginctl --no-pager
+> 
+> 
+> This is due to the fact that some essential additions to
+> /etc/pam.d/system-auth are not done when systemd is installed.
+> 
+> I added the following line to the end of my system-auth (the "login"
+> file where console kit connector lies didn't work):
+> 
+> -session    optional      pam_systemd.so
+> 
+> 
+> 
+> The question is, how should we handle this? Edit the pam package and add
+> it or do something more complex? AFAIK Fedora uses a system to manage
+> these files called authconfig.... not sure if we could/should adopt
+> that. I don't know much about it.
+> 
+> 
+> 
+> 
+> On a related note, we'll also need to rebuild udev without udev-acl
+> support, as this is now
+> handled by systemd. At present, with the above fix to pam, I will be
+> getting my ACLs written twice, which (when systemd knows I'm logged in)
+> is fine. I think it's actually the default in udev 173, but
+> we can do that manually with 172 via:
+>   --disable-udev_acl
+> in udev.
+> 
+> That said, this would commit us to systemd so we need to tread carefully
+> here as without systemd, then the ACLs would not get written with
+> obvious consequences (basically the exact opposite of now!).
+> 
+> Anyway, for now I have my ACLs back and can use my audio devices! Yay!
+> 
+> Col
+> 
+> 
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007518.html b/zarb-ml/mageia-dev/2011-August/007518.html new file mode 100644 index 000000000..7b7ff7e8b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007518.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] cauldron core/release udev-173-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release udev-173-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Thu Aug 25 16:32:09 CEST 2011 +

+
+ +
Le Jeudi 25 Août 2011 16:22:23 D.Morgan a écrit :
+[...]
+> 
+> %post
+> # Make sure pam_systemd is enabled
+> if ! /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ; then
+>         /usr/sbin/authconfig --update --nostart >/dev/null 2>&1 || :
+> 
+>         # Try harder
+>         /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ||
+> /usr/sbin/authconfig --updateall --nostart >/dev/null 2>&1 || :
+> fi
+Then we should import & require authconfig for this %post ( 
+http://pkgs.fedoraproject.org/gitweb/?p=authconfig.git )
+because authconfig is not available on mageia.
+
+I'm also not sure that we really need it because it seems to be a quite 
+specific usage tool.
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007519.html b/zarb-ml/mageia-dev/2011-August/007519.html new file mode 100644 index 000000000..ee7f5671d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007519.html @@ -0,0 +1,171 @@ + + + + [Mageia-dev] cauldron core/release udev-173-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release udev-173-1.mga2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Thu Aug 25 16:33:09 CEST 2011 +

+
+ +
'Twas brillig, and D.Morgan at 25/08/11 15:22 did gyre and gimble:
+> On Thu, Aug 25, 2011 at 4:18 PM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>> 'Twas brillig, and Mageia Team at 25/08/11 09:56 did gyre and gimble:
+>>> Name        : udev                         Relocations: (not relocatable)
+>>> Version     : 173                               Vendor: Mageia.Org
+>>> Release     : 1.mga2                        Build Date: Thu Aug 25 10:54:41 2011
+>>> Install Date: (not installed)               Build Host: jonund
+>>> Group       : System/Configuration/Hardware   Source RPM: (none)
+>>> Size        : 745928                           License: GPLv2
+>>> Signature   : (none)
+>>> Packager    : Mageia Team <http://www.mageia.org>
+>>> URL         : ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug
+>>> Summary     : A userspace implementation of devfs
+>>> Description :
+>>> Udev is an implementation of devfs/devfsd in userspace using sysfs and
+>>> /sbin/hotplug. It requires a 2.6 kernel to run properly.
+>>>
+>>> Like devfs, udev dynamically creates and removes device nodes from /dev/.
+>>> It responds to /sbin/hotplug device events.
+>>>
+>>> misc <misc> 173-1.mga2:
+>>> + Revision: 135235
+>>> - fix description ( rpmlint error )
+>>>
+>>>   + tv <tv>
+>>>     - fix file list
+>>>     - new release
+>>>     - rediff patch 0
+>>
+>> So, with the new udev, it seems that udev-acl is removed. This is a step
+>> towards systemd which now handles all the ACL application.
+>>
+>> Do we really want this new udev now? If so, then we really need to step
+>> up the systemd integration. Things are mostly working fine for me
+>> without udev-acls, but even with the systemd package as presently
+>> available, I have to edit my /etc/pamd.d/system-auth file to include the
+>> pam_systemd stuff - see my earlier message to this list about that.
+> 
+> what about doing like fedora ?
+> 
+> 
+> 
+> %post
+> # Make sure pam_systemd is enabled
+> if ! /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ; then
+>         /usr/sbin/authconfig --update --nostart >/dev/null 2>&1 || :
+> 
+>         # Try harder
+>         /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ||
+> /usr/sbin/authconfig --updateall --nostart >/dev/null 2>&1 || :
+> fi
+
+Yup that's what I asked in my last email about this several weeks ago.
+I've pinged it up to get more discussion about the topic.
+
+In the meantime I've re-enabled udev-acl in udev so we can delay the
+breakage until things are properly decided.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007520.html b/zarb-ml/mageia-dev/2011-August/007520.html new file mode 100644 index 000000000..13e76b252 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007520.html @@ -0,0 +1,147 @@ + + + + [Mageia-dev] change in perl automatic provides extraction + + + + + + + + + +

[Mageia-dev] change in perl automatic provides extraction

+ Jerome Quelin + jquelin at gmail.com +
+ Thu Aug 25 16:41:15 CEST 2011 +

+
+ +
hi,
+
+currently, perl modules provided by a given rpm are automatically
+extracted.  however, modules beginning with a lower-case are not
+accounted, due to the following code in find-provides:
+
+    echo "$filelist" | tr '[:blank:]' \\n | @RPMVENDORDIR@/perl.prov |
+    grep 'perl([[:upper:]]' | sort -u \
+            && test ${PIPESTATUS[2]} -ne 0 && echo 'error:
+            @RPMVENDORDIR@/perl.prov failed' >&2 && exit 1
+
+note the "grep 'perl([[:upper:]]'" part.
+
+as more and more perl lower-case modules are released on cpan, or even
+some pragmatas released on cpan, this is just plain wrong: we are forced
+to add manually some "provides: perl(foo)" that have been filtered
+out...  :-(
+
+note also that perl 5 porters are currently speaking about trimming
+perl (even pragmas), so this is not something i'm making out of my mind.
+
+i therefore propose to apply the following patch:
+$ svn di
+Index: find-provides.in
+===================================================================
+--- find-provides.in    (révision 1889)
++++ find-provides.in    (copie de travail)
+@@ -47,7 +47,7 @@
+ #
+ # --- Perl modules.
+ [ -x @RPMVENDORDIR@/perl.prov ] &&
+-    echo "$filelist" | tr '[:blank:]' \\n | @RPMVENDORDIR@/perl.prov | grep 'perl([[:upper:]]' | sort -u \
++    echo "$filelist" | tr '[:blank:]' \\n | @RPMVENDORDIR@/perl.prov | grep 'perl(' | sort -u \
+        && test ${PIPESTATUS[2]} -ne 0 && echo 'error: @RPMVENDORDIR@/perl.prov failed' >&2 && exit 1
+ 
+ #
+
+
+==> if someone has a compelling reason to disagree, speak now
+
+otherwise, i'll proceed with the change, and will rebuild (at least)
+perl to provide those. other modules will be rebuilt when updating them
+to latest upstream.
+
+regards,
+jérôme 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007521.html b/zarb-ml/mageia-dev/2011-August/007521.html new file mode 100644 index 000000000..3ed76fcd3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007521.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Aug 25 19:12:26 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 14:09:26, Stew Benedict a écrit :
+> On 08/24/2011 08:50 PM, Samuel Verschelde wrote:
+> > Hi,
+> > 
+> > I was told that QA Team's work's visibility needs to be improved, so as a
+> > team member I'll try to give you some sort of status report.
+> > 
+> > - 1 has been validated by QA one month ago, but was assigned to security
+> > team following updates policy for security fixes, and got not answer. We
+> > have to improve either the policy or the security team here (or both).
+> 
+> Do you have a pointer to this bug? I'm not finding it in bugzilla. I'm
+> not sure what I can do with it once assigned back to secteam, aside from
+> write an advisory text. I don't have admin rights to release it, etc.
+> (afaik). It was basically my understanding that the secteam role is to
+> initiate the bug, provide patches, POC, and advisory text and the
+> maintainer do the update and pass it on to QA. I've stopped even
+> intiating because they are just sitting there in the new/unassigned
+> state. some for 2 months or more now. While a shiny new KDE is nice, not
+> pushing updates for published vulnerabilities makes us look bad, imho.
+
+It's https://bugs.mageia.org/show_bug.cgi?id=2239
+
+I think the initial idea in the updates policy is that security fixes have to 
+be tested by secteam to ensure that the security problem is not there anymore, 
+because sometimes the upstream or the packager fixes it in a wrong way or does 
+a mistake, so we need to ensure the security problems are really fixed. 
+Otherwise we risk saying that a security issue is fixed when it's not. 
+Obviously, this can't happen if the security team doesn't grow. Maybe some 
+kind of joint effort from security and QA could help ?
+
+I already know updates that have been pushed without the security fixes being 
+tested.
+
+Also, the security bugs being open in bugzilla and not adressed by the 
+packagers is a really big issue, that we have to find a way to fix as soon as 
+possible. Can you give us a link to the list of pending security issues ?
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007522.html b/zarb-ml/mageia-dev/2011-August/007522.html new file mode 100644 index 000000000..6e3dcf14a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007522.html @@ -0,0 +1,138 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Remco Rijnders + remco at webconquest.com +
+ Thu Aug 25 20:14:45 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 08:09:26AM -0400, Stew wrote in
+<4E563B76.7080300 at gmail.com>:
+>On 08/24/2011 08:50 PM, Samuel Verschelde wrote:
+>>Hi,
+>>
+>>I was told that QA Team's work's visibility needs to be improved, so as a team
+>>member I'll try to give you some sort of status report.
+>
+>>- 1 has been validated by QA one month ago, but was assigned to security team
+>>following updates policy for security fixes, and got not answer. We have to
+>>improve either the policy or the security team here (or both).
+>Do you have a pointer to this bug? I'm not finding it in bugzilla. 
+>I'm not sure what I can do with it once assigned back to secteam, 
+>aside from write an advisory text. I don't have admin rights to 
+>release it, etc. (afaik). It was basically my understanding that the 
+>secteam role is to initiate the bug, provide patches, POC, and 
+>advisory text and the maintainer do the update and pass it on to QA. 
+>I've stopped even intiating because they are just sitting there in 
+>the new/unassigned state. some for 2 months or more now. While a 
+>shiny new KDE is nice, not pushing updates for published 
+>vulnerabilities makes us look bad, imho.
+
+I think what we need is a trinity of triage, secteam, and QA to work on 
+security related things. Triage team will assign or cc the security team 
+on security related bugs as efficiently as possible, from there security 
+team will work with the maintainer on the fix and hands it to qa for 
+(expedited) testing and release.
+
+My personal feeling is that security is too important a thing to leave up 
+to an individual maintainer or last committer to fix, especially when it 
+is remotely exploitable. Perhaps make a distinction on the severity of the 
+security issue?
+
+- If it needs an authenticated user for an exploit to work, assign it to 
+   the maintainer, Cc security team. If there is no response from the 
+   maintainer after x days (say 10 or so), security team takes over 
+   responsibility.
+
+- If it is remotely exploitable and leads to a DoS or take over, security 
+   team is instantly responsible and Cc's the maintainer on the bug and 
+   works on a quick update.
+
+In my opinion it is more important to be concerned with the safety of our 
+users machines than with perhaps stepping on a sour maintainers toes.
+
+Perhaps in the next packagers meeting something like this can be agreed 
+on? The security team needs to have the needed privileges to quickly 
+handle security issues the best way it sees fit.
+
+Remmy
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110825/2bc2651f/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007523.html b/zarb-ml/mageia-dev/2011-August/007523.html new file mode 100644 index 000000000..6e23e195f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007523.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer? + + + + + + + + + +

[Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer?

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Thu Aug 25 20:20:26 CEST 2011 +

+
+ +
Le Jeudi 25 Août 2011 13:35:23 Jerome Quelin a écrit :
+> On 11/08/24 15:48 -0500, Luis Daniel Lucio Quiroz wrote:
+> > e) a top of 70 packages to maintain is a good limit for people, there is
+> > no sense people that maintains 500 packages. we call this single poing
+> > of failure.
+> 
+> i beg to differ:
+> 
+>     $ mgarepo maintdb get|grep jquelin|wc -l
+>     2505
+> 
+> i'm *really* updating those packages by myself, with the help of some
+> scripts (i blogged about magpie, and also posted here). and i'm not
+> aware of anyone really using perl for dev on mageia to object that i'm
+> doing a bad job...
+> 
+> now, kharec is joining me as perl stack maintainer, and i have
+> an apprentice willing to join perl maintainance fun as well. so i guess
+> it alleviates your spof argument...
+> 
+> jérôme
+
+
+Sorry,    of course allways there are exceptions :)
+
+LD
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007524.html b/zarb-ml/mageia-dev/2011-August/007524.html new file mode 100644 index 000000000..6dd6476b8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007524.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer? + + + + + + + + + +

[Mageia-dev] Fwd: [Mageia-discuss] PROPOSAL: so, you are already contributor, do you want to be maintainer?

+ Remco Rijnders + remco at webconquest.com +
+ Thu Aug 25 20:27:36 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 01:35:23PM +0200, Jerome wrote in
+<20110825113523.GI14995 at mongueurs.net>:
+>On 11/08/24 15:48 -0500, Luis Daniel Lucio Quiroz wrote:
+>> e) a top of 70 packages to maintain is a good limit for people, there is no
+>> sense people that maintains 500 packages. we call this single poing of
+>> failure.
+>
+>i beg to differ:
+>
+>    $ mgarepo maintdb get|grep jquelin|wc -l
+>    2505
+>
+>i'm *really* updating those packages by myself, with the help of some
+>scripts (i blogged about magpie, and also posted here). and i'm not
+>aware of anyone really using perl for dev on mageia to object that i'm
+>doing a bad job...
+>
+>now, kharec is joining me as perl stack maintainer, and i have
+>an apprentice willing to join perl maintainance fun as well. so i guess
+>it alleviates your spof argument...
+
+I think Luis meant it more as a ball park figure rather than a hard limit. 
+That is, people should only maintain as many packages as they can actually 
+manage and not set themselves as maintainer for a package for reasons of 
+seeing their name in print.
+
+Also, in debian for example it is not easy to become a maintainer as all 
+of the 'fun' packages are taken already. I don't think we are in such a 
+luxorious position yet.
+
+Cheers,
+
+Remco
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110825/2eb553d6/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007525.html b/zarb-ml/mageia-dev/2011-August/007525.html new file mode 100644 index 000000000..6b27cc81b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007525.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Aug 25 20:41:27 CEST 2011 +

+
+ +
Op donderdag 25 augustus 2011 20:14:45 schreef Remco Rijnders:
+> On Thu, Aug 25, 2011 at 08:09:26AM -0400, Stew wrote in
+> 
+> <4E563B76.7080300 at gmail.com>:
+> >On 08/24/2011 08:50 PM, Samuel Verschelde wrote:
+> >>Hi,
+> >>
+> >>I was told that QA Team's work's visibility needs to be improved, so as a
+> >>team member I'll try to give you some sort of status report.
+> >>
+> >>- 1 has been validated by QA one month ago, but was assigned to security
+> >>team following updates policy for security fixes, and got not answer. We
+> >>have to improve either the policy or the security team here (or both).
+> >
+> >Do you have a pointer to this bug? I'm not finding it in bugzilla.
+> >I'm not sure what I can do with it once assigned back to secteam,
+> >aside from write an advisory text. I don't have admin rights to
+> >release it, etc. (afaik). It was basically my understanding that the
+> >secteam role is to initiate the bug, provide patches, POC, and
+> >advisory text and the maintainer do the update and pass it on to QA.
+> >I've stopped even intiating because they are just sitting there in
+> >the new/unassigned state. some for 2 months or more now. While a
+> >shiny new KDE is nice, not pushing updates for published
+> >vulnerabilities makes us look bad, imho.
+> 
+> I think what we need is a trinity of triage, secteam, and QA to work on
+> security related things. Triage team will assign or cc the security team
+> on security related bugs as efficiently as possible, from there security
+> team will work with the maintainer on the fix and hands it to qa for
+> (expedited) testing and release.
+> 
+> My personal feeling is that security is too important a thing to leave up
+> to an individual maintainer or last committer to fix, especially when it
+> is remotely exploitable. Perhaps make a distinction on the severity of the
+> security issue?
+> 
+> - If it needs an authenticated user for an exploit to work, assign it to
+>    the maintainer, Cc security team. If there is no response from the
+>    maintainer after x days (say 10 or so), security team takes over
+>    responsibility.
+> 
+> - If it is remotely exploitable and leads to a DoS or take over, security
+>    team is instantly responsible and Cc's the maintainer on the bug and
+>    works on a quick update.
+> 
+> In my opinion it is more important to be concerned with the safety of our
+> users machines than with perhaps stepping on a sour maintainers toes.
+> 
+> Perhaps in the next packagers meeting something like this can be agreed
+> on? The security team needs to have the needed privileges to quickly
+> handle security issues the best way it sees fit.
+> 
+> Remmy
+
++1
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007526.html b/zarb-ml/mageia-dev/2011-August/007526.html new file mode 100644 index 000000000..18875c44f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007526.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Aug 25 20:43:09 CEST 2011 +

+
+ +
Op donderdag 25 augustus 2011 02:50:20 schreef Samuel Verschelde:
+> Best regards
+> 
+> Samuel Verschelde
+
+that is a very nice summary, it seems the updates are being handled better 
+than i thought (except for security fixes; perhaps there is miscommunication 
+between secteam and qa-team?)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007527.html b/zarb-ml/mageia-dev/2011-August/007527.html new file mode 100644 index 000000000..ab310b2bb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007527.html @@ -0,0 +1,128 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Sander Lepik + sander.lepik at eesti.ee +
+ Thu Aug 25 20:45:16 CEST 2011 +

+
+ +
25.08.2011 21:28, Mageia Team kirjutas:
+> Name        : firefox-ext-add-on-compatibility-reporter  Relocations: (not relocatable)
+> Version     : 0.9                               Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Thu Aug 25 20:27:17 2011
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Networking/WWW                Source RPM: (none)
+> Size        : 133229                           License: MPL
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/
+> Summary     : Firefox extension that enables to report broken/working extensions
+> Description :
+> Help Mozilla make sure your favorite add-ons get updated for upcoming Firefox
+> releases by using this extension to report whether they still work or are
+> having some issues with alpha and beta releases.
+>
+> tv <tv> 0.9-1.mga2:
+> + Revision: 135357
+> - new release
+> - imported package firefox-ext-add-on-compatibility-reporter
+WHY OH WHY are you doing this?!
+
+This add-on can be downloaded from amo. You import new extensions but i can't see you
+updating them when new Firefox is released!
+
+There is really no reason to make our life so hard :/ It's a real pain to keep track on all
+those extensions that need upgrading when new Firefox is coming.
+
+Bad idea, really bad idea!
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007528.html b/zarb-ml/mageia-dev/2011-August/007528.html new file mode 100644 index 000000000..9ac4ddac9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007528.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update. + + + + + + + + + +

[Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update.

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Aug 25 20:49:44 CEST 2011 +

+
+ +
Op donderdag 25 augustus 2011 11:47:45 schreef nicolas vigier:
+> On Thu, 25 Aug 2011, David W. Hodgins wrote:
+> > The problem with using "urpmi --auto-select" is that it increases i/o
+> > and cpu usage for every execution of the check for updates by mgaapplet.
+> 
+> No, it doesn't need to use all repositories to check for updates. It can
+> use "urpmq --updates --auto-select" to see what updates are available,
+> and only use all repositories to install them.
+> 
+> > On my 6 year old system 5 seconds for "urpmi.update --update" versus
+> > 24 seconds for "urpmi --auto-select", when the system is up-to-date.
+> 
+> It's not doing the same thing, so this comparison doesn't mean anything.
+
+tbf, i personally think the best solution is actually to make it so that
+urpmi --update --auto-select works the same way as urpmq --update --auto-
+select, so that this can be also fixes for commandline usage when not using the 
+mgaapplet.
+
+thus: updating with --update should use dependencies from all media.
+
+this is imho the cleanest way.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007529.html b/zarb-ml/mageia-dev/2011-August/007529.html new file mode 100644 index 000000000..b953067c2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007529.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Anne nicolas + ennael at mageia.org +
+ Thu Aug 25 20:52:17 CEST 2011 +

+
+ +
Le 25 août 2011 20:43, "Maarten Vanraes" <maarten.vanraes at gmail.com> a
+écrit :
+>
+> Op donderdag 25 augustus 2011 02:50:20 schreef Samuel Verschelde:
+> > Best regards
+> >
+> > Samuel Verschelde
+>
+> that is a very nice summary, it seems the updates are being handled better
+> than i thought (except for security fixes; perhaps there is
+miscommunication
+> between secteam and qa-team?)
+
+It means we need some more packagers. What about finalizing your training?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110825/ad2ee3d5/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007530.html b/zarb-ml/mageia-dev/2011-August/007530.html new file mode 100644 index 000000000..39fabbfee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007530.html @@ -0,0 +1,136 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Aug 25 20:53:37 CEST 2011 +

+
+ +
Op donderdag 25 augustus 2011 20:45:16 schreef Sander Lepik:
+> 25.08.2011 21:28, Mageia Team kirjutas:
+> > Name        : firefox-ext-add-on-compatibility-reporter  Relocations:
+> > (not relocatable) Version     : 0.9                              
+> > Vendor: Mageia.Org Release     : 1.mga2                        Build
+> > Date: Thu Aug 25 20:27:17 2011 Install Date: (not installed)            
+> >   Build Host: jonund
+> > Group       : Networking/WWW                Source RPM: (none)
+> > Size        : 133229                           License: MPL
+> > Signature   : (none)
+> > Packager    : Mageia Team <http://www.mageia.org>
+> > URL         :
+> > https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-repo
+> > rter/ Summary     : Firefox extension that enables to report
+> > broken/working extensions Description :
+> > Help Mozilla make sure your favorite add-ons get updated for upcoming
+> > Firefox releases by using this extension to report whether they still
+> > work or are having some issues with alpha and beta releases.
+> > 
+> > tv <tv> 0.9-1.mga2:
+> > + Revision: 135357
+> > - new release
+> > - imported package firefox-ext-add-on-compatibility-reporter
+> 
+> WHY OH WHY are you doing this?!
+> 
+> This add-on can be downloaded from amo. You import new extensions but i
+> can't see you updating them when new Firefox is released!
+> 
+> There is really no reason to make our life so hard :/ It's a real pain to
+> keep track on all those extensions that need upgrading when new Firefox is
+> coming.
+> 
+> Bad idea, really bad idea!
+
+What if we note somewhere all the extensions/plugins so that we know which 
+have to be rebuilt?
+
+personally, even if it's downloadable, i disagree that this is not wanted. for 
+example, in some environments access to internet could be restricted, but for 
+example a local mirror could be available.
+
+i believe we should package as much extensions as possible.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007531.html b/zarb-ml/mageia-dev/2011-August/007531.html new file mode 100644 index 000000000..2cccaa12f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007531.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Thu Aug 25 21:02:06 CEST 2011 +

+
+ +
Op donderdag 25 augustus 2011 20:52:17 schreef Anne nicolas:
+> Le 25 août 2011 20:43, "Maarten Vanraes" <maarten.vanraes at gmail.com> a
+> 
+> écrit :
+> > Op donderdag 25 augustus 2011 02:50:20 schreef Samuel Verschelde:
+> > > Best regards
+> > > 
+> > > Samuel Verschelde
+> > 
+> > that is a very nice summary, it seems the updates are being handled
+> > better than i thought (except for security fixes; perhaps there is
+> 
+> miscommunication
+> 
+> > between secteam and qa-team?)
+> 
+> It means we need some more packagers. What about finalizing your training?
+
+Sure, i'm packaging as fast as my RL (and mga2 dev TODO list) allows me. I 
+guess you should ask Anssi if i'm ready or not. I must say that i'm not sure 
+if security bugs are actually my thing though. I never hacked servers, so i 
+don't really know much about it. But in any case, i'm packaging, and i suppose 
+the only difference being a full packager, will be that i can submit myself and 
+not bother Anssi too much.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007532.html b/zarb-ml/mageia-dev/2011-August/007532.html new file mode 100644 index 000000000..a88c8a800 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007532.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Sander Lepik + sander.lepik at eesti.ee +
+ Thu Aug 25 21:03:42 CEST 2011 +

+
+ +
25.08.2011 21:53, Maarten Vanraes kirjutas:
+> i believe we should package as much extensions as possible.
+And if there is security hole in extension? Do you monitor all of them? Most of them get
+updated w/o big notice. We do not have people to monitor extensions. And it's stopping us to
+update Firefox.
+
+Too many problems where we could avoid them.
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007533.html b/zarb-ml/mageia-dev/2011-August/007533.html new file mode 100644 index 000000000..4aefc59ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007533.html @@ -0,0 +1,156 @@ + + + + [Mageia-dev] cauldron core/release udev-173-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release udev-173-1.mga2

+ Michael Scherer + misc at zarb.org +
+ Thu Aug 25 21:29:06 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 à 15:33 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and D.Morgan at 25/08/11 15:22 did gyre and gimble:
+> > On Thu, Aug 25, 2011 at 4:18 PM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> >> 'Twas brillig, and Mageia Team at 25/08/11 09:56 did gyre and gimble:
+> >>> Name        : udev                         Relocations: (not relocatable)
+> >>> Version     : 173                               Vendor: Mageia.Org
+> >>> Release     : 1.mga2                        Build Date: Thu Aug 25 10:54:41 2011
+> >>> Install Date: (not installed)               Build Host: jonund
+> >>> Group       : System/Configuration/Hardware   Source RPM: (none)
+> >>> Size        : 745928                           License: GPLv2
+> >>> Signature   : (none)
+> >>> Packager    : Mageia Team <http://www.mageia.org>
+> >>> URL         : ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug
+> >>> Summary     : A userspace implementation of devfs
+> >>> Description :
+> >>> Udev is an implementation of devfs/devfsd in userspace using sysfs and
+> >>> /sbin/hotplug. It requires a 2.6 kernel to run properly.
+> >>>
+> >>> Like devfs, udev dynamically creates and removes device nodes from /dev/.
+> >>> It responds to /sbin/hotplug device events.
+> >>>
+> >>> misc <misc> 173-1.mga2:
+> >>> + Revision: 135235
+> >>> - fix description ( rpmlint error )
+> >>>
+> >>>   + tv <tv>
+> >>>     - fix file list
+> >>>     - new release
+> >>>     - rediff patch 0
+> >>
+> >> So, with the new udev, it seems that udev-acl is removed. This is a step
+> >> towards systemd which now handles all the ACL application.
+> >>
+> >> Do we really want this new udev now? If so, then we really need to step
+> >> up the systemd integration. Things are mostly working fine for me
+> >> without udev-acls, but even with the systemd package as presently
+> >> available, I have to edit my /etc/pamd.d/system-auth file to include the
+> >> pam_systemd stuff - see my earlier message to this list about that.
+> >
+> > what about doing like fedora ?
+> > 
+> > 
+> > 
+> > %post
+> > # Make sure pam_systemd is enabled
+> > if ! /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ; then
+> >         /usr/sbin/authconfig --update --nostart >/dev/null 2>&1 || :
+> > 
+> >         # Try harder
+> >         /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ||
+> > /usr/sbin/authconfig --updateall --nostart >/dev/null 2>&1 || :
+> > fi
+
+I think it may be easier to write a script around augeas than import
+authconfig, as I suspect that it would do much more change.
+
+
+> Yup that's what I asked in my last email about this several weeks ago.
+> I've pinged it up to get more discussion about the topic.
+
+In fact, it was not clear that you asked a question in the mail :/
+
+We said that we would support booting without systemd-, so to me, this
+should be taken in account.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007534.html b/zarb-ml/mageia-dev/2011-August/007534.html new file mode 100644 index 000000000..c81577071 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007534.html @@ -0,0 +1,118 @@ + + + + [Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update. + + + + + + + + + +

[Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update.

+ andre999 + andr55 at laposte.net +
+ Thu Aug 25 21:42:53 CEST 2011 +

+
+ +
Maarten Vanraes a écrit :
+> Op donderdag 25 augustus 2011 11:47:45 schreef nicolas vigier:
+>> On Thu, 25 Aug 2011, David W. Hodgins wrote:
+>>> The problem with using "urpmi --auto-select" is that it increases i/o
+>>> and cpu usage for every execution of the check for updates by mgaapplet.
+>>
+>> No, it doesn't need to use all repositories to check for updates. It can
+>> use "urpmq --updates --auto-select" to see what updates are available,
+>> and only use all repositories to install them.
+>>
+[...]
+>
+> tbf, i personally think the best solution is actually to make it so that
+> urpmi --update --auto-select works the same way as urpmq --update --auto-
+> select, so that this can be also fixes for commandline usage when not using the
+> mgaapplet.
+>
+> thus: updating with --update should use dependencies from all media.
+>
+> this is imho the cleanest way.
+>
++1
+
+I like the idea of a previous post, that when an update repo is activated, the 
+corresponding regular repo is activated as well.
+This could be enforced by automatically activating the regular repo in such a case.
+
+Also when an update is refused, it should always give the reason, instead of 
+often (sometimes?) simply saying that it could not be updated.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007535.html b/zarb-ml/mageia-dev/2011-August/007535.html new file mode 100644 index 000000000..cc2e3f60e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007535.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Security + + + + + + + + + +

[Mageia-dev] Security

+ Stefano Negro + stblack at gmail.com +
+ Thu Aug 25 21:53:50 CEST 2011 +

+
+ +
Are we affected by this bugs ?
+http://www.ubuntu.com/usn/usn-1195-1/
+http://www.ubuntu.com/usn/usn-1196-1/
+
+-- 
+Cheers
+Stblack
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110825/fe3cb21c/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007536.html b/zarb-ml/mageia-dev/2011-August/007536.html new file mode 100644 index 000000000..fb3ce7f30 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007536.html @@ -0,0 +1,114 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ andre999 + andr55 at laposte.net +
+ Thu Aug 25 21:58:33 CEST 2011 +

+
+ +
Sander Lepik a écrit :
+> 25.08.2011 21:53, Maarten Vanraes kirjutas:
+>> i believe we should package as much extensions as possible.
+> And if there is security hole in extension? Do you monitor all of them? Most of them get
+> updated w/o big notice. We do not have people to monitor extensions. And it's stopping us to
+> update Firefox.
+>
+> Too many problems where we could avoid them.
+>
+> --
+> Sander
++1
+
+Now that mozilla apps (ff/tb/sm) monitor automatically extensions, it is even 
+more important that we let mozilla apps handle the extensions.
+For instance, they will update the app version of the extension without 
+redownloading the extension, disable extensions with version conflict, etc.
+Extensions tend to be small, and if the user doesn't have Internet access, they 
+don't need the extension anyway.
+A packaged extension would likely be bigger than the extension as well.
+In sum, only disadvantages for us to package mozilla extensions.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007537.html b/zarb-ml/mageia-dev/2011-August/007537.html new file mode 100644 index 000000000..3f1f89312 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007537.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Security + + + + + + + + + +

[Mageia-dev] Security

+ andre999 + andr55 at laposte.net +
+ Thu Aug 25 22:33:13 CEST 2011 +

+
+ +
Stefano Negro a écrit :
+> Are we affected by this bugs ?
+> http://www.ubuntu.com/usn/usn-1195-1/
+> http://www.ubuntu.com/usn/usn-1196-1/
+>
+> --
+> Cheers
+> Stblack
+
+For the first, we are at our 4th revision of that version of libwebkit, Ubuntu 
+at the original.  (So apparently Ubuntu is trailing us.)
+The second is Ubuntu-specific.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007538.html b/zarb-ml/mageia-dev/2011-August/007538.html new file mode 100644 index 000000000..0a3d897ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007538.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] [RPM] cauldron core/release kannasaver-1.2.1-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release kannasaver-1.2.1-1.mga2

+ Balcaen John + mikala at mageia.org +
+ Thu Aug 25 22:50:31 CEST 2011 +

+
+ +
Le Mercredi 24 Août 2011 15:57:09 Mageia Team a écrit :
+> Name        : kannasaver                   Relocations: (not
+> relocatable) Version     : 1.2.1                             Vendor:
+> Mageia.Org Release     : 1.mga2                        Build Date:
+[...]
+> exactly the same, which sits an www.thejapanesepage.com for free.
+> 
+> juancho <juancho> 1.2.1-1.mga2:
+> + Revision: 135114
+> - Adjusted mkrel
+> - Adjusted mkrel
+> 
+>   + gejo <gejo>
+>     - Update Group section
+>     - Remove dot at the end of Summary
+>     - Change Group in SPEC
+>     - imported package kannasaver
+
+You should also import fonts-ttf-japanese-extra or remove it as a 
+require for kannasaver .
+
+Regards,
+
+-- 
+Balcaen John
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007539.html b/zarb-ml/mageia-dev/2011-August/007539.html new file mode 100644 index 000000000..a4e5c5ed3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007539.html @@ -0,0 +1,181 @@ + + + + [Mageia-dev] Viviane, automated system to test installer + + + + + + + + + +

[Mageia-dev] Viviane, automated system to test installer

+ Michael Scherer + misc at zarb.org +
+ Thu Aug 25 22:49:05 CEST 2011 +

+
+ +
Hi,
+
+I finished a quick script that I wrote during my spare time on Wednesday
+to do a automated test installation in a vm, using libvirt, virtinst,
+and drakx auto-installation feature.  
+
+As I like catchy names, the project is called Viviane, for 
+Virtualized Integrated Verification of Installer with Automated
+Networked Eyeballs. Why did I chose that name is buried deep in the
+script, kudos to who find it ( and there goes the trick to make people
+read my code ).
+
+Presentation 
+-------------
+
+The idea is to use the network installation of cauldron on a qemu vm, to
+restart the vm and thanks to autologin, autostart folder of xdg and
+serial virtio, send the information to the host that the installation ad
+first boot worked. Then after a timeout, the virtual machine is wiped,
+and a mail is sent if the installation was not finished in 30 minutes
+( configurable delay, based on the time needed on my laptop and my
+network connection ). 
+
+
+The goal is to test if the automated installation work, and if the
+distribution is able to boot. While this seems not much, that's at least
+a starting point.
+  
+Remaining problem
+------------------
+
+Main problems is that it requires a patch on virtinst, to add the
+support of Mageia ( https://bugzilla.redhat.com/show_bug.cgi?id=733121
+). So I cannot deploy it now on rabbit, as this would requires some
+custom packages and some tests first.
+
+For now, it was tested against Mandriva 2010.2 that installed fine each
+time. As each run take me 30 minutes, there may still have some bugs
+left or introduced after the last cleaning. So while I think it should
+work fine and out of the box on supported hardware ( connected to the
+internet, with 1G of memory to spare, proper processor and around 9G of
+free disk space ), I didn't test anywhere else than on my laptop.
+
+I post this here so I can gather patches and ideas ( I remind that
+remarks without patchs will have a non negligible chance of not being
+implemented wether I am convinced or not ), and I will commit the script
+to our svn once I am sure it is ready ( ie soon )
+
+The future
+-----------
+
+The idea could be extended to run more than a simple script that do
+"echo hello > /dev/ttyS0" ( as it does now ) like something that for
+example start firefox on a custom url, check that firefox did start and
+was able to load the url then kill it. 
+
+Using xnee, or accessibility support, some automation of graphical
+interface could be done, but that's the hard part.  
+
+I also planned to also add a screenshot of the guest upon failure ( that
+requires a recent libvirt ) and to suspend the system for further
+analysis, and to distribute this with a webserver. Some more
+informations could be gather with libguestfs, but I didn't looked much
+at it for now.
+
+I also didn't think of integration with something like buildbot or
+jenkins, or just youri.
+
+And finally, with automated livecd creation we could also test livecd,
+provided the small hook I used are added ( ie, 1 script and 1 desktop
+file ) is added, and provided we shunt the first time boot wizard.
+-- 
+Michael Scherer
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: viviane.sh
+Type: application/x-shellscript
+Size: 6466 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110825/7f2c0b35/attachment-0001.bin>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007540.html b/zarb-ml/mageia-dev/2011-August/007540.html new file mode 100644 index 000000000..48586c869 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007540.html @@ -0,0 +1,140 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Stew Benedict + stewbintn at gmail.com +
+ Thu Aug 25 23:48:19 CEST 2011 +

+
+ +
On 08/25/2011 01:12 PM, Samuel Verschelde wrote:
+> Le jeudi 25 août 2011 14:09:26, Stew Benedict a écrit :
+>> On 08/24/2011 08:50 PM, Samuel Verschelde wrote:
+>>> Hi,
+>>>
+>>> I was told that QA Team's work's visibility needs to be improved, so as a
+>>> team member I'll try to give you some sort of status report.
+>>>
+>>> - 1 has been validated by QA one month ago, but was assigned to security
+>>> team following updates policy for security fixes, and got not answer. We
+>>> have to improve either the policy or the security team here (or both).
+>> Do you have a pointer to this bug? I'm not finding it in bugzilla. I'm
+>> not sure what I can do with it once assigned back to secteam, aside from
+>> write an advisory text. I don't have admin rights to release it, etc.
+>> (afaik). It was basically my understanding that the secteam role is to
+>> initiate the bug, provide patches, POC, and advisory text and the
+>> maintainer do the update and pass it on to QA. I've stopped even
+>> intiating because they are just sitting there in the new/unassigned
+>> state. some for 2 months or more now. While a shiny new KDE is nice, not
+>> pushing updates for published vulnerabilities makes us look bad, imho.
+> It's https://bugs.mageia.org/show_bug.cgi?id=2239
+>
+> I think the initial idea in the updates policy is that security fixes have to
+> be tested by secteam to ensure that the security problem is not there anymore,
+> because sometimes the upstream or the packager fixes it in a wrong way or does
+> a mistake, so we need to ensure the security problems are really fixed.
+> Otherwise we risk saying that a security issue is fixed when it's not.
+> Obviously, this can't happen if the security team doesn't grow. Maybe some
+> kind of joint effort from security and QA could help ?
+>
+> I already know updates that have been pushed without the security fixes being
+> tested.
+>
+> Also, the security bugs being open in bugzilla and not adressed by the
+> packagers is a really big issue, that we have to find a way to fix as soon as
+> possible. Can you give us a link to the list of pending security issues ?
+>
+While I don't disagree with the theory, it's not workable with the 
+current state, as I don't have enough free cycles to think about 
+actually updating any packages an/or doing the testing. One has to keep 
+in mind that in the past life this was nearly a full time job for 2 
+people to identify, fix build, test, release updates for the supported 
+releases. The people that have inquired about helping with security 
+issues quickly go away when they find out how inglorious(sic) it is.
+
+Well, for instance, this is my "my bugs" list:
+
+https://bugs.mageia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&email1=stewbintn%40gmail.com&field0-0-0=bug_status&type0-0-0=notequals&value0-0-0=UNCONFIRMED&field0-0-1=reporter&type0-0-1=equals&value0-0-1=stewbintn%40gmail.com
+
+and here's my "open security issues" list (if it works for others):
+
+https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Open%20security%20issues
+
+First list is 8 bugs, 2nd is 25. 8 bugs wouldn't be an issue if they 
+were 1 week or 2 old, but 2 months for a known issue with a published 
+fix that everyone else has released is unacceptable.
+
+I think other have done things with tags etc.
+
+-- 
+
+Stew Benedict
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007541.html b/zarb-ml/mageia-dev/2011-August/007541.html new file mode 100644 index 000000000..5fe8676ee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007541.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Samuel Verschelde + stormi at laposte.net +
+ Fri Aug 26 00:08:15 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 23:48:19, Stew Benedict a écrit :
+> While I don't disagree with the theory, it's not workable with the
+> current state, as I don't have enough free cycles to think about
+> actually updating any packages an/or doing the testing. One has to keep
+> in mind that in the past life this was nearly a full time job for 2
+> people to identify, fix build, test, release updates for the supported
+> releases. The people that have inquired about helping with security
+> issues quickly go away when they find out how inglorious(sic) it is.
+> 
+> Well, for instance, this is my "my bugs" list:
+> 
+> https://bugs.mageia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&b
+> ug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailreporter1=1
+> &emailtype1=exact&email1=stewbintn%40gmail.com&field0-0-0=bug_status&type0-
+> 0-0=notequals&value0-0-0=UNCONFIRMED&field0-0-1=reporter&type0-0-1=equals&v
+> alue0-0-1=stewbintn%40gmail.com
+> 
+> and here's my "open security issues" list (if it works for others):
+> 
+> https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Open%20securi
+> ty%20issues
+
+No, it doesn't work. I think you must share it some way so that we can add it 
+to our saved searches. Basically, it's a search for all bug reports with the 
+"security" component ?
+
+Samuel
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007542.html b/zarb-ml/mageia-dev/2011-August/007542.html new file mode 100644 index 000000000..67f9b6860 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007542.html @@ -0,0 +1,179 @@ + + + + [Mageia-dev] cauldron core/release udev-173-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release udev-173-1.mga2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Aug 26 00:47:42 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 25/08/11 20:29 did gyre and gimble:
+> Le jeudi 25 août 2011 à 15:33 +0100, Colin Guthrie a écrit :
+>> 'Twas brillig, and D.Morgan at 25/08/11 15:22 did gyre and gimble:
+>>> On Thu, Aug 25, 2011 at 4:18 PM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+>>>> 'Twas brillig, and Mageia Team at 25/08/11 09:56 did gyre and gimble:
+>>>>> Name        : udev                         Relocations: (not relocatable)
+>>>>> Version     : 173                               Vendor: Mageia.Org
+>>>>> Release     : 1.mga2                        Build Date: Thu Aug 25 10:54:41 2011
+>>>>> Install Date: (not installed)               Build Host: jonund
+>>>>> Group       : System/Configuration/Hardware   Source RPM: (none)
+>>>>> Size        : 745928                           License: GPLv2
+>>>>> Signature   : (none)
+>>>>> Packager    : Mageia Team <http://www.mageia.org>
+>>>>> URL         : ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug
+>>>>> Summary     : A userspace implementation of devfs
+>>>>> Description :
+>>>>> Udev is an implementation of devfs/devfsd in userspace using sysfs and
+>>>>> /sbin/hotplug. It requires a 2.6 kernel to run properly.
+>>>>>
+>>>>> Like devfs, udev dynamically creates and removes device nodes from /dev/.
+>>>>> It responds to /sbin/hotplug device events.
+>>>>>
+>>>>> misc <misc> 173-1.mga2:
+>>>>> + Revision: 135235
+>>>>> - fix description ( rpmlint error )
+>>>>>
+>>>>>   + tv <tv>
+>>>>>     - fix file list
+>>>>>     - new release
+>>>>>     - rediff patch 0
+>>>>
+>>>> So, with the new udev, it seems that udev-acl is removed. This is a step
+>>>> towards systemd which now handles all the ACL application.
+>>>>
+>>>> Do we really want this new udev now? If so, then we really need to step
+>>>> up the systemd integration. Things are mostly working fine for me
+>>>> without udev-acls, but even with the systemd package as presently
+>>>> available, I have to edit my /etc/pamd.d/system-auth file to include the
+>>>> pam_systemd stuff - see my earlier message to this list about that.
+>>>
+>>> what about doing like fedora ?
+>>>
+>>>
+>>>
+>>> %post
+>>> # Make sure pam_systemd is enabled
+>>> if ! /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ; then
+>>>         /usr/sbin/authconfig --update --nostart >/dev/null 2>&1 || :
+>>>
+>>>         # Try harder
+>>>         /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac ||
+>>> /usr/sbin/authconfig --updateall --nostart >/dev/null 2>&1 || :
+>>> fi
+> 
+> I think it may be easier to write a script around augeas than import
+> authconfig, as I suspect that it would do much more change.
+
+I'm not familiar with augeas... but this should be possible. Do the
+tools we already have for e.g. configuring LDAP logins have routines for
+editing the system-auth file perhaps?
+
+>> Yup that's what I asked in my last email about this several weeks ago.
+>> I've pinged it up to get more discussion about the topic.
+> 
+> In fact, it was not clear that you asked a question in the mail :/
+
+Hmm, I thought: "The question is, how should we handle this?" was a
+pretty obvious question... I even used the word "question" :p :D
+
+> We said that we would support booting without systemd-, so to me, this
+> should be taken in account.
+
+Yeah but I think using the "optional" word in pam config means that it's
+quite safe even if systemd is not running, so I don't think this is an
+issue.
+
+That's why I suggested even just patching pam directly... but modifying
+the file should also be possible as that what ldap auth configuration
+does anyway, so it's no great shakes.
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007543.html b/zarb-ml/mageia-dev/2011-August/007543.html new file mode 100644 index 000000000..236450053 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007543.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 26 00:57:26 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011, Maarten Vanraes wrote:
+
+> 
+> Sure, i'm packaging as fast as my RL (and mga2 dev TODO list) allows me. I 
+> guess you should ask Anssi if i'm ready or not. I must say that i'm not sure 
+> if security bugs are actually my thing though. I never hacked servers, so i 
+> don't really know much about it. But in any case, i'm packaging, and i suppose 
+
+Doing security updates has nothing to do with hacking servers, it's
+looking for the right patch to fix the issue, and updating the package
+with the patch applied.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007544.html b/zarb-ml/mageia-dev/2011-August/007544.html new file mode 100644 index 000000000..0014f56e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007544.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Copying dependencies to Updates (Testing), or?changing mgaapplet to use urpmi --auto-update instead of urpmi?--update. + + + + + + + + + +

[Mageia-dev] Copying dependencies to Updates (Testing), or?changing mgaapplet to use urpmi --auto-update instead of urpmi?--update.

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 26 01:06:47 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011, Maarten Vanraes wrote:
+
+> Op donderdag 25 augustus 2011 11:47:45 schreef nicolas vigier:
+> > On Thu, 25 Aug 2011, David W. Hodgins wrote:
+> > > The problem with using "urpmi --auto-select" is that it increases i/o
+> > > and cpu usage for every execution of the check for updates by mgaapplet.
+> > 
+> > No, it doesn't need to use all repositories to check for updates. It can
+> > use "urpmq --updates --auto-select" to see what updates are available,
+> > and only use all repositories to install them.
+> > 
+> > > On my 6 year old system 5 seconds for "urpmi.update --update" versus
+> > > 24 seconds for "urpmi --auto-select", when the system is up-to-date.
+> > 
+> > It's not doing the same thing, so this comparison doesn't mean anything.
+> 
+> tbf, i personally think the best solution is actually to make it so that
+> urpmi --update --auto-select works the same way as urpmq --update --auto-
+> select, so that this can be also fixes for commandline usage when not using the 
+> mgaapplet.
+
+They work the same way.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007545.html b/zarb-ml/mageia-dev/2011-August/007545.html new file mode 100644 index 000000000..afd55a437 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007545.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 26 01:11:55 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011, Maarten Vanraes wrote:
+
+> 
+> +1
+
+Can you avoid posting when you have nothing interesting to say ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007546.html b/zarb-ml/mageia-dev/2011-August/007546.html new file mode 100644 index 000000000..a9cb909a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007546.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] Viviane, automated system to test installer + + + + + + + + + +

[Mageia-dev] Viviane, automated system to test installer

+ Eugeni Dodonov + eugeni at dodonov.net +
+ Fri Aug 26 01:39:43 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 17:49, Michael Scherer <misc at zarb.org> wrote:
+
+> Hi,
+>
+> I finished a quick script that I wrote during my spare time on Wednesday
+> to do a automated test installation in a vm, using libvirt, virtinst,
+> and drakx auto-installation feature.
+>
+> As I like catchy names, the project is called Viviane, for
+> Virtualized Integrated Verification of Installer with Automated
+> Networked Eyeballs. Why did I chose that name is buried deep in the
+> script, kudos to who find it ( and there goes the trick to make people
+> read my code ).
+>
+
+After all this suspense you did, I read the entire code at least 5 times,
+but I am still clueless.
+
+Although, it was a nice choice for the name, that's for sure :).
+
+-- 
+Eugeni Dodonov
+http://eugeni.dodonov.net/
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110825/9eb9ffb2/attachment.html>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007547.html b/zarb-ml/mageia-dev/2011-August/007547.html new file mode 100644 index 000000000..950b2fe8a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007547.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Eugeni Dodonov + eugeni at dodonov.net +
+ Fri Aug 26 01:41:58 CEST 2011 +

+
+ +
On Thu, Aug 25, 2011 at 18:48, Stew Benedict <stewbintn at gmail.com> wrote:
+
+> While I don't disagree with the theory, it's not workable with the current
+> state, as I don't have enough free cycles to think about actually updating
+> any packages an/or doing the testing. One has to keep in mind that in the
+> past life this was nearly a full time job for 2 people to identify, fix
+> build, test, release updates for the supported releases. The people that
+> have inquired about helping with security issues quickly go away when they
+> find out how inglorious(sic) it is.
+>
+
++100 to this. As former member of Mandriva Security team as well, I sign up
+under all of your words.
+
+-- 
+Eugeni Dodonov
+http://eugeni.dodonov.net/
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110825/9ee67aab/attachment-0001.html>
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007548.html b/zarb-ml/mageia-dev/2011-August/007548.html new file mode 100644 index 000000000..c285486d0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007548.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update. + + + + + + + + + +

[Mageia-dev] Copying dependencies to Updates (Testing), or changing mgaapplet to use urpmi --auto-update instead of urpmi --update.

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Fri Aug 26 01:50:21 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011 15:42:53 -0400, andre999 <andr55 at laposte.net> wrote:
+
+> I like the idea of a previous post, that when an update repo is activated, the
+> corresponding regular repo is activated as well.
+> This could be enforced by automatically activating the regular repo in such a case.
+
+Agreed.  https://bugs.mageia.org/show_bug.cgi?id=2097 has been reopened.
+That's the bug that originally showed the problem.
+
+The purpose of bug 2097 was to add an explicit requires of hugin,
+to kipi-plugins-expoblending.
+
+I thought adding hugin to updates would fix the problem, but it
+is not enough, as hugin requires enblend, which is in the
+core release repository, only.
+
+The only way to guarantee that we don't have broken updates, would
+be to copy everything shown by urpmq --requires-recursive, to
+updates testing, and then to updates.  Likewise for non-free
+and tainted updates.  That would be a nightmare of duplication.
+
+I believe mgaapplet must be modified.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007549.html b/zarb-ml/mageia-dev/2011-August/007549.html new file mode 100644 index 000000000..a8ad1762c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007549.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] Security + + + + + + + + + +

[Mageia-dev] Security

+ Michael Scherer + misc at zarb.org +
+ Fri Aug 26 02:05:12 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 à 21:53 +0200, Stefano Negro a écrit :
+> Are we affected by this bugs ?
+> http://www.ubuntu.com/usn/usn-1195-1/
+
+That's likely, given that we are shipping a unpatched version, from what
+I see.
+
+> http://www.ubuntu.com/usn/usn-1196-1/
+
+we don't ship it in 1 or cauldron for now, so no.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007550.html b/zarb-ml/mageia-dev/2011-August/007550.html new file mode 100644 index 000000000..be0f43cf5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007550.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Michael Scherer + misc at zarb.org +
+ Fri Aug 26 02:16:55 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 à 22:03 +0300, Sander Lepik a écrit :
+> 25.08.2011 21:53, Maarten Vanraes kirjutas:
+> > i believe we should package as much extensions as possible.
+> And if there is security hole in extension? have 
+
+If there is security issue in others rpms ?
+
+You realize that extensions count for around 0.1% of the software we
+have, so if they place to much burden on the security team or packagers,
+the rest of the rpm would place much more burden ?
+
+>  Do you monitor all of them? Most of them get
+> updated w/o big notice.
+
+Like most softwares we ship.
+
+>  We do not have people to monitor extensions. And it's stopping us to
+> update Firefox.
+
+There is 8 extensions in our stable release. There is 19357 binaries
+rpms, and 7612 src.rpm. 
+
+What is preventing firefox is the mozilla fondation policy, that is
+completely inadapted to any serious commitment to quality by a third
+party due to their disrespect of well established procedures, and
+disrespect for their distributors. 
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007551.html b/zarb-ml/mageia-dev/2011-August/007551.html new file mode 100644 index 000000000..c3f86964a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007551.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Unable to install Firefox 6. + + + + + + + + + +

[Mageia-dev] Unable to install Firefox 6.

+ Ernest N. Wilcox Jr. + ewilcox at bex.net +
+ Fri Aug 26 06:54:34 CEST 2011 +

+
+ +
When I ran updates today, the Firefox 6 installation returned the following 
+error:
+
+Sorry, the following package cannot be selected:
+
+- firefox-6.0-1.1.mga1.x86_64 (due to unsatisfied lib64nspr4[>= 2:4.8.9])
+
+HTH,
+
+Ernie
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007552.html b/zarb-ml/mageia-dev/2011-August/007552.html new file mode 100644 index 000000000..f889c9da4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007552.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] Unable to install Firefox 6. + + + + + + + + + +

[Mageia-dev] Unable to install Firefox 6.

+ Funda Wang + fundawang at gmail.com +
+ Fri Aug 26 08:04:03 CEST 2011 +

+
+ +
I guess somebody fogot to move nss and nspr from updates_testing to updates.
+
+2011/8/26 Ernest N. Wilcox Jr. <ewilcox at bex.net>:
+> When I ran updates today, the Firefox 6 installation returned the following
+> error:
+>
+> Sorry, the following package cannot be selected:
+>
+> - firefox-6.0-1.1.mga1.x86_64 (due to unsatisfied lib64nspr4[>= 2:4.8.9])
+>
+> HTH,
+>
+> Ernie
+>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007553.html b/zarb-ml/mageia-dev/2011-August/007553.html new file mode 100644 index 000000000..203991bcd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007553.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Unable to install Firefox 6. + + + + + + + + + +

[Mageia-dev] Unable to install Firefox 6.

+ D.Morgan + dmorganec at gmail.com +
+ Fri Aug 26 08:06:06 CEST 2011 +

+
+ +
On Fri, Aug 26, 2011 at 8:04 AM, Funda Wang <fundawang at gmail.com> wrote:
+> I guess somebody fogot to move nss and nspr from updates_testing to updates.
+>
+> 2011/8/26 Ernest N. Wilcox Jr. <ewilcox at bex.net>:
+>> When I ran updates today, the Firefox 6 installation returned the following
+>> error:
+>>
+>> Sorry, the following package cannot be selected:
+>>
+>> - firefox-6.0-1.1.mga1.x86_64 (due to unsatisfied lib64nspr4[>= 2:4.8.9])
+>>
+>> HTH,
+>>
+>> Ernie
+>>
+>
+
+yes, in progress.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007554.html b/zarb-ml/mageia-dev/2011-August/007554.html new file mode 100644 index 000000000..339d8a5a7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007554.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for help from you packagers

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 26 08:22:31 CEST 2011 +

+
+ +
Op vrijdag 26 augustus 2011 00:57:26 schreef nicolas vigier:
+> On Thu, 25 Aug 2011, Maarten Vanraes wrote:
+> > Sure, i'm packaging as fast as my RL (and mga2 dev TODO list) allows me.
+> > I guess you should ask Anssi if i'm ready or not. I must say that i'm
+> > not sure if security bugs are actually my thing though. I never hacked
+> > servers, so i don't really know much about it. But in any case, i'm
+> > packaging, and i suppose
+> 
+> Doing security updates has nothing to do with hacking servers, it's
+> looking for the right patch to fix the issue, and updating the package
+> with the patch applied.
+
+but don't you have to test it that it actually works?
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007555.html b/zarb-ml/mageia-dev/2011-August/007555.html new file mode 100644 index 000000000..740497b46 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007555.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Apache security flaw + + + + + + + + + +

[Mageia-dev] Apache security flaw

+ andre999 + andr55 at laposte.net +
+ Fri Aug 26 08:45:54 CEST 2011 +

+
+ +
An apprentice-to-be gave me this link to an apache security flaw.
+
+http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
+
+Just to let the apache maintainer & sysadmins know (in case you don't already).
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007556.html b/zarb-ml/mageia-dev/2011-August/007556.html new file mode 100644 index 000000000..67a631197 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007556.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Fri Aug 26 09:27:41 CEST 2011 +

+
+ +
On 25/08/2011 21:03, Sander Lepik wrote:
+> 25.08.2011 21:53, Maarten Vanraes kirjutas:
+>> i believe we should package as much extensions as possible.
+> And if there is security hole in extension? Do you monitor all of them? Most of them get
+> updated w/o big notice. We do not have people to monitor extensions.
+Just create another dedicated update source for youri-check if you 
+really need it.
+
+> And it's stopping us to
+> update Firefox.
+I don't see where it is stated than firefox can't get updated until all 
+extensions in the distributions work with it.
+
+The large advantage of packaged extensions is that they are managed by 
+sysadmins, instead of users, which makes a difference when they are 
+different people.
+-- 
+BOFH excuse #139:
+
+UBNC (user brain not connected)
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007557.html b/zarb-ml/mageia-dev/2011-August/007557.html new file mode 100644 index 000000000..14868b6e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007557.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Sander Lepik + sander.lepik at eesti.ee +
+ Fri Aug 26 09:50:42 CEST 2011 +

+
+ +
26.08.2011 10:27, Guillaume Rousse kirjutas:
+> I don't see where it is stated than firefox can't get updated until 
+> all extensions in the distributions work with it.
+I would call it a regression that shouldn't pass QA. One day your ads 
+ands scripts are blocked and the other day they are not. Great user 
+experience..
+> The large advantage of packaged extensions is that they are managed by 
+> sysadmins, instead of users, which makes a difference when they are 
+> different people.
+And even larger disadvantage comes in when they are not updated. Contain 
+memory leaks and so on. The biggest problem here is that the packager 
+who imported those addons is not keeping them up-to-date.
+
+Sysadmin can copy those extensions into place anyway. Then it's up to 
+him/her to keep them up-to-date. Currently we have to take care of that 
+and we don't (or if anyone wants to claim that we do then we do it 
+really poorly as there are already newer versions of addons that got 
+pushed with latest update).
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007558.html b/zarb-ml/mageia-dev/2011-August/007558.html new file mode 100644 index 000000000..e70dc5875 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007558.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Florian Hubold + doktor5000 at arcor.de +
+ Fri Aug 26 09:56:43 CEST 2011 +

+
+ +
Am 26.08.2011 09:50, schrieb Sander Lepik:
+> 26.08.2011 10:27, Guillaume Rousse kirjutas:
+>> I don't see where it is stated than firefox can't get updated until all 
+>> extensions in the distributions work with it.
+> I would call it a regression that shouldn't pass QA. One day your ads ands 
+> scripts are blocked and the other day they are not. Great user experience..
+>> The large advantage of packaged extensions is that they are managed by 
+>> sysadmins, instead of users, which makes a difference when they are 
+>> different people.
+> And even larger disadvantage comes in when they are not updated. Contain 
+> memory leaks and so on. The biggest problem here is that the packager who 
+> imported those addons is not keeping them up-to-date.
+>
+> Sysadmin can copy those extensions into place anyway. Then it's up to him/her 
+> to keep them up-to-date. Currently we have to take care of that and we don't 
+> (or if anyone wants to claim that we do then we do it really poorly as there 
+> are already newer versions of addons that got pushed with latest update).
+>
+> -- 
+> Sander
+>
+>
+Well, as there are mostly no bigger changes like in %files, can't an update of 
+those addons
+be scripted or automated halfway? So someone just needs to push this prior to a 
+Firefox update?
+
+Not saying i have an opinion pro or against packaged addons, but it is really a 
+nuisance
+as those who do the Firefox update also need to update all those addons, which 
+is unfair,
+seems to me if it's not the importer/maintainer of those addons who does the 
+update.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007559.html b/zarb-ml/mageia-dev/2011-August/007559.html new file mode 100644 index 000000000..402ed04bf --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007559.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] Apache security flaw + + + + + + + + + +

[Mageia-dev] Apache security flaw

+ Remco Rijnders + remco at webconquest.com +
+ Fri Aug 26 10:11:52 CEST 2011 +

+
+ +
On Fri, Aug 26, 2011 at 02:45:54AM -0400, andre999 wrote in
+<4E574122.1000008 at laposte.net>:
+>An apprentice-to-be gave me this link to an apache security flaw.
+>
+>http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
+>
+>Just to let the apache maintainer & sysadmins know (in case you don't already).
+
+Hi, thanks for the heads up. There is a bug open for this on bugzilla: 
+https://bugs.mageia.org/show_bug.cgi?id=2510
+
+Thanks,
+
+Remco
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110826/455b04cc/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007560.html b/zarb-ml/mageia-dev/2011-August/007560.html new file mode 100644 index 000000000..f0e86085a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007560.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Fri Aug 26 10:15:11 CEST 2011 +

+
+ +
On 26/08/2011 09:50, Sander Lepik wrote:
+> 26.08.2011 10:27, Guillaume Rousse kirjutas:
+>> I don't see where it is stated than firefox can't get updated until
+>> all extensions in the distributions work with it.
+> I would call it a regression that shouldn't pass QA. One day your ads
+> ands scripts are blocked and the other day they are not. Great user
+> experience..
+>> The large advantage of packaged extensions is that they are managed by
+>> sysadmins, instead of users, which makes a difference when they are
+>> different people.
+> And even larger disadvantage comes in when they are not updated. Contain
+> memory leaks and so on. The biggest problem here is that the packager
+> who imported those addons is not keeping them up-to-date.
+>
+> Sysadmin can copy those extensions into place anyway. Then it's up to
+> him/her to keep them up-to-date. Currently we have to take care of that
+> and we don't (or if anyone wants to claim that we do then we do it
+> really poorly as there are already newer versions of addons that got
+> pushed with latest update).
+And how are firefox extensions different than the rest of the 
+distribution for both of your points ?
+
+-- 
+BOFH excuse #283:
+
+Lawn mower blade in your fan need sharpening
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007561.html b/zarb-ml/mageia-dev/2011-August/007561.html new file mode 100644 index 000000000..ea9ce664c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007561.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Michael Scherer + misc at zarb.org +
+ Fri Aug 26 12:19:57 CEST 2011 +

+
+ +
Le jeudi 25 août 2011 à 12:17 +0100, Colin Guthrie a écrit :
+> 'Twas brillig, and Michael Scherer at 24/08/11 10:46 did gyre and gimble:
+> >> At present, a number of my machines have scripts that hook into the network 
+> >> scripts. For example, one to update the bind forwarders from the DNS IPs 
+> >> returned by pppd when the interface comes up. On another machine, a script 
+> >> that unloads the wireless broadband driver when the interface goes down (I 
+> >> think this modem has buggy firmware). Then, there are the existing scripts 
+> >> shipped in the distribution (e.g. to reload squid).
+> 
+> Just on this point in particular (as Misc has pretty much covered
+> everything I would say and more!), the need to do this will likely go
+> away very soon.
+> 
+> I don't know the full ins and outs here but AFAIK, there was/are various
+> uses of dnsmasq in Network Manager to provide caching DNS (which I
+> presume is the basic need with bind+forwarders).
+
+That's optional, but yes, you can tell to nm to manage dnsmasq or bind
+to provides caching for dns. Dnsmasq is also used to share the
+connection.
+
+To enable it, I think you need to set this :
+
+[main]
+dns=dnsmasq   
+
+( or bind, even if this is marked experimental in git )
+
+I tested on nm-0.9, my network didn't explose
+-- 
+Michael Scherer
+
+
+
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007562.html b/zarb-ml/mageia-dev/2011-August/007562.html new file mode 100644 index 000000000..656268d7f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007562.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for?help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for?help from you packagers

+ nicolas vigier + boklm at mars-attacks.org +
+ Fri Aug 26 12:33:34 CEST 2011 +

+
+ +
On Fri, 26 Aug 2011, Maarten Vanraes wrote:
+
+> Op vrijdag 26 augustus 2011 00:57:26 schreef nicolas vigier:
+> > On Thu, 25 Aug 2011, Maarten Vanraes wrote:
+> > > Sure, i'm packaging as fast as my RL (and mga2 dev TODO list) allows me.
+> > > I guess you should ask Anssi if i'm ready or not. I must say that i'm
+> > > not sure if security bugs are actually my thing though. I never hacked
+> > > servers, so i don't really know much about it. But in any case, i'm
+> > > packaging, and i suppose
+> > 
+> > Doing security updates has nothing to do with hacking servers, it's
+> > looking for the right patch to fix the issue, and updating the package
+> > with the patch applied.
+> 
+> but don't you have to test it that it actually works?
+
+And you don't know how to run an exploit ?
+
+It's interesting that when there is some work to be done, you never know
+how to do anything, but it's never a problem to talk about anything like
+an expert, give your opinion about everything, say what should be done,
+how it should be done, etc ...
+
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007563.html b/zarb-ml/mageia-dev/2011-August/007563.html new file mode 100644 index 000000000..0500e158c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007563.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default. + + + + + + + + + +

[Mageia-dev] Proposal: Deprecate draknetcenter+network init scripts after systemd becomes default.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Fri Aug 26 12:45:04 CEST 2011 +

+
+ +
'Twas brillig, and Michael Scherer at 26/08/11 11:19 did gyre and gimble:
+> Le jeudi 25 août 2011 à 12:17 +0100, Colin Guthrie a écrit :
+>> 'Twas brillig, and Michael Scherer at 24/08/11 10:46 did gyre and gimble:
+>>>> At present, a number of my machines have scripts that hook into the network 
+>>>> scripts. For example, one to update the bind forwarders from the DNS IPs 
+>>>> returned by pppd when the interface comes up. On another machine, a script 
+>>>> that unloads the wireless broadband driver when the interface goes down (I 
+>>>> think this modem has buggy firmware). Then, there are the existing scripts 
+>>>> shipped in the distribution (e.g. to reload squid).
+>>
+>> Just on this point in particular (as Misc has pretty much covered
+>> everything I would say and more!), the need to do this will likely go
+>> away very soon.
+>>
+>> I don't know the full ins and outs here but AFAIK, there was/are various
+>> uses of dnsmasq in Network Manager to provide caching DNS (which I
+>> presume is the basic need with bind+forwarders).
+> 
+> That's optional, but yes, you can tell to nm to manage dnsmasq or bind
+> to provides caching for dns. Dnsmasq is also used to share the
+> connection.
+> 
+> To enable it, I think you need to set this :
+> 
+> [main]
+> dns=dnsmasq   
+> 
+> ( or bind, even if this is marked experimental in git )
+> 
+> I tested on nm-0.9, my network didn't explose
+
+Cool, but regardless, all of this can and will be removed from NM soon
+enough anyway. The new DNS system backed into nsswitch will be much
+nicer in this regard and nscd will be able to handle all the caching needs.
+
+Not sure about shared connections, but that shouldn't be a problem
+generally as the client can just be told to use the same upstream DNS
+servers AFAIK.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007564.html b/zarb-ml/mageia-dev/2011-August/007564.html new file mode 100644 index 000000000..e00736665 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007564.html @@ -0,0 +1,110 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for?help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for?help from you packagers

+ Samuel Verschelde + stormi at laposte.net +
+ Fri Aug 26 12:49:40 CEST 2011 +

+
+ +
Le vendredi 26 août 2011 12:33:34, nicolas vigier a écrit :
+> On Fri, 26 Aug 2011, Maarten Vanraes wrote:
+> > Op vrijdag 26 augustus 2011 00:57:26 schreef nicolas vigier:
+> > > On Thu, 25 Aug 2011, Maarten Vanraes wrote:
+> > > > Sure, i'm packaging as fast as my RL (and mga2 dev TODO list) allows
+> > > > me. I guess you should ask Anssi if i'm ready or not. I must say
+> > > > that i'm not sure if security bugs are actually my thing though. I
+> > > > never hacked servers, so i don't really know much about it. But in
+> > > > any case, i'm packaging, and i suppose
+> > > 
+> > > Doing security updates has nothing to do with hacking servers, it's
+> > > looking for the right patch to fix the issue, and updating the package
+> > > with the patch applied.
+> > 
+> > but don't you have to test it that it actually works?
+> 
+> And you don't know how to run an exploit ?
+> 
+> It's interesting that when there is some work to be done, you never know
+> how to do anything, but it's never a problem to talk about anything like
+> an expert, give your opinion about everything, say what should be done,
+> how it should be done, etc ...
+
+Well, AL13N is just saying what the current policy is, see  
+http://www.mageia.org/wiki/doku.php?id=updates_policy#roles
+
+"Security team" : "Design POC (Proof Of Concept) if necessary/possible to test 
+whether updated build is immune to issue"
+
+Now, if the policy needs to be changed and security fixes no more need to be 
+verified when they can be, it will be less work for everybody, but also a lower 
+security level (people make mistakes).
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007565.html b/zarb-ml/mageia-dev/2011-August/007565.html new file mode 100644 index 000000000..90b3fcfeb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007565.html @@ -0,0 +1,130 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 26 17:22:11 CEST 2011 +

+
+ +
Op vrijdag 26 augustus 2011 09:56:43 schreef Florian Hubold:
+> Am 26.08.2011 09:50, schrieb Sander Lepik:
+> > 26.08.2011 10:27, Guillaume Rousse kirjutas:
+> >> I don't see where it is stated than firefox can't get updated until all
+> >> extensions in the distributions work with it.
+> > 
+> > I would call it a regression that shouldn't pass QA. One day your ads
+> > ands scripts are blocked and the other day they are not. Great user
+> > experience..
+> > 
+> >> The large advantage of packaged extensions is that they are managed by
+> >> sysadmins, instead of users, which makes a difference when they are
+> >> different people.
+> > 
+> > And even larger disadvantage comes in when they are not updated. Contain
+> > memory leaks and so on. The biggest problem here is that the packager who
+> > imported those addons is not keeping them up-to-date.
+> > 
+> > Sysadmin can copy those extensions into place anyway. Then it's up to
+> > him/her to keep them up-to-date. Currently we have to take care of that
+> > and we don't (or if anyone wants to claim that we do then we do it
+> > really poorly as there are already newer versions of addons that got
+> > pushed with latest update).
+> 
+> Well, as there are mostly no bigger changes like in %files, can't an update
+> of those addons
+> be scripted or automated halfway? So someone just needs to push this prior
+> to a Firefox update?
+> 
+> Not saying i have an opinion pro or against packaged addons, but it is
+> really a nuisance
+> as those who do the Firefox update also need to update all those addons,
+> which is unfair,
+> seems to me if it's not the importer/maintainer of those addons who does
+> the update.
+
+well, regardless of what we do, we should update all the packages requiring 
+any package to be sure they are working/updated, before the actual push from 
+testing to updates, imho.
+
+in fact, i think updates should be blocked from pushing until all packages 
+dependant on it or also working or updated for it. perhaps if such an addon 
+package is badly maintained, it should be dropped; if not, perhaps the move 
+from testing to updates can wait one more day...?
+
+one could argue that if it's a security fix, it should not have to wait, but 
+then one could argue that certain plugins increase security and thus those 
+should definately be working before the move from testing to updates. so i 
+guess i would call this "maintainers privilege". none the less, if this is 
+chosen, the others should follow quickly or maybe they aren't maintained well, 
+so they could be dropped.
+
+for cauldron, there is no such need.
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007566.html b/zarb-ml/mageia-dev/2011-August/007566.html new file mode 100644 index 000000000..fe6bdedfc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007566.html @@ -0,0 +1,124 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 26 17:26:20 CEST 2011 +

+
+ +
Op vrijdag 26 augustus 2011 09:56:43 schreef Florian Hubold:
+> Am 26.08.2011 09:50, schrieb Sander Lepik:
+> > 26.08.2011 10:27, Guillaume Rousse kirjutas:
+> >> I don't see where it is stated than firefox can't get updated until all
+> >> extensions in the distributions work with it.
+> > 
+> > I would call it a regression that shouldn't pass QA. One day your ads
+> > ands scripts are blocked and the other day they are not. Great user
+> > experience..
+> > 
+> >> The large advantage of packaged extensions is that they are managed by
+> >> sysadmins, instead of users, which makes a difference when they are
+> >> different people.
+> > 
+> > And even larger disadvantage comes in when they are not updated. Contain
+> > memory leaks and so on. The biggest problem here is that the packager who
+> > imported those addons is not keeping them up-to-date.
+> > 
+> > Sysadmin can copy those extensions into place anyway. Then it's up to
+> > him/her to keep them up-to-date. Currently we have to take care of that
+> > and we don't (or if anyone wants to claim that we do then we do it
+> > really poorly as there are already newer versions of addons that got
+> > pushed with latest update).
+> 
+> Well, as there are mostly no bigger changes like in %files, can't an update
+> of those addons
+> be scripted or automated halfway? So someone just needs to push this prior
+> to a Firefox update?
+> 
+> Not saying i have an opinion pro or against packaged addons, but it is
+> really a nuisance
+> as those who do the Firefox update also need to update all those addons,
+> which is unfair,
+> seems to me if it's not the importer/maintainer of those addons who does
+> the update.
+
+thinking about what i said in previous email...
+
+i myself maintain a package which contains a firefox addon. maybe maintainers 
+of dependant packages could be notified if the requirement is pushed to 
+updates_testing? so they can test if this is working or not?
+
+if anyone maintains a list:
+
+beid-middleware
+
+is the name of the package, and i haven't yet tested if it does work or not.
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007567.html b/zarb-ml/mageia-dev/2011-August/007567.html new file mode 100644 index 000000000..451c3e1cd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007567.html @@ -0,0 +1,148 @@ + + + + [Mageia-dev] Status report for Mageia 1 updates, and call for?help from you packagers + + + + + + + + + +

[Mageia-dev] Status report for Mageia 1 updates, and call for?help from you packagers

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 26 17:50:54 CEST 2011 +

+
+ +
Op vrijdag 26 augustus 2011 12:49:40 schreef Samuel Verschelde:
+> Le vendredi 26 août 2011 12:33:34, nicolas vigier a écrit :
+> > On Fri, 26 Aug 2011, Maarten Vanraes wrote:
+> > > but don't you have to test it that it actually works?
+> > 
+> > And you don't know how to run an exploit ?
+
+I have never done this before, perhaps secteam needs training for such?
+
+> > It's interesting that when there is some work to be done, you never know
+> > how to do anything, but it's never a problem to talk about anything like
+> > an expert, give your opinion about everything, say what should be done,
+> > how it should be done, etc ...
+
+Yes, that is interesting.
+
+I think it's only natural for people to have an opinion, and i know you do 
+alot of work on Mageia, but not everyone can do as much as you, and it's not 
+because i sometimes say a few things on IRC that i'm not doing anything.
+
+boklm: I must say that i feel like i have to defend myself, to your post:
+1. i don't think i speak "like an expert", but if you attribute this to me, i 
+can only think of this as a compliment, as people who speak like experts are 
+imho people who evidently know what they are talking about.
+
+2. none the less, even if i'm not planning on putting any time in somethign, 
+that doesn't refrain me from speaking my opinions, and i think i can determine 
+which solution is a quick & dirty fix, and which is a good one, IMHO. i supply 
+it, you're free to ignore it.
+
+3. as everyone, i too have priorities, even though mageia is high on it, it's 
+still below RL with wife and kids. as an estimate, except for IRC time, during 
+day and the meetings, as a reference, i think i can spend about 10-15hours on 
+mageia per week.
+
+4. even though my dayjob is in IT Security, i have never done penetration 
+testing or hacked someone. My priorities or on development and server 
+maintenance. None the less, as a "sysadmin" (dayjob), i am very interested 
+about stable systems, updates & security patches.
+
+5. i'm sure you know it'm a still a novice packager, but being a novice 
+packager doesn't refrain me to "package", and i "maintain" my packages as far 
+as i'm able to in the best of my abilities. Maybe Anssi is a stricter mentor 
+than others, but i see no issue with that.
+
+6. this may be a bad comparison, but it was my understanding that any 
+contribution, how small though it may be, is still valued. If you think my 
+contribution is not enough, or if you feel that i should just shut up if i 
+don't plan to spend some time on that, then i guess it's tough luck for you. 
+at least i'm contributing to something, i'm sure there's people reacting which 
+don't contribute at all. but as i said, you're free to ignore my advice.
+
+I hadn't planned on reacting to such posts, to not fill up the mailing list 
+with unecessary stuff as you so pointed out to me, but too much is too much, if 
+there are accusations (i perceive your post as such, though maybe i'm wrong, 
+please tell me if i am), i WILL defend myself.
+
+(imho, accusations shouldn't be on public mailing lists though)
+
+> Well, AL13N is just saying what the current policy is, see
+> http://www.mageia.org/wiki/doku.php?id=updates_policy#roles
+> 
+> "Security team" : "Design POC (Proof Of Concept) if necessary/possible to
+> test whether updated build is immune to issue"
+
+indeed, it's a requirement that i think is wanted.
+
+> Now, if the policy needs to be changed and security fixes no more need to
+> be verified when they can be, it will be less work for everybody, but also
+> a lower security level (people make mistakes).
+> 
+> Best regards
+> 
+> Samuel Verschelde
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007568.html b/zarb-ml/mageia-dev/2011-August/007568.html new file mode 100644 index 000000000..3f9f04d11 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007568.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Fri Aug 26 20:25:47 CEST 2011 +

+
+ +
On Fri, 26 Aug 2011 11:26:20 -0400, Maarten Vanraes <maarten.vanraes at gmail.com> wrote:
+
+> beid-middleware
+> is the name of the package, and i haven't yet tested if it does work or not.
+
+As I don't have the hardware, I couldn't test that it actually works.  I did
+confirm that it (and all of the firefox extensions/plugins we package) loads,
+and is not disabled by firefox 6.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007569.html b/zarb-ml/mageia-dev/2011-August/007569.html new file mode 100644 index 000000000..58a2d9c72 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007569.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Fri Aug 26 21:14:09 CEST 2011 +

+
+ +
Op vrijdag 26 augustus 2011 20:25:47 schreef David W. Hodgins:
+> On Fri, 26 Aug 2011 11:26:20 -0400, Maarten Vanraes 
+<maarten.vanraes at gmail.com> wrote:
+> > beid-middleware
+> > is the name of the package, and i haven't yet tested if it does work or
+> > not.
+> 
+> As I don't have the hardware, I couldn't test that it actually works.  I
+> did confirm that it (and all of the firefox extensions/plugins we package)
+> loads, and is not disabled by firefox 6.
+> 
+> Regards, Dave Hodgins
+
+yes, i had tested it after i sent the email.
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007570.html b/zarb-ml/mageia-dev/2011-August/007570.html new file mode 100644 index 000000000..2413c65d5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007570.html @@ -0,0 +1,135 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2

+ andre999 + andr55 at laposte.net +
+ Fri Aug 26 21:19:24 CEST 2011 +

+
+ +
Florian Hubold a écrit :
+> Am 26.08.2011 09:50, schrieb Sander Lepik:
+>> 26.08.2011 10:27, Guillaume Rousse kirjutas:
+>>> I don't see where it is stated than firefox can't get updated until
+>>> all extensions in the distributions work with it.
+>> I would call it a regression that shouldn't pass QA. One day your ads
+>> ands scripts are blocked and the other day they are not. Great user
+>> experience..
+>>> The large advantage of packaged extensions is that they are managed
+>>> by sysadmins, instead of users, which makes a difference when they
+>>> are different people.
+>> And even larger disadvantage comes in when they are not updated.
+>> Contain memory leaks and so on. The biggest problem here is that the
+>> packager who imported those addons is not keeping them up-to-date.
+>>
+>> Sysadmin can copy those extensions into place anyway. Then it's up to
+>> him/her to keep them up-to-date. Currently we have to take care of
+>> that and we don't (or if anyone wants to claim that we do then we do
+>> it really poorly as there are already newer versions of addons that
+>> got pushed with latest update).
+>>
+>> --
+>> Sander
+>>
+>>
+> Well, as there are mostly no bigger changes like in %files, can't an
+> update of those addons
+> be scripted or automated halfway? So someone just needs to push this
+> prior to a Firefox update?
+>
+> Not saying i have an opinion pro or against packaged addons, but it is
+> really a nuisance
+> as those who do the Firefox update also need to update all those addons,
+> which is unfair,
+> seems to me if it's not the importer/maintainer of those addons who does
+> the update.
+>
+I don't know how mageia-packaged firefox has changed things, but official ff 
+now automatically accepts any extensions that are compatible, updating their 
+version compatibility, and disables those using statements no longer 
+compatible.  For individual users, this should be more than adequate, since the 
+extension manager can be used to update extensions as necessary.  (As well as 
+automatic notification.  I would recommend that most ordinary users rely on 
+ff's buildin extension manager, unless they are maintaining more than 1 computer.
+
+Although I often forget about it, the case where administrators manage software 
+installation, and not ordinary users, updates are somewhat different -- but sys 
+admins would be able to deal with it (by downloading the extension and 
+installing locally) whenever the extension package is not yet available.  So 
+although it may be inconvenient, missing extension packages is not a blocker.
+Note that it would be preferable that we package ff so that compatible 
+extensions are automatically updated, if possible.  (Maybe that is already the 
+case.)
+If ff is so packaged, packaging extensions becomes less urgent.
+
+BTW, I would suggest that packaged extensions contain a note that recommends 
+that ordinary users use ff's buildin extension manager to install extensions.
+Note that ff extensions will now normally install in seamonkey (iceape) as well.
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007571.html b/zarb-ml/mageia-dev/2011-August/007571.html new file mode 100644 index 000000000..8d10f1214 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007571.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Packaging multiple versions of a same lib + + + + + + + + + +

[Mageia-dev] Packaging multiple versions of a same lib

+ Listes ( José Jorge) + lists.jjorge at free.fr +
+ Fri Aug 26 23:41:01 CEST 2011 +

+
+ +
hi, I am trying to understand how to package 'the good way' several version of 
+a library : clanlib.
+
+This library is used by several games, using version 0.6 or 0.8 or 2.1 or 2.2 
+etc. Each version is not backwards compatible.
+
+Can we still package such software? Is it in a policy I have not found?
+Thanks
+
+Zézinho
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007572.html b/zarb-ml/mageia-dev/2011-August/007572.html new file mode 100644 index 000000000..8fcc58210 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007572.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] Packaging multiple versions of a same lib + + + + + + + + + +

[Mageia-dev] Packaging multiple versions of a same lib

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Fri Aug 26 23:46:26 CEST 2011 +

+
+ +
Le Vendredi 26 Août 2011 23:41:01 Listes a écrit :
+> hi, I am trying to understand how to package 'the good way' several version
+> of a library : clanlib.
+> 
+> This library is used by several games, using version 0.6 or 0.8 or 2.1 or
+> 2.2 etc. Each version is not backwards compatible.
+> 
+> Can we still package such software? Is it in a policy I have not found?
+> Thanks
+> 
+> Zézinho
+
+Take as an example libnet, we have packed 1.0 1.2 and .1.4 i guess
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007573.html b/zarb-ml/mageia-dev/2011-August/007573.html new file mode 100644 index 000000000..35fbd2e80 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007573.html @@ -0,0 +1,137 @@ + + + + [Mageia-dev] systemd + udev 173 + gnome-shell + + + + + + + + + +

[Mageia-dev] systemd + udev 173 + gnome-shell

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Aug 27 01:46:17 CEST 2011 +

+
+ +
Hi,
+
+OK, so this combo is currently broken!
+
+Here is the explanation.
+
+With udev 172, udev-acl would apply ACLs to devices (such as the DRI
+device) when console-kit registers a new session.
+
+This included the gdm user at the login manager.
+
+systemd is gradually taking over the job of consolekit. This means that
+systemd now handles the ACL writing and login sessions should be
+visiible via systemctl-loginctl (as opposed to ck-list-sessions).
+
+
+With udev 172, both systemd and console-kit would trigger ACL writes.
+Normally this is fine, they both ultimately do the same thing.
+
+But, it seems that in actual fact, systemctl-logind wasn't ever
+registering the gdm session. Thankfully console-kit did, and thus gdm
+user got the ACLs it needed.
+
+
+Now this is where the problem arises. With udev 173, udev-acl knows
+whether or not systemd is running and if it is, it it won't write the
+ACLs. This means that even tho' gdm is still registered with
+console-kit, this will never actually trigger an ACL write.
+
+This means that gdm does not have access to /dev/dri/card0 and thus
+cannot determine if the device is capable of 3D accel. This then sets an
+atom on the root window which the gnome-session-check-accelerated binary
+looks for. This atom acts as a little cache. If it doesn't exist, it
+does a full probe and then writes the atom. The next time it runs it
+finds the atom and skips the actual checks. But as the atom was written
+by gdm when it couldn't access dri, it says no accel is available, even
+although the user can actually access it.
+
+
+I've not yet sussed out gdm is not registering with systemd... it should
+all be automatic via pam... but something somewhere is failing :s
+
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007574.html b/zarb-ml/mageia-dev/2011-August/007574.html new file mode 100644 index 000000000..6b6a8e5a5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007574.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ Bill Gatliff + bgat at billgatliff.com +
+ Wed Aug 24 18:26:00 CEST 2011 +

+
+ +
Luke:
+
+
+Step back from the keyboard just a bit.  :)
+
+It's true that the glass isn't completely full--- but it's pretty
+darned full!  And we wouldn't be discussing the various GPL and other
+violations that you cite were it not for the overwhelming successes of
+Free Software, ARM, Linux, and Android.
+
+We are well past debating the merits of Free Software et. al, which
+itself is a huge milestone that we need to recognize.  Now it's time
+to let the lawyers do their jobs.  And they will, because there are
+tremendous sums of money at play.  Money that wouldn't be there if it
+weren't for us developers.  But we need to stay out of their way,
+while at the same time taking care to continue producing tangible
+things that are worth fighting over.
+
+As developers, we've won.  Deal with it.  Revel in it.  And then get over it.
+
+I have observed all the hand-wringing regarding the state of ARM
+Linux, and it's obvious to everyone that there is still work to be
+done.  ARM isn't like PCs, and that's obviously inconvenient for Linus
+but it's an essential part of ARM's success.  Russell King has been
+overworked for a decade or more, attempting through sheer force of
+human/developer will to keep ARM Linux from running off the rails.
+
+As far as ARM Linux is concerned, I think we're dangerously close to
+being smothered by our own success.   We have to learn to work
+smarter, because we can't work any harder.  And I applaud Linaro and
+the countless others for recognizing this problem and looking for ways
+to resolve it.
+
+I for one would love to participate in the ARM Summit, but I'm a sole
+proprietor without an expense account to charge the travel costs to
+and they are too large for me to carry personally.  I suspect I'm not
+the only one in that situation.
+
+The fact that there has been little response to the ARM Summit doesn't
+mean that nobody cares or that the problems seem to large to solve.
+It just means that we're going to have to find a different way to get
+this work done.
+
+
+b.g.
+-- 
+Bill Gatliff
+bgat at billgatliff.com
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007575.html b/zarb-ml/mageia-dev/2011-August/007575.html new file mode 100644 index 000000000..b297825e0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007575.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ david at lang.hm + david at lang.hm +
+ Thu Aug 25 01:55:14 CEST 2011 +

+
+ +
On Wed, 24 Aug 2011, Bill Gatliff wrote:
+
+> I have observed all the hand-wringing regarding the state of ARM
+> Linux, and it's obvious to everyone that there is still work to be
+> done.  ARM isn't like PCs, and that's obviously inconvenient for Linus
+> but it's an essential part of ARM's success.
+
+I think that the thing being disputed isn't that ARM is different from 
+PCs, but rather the issue that different ARM SOs do the same thing in 
+different ways.
+
+in the early days of the PC we had the same issues (those who were around 
+to remember the 'almost' PC compatible machines (from some of the biggest 
+names in the business). they all thought that they had good reasons to do 
+things differently, but over time they all changed to hide the differences 
+from the system.
+
+ARM is currently in worse shape than the PC market ever was in this 
+aspect, but in this case it's less a matter of getting the hardware guys 
+to change what they do than it is to get better documentation of what the 
+hardware is really doing and not duplicating drivers for cases where the 
+right answer is just replacing a constant with a variable (just as an 
+example of the very common case where the same component is wired to a 
+different address)
+
+David Lang
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007576.html b/zarb-ml/mageia-dev/2011-August/007576.html new file mode 100644 index 000000000..e2f298966 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007576.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ Bill Gatliff + bgat at billgatliff.com +
+ Fri Aug 26 18:11:41 CEST 2011 +

+
+ +
David:
+
+On Wed, Aug 24, 2011 at 6:55 PM,  <david at lang.hm> wrote:
+> ARM is currently in worse shape than the PC market ever was in this aspect,
+> but in this case it's less a matter of getting the hardware guys to change
+> what they do than it is to get better documentation of what the hardware is
+> really doing and not duplicating drivers for cases where the right answer is
+> just replacing a constant with a variable (just as an example of the very
+> common case where the same component is wired to a different address)
+
+I agree.
+
+Maybe Linaro or an equivalent organization could provide a "ARM kernel
+janitor" service to the community, where they refactor existing ARM
+platform/driver code to make it more common.  This is something that's
+difficult for a single person with experience in only one or two SoCs
+to do, but it would be pretty straightforward work for a team of three
+or four people with broad coverage of the SoC devices the kernel
+supports now.
+
+As such refactoring consolidated larger and larger chunks of kernel
+code, new designs would gravitate towards those consolidated
+implementations because they would be the dominant references.
+
+
+b.g.
+-- 
+Bill Gatliff
+bgat at billgatliff.com
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007577.html b/zarb-ml/mageia-dev/2011-August/007577.html new file mode 100644 index 000000000..fabede0bd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007577.html @@ -0,0 +1,133 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ Bill Gatliff + bgat at billgatliff.com +
+ Fri Aug 26 20:41:55 CEST 2011 +

+
+ +
Russell:
+
+On Fri, Aug 26, 2011 at 11:35 AM, Russell King - ARM Linux
+<linux at arm.linux.org.uk> wrote:
+> On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
+>> As such refactoring consolidated larger and larger chunks of kernel
+>> code, new designs would gravitate towards those consolidated
+>> implementations because they would be the dominant references.
+>
+> Don't bet on it.  That's not how it works (unfortunately.)
+
+I wasn't being clear.
+
+The Linux community isn't large enough to dictate to ARM SoC designers
+how their hardware should work--- mostly because the "Linux community"
+doesn't buy chips, corporations do.  And it has been my experience
+that the parts of corporations that negotiate deals for the hardware
+aren't populated with the developers of the drivers for said hardware.
+
+What I meant was that as new hardware becomes available, if we have
+strong driver models then driver authors will adopt those APIs rather
+than inventing their own.
+
+I'm thinking about GPIO before gpiolib, for example.  Or the current
+state of PWM.
+
+> This "need to be different" is so heavily embedded in the mindset of the
+> hardware people that I doubt "providing consolidated implementations"
+> will make the blind bit of difference.  I doubt that hardware people
+> coming up with these abominations even care one bit about what's in
+> the kernel.
+
+I don't routinely see a "need to be different" as existing strictly
+for its' own sake, even with the hardware guys.  Rather, I see a lot
+of developers (hardware and software) that are so consumed with their
+own requirements and deadlines that they don't get the chance to step
+back and see the bigger picture.  The resulting fragmentation is a
+symptom, not the disease itself.
+
+And honestly, some of the fragmentation is a really good thing.  I
+love how Atmel does their GPIO controllers on the SAM-series parts,
+for example.  The SODR and CODR registers are a godsend for concurrent
+code.  We wouldn't have such treats if everybody did things the same
+way.
+
+So I'm generally ambivalent to the hardware situation.  But that
+doesn't mean that the software has to be equally fragmented.  In fact,
+I think the hardware situation necessitates that we pay particular
+attention to NOT fragmenting the drivers for said hardware.  Gpiolib
+proves that is possible, something I didn't think I would find myself
+saying when David Brownell started his effort.  I'm glad he proved me
+wrong.
+
+
+
+b.g.
+-- 
+Bill Gatliff
+bgat at billgatliff.com
+
+ + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007578.html b/zarb-ml/mageia-dev/2011-August/007578.html new file mode 100644 index 000000000..1d71d52bc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007578.html @@ -0,0 +1,106 @@ + + + + [Mageia-dev] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM summit at Plumbers 2011

+ Steve McIntyre + steve.mcintyre at linaro.org +
+ Tue Aug 23 18:11:34 CEST 2011 +

+
+ +
On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote:
+>Hi folks,
+>
+>Following on from the founding of the cross-distro ARM mailing list,
+>I'd like to propose an ARM summit at this year's Linux Plumbers
+>conference [1]. I'm hoping for a slot on Thursday evening, but this
+>remains to be confirmed at this point.
+>
+>We had some lively discussion about the state of ARM Linux distros at
+>the Linaro Connect [2] event in Cambridge last week. It rapidly became
+>clear that some of the topics we discussed deserve a wider audience,
+>so we're suggesting a meetup at Plumbers for that bigger
+>discussion. The initial proposed agenda is:
+>
+> * ARM hard-float
+>   + What is it and why does it matter?
+>   + How can distributions keep compatible (i.e. gcc triplet to
+>     describe the port)?
+>
+> * Adding support for ARM as an architecture to the Linux Standard
+>   Base (LSB)
+>   + Does it matter?
+>   + What's needed?
+>
+> * FHS - multi-arch coming soon, how do we proceed?
+>
+> * 3D support on ARM platforms
+>   + Open GL vs. GLES - which is appropriate?
+>
+>but I'm sure that other people will think of more issues they'd like
+>to discuss. :-)
+>
+>If you wish to attend, please reply to the cross-distro list and let
+>us know to expect you. Make sure you're registered to attend Plumbers
+>Conf, and get your travel and accommodation organised ASAP.
+>
+>[1] http://www.linuxplumbersconf.org/2011/
+>[2] http://connect.linaro.org/
+
+UPDATE: we've not had many people confirm interest in this event yet,
+which is a shame. If you would like to join us for this session,
+please reply and let me know. If we don't get enough interest by the
+end of Sunday (28th August), then we'll have to cancel the meeting.
+
+Cheers,
+-- 
+Steve McIntyre                                steve.mcintyre at linaro.org
+<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007579.html b/zarb-ml/mageia-dev/2011-August/007579.html new file mode 100644 index 000000000..83732bc47 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007579.html @@ -0,0 +1,119 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ Gordan Bobic + gordan at bobich.net +
+ Tue Aug 23 18:25:34 CEST 2011 +

+
+ +
 On Tue, 23 Aug 2011 17:11:34 +0100, Steve McIntyre 
+ <steve.mcintyre at linaro.org> wrote:
+> On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote:
+>>Hi folks,
+>>
+>>Following on from the founding of the cross-distro ARM mailing list,
+>>I'd like to propose an ARM summit at this year's Linux Plumbers
+>>conference [1]. I'm hoping for a slot on Thursday evening, but this
+>>remains to be confirmed at this point.
+>>
+>>We had some lively discussion about the state of ARM Linux distros at
+>>the Linaro Connect [2] event in Cambridge last week. It rapidly 
+>> became
+>>clear that some of the topics we discussed deserve a wider audience,
+>>so we're suggesting a meetup at Plumbers for that bigger
+>>discussion. The initial proposed agenda is:
+>>
+>> * ARM hard-float
+>>   + What is it and why does it matter?
+>>   + How can distributions keep compatible (i.e. gcc triplet to
+>>     describe the port)?
+>>
+>> * Adding support for ARM as an architecture to the Linux Standard
+>>   Base (LSB)
+>>   + Does it matter?
+>>   + What's needed?
+>>
+>> * FHS - multi-arch coming soon, how do we proceed?
+>>
+>> * 3D support on ARM platforms
+>>   + Open GL vs. GLES - which is appropriate?
+>>
+>>but I'm sure that other people will think of more issues they'd like
+>>to discuss. :-)
+>>
+>>If you wish to attend, please reply to the cross-distro list and let
+>>us know to expect you. Make sure you're registered to attend Plumbers
+>>Conf, and get your travel and accommodation organised ASAP.
+>>
+>>[1] http://www.linuxplumbersconf.org/2011/
+>>[2] http://connect.linaro.org/
+>
+> UPDATE: we've not had many people confirm interest in this event yet,
+> which is a shame. If you would like to join us for this session,
+> please reply and let me know. If we don't get enough interest by the
+> end of Sunday (28th August), then we'll have to cancel the meeting.
+
+ Unfortunately there is no way I could make it, but on the subject of 3D 
+ support on ARM, Luke recently mentioned something that initially seemed 
+ outlandish but upon closer examination doesn't seem like a bad idea. As 
+ we all know, the state of openness of specifications of commonly used 
+ ARM 3D GPUs is at best dire. What has been proposed is a bit radical, 
+ but it doesn't actually seem that implausible. Specifically, combining 
+ Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and 
+ the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea 
+ is to have an OGP GPU in firmware in FPGA. In terms of the power budget, 
+ it seems to work relatively sanely considering what it is, and it is as 
+ ideal as it gets as far as openness and flexibility goes.
+
+ I just thought it's worthy of a mention.
+
+ Gordan
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007580.html b/zarb-ml/mageia-dev/2011-August/007580.html new file mode 100644 index 000000000..a274b97e2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007580.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011

+ omalleys at msu.edu + omalleys at msu.edu +
+ Tue Aug 23 20:01:43 CEST 2011 +

+
+ +
Quoting Gordan Bobic <gordan at bobich.net>:
+>  Unfortunately there is no way I could make it, but on the subject of 3D
+>  support on ARM, Luke recently mentioned something that initially seemed
+>  outlandish but upon closer examination doesn't seem like a bad idea. As
+>  we all know, the state of openness of specifications of commonly used
+>  ARM 3D GPUs is at best dire. What has been proposed is a bit radical,
+>  but it doesn't actually seem that implausible. Specifically, combining
+>  Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and
+>  the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea
+>  is to have an OGP GPU in firmware in FPGA. In terms of the power budget,
+>  it seems to work relatively sanely considering what it is, and it is as
+>  ideal as it gets as far as openness and flexibility goes.
+>
+>  I just thought it's worthy of a mention.
+
+It does seem outlandish, but it is kind of cool. Is it going to give  
+enough 3d speed? The next gen tegra is supposed to have a 24 core GPU.
+
+It is probably more sane then my idea of just having a test suite from  
+digital video out -> digital video receiver/capture card to get known  
+test results. Then you could set up a hinted genetic algorithm based  
+on a comparison. It would only work with digital video signals though.
+
+
+
+
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007581.html b/zarb-ml/mageia-dev/2011-August/007581.html new file mode 100644 index 000000000..7dc02ebe8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007581.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011

+ Gordan Bobic + gordan at bobich.net +
+ Wed Aug 24 00:26:00 CEST 2011 +

+
+ +
On 08/23/2011 07:01 PM, omalleys at msu.edu wrote:
+> Quoting Gordan Bobic <gordan at bobich.net>:
+>> Unfortunately there is no way I could make it, but on the subject of 3D
+>> support on ARM, Luke recently mentioned something that initially seemed
+>> outlandish but upon closer examination doesn't seem like a bad idea. As
+>> we all know, the state of openness of specifications of commonly used
+>> ARM 3D GPUs is at best dire. What has been proposed is a bit radical,
+>> but it doesn't actually seem that implausible. Specifically, combining
+>> Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and
+>> the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea
+>> is to have an OGP GPU in firmware in FPGA. In terms of the power budget,
+>> it seems to work relatively sanely considering what it is, and it is as
+>> ideal as it gets as far as openness and flexibility goes.
+>>
+>> I just thought it's worthy of a mention.
+>
+> It does seem outlandish, but it is kind of cool. Is it going to give
+> enough 3d speed? The next gen tegra is supposed to have a 24 core GPU.
+
+If you can quantify what "enough 3D speed" means, then perhaps that can 
+be assessed. There really aren't many applications around at the moment 
+to make this an issue. I'd be more interested in it's ability to decode 
+1080p.
+
+Then again - it's FPGA! You can load a different "firmware" depending on 
+whether you need 1080p decoding or 3D rendering, or some other kind of 
+specialized DSP offload with only bare minimal VGA. :)
+
+Personally, I think OGP would be worth it even if just for the fact that 
+we would no longer have to beg (in vain) the vendors for decent drivers 
+or published specs. The added flexibility on top is just a "free extra". :)
+
+Gordan
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007582.html b/zarb-ml/mageia-dev/2011-August/007582.html new file mode 100644 index 000000000..cab37023c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007582.html @@ -0,0 +1,111 @@ + + + + [Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011

+ Luke Kenneth Casson Leighton + lkcl at lkcl.net +
+ Wed Aug 24 13:00:43 CEST 2011 +

+
+ +
[ok i'm going to do another cross-post in a bit which will give some
+background and also perhaps some other topics for discussion, but i
+wanted to cover this first.  apologies for people for whom this is
+just noise]
+
+On Tue, Aug 23, 2011 at 7:01 PM,  <omalleys at msu.edu> wrote:
+
+>>  the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea
+>>  is to have an OGP GPU in firmware in FPGA. In terms of the power budget,
+>>  it seems to work relatively sanely considering what it is, and it is as
+>>  ideal as it gets as far as openness and flexibility goes.
+>>
+>>  I just thought it's worthy of a mention.
+>
+> It does seem outlandish, but it is kind of cool. Is it going to give enough
+> 3d speed? The next gen tegra is supposed to have a 24 core GPU.
+
+ if nvidia have a published announcement of their plans to release a
+fully free-software-compliant 3D driver to match the proprietary
+hardware, then that would be brilliant news [about their next gen
+GPU].
+
+ about the zynq idea: it actually doesn't matter if it's "enough".
+the very fact that free software developers - and people who want to
+be free software developers - around the world could even _remotely_
+consider buying one of these for an affordable price instead of $750
+for the present OGP card means that more people can at least begin to
+try to address the unbelievably wide and very discouraging gap between
+us and proprietary 3D hardware.
+
+ the NREs on producing a set of masks are _only_ $250,000 if you are a
+taiwanese company asking TSMC, but for everyone else they're at least
+$2 million.  the development costs if you use off-the-shelf tools
+before you even _get_ to the point where you can ask a fab to produce
+those masks spiral out of control (Mentor Graphics charges something
+like $250,000 per month or maybe per week per user; NREs for
+peripheral hard macros can be $50k to $100k each etc. etc.), taking
+the total development costs in many cases to well above $USD 30
+million.
+
+ and that's excluding all that "proprietary software" which of course
+is utterly useless without the corresponding hardware but, because of
+USA Accountancy Rules, where "IP" can be added to the books to
+increase the value of a company, there's a strong financial
+disincentive to consider just "givvin it aww away 4 fwee".
+
+ and here we are with a CPU which could well be around the $25 - $30
+mark in large enough volumes, presented with the possibility to say
+"**** u all, you proprietary GPU companies and your greed, fear,
+patent warfare and lack of willingness to collaborate and cooperate".
+
+ok maybe not those exact words but you know what i mean :)
+
+l.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007583.html b/zarb-ml/mageia-dev/2011-August/007583.html new file mode 100644 index 000000000..beb7ba7ef --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007583.html @@ -0,0 +1,121 @@ + + + + [Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011

+ Gordan Bobic + gordan at bobich.net +
+ Wed Aug 24 13:10:44 CEST 2011 +

+
+ +
 On Wed, 24 Aug 2011 12:00:43 +0100, Luke Kenneth Casson Leighton 
+ <lkcl at lkcl.net> wrote:
+> [ok i'm going to do another cross-post in a bit which will give some
+> background and also perhaps some other topics for discussion, but i
+> wanted to cover this first.  apologies for people for whom this is
+> just noise]
+>
+> On Tue, Aug 23, 2011 at 7:01 PM,  <omalleys at msu.edu> wrote:
+>
+>>>  the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The 
+>>> idea
+>>>  is to have an OGP GPU in firmware in FPGA. In terms of the power 
+>>> budget,
+>>>  it seems to work relatively sanely considering what it is, and it 
+>>> is as
+>>>  ideal as it gets as far as openness and flexibility goes.
+>>>
+>>>  I just thought it's worthy of a mention.
+>>
+>> It does seem outlandish, but it is kind of cool. Is it going to give 
+>> enough
+>> 3d speed? The next gen tegra is supposed to have a 24 core GPU.
+>
+>  if nvidia have a published announcement of their plans to release a
+> fully free-software-compliant 3D driver to match the proprietary
+> hardware, then that would be brilliant news [about their next gen
+> GPU].
+>
+>  about the zynq idea: it actually doesn't matter if it's "enough".
+> the very fact that free software developers - and people who want to
+> be free software developers - around the world could even _remotely_
+> consider buying one of these for an affordable price instead of $750
+> for the present OGP card means that more people can at least begin to
+> try to address the unbelievably wide and very discouraging gap 
+> between
+> us and proprietary 3D hardware.
+>
+>  the NREs on producing a set of masks are _only_ $250,000 if you are 
+> a
+> taiwanese company asking TSMC, but for everyone else they're at least
+> $2 million.  the development costs if you use off-the-shelf tools
+> before you even _get_ to the point where you can ask a fab to produce
+> those masks spiral out of control (Mentor Graphics charges something
+> like $250,000 per month or maybe per week per user; NREs for
+> peripheral hard macros can be $50k to $100k each etc. etc.), taking
+> the total development costs in many cases to well above $USD 30
+> million.
+>
+>  and that's excluding all that "proprietary software" which of course
+> is utterly useless without the corresponding hardware but, because of
+> USA Accountancy Rules, where "IP" can be added to the books to
+> increase the value of a company, there's a strong financial
+> disincentive to consider just "givvin it aww away 4 fwee".
+>
+>  and here we are with a CPU which could well be around the $25 - $30
+> mark in large enough volumes, presented with the possibility to say
+> "**** u all, you proprietary GPU companies and your greed, fear,
+> patent warfare and lack of willingness to collaborate and cooperate".
+>
+> ok maybe not those exact words but you know what i mean :)
+
+ I quite like the wording, actually. :)
+
+ Gordan
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007584.html b/zarb-ml/mageia-dev/2011-August/007584.html new file mode 100644 index 000000000..e451a7828 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007584.html @@ -0,0 +1,265 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ Luke Kenneth Casson Leighton + lkcl at lkcl.net +
+ Wed Aug 24 15:41:36 CEST 2011 +

+
+ +
On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote:
+>Hi folks,
+>
+>Following on from the founding of the cross-distro ARM mailing list,
+>I'd like to propose an ARM summit at this year's Linux Plumbers
+>conference [1]. I'm hoping for a slot on Thursday evening, but this
+>remains to be confirmed at this point.
+>
+>We had some lively discussion about the state of ARM Linux distros at
+>the Linaro Connect [2] event in Cambridge last week. It rapidly became
+>clear that some of the topics we discussed deserve a wider audience,
+>so we're suggesting a meetup at Plumbers for that bigger
+>discussion.
+
+ok.  allow me to give some perspective and background as to why i
+believe that a bigger discussion is important, and to whom that
+discussion is important.
+
+a few years ago i read what seems like a silly book, called "The
+Strategy-Focussed Organisation".  sounds trite, but i was advised to
+read it when i proposed some ideas and was confronted with the very
+valid question "why should i [a lowly "developer"] _care_ about this
+'strategy' that you are proposing?" (fortunately the person who asked
+the question was the same one who advised me to read this "silly"
+book).
+
+ it's a tough one, isn't it?  why should any of us - as free software
+developers - _care_ about the state of ARM Linux?  you're getting on
+with the truly crucial task of managing the distro that you're
+committed to.  it's a focussed job: it's a vital role, and you should
+not let anyone tell you otherwise.
+
+yet... and this is the bit that this silly book explained: it's just
+as important to know where *your* role "fits in" with what else is
+going on.  linaro, for example, as you no doubt well know, is tasked
+(by its subscribers who pay $1m / year) with sorting out vital
+underlying infrastructure that ties what *you* are doing in with the
+subscriber's ARM CPUs.  you're doing the user-facing stuff; they're
+doing the CPU-facing stuff.  that's *their* strategic role: in
+concrete terms it means sorting out gcc with ARM optimisations, and it
+means seeking out and/or increasing the number of areas of shared and
+refactored code across as many places as possible, in order to reduce
+the software development effort required of their subscribers.  linux
+kernel.  device tree.  LSB.  (and, it has to be said, _if_ the stupid,
+stupid 3D GPU companies got with the picture, linaro could well take
+gallium3d for example under its wing, too).
+
+so the key question is: if linaro is "taking care of" this aspect,
+because that's linaro's role, then why _should_ any distro maintainer
+care?  yes they should be aware of what's happening, but there's no
+real incentive to get pro-actively involved, is there?  all that's
+required is passive acceptance of the work filtering down from
+linaro...
+
+and this perhaps explains the lack of response to the proposed meetup, steve.
+
+[the other reason is that yes, although _discussion_ can take place
+about 3D GPUs, we as free software developers feel "powerless to act"
+in the face of so much money.  despite the fact (which personally
+makes me extremely angry) that without our overall contribution these
+companies simply would not have a gnu/linux distro or a linux kernel
+on which to make that money].
+
+so, the important question to ask, then, is what *is* good motivation
+to take action?  if, indeed, any action need be taken at all, which is
+a perfectly reasonable conclusion to reach.  not that i personally
+agree with that, but i can live with it :)
+
+and, to answer that question, i feel it's important to take into
+account some context and background.  many of these things you will
+already be aware of, but let me put them all together, here.
+
+take a deep breath...
+
+* with the rise of android, Matt Codon shows us an empirical glimpse
+into the blatant state of GPL violations by OEMs taking place on the
+Linux Kernel and more: http://www.codon.org.uk/~mjg59/android_tablets/
+
+* many android vendors have lost the right to use linux kernel source
+code. this article is the most insightful and non-aggrandising i've
+yet found into the GPL violations situation and its consequences:
+http://fosspatents.blogspot.com/2011/08/most-android-vendors-lost-their-linux.html
+
+* Our Linus declared in april that he was getting fed up with the
+state of the ARM Linux Kernel.  my take on this is that there is an
+overwhelming amount of "selfishness" creeping into the Linux Kernel
+development. Our Linus has also recently stated that his passion is
+actually low-level device driver development.
+http://thread.gmane.org/gmane.linux.kernel/1114495/focus=112007
+
+* Russell King, the ARM maintainer, has completely lost all motivation
+to work on the task of merging ARM Linux patches.  with the amount of
+selfishness that has been going on for so many years, i am surprised
+he's tolerated it this long.
+http://article.gmane.org/gmane.linux.kernel/1121096
+
+* I've seen proposed solutions and many many descriptions of the
+problems caused by the rise of ARM Linux, but none of them look at
+this from an "overview" perspective, which is that the core of the
+problem is lack of cooperation and collaboration - precisely counter
+to the whole purpose of Free Software.  here, i hope and believe, is a
+small insight into that, along with some references and links:
+http://lkcl.net/linux/linux-selfish.vs.cooperation.html
+
+* an attempt last year to motivate people to get together to buy an
+early ARM Laptop (the CT-PC89E) which would have been available at the
+time in mass-volume for $102, the design of which turned out to be
+sponsored by China Telecom, found more than just GPL violations on the
+Linux Kernel and u-boot source code.  from this chinese factory (who
+were purely hardware assemblers and middle-men.  girls actually) one
+of the ICs responsible for keyboard and mouse was "black" - no
+markings; the gnu/linux distribution "mid-linux.com" was *also* a
+GPL-violating distro which may have links to China's Great Firewalled
+"Red Flag" Linux; the ODM (who licensed the design from China Telecom)
+was instructed to offer us nothing more than China Telecom 3G CDMA
+modems (useless for Europe which needs UMTS); successful
+reverse-engineering of a linux kernel onto the device encountered
+evidence of "security" attempts to lock the GPL-violating kernel to
+the device (which we easily replaced); when my associate presented
+Debian GNU/Linux running on the device at a meeting with the ODM and
+told them it had an entirely GPL-compliant and entirely Free GNU/Linux
+Distro on it, which we wanted to sell across the world, they went very
+very quiet.  lastly, Frans, who created the Debian Installer Port for
+the 20 people who bought the CT-PC89E samples, is dead.  by suicide.
+i leave these as facts - stated facts - and allow YOU to sift through
+them and choose which ones to put together, to make your own
+conclusion(s).  they may OR MAY NOT be related.
+
+* the FreedomBox Foundation has a clearly-stated goal, to create the
+software around small boxes that provide "transition" technology off
+of non-free and privacy-invasive servers that are all too tempting for
+corporations and governments to interfere with or peek at... yet there
+is a clear disconnect and a very wide gap between stating the goal and
+actually taking any action to go about creating the software, which
+has clearly not been addressed.  The Elephant is in the room, here...
+
+* the UK government was praised by China for looking into possible
+censorship of the Internet:
+http://yro.slashdot.org/story/11/08/16/0019248/China-Praises-UK-Internet-Censorship-Plan
+http://news.slashdot.org/story/11/08/22/217206/Twitter-To-Meet-With-UK-Government-About-Riots
+
+* amongst many other things, the USA continues to take illegal control
+of DNS zones, destroying the trust and sovereignty of the very fabric
+of the Internet.
+
+* nokia (who received a $EUR 0.5 billion loan from the European
+Investment Bank just a few years ago) - our darlings who were using
+debian as the basis for their smartphone strategy - bought the
+proprietary and non-community-driven late-GPL-releasing Trolltech, and
+then recently pulled out of meego _and_ the open-sourcing of Series 60
+and out of free software entirely with the famous "burning platform"
+quote from their CEO.
+
+* HP has very wisely just fire-sold their entire tablet stock in a way
+that will completely recoup their capital outlay (if it has a
+resistive touchscreen then the BOM is an estimated $80 and the tablets
+have sold out in a few days at $98: $18 is just enough wiggle-room for
+shipping as well as possibly even a modest profit, particularly on the
+32gb version @ retail $150.  if it's capacitive, the BOM will have an
+extra appx $30 on top, meaning they'll get all the working capital
+back... just).
+
+* lastly and perhaps most crucially, it has to be said that this "Peak
+Oil" thing, along with the "Global Warming" thing, is undeniably
+taking a grip on the world, which leaves people with a choice to
+*readily* face it (i.e. be prepared and better yet as well get _other
+people_ prepared, as a secondary priority), or to face the upcoming
+situation in a "Crisis" mode, which, if faced *as* a "Crisis" is quite
+likely to result in your death.  people such as joey hess clearly get
+it: joey now lives entirely off-grid, and yet still has an internet
+connection. in a forest.  i live in a remote area of scotland, now, in
+a place which has its own well, and we're growing our own food.  it's
+still a work-in-progress.
+
+
+i could continue with this, and expand it with more examples, but let
+me make some summary points:
+
+* we're intelligent people, who have achieved a great deal
+* we're responsible for creating the software that underpins today's
+computer technology
+* governments are waltzing in and doing whatever they feel like.
+* corporations are creating hardware WITHOUT taking us into account,
+and are grabbing with both hands and returning nothing.
+
+ in short: we - intelligent Free Software Developers - are having the
+piss taken out of us, to put it mildly.
+
+so - i tell you what: i'm going to stop there, for now.  i'm going to
+leave it at that, for people to think, digest the above, and perhaps
+come up with some answers [i have some ideas, but i want to know most
+crucially if people are willing to hear them!].  and, to give you an
+opportunity to think: is this my problem, at all?  do i actually care?
+ what _is_ my role?  and, if i _do_ care, what could i do if i combine
+with a number of other people who also care?
+
+i trust that you can see that the scope of the background goes wayyy
+beyond that which linaro is tasked with, so i hope - i really do -
+that you feel that this really is something which you care about and
+can actually feel motivated to consider that _some_ sort of action
+needs to be taken, beyond the very valuable tasks and roles which you
+are presently carrying out.
+
+if, on an individual basis, you feel that the answer is "no", it's not
+my problem, then i can only apologise for having taken up your time,
+and wish you good luck with the future.
+
+l.
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007585.html b/zarb-ml/mageia-dev/2011-August/007585.html new file mode 100644 index 000000000..783afc93d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007585.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ Russell King - ARM Linux + linux at arm.linux.org.uk +
+ Fri Aug 26 18:35:02 CEST 2011 +

+
+ +
On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
+> As such refactoring consolidated larger and larger chunks of kernel
+> code, new designs would gravitate towards those consolidated
+> implementations because they would be the dominant references.
+
+Don't bet on it.  That's not how it works (unfortunately.)
+
+Just look at the many serial port inventions dreamt up by SoC designers -
+everyone is different from each other.  Now consider: why didn't they use
+a well established standard 16550A or later design?
+
+Also consider why ARM Ltd designed the PL010 and PL011 primecells which
+are different from the 16550A.
+
+This "need to be different" is so heavily embedded in the mindset of the
+hardware people that I doubt "providing consolidated implementations"
+will make the blind bit of difference.  I doubt that hardware people
+coming up with these abominations even care one bit about what's in
+the kernel.
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007586.html b/zarb-ml/mageia-dev/2011-August/007586.html new file mode 100644 index 000000000..71bbbf2c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007586.html @@ -0,0 +1,228 @@ + + + + [Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

+ Luke Kenneth Casson Leighton + lkcl at lkcl.net +
+ Fri Aug 26 23:02:09 CEST 2011 +

+
+ +
russell, good to hear from you.
+
+can i recommend, that although this is a really wide set of
+cross-posting on a discussion that underpins pretty much everything
+(except gnu/hurd and minix) because it's linux kernel, that, just as
+steve kindly advised, we keep this to e.g.
+cross-distro at lists.linaro.org?  i'll be doing that from now on [after
+this] perhaps including arm-netbooks as well, but will be taking off
+all the distros.
+
+so - folks, let's be clear: please move this discussion to
+cross-distro at lists.linaro.org, and, if it's worthwhile discussing in
+person, please do contact steve, so he can keep the slot open at the
+Plumbers 2011 summit.
+
+On Fri, Aug 26, 2011 at 5:35 PM, Russell King - ARM Linux
+<linux at arm.linux.org.uk> wrote:
+> On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
+>> As such refactoring consolidated larger and larger chunks of kernel
+>> code, new designs would gravitate towards those consolidated
+>> implementations because they would be the dominant references.
+>
+> Don't bet on it.  That's not how it works (unfortunately.)
+>
+> Just look at the many serial port inventions dreamt up by SoC designers -
+> everyone is different from each other.  Now consider: why didn't they use
+> a well established standard 16550A or later design?
+
+ *sigh* because they wanted to save power.  or pins.  or... just be
+bloody-minded.
+
+> This "need to be different" is so heavily embedded in the mindset of the
+> hardware people that I doubt "providing consolidated implementations"
+> will make the blind bit of difference.
+
+ i think... russell... after they are told, repeatedly, "no, you can't
+have that pile of junk in the mainline linux kernel, Get With The
+Programme", you'd think that, cumulatively if they end up having to
+maintain a 6mb patch full of such shit, they _might_ get with the
+programme?
+
+ and if they don't, well.... who honestly cares?  if they don't, it's
+not *your* problem, is it?  _they_ pay their employees to continue to
+main a pile of junk, instead of spongeing off of _your_ time (and
+linus's, and everyone else's in the Free Software Community).
+
+
+>  I doubt that hardware people
+> coming up with these abominations even care one bit about what's in
+> the kernel.
+
+ then don't f******g make it _your_ problem, or anyone else's, upstream!! :)
+
+ this is the core of the proposal that i have been advocating: if it's
+"selfish", i.e. as bill and many many others clearly agree with "if
+the bang-per-buck ratio is on the low side" then keep it *out* the
+mainline linux kernel...
+
+ ... and that really is the end of the matter.
+
+the sensible people that i've been talking to about this are truly
+puzzled as to why the principles of "cooperation and collaboration"
+behind free software are just being... completely ignored, in
+something as vital as The Linux Kernel, and they feel that it's really
+blindingly obvious that the "bang-per-buck" ratio of patches to
+mainline linux kernel need to go up.
+
+ so the core of the proposal that is the proposed
+"selfish-vs-cooperation patch policy" is quite simple: if the patch
+has _some_ evidence of collaboration, cooperation, refactoring,
+sharing - *anything* that increases the bang-per-buck ratio with
+respect to the core fundamental principles of Free Software - it goes
+to the next phase [which is technical evaluation etc. etc.].
+otherwise, it's absolutely out, regardless of its technical
+correctness, and that's the end of it.
+
+ the linux kernel mainline source tree should *not* be a
+dumping-ground for a bunch of selfish self-centred pathological
+profit-mongering corporations whose employees end up apologising in
+sheer embarrassment as they submit time-pressured absolutely shit
+non-cooperative and impossible-to-maintain code.
+
+ you're not the only one, russell, who is pissed off at having to tidy
+up SoC vendors' patches.  there's another ARM-Linux guy, forget his
+name, specialises in samsung: two years ago he said that he was
+getting fed up with receiving yet another pile of rushed junk... and
+that's *just* him, specialising in samsung ARM SoCs!
+
+we're just stunned that you, the recipient of _multiple_ SoC vendors
+piles of shite, have tolerated this for so long!
+
+anyway - i've endeavoured to put together some examples, in case
+that's not clear: i admit it's quite hard to create clear examples,
+and would greatly appreciate help doing so.  i've had some very much
+appreciated help from one of the openwrt developers (thanks!)
+clarifying by creating another example that's similar to one which
+wasn't clear.
+
+   http://lkcl.net/linux/linux-selfish.vs.cooperation.html
+
+this should be _fun_, guys.  it shouldn't be a chore.  if you're not
+enjoying it, and not being paid, tell the people who are clearly
+taking the piss to f*** off!
+
+ but - i also would like to underscore this with another idea: "lead
+by example" (which is why i've kept the large cross-distro list)  we -
+the free software community - are seeing tons of nice lovely android
+tablets, tons of nice lovely expensive bits of big iron and/or x86
+laptops, and only in very small areas (OpenRD Ultimate, GuruPlug,
+Pandaboard, IMX53QSB, Origen) are our needs for actual hardware which
+_we_ want (and i'm *not* being presumptious here - i'm inviting people
+to *say* what they want) just aren't being met.
+
+ who wants a bloody 800x600 VIA VunnnderMedia ARM9 350mhz tablet, to
+do linux kernel and gnu/linux distribution development on, _anyway_???
+  and who the hell wants only 512mb of RAM (iMX51).  and who in their
+right fucking mind dreamed up that 1024x600 LCD panel size?
+
+ so here's what i propose:
+
+ we, The Free Software Community, want Our Figureheads (linus, bruce,
+alan, russell) to call us to arms (so to speak), to band together a la
+KickStarter http://kickstarter.org (or other), so that we can create
+the hardware platform(s) that *we* want, and, in the process, can take
+the opportunity to sort out the Linux Kernel mainline tree in the
+process (learning by doing, doing by leading, leading by example etc.
+etc.)
+
+ apart from anything - and this goes to you, linus and russell - i
+think that you would be much happier taking a break from doing git
+patch conflict management, _actually_ getting down and dirty with some
+real device driver writing, and i think you'd be much happier doing
+that knowing that the device you were writing those kernel drivers for
+was something that actual real free software developers really really
+wanted.
+
+ now, as i said above: i don't _dare_ to presume that i know what
+actual real free software developers want, in terms of hardware, but
+there's a small sampling on the debian-arm mailing list... let me drop
+you roughly in the middle of it, here:
+http://lists.debian.org/debian-arm/2011/08/msg00045.html  mostly that
+was focussed around those little engineering boards (panda, IMX53QSB,
+origen etc.) but my aim here is to get people to think:
+
+ what hardware, which is fully free-software-compliant, that you would
+buy and recommend to others, that could also be attractive in
+mass-volume, do _you_ want to see, that would be useful to _you_?
+
+ i'm getting fed up of seeing stuff come out of factories that's
+completely useless.  or gpl-violating.  and/or requires
+reverse-engineering.
+http://lkcl.net/linux/ideal-vs-reality.of.product.development.html for
+some background.
+
+ as a free software developer, what hardware do YOU want?
+
+ answers on this one to arm-netbooks at lists.phcomp.co.uk (subscription
+required, please remember)
+
+ and, lastly - linus, russell, alan, bruce: there are people out there
+who would really appreciate if you could take up this call.  not just
+me.  we'd like to see you using your skills, and actually be happy and
+enjoy doing nitty-gritty linux kernel development, to the benefit of
+the free software community, instead of turning into patch
+junkies^H^H^H^H^H^Hmonkeys^H^H^H^H^H^H^Hmanagers.
+
+ l.
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007587.html b/zarb-ml/mageia-dev/2011-August/007587.html new file mode 100644 index 000000000..2b6ae3733 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007587.html @@ -0,0 +1,238 @@ + + + + [Mageia-dev] [lsb-discuss] [fedora-arm] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] [lsb-discuss] [fedora-arm] ARM summit at Plumbers 2011

+ keld at keldix.com + keld at keldix.com +
+ Fri Aug 26 23:36:41 CEST 2011 +

+
+ +
I would relly like the dscussion to go on widely as it is now.
+Otherwise I would probably not follow this interesting discussion.
+
+best regards
+keld
+
+On Fri, Aug 26, 2011 at 10:02:09PM +0100, Luke Kenneth Casson Leighton wrote:
+> russell, good to hear from you.
+> 
+> can i recommend, that although this is a really wide set of
+> cross-posting on a discussion that underpins pretty much everything
+> (except gnu/hurd and minix) because it's linux kernel, that, just as
+> steve kindly advised, we keep this to e.g.
+> cross-distro at lists.linaro.org?  i'll be doing that from now on [after
+> this] perhaps including arm-netbooks as well, but will be taking off
+> all the distros.
+> 
+> so - folks, let's be clear: please move this discussion to
+> cross-distro at lists.linaro.org, and, if it's worthwhile discussing in
+> person, please do contact steve, so he can keep the slot open at the
+> Plumbers 2011 summit.
+> 
+> On Fri, Aug 26, 2011 at 5:35 PM, Russell King - ARM Linux
+> <linux at arm.linux.org.uk> wrote:
+> > On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
+> >> As such refactoring consolidated larger and larger chunks of kernel
+> >> code, new designs would gravitate towards those consolidated
+> >> implementations because they would be the dominant references.
+> >
+> > Don't bet on it. ??That's not how it works (unfortunately.)
+> >
+> > Just look at the many serial port inventions dreamt up by SoC designers -
+> > everyone is different from each other. ??Now consider: why didn't they use
+> > a well established standard 16550A or later design?
+> 
+>  *sigh* because they wanted to save power.  or pins.  or... just be
+> bloody-minded.
+> 
+> > This "need to be different" is so heavily embedded in the mindset of the
+> > hardware people that I doubt "providing consolidated implementations"
+> > will make the blind bit of difference.
+> 
+>  i think... russell... after they are told, repeatedly, "no, you can't
+> have that pile of junk in the mainline linux kernel, Get With The
+> Programme", you'd think that, cumulatively if they end up having to
+> maintain a 6mb patch full of such shit, they _might_ get with the
+> programme?
+> 
+>  and if they don't, well.... who honestly cares?  if they don't, it's
+> not *your* problem, is it?  _they_ pay their employees to continue to
+> main a pile of junk, instead of spongeing off of _your_ time (and
+> linus's, and everyone else's in the Free Software Community).
+> 
+> 
+> > ??I doubt that hardware people
+> > coming up with these abominations even care one bit about what's in
+> > the kernel.
+> 
+>  then don't f******g make it _your_ problem, or anyone else's, upstream!! :)
+> 
+>  this is the core of the proposal that i have been advocating: if it's
+> "selfish", i.e. as bill and many many others clearly agree with "if
+> the bang-per-buck ratio is on the low side" then keep it *out* the
+> mainline linux kernel...
+> 
+>  ... and that really is the end of the matter.
+> 
+> the sensible people that i've been talking to about this are truly
+> puzzled as to why the principles of "cooperation and collaboration"
+> behind free software are just being... completely ignored, in
+> something as vital as The Linux Kernel, and they feel that it's really
+> blindingly obvious that the "bang-per-buck" ratio of patches to
+> mainline linux kernel need to go up.
+> 
+>  so the core of the proposal that is the proposed
+> "selfish-vs-cooperation patch policy" is quite simple: if the patch
+> has _some_ evidence of collaboration, cooperation, refactoring,
+> sharing - *anything* that increases the bang-per-buck ratio with
+> respect to the core fundamental principles of Free Software - it goes
+> to the next phase [which is technical evaluation etc. etc.].
+> otherwise, it's absolutely out, regardless of its technical
+> correctness, and that's the end of it.
+> 
+>  the linux kernel mainline source tree should *not* be a
+> dumping-ground for a bunch of selfish self-centred pathological
+> profit-mongering corporations whose employees end up apologising in
+> sheer embarrassment as they submit time-pressured absolutely shit
+> non-cooperative and impossible-to-maintain code.
+> 
+>  you're not the only one, russell, who is pissed off at having to tidy
+> up SoC vendors' patches.  there's another ARM-Linux guy, forget his
+> name, specialises in samsung: two years ago he said that he was
+> getting fed up with receiving yet another pile of rushed junk... and
+> that's *just* him, specialising in samsung ARM SoCs!
+> 
+> we're just stunned that you, the recipient of _multiple_ SoC vendors
+> piles of shite, have tolerated this for so long!
+> 
+> anyway - i've endeavoured to put together some examples, in case
+> that's not clear: i admit it's quite hard to create clear examples,
+> and would greatly appreciate help doing so.  i've had some very much
+> appreciated help from one of the openwrt developers (thanks!)
+> clarifying by creating another example that's similar to one which
+> wasn't clear.
+> 
+>    http://lkcl.net/linux/linux-selfish.vs.cooperation.html
+> 
+> this should be _fun_, guys.  it shouldn't be a chore.  if you're not
+> enjoying it, and not being paid, tell the people who are clearly
+> taking the piss to f*** off!
+> 
+>  but - i also would like to underscore this with another idea: "lead
+> by example" (which is why i've kept the large cross-distro list)  we -
+> the free software community - are seeing tons of nice lovely android
+> tablets, tons of nice lovely expensive bits of big iron and/or x86
+> laptops, and only in very small areas (OpenRD Ultimate, GuruPlug,
+> Pandaboard, IMX53QSB, Origen) are our needs for actual hardware which
+> _we_ want (and i'm *not* being presumptious here - i'm inviting people
+> to *say* what they want) just aren't being met.
+> 
+>  who wants a bloody 800x600 VIA VunnnderMedia ARM9 350mhz tablet, to
+> do linux kernel and gnu/linux distribution development on, _anyway_???
+>   and who the hell wants only 512mb of RAM (iMX51).  and who in their
+> right fucking mind dreamed up that 1024x600 LCD panel size?
+> 
+>  so here's what i propose:
+> 
+>  we, The Free Software Community, want Our Figureheads (linus, bruce,
+> alan, russell) to call us to arms (so to speak), to band together a la
+> KickStarter http://kickstarter.org (or other), so that we can create
+> the hardware platform(s) that *we* want, and, in the process, can take
+> the opportunity to sort out the Linux Kernel mainline tree in the
+> process (learning by doing, doing by leading, leading by example etc.
+> etc.)
+> 
+>  apart from anything - and this goes to you, linus and russell - i
+> think that you would be much happier taking a break from doing git
+> patch conflict management, _actually_ getting down and dirty with some
+> real device driver writing, and i think you'd be much happier doing
+> that knowing that the device you were writing those kernel drivers for
+> was something that actual real free software developers really really
+> wanted.
+> 
+>  now, as i said above: i don't _dare_ to presume that i know what
+> actual real free software developers want, in terms of hardware, but
+> there's a small sampling on the debian-arm mailing list... let me drop
+> you roughly in the middle of it, here:
+> http://lists.debian.org/debian-arm/2011/08/msg00045.html  mostly that
+> was focussed around those little engineering boards (panda, IMX53QSB,
+> origen etc.) but my aim here is to get people to think:
+> 
+>  what hardware, which is fully free-software-compliant, that you would
+> buy and recommend to others, that could also be attractive in
+> mass-volume, do _you_ want to see, that would be useful to _you_?
+> 
+>  i'm getting fed up of seeing stuff come out of factories that's
+> completely useless.  or gpl-violating.  and/or requires
+> reverse-engineering.
+> http://lkcl.net/linux/ideal-vs-reality.of.product.development.html for
+> some background.
+> 
+>  as a free software developer, what hardware do YOU want?
+> 
+>  answers on this one to arm-netbooks at lists.phcomp.co.uk (subscription
+> required, please remember)
+> 
+>  and, lastly - linus, russell, alan, bruce: there are people out there
+> who would really appreciate if you could take up this call.  not just
+> me.  we'd like to see you using your skills, and actually be happy and
+> enjoy doing nitty-gritty linux kernel development, to the benefit of
+> the free software community, instead of turning into patch
+> junkies^H^H^H^H^H^Hmonkeys^H^H^H^H^H^H^Hmanagers.
+> 
+>  l.
+> _______________________________________________
+> lsb-discuss mailing list
+> lsb-discuss at lists.linux-foundation.org
+> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007588.html b/zarb-ml/mageia-dev/2011-August/007588.html new file mode 100644 index 000000000..977d7319b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007588.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] systemd + udev 173 + gnome-shell + + + + + + + + + +

[Mageia-dev] systemd + udev 173 + gnome-shell

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Aug 27 16:36:01 CEST 2011 +

+
+ +
'Twas brillig, and Colin Guthrie at 27/08/11 00:46 did gyre and gimble:
+> Hi,
+> 
+> OK, so this combo is currently broken!
+> 
+> Here is the explanation.
+> 
+> With udev 172, udev-acl would apply ACLs to devices (such as the DRI
+> device) when console-kit registers a new session.
+> 
+> This included the gdm user at the login manager.
+> 
+> systemd is gradually taking over the job of consolekit. This means that
+> systemd now handles the ACL writing and login sessions should be
+> visiible via systemctl-loginctl (as opposed to ck-list-sessions).
+> 
+> 
+> With udev 172, both systemd and console-kit would trigger ACL writes.
+> Normally this is fine, they both ultimately do the same thing.
+> 
+> But, it seems that in actual fact, systemctl-logind wasn't ever
+> registering the gdm session. Thankfully console-kit did, and thus gdm
+> user got the ACLs it needed.
+> 
+> 
+> Now this is where the problem arises. With udev 173, udev-acl knows
+> whether or not systemd is running and if it is, it it won't write the
+> ACLs. This means that even tho' gdm is still registered with
+> console-kit, this will never actually trigger an ACL write.
+> 
+> This means that gdm does not have access to /dev/dri/card0 and thus
+> cannot determine if the device is capable of 3D accel. This then sets an
+> atom on the root window which the gnome-session-check-accelerated binary
+> looks for. This atom acts as a little cache. If it doesn't exist, it
+> does a full probe and then writes the atom. The next time it runs it
+> finds the atom and skips the actual checks. But as the atom was written
+> by gdm when it couldn't access dri, it says no accel is available, even
+> although the user can actually access it.
+> 
+> 
+> I've not yet sussed out gdm is not registering with systemd... it should
+> all be automatic via pam... but something somewhere is failing :s
+
+OK, sussed it out eventually (I was looking in fedora's "master" branch
+rather than "f16" branch so missed some patches :()
+
+gdm patched to make it all work now. I'm not really sure how kdm will
+behave but I wouldn't be surprised if it's broken.
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007589.html b/zarb-ml/mageia-dev/2011-August/007589.html new file mode 100644 index 000000000..ec9d05c14 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007589.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] cauldron core/release udev-173-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release udev-173-1.mga2

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Aug 27 16:39:55 CEST 2011 +

+
+ +
'Twas brillig, and Colin Guthrie at 25/08/11 23:47 did gyre and gimble:
+>> > We said that we would support booting without systemd-, so to me, this
+>> > should be taken in account.
+> Yeah but I think using the "optional" word in pam config means that it's
+> quite safe even if systemd is not running, so I don't think this is an
+> issue.
+> 
+> That's why I suggested even just patching pam directly... but modifying
+> the file should also be possible as that what ldap auth configuration
+> does anyway, so it's no great shakes.
+
+OK, executive decision for now:
+
+I've just added the line:
+
+-session    optional      pam_systemd.so
+
+to /etc/pam.d/system-auth in the pam package.
+
+
+This change is quite safe:
+ 1. The leading - on the line means that if pam_systemd.so does not
+exist, it will be ignored.
+ 2. pamd_systemd.so itself is clever and if systemd is not running, it
+is a noop.
+
+So for all scenarios, this change is safe.
+
+If we want to do more with e.g. authconfig later, this can be done, but
+it's not strictly speaking needed for now.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007590.html b/zarb-ml/mageia-dev/2011-August/007590.html new file mode 100644 index 000000000..4a698ebf8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007590.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] systemd + ACL: Why it is broken. + + + + + + + + + +

[Mageia-dev] systemd + ACL: Why it is broken.

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Aug 27 16:40:43 CEST 2011 +

+
+ +
[As stated on another thread: just reposting here for future contextual
+history]
+
+OK, executive decision for now:
+
+I've just added the line:
+
+-session    optional      pam_systemd.so
+
+to /etc/pam.d/system-auth in the pam package.
+
+
+This change is quite safe:
+ 1. The leading - on the line means that if pam_systemd.so does not
+exist, it will be ignored.
+ 2. pamd_systemd.so itself is clever and if systemd is not running, it
+is a noop.
+
+So for all scenarios, this change is safe.
+
+If we want to do more with e.g. authconfig later, this can be done, but
+it's not strictly speaking needed for now.
+
+Col
+
+
+
+'Twas brillig, and Colin Guthrie at 25/08/11 15:26 did gyre and gimble:
+> Ping!
+> 
+> Any thoughts on the below email?
+> 
+> Seeing as udev 173 has landed which removes supoprt for udev-acl, we
+> need to either back out 173 (or rebuild with udev-acl support) or we
+> need to use systemd with the below changes officially blessed!
+> 
+> Col
+> 
+> 'Twas brillig, and Colin Guthrie at 04/08/11 18:43 did gyre and gimble:
+>> Hi,
+>>
+>> OK, so the reason that device ACLs are kinda broken with systemd is
+>> because the acl stuff is being done twice, once via udev and again via
+>> systemd.... but sadly systemd gets it wrong as it's not aware of the
+>> user session, see:
+>> systemd-loginctl --no-pager
+>>
+>>
+>> This is due to the fact that some essential additions to
+>> /etc/pam.d/system-auth are not done when systemd is installed.
+>>
+>> I added the following line to the end of my system-auth (the "login"
+>> file where console kit connector lies didn't work):
+>>
+>> -session    optional      pam_systemd.so
+>>
+>>
+>>
+>> The question is, how should we handle this? Edit the pam package and add
+>> it or do something more complex? AFAIK Fedora uses a system to manage
+>> these files called authconfig.... not sure if we could/should adopt
+>> that. I don't know much about it.
+>>
+>>
+>>
+>>
+>> On a related note, we'll also need to rebuild udev without udev-acl
+>> support, as this is now
+>> handled by systemd. At present, with the above fix to pam, I will be
+>> getting my ACLs written twice, which (when systemd knows I'm logged in)
+>> is fine. I think it's actually the default in udev 173, but
+>> we can do that manually with 172 via:
+>>   --disable-udev_acl
+>> in udev.
+>>
+>> That said, this would commit us to systemd so we need to tread carefully
+>> here as without systemd, then the ACLs would not get written with
+>> obvious consequences (basically the exact opposite of now!).
+>>
+>> Anyway, for now I have my ACLs back and can use my audio devices! Yay!
+>>
+>> Col
+>>
+>>
+> 
+> 
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007591.html b/zarb-ml/mageia-dev/2011-August/007591.html new file mode 100644 index 000000000..8d2d43c1d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007591.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Warning: systemd + kdm + + + + + + + + + +

[Mageia-dev] Warning: systemd + kdm

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Aug 27 16:53:23 CEST 2011 +

+
+ +
Hi,
+
+This is just a warning. I've not tried this but there are potentially
+problems with using kdm and systemd after the latest udev.
+
+It might not manifest itself in the same was as with GDM, but if you
+notice something funny with this combo, it could be the reason. kdm may
+need patched to show up under systemd-loginctl and thus get ACLs written.
+
+A simply check for someone with the appropriate setup would be to see
+(via a console login) whether or not ck-list-sessions showed kdm user or
+not. If not then no worries, but if it does show up there, then it
+should also show up in systemd-loginctl - if it does not, then there
+could very well be problems).
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007592.html b/zarb-ml/mageia-dev/2011-August/007592.html new file mode 100644 index 000000000..2e7275e71 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007592.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Handling GNOME 2.x Broken Dependencies + + + + + + + + + +

[Mageia-dev] Handling GNOME 2.x Broken Dependencies

+ Shlomi Fish + shlomif at shlomifish.org +
+ Sat Aug 27 16:48:55 CEST 2011 +

+
+ +
Hi all,
+
+http://pkgsubmit.mageia.org/ - this page reads:
+
+<<<
+66 broken dependencies. You can help!
+>>>
+
+I've been trying to slowly resolve these dependencies, but been running into
+some problems. Some of them were resolved by fixing this bug:
+
+https://bugs.mageia.org/show_bug.cgi?id=1839
+
+But some of them are more tricky. For example, some packages still depend on
+devel(libpanel-applet-2) which is a GNOME 2.x package that is no longer
+available in the repository. What should we do about these GNOME 2.x packages
+and their dependent packages?
+
+Regards,
+
+	Shlomi Fish
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+What Makes Software Apps High Quality -  http://shlom.in/sw-quality
+
+CPAN thrives *because* of the unfettered uploading of shit, not in spite of it.
+    — Andy Lester
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007593.html b/zarb-ml/mageia-dev/2011-August/007593.html new file mode 100644 index 000000000..02fc7e0e3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007593.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Handling GNOME 2.x Broken Dependencies + + + + + + + + + +

[Mageia-dev] Handling GNOME 2.x Broken Dependencies

+ Funda Wang + fundawang at gmail.com +
+ Sat Aug 27 17:28:09 CEST 2011 +

+
+ +
I guess we should just remove them. Actually,  only
+gnome-sensors-applet, libpanelappletmm and perl-Gnome2-PanelApplet are
+affected, and those packages are not required by any other packages.
+
+2011/8/27 Shlomi Fish <shlomif at shlomifish.org>:
+> Hi all,
+>
+> http://pkgsubmit.mageia.org/ - this page reads:
+>
+> <<<
+> 66 broken dependencies. You can help!
+>>>>
+>
+> I've been trying to slowly resolve these dependencies, but been running into
+> some problems. Some of them were resolved by fixing this bug:
+>
+> https://bugs.mageia.org/show_bug.cgi?id=1839
+>
+> But some of them are more tricky. For example, some packages still depend on
+> devel(libpanel-applet-2) which is a GNOME 2.x package that is no longer
+> available in the repository. What should we do about these GNOME 2.x packages
+> and their dependent packages?
+>
+> Regards,
+>
+>        Shlomi Fish
+>
+> --
+> -----------------------------------------------------------------
+> Shlomi Fish       http://www.shlomifish.org/
+> What Makes Software Apps High Quality -  http://shlom.in/sw-quality
+>
+> CPAN thrives *because* of the unfettered uploading of shit, not in spite of it.
+>    — Andy Lester
+>
+> Please reply to list if it's a mailing list post - http://shlom.in/reply .
+>
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007594.html b/zarb-ml/mageia-dev/2011-August/007594.html new file mode 100644 index 000000000..4feb02eb2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007594.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Handling GNOME 2.x Broken Dependencies + + + + + + + + + +

[Mageia-dev] Handling GNOME 2.x Broken Dependencies

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Sat Aug 27 17:32:03 CEST 2011 +

+
+ +
'Twas brillig, and Funda Wang at 27/08/11 16:28 did gyre and gimble:
+> I guess we should just remove them. Actually,  only
+> gnome-sensors-applet, libpanelappletmm and perl-Gnome2-PanelApplet are
+> affected, and those packages are not required by any other packages.
+
+Yup +1 on that.
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007595.html b/zarb-ml/mageia-dev/2011-August/007595.html new file mode 100644 index 000000000..b5bbe2771 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007595.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] Handling GNOME 2.x Broken Dependencies + + + + + + + + + +

[Mageia-dev] Handling GNOME 2.x Broken Dependencies

+ D.Morgan + dmorganec at gmail.com +
+ Sat Aug 27 17:40:42 CEST 2011 +

+
+ +
On Sat, Aug 27, 2011 at 5:32 PM, Colin Guthrie <mageia at colin.guthr.ie> wrote:
+> 'Twas brillig, and Funda Wang at 27/08/11 16:28 did gyre and gimble:
+>> I guess we should just remove them. Actually,  only
+>> gnome-sensors-applet, libpanelappletmm and perl-Gnome2-PanelApplet are
+>> affected, and those packages are not required by any other packages.
+>
+> Yup +1 on that.
+>
+> Col
+
+we should do like in fedora and obsolete them.
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007596.html b/zarb-ml/mageia-dev/2011-August/007596.html new file mode 100644 index 000000000..cdd882bd7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007596.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ Florian Hubold + doktor5000 at arcor.de +
+ Sat Aug 27 17:58:22 CEST 2011 +

+
+ +
Hello,
+
+as was already proposed some time ago, but not implemented yet,
+i'm proposing a mageia-packager package, maybe as a task-package.
+IMHO It should at least require the following:
+
+rpm-build
+rpmlint
+rpmlint-mageia-policy
+bm                              implicitly required by magpie
+mgarepo                     implicitly required by magpie
+magpie
+openssh-askpass        for basic ssh setup
+keychain                      for basic ssh setup
+
+
+What else should be in there? Please comment :)
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007597.html b/zarb-ml/mageia-dev/2011-August/007597.html new file mode 100644 index 000000000..5d61852c7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007597.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ Michael Scherer + misc at zarb.org +
+ Sat Aug 27 18:08:34 CEST 2011 +

+
+ +
Le samedi 27 août 2011 à 17:58 +0200, Florian Hubold a écrit :
+> Hello,
+> 
+> as was already proposed some time ago, but not implemented yet,
+> i'm proposing a mageia-packager package, maybe as a task-package.
+> IMHO It should at least require the following:
+> 
+> rpm-build
+> rpmlint
+> rpmlint-mageia-policy
+> bm                              implicitly required by magpie
+> mgarepo                     implicitly required by magpie
+
+
+> magpie
+why ?
+
+> openssh-askpass        for basic ssh setup
+> keychain                      for basic ssh setup
+
+They should no longer be needed ( even if no one confirmed that on the
+bug report about it ). 
+
+And keychain is ( or was ) annoying, as it ask the key each time you
+log :/ ( didn't tested since a long time however )
+
+
+-- 
+Michael Scherer
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007598.html b/zarb-ml/mageia-dev/2011-August/007598.html new file mode 100644 index 000000000..81d8e552f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007598.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Sat Aug 27 18:26:06 CEST 2011 +

+
+ +
On 27/08/2011 18:08, Michael Scherer wrote:
+> And keychain is ( or was ) annoying, as it ask the key each time you
+> log :/ ( didn't tested since a long time however )
+This behaviour is configurable.
+
+Anyway, the whole added value of one package to just requires 8 others, 
+when the target population is supposed to have a some minimal technical 
+experience, is quite discussable.
+-- 
+BOFH excuse #115:
+
+your keyboard's space bar is generating spurious keycodes.
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007599.html b/zarb-ml/mageia-dev/2011-August/007599.html new file mode 100644 index 000000000..9d130684b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007599.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] The Hydra Nature of the horde-* packages

+ Shlomi Fish + shlomif at shlomifish.org +
+ Sat Aug 27 18:17:56 CEST 2011 +

+
+ +
Hi all,
+
+I just rebuilt a few horde-* packages for which there were missing
+dependencies in http://pkgsubmit.mageia.org/data/missing-deps.i586.txt , but
+now there are more that are not there:
+
+horde-compress
+horde-datatree
+horde-history
+horde-secret
+horde-text-filter
+horde-token
+
+This reminds me of the http://en.wikipedia.org/wiki/Lernaean_Hydra where if you
+cut one of its heads, then two grow instead. 
+
+How can we resolve all the horde dependencies for good? Why do they reappear?
+What is the underlying problem?
+
+I'm CCing it to mageia-sysadm because it may be a Sys admin problem.
+
+Regards,
+
+	Shlomi Fish
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+First stop for Perl beginners - http://perl-begin.org/
+
+An apple a day keeps the doctor away.
+Two apples a day will keep two doctors away. 
+    — one of Shlomi Fish’s relatives
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007600.html b/zarb-ml/mageia-dev/2011-August/007600.html new file mode 100644 index 000000000..d32b715e1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007600.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] The Hydra Nature of the horde-* packages

+ Thomas Spuhler + thomas at btspuhler.com +
+ Sat Aug 27 18:31:45 CEST 2011 +

+
+ +
On Saturday, August 27, 2011 09:17:56 am Shlomi Fish wrote:
+> Hi all,
+> 
+> I just rebuilt a few horde-* packages for which there were missing
+> dependencies in http://pkgsubmit.mageia.org/data/missing-deps.i586.txt ,
+> but now there are more that are not there:
+> 
+> horde-compress
+> horde-datatree
+> horde-history
+> horde-secret
+> horde-text-filter
+> horde-token
+> 
+> This reminds me of the http://en.wikipedia.org/wiki/Lernaean_Hydra where if
+> you cut one of its heads, then two grow instead.
+> 
+> How can we resolve all the horde dependencies for good? Why do they
+> reappear? What is the underlying problem?
+> 
+> I'm CCing it to mageia-sysadm because it may be a Sys admin problem.
+> 
+> Regards,
+> 
+> 	Shlomi Fish
+
+These will be removed when the whole horde tree is done. The new names are:]
+
+php-pear-Horde..... 
+
+I am working on them, but there are a lot of deps to be built.
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007601.html b/zarb-ml/mageia-dev/2011-August/007601.html new file mode 100644 index 000000000..a75c340db --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007601.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ Remco Rijnders + remco at webconquest.com +
+ Sat Aug 27 18:32:10 CEST 2011 +

+
+ +
On Sat, Aug 27, 2011 at 06:26:06PM +0200, Guillaume wrote in
+<4E591A9E.9040709 at gmail.com>:
+>
+>Anyway, the whole added value of one package to just requires 8 
+>others, when the target population is supposed to have a some minimal 
+>technical experience, is quite discussable.
+
+I politely like to disagree. One might be quite technically experienced 
+but be new to the packaging field in general or Mageia in specific. I've 
+seen several novice packagers (which includes myself) run into the same 
+kind of issue time and again.
+
+Sure, they can all probably work out what's wrong (or ask), and then fix 
+it, but why have them run into the wall in the first place?
+
+It hurts no one to have all the commonly used tools for packaging 
+installed by installing one task package.
+
+Remco
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110827/8f10d734/attachment.asc>
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007602.html b/zarb-ml/mageia-dev/2011-August/007602.html new file mode 100644 index 000000000..a87b12126 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007602.html @@ -0,0 +1,107 @@ + + + + [Mageia-dev] The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] The Hydra Nature of the horde-* packages

+ Thomas Spuhler + thomas at btspuhler.com +
+ Sat Aug 27 18:35:29 CEST 2011 +

+
+ +
On Saturday, August 27, 2011 09:31:45 am Thomas Spuhler wrote:
+> On Saturday, August 27, 2011 09:17:56 am Shlomi Fish wrote:
+> > Hi all,
+> > 
+> > I just rebuilt a few horde-* packages for which there were missing
+> > dependencies in http://pkgsubmit.mageia.org/data/missing-deps.i586.txt ,
+> > but now there are more that are not there:
+> > 
+> > horde-compress
+> > horde-datatree
+> > horde-history
+> > horde-secret
+> > horde-text-filter
+> > horde-token
+> > 
+> > This reminds me of the http://en.wikipedia.org/wiki/Lernaean_Hydra where
+> > if you cut one of its heads, then two grow instead.
+> > 
+> > How can we resolve all the horde dependencies for good? Why do they
+> > reappear? What is the underlying problem?
+> > 
+> > I'm CCing it to mageia-sysadm because it may be a Sys admin problem.
+> > 
+> > Regards,
+> > 
+> > 	Shlomi Fish
+> 
+> These will be removed when the whole horde tree is done. The new names
+> are:]
+> 
+> php-pear-Horde.....
+> 
+> I am working on them, but there are a lot of deps to be built.
+BTW, if you use http://check.mageia.org/dependencies.html
+you get a better picture of the deps.
+
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007603.html b/zarb-ml/mageia-dev/2011-August/007603.html new file mode 100644 index 000000000..1a99343d9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007603.html @@ -0,0 +1,122 @@ + + + + [Mageia-dev] The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] The Hydra Nature of the horde-* packages

+ Shlomi Fish + shlomif at shlomifish.org +
+ Sat Aug 27 18:47:37 CEST 2011 +

+
+ +
Hi Thomas,
+
+On Sat, 27 Aug 2011 09:31:45 -0700
+Thomas Spuhler <thomas at btspuhler.com> wrote:
+
+> On Saturday, August 27, 2011 09:17:56 am Shlomi Fish wrote:
+> > Hi all,
+> > 
+> > I just rebuilt a few horde-* packages for which there were missing
+> > dependencies in http://pkgsubmit.mageia.org/data/missing-deps.i586.txt ,
+> > but now there are more that are not there:
+> > 
+> > horde-compress
+> > horde-datatree
+> > horde-history
+> > horde-secret
+> > horde-text-filter
+> > horde-token
+> > 
+> > This reminds me of the http://en.wikipedia.org/wiki/Lernaean_Hydra where if
+> > you cut one of its heads, then two grow instead.
+> > 
+> > How can we resolve all the horde dependencies for good? Why do they
+> > reappear? What is the underlying problem?
+> > 
+> > I'm CCing it to mageia-sysadm because it may be a Sys admin problem.
+> > 
+> > Regards,
+> > 
+> > 	Shlomi Fish
+> 
+> These will be removed when the whole horde tree is done. The new names are:]
+> 
+> php-pear-Horde..... 
+> 
+> I am working on them, but there are a lot of deps to be built.
+> 
+
+I don't understand exactly how these things are related? Why have we been
+having lots of broken horde-* dependencies for a long while? Why do horde-*
+packages disappear? Can we discuss this on IRC? I am "rindolf" there.
+
+Regards,
+
+	Shlomi Fish
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+Original Riddles - http://www.shlomifish.org/puzzles/
+
+Chuck Norris doesn’t make mistakes. (Su‐Shee) He corrects God. (Shlomi Fish)
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007604.html b/zarb-ml/mageia-dev/2011-August/007604.html new file mode 100644 index 000000000..d7afa910d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007604.html @@ -0,0 +1,144 @@ + + + + [Mageia-dev] Fw: The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] Fw: The Hydra Nature of the horde-* packages

+ Shlomi Fish + shlomif at shlomifish.org +
+ Sat Aug 27 18:57:20 CEST 2011 +

+
+ +
+
+Begin forwarded message:
+
+Date: Sat, 27 Aug 2011 19:47:37 +0300
+From: Shlomi Fish <shlomif at shlomifish.org>
+To: Mageia development mailing-list <mageia-dev at mageia.org>
+Cc: thomas at btspuhler.com
+Subject: Re: [Mageia-dev] The Hydra Nature of the horde-* packages
+
+
+Hi Thomas,
+
+On Sat, 27 Aug 2011 09:31:45 -0700
+Thomas Spuhler <thomas at btspuhler.com> wrote:
+
+> On Saturday, August 27, 2011 09:17:56 am Shlomi Fish wrote:
+> > Hi all,
+> > 
+> > I just rebuilt a few horde-* packages for which there were missing
+> > dependencies in http://pkgsubmit.mageia.org/data/missing-deps.i586.txt ,
+> > but now there are more that are not there:
+> > 
+> > horde-compress
+> > horde-datatree
+> > horde-history
+> > horde-secret
+> > horde-text-filter
+> > horde-token
+> > 
+> > This reminds me of the http://en.wikipedia.org/wiki/Lernaean_Hydra where if
+> > you cut one of its heads, then two grow instead.
+> > 
+> > How can we resolve all the horde dependencies for good? Why do they
+> > reappear? What is the underlying problem?
+> > 
+> > I'm CCing it to mageia-sysadm because it may be a Sys admin problem.
+> > 
+> > Regards,
+> > 
+> > 	Shlomi Fish
+> 
+> These will be removed when the whole horde tree is done. The new names are:]
+> 
+> php-pear-Horde..... 
+> 
+> I am working on them, but there are a lot of deps to be built.
+> 
+
+I don't understand exactly how these things are related? Why have we been
+having lots of broken horde-* dependencies for a long while? Why do horde-*
+packages disappear? Can we discuss this on IRC? I am "rindolf" there.
+
+Regards,
+
+	Shlomi Fish
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+Original Riddles - http://www.shlomifish.org/puzzles/
+
+Chuck Norris doesn’t make mistakes. (Su‐Shee) He corrects God. (Shlomi Fish)
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+First stop for Perl beginners - http://perl-begin.org/
+
+NASA Uses COBOL.
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007605.html b/zarb-ml/mageia-dev/2011-August/007605.html new file mode 100644 index 000000000..21c096c29 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007605.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Looking for a Mageia packaging mentor + + + + + + + + + +

[Mageia-dev] Looking for a Mageia packaging mentor

+ Olav Vitters + olav at vitters.nl +
+ Sat Aug 27 19:07:18 CEST 2011 +

+
+ +
[ Initially I something similar to this to tombhadAC because he's
+  involved with GNOME packaging, but think he's busy as I didn't get a
+  response ]
+
+I'd like to join the Mageia packaging team.
+
+I'm interested to help ensure Cauldron
+1) has the latest GNOME packages available. Meaning: upgrade the micro
+versions. I'm involved in GNOME (sysadmin, release team) and I use
+Mageia myself, so that is the reason why I want to help Mageia.
+2) possibly add packages from Cooker that are not available in Cauldron
+(I'm a *long* time Mandriva/Mandrake user). My main interest is with the
+GNOME packages though.
+
+Experience in rpm packaging: Never created a spec file from scratch, but
+have often changed existing spec files (minor changes such as version
+changes, addition/removing of patches and so on) and sometimes had to
+redo a patch (mostly Python; not a C developer). Done that when needed
+over the last ~5 years or so across various distributions
+(Mandrake/Fedora/RHEL and even a few times .deb on Ubuntu).
+
+Note: My interest is mainly to stay a novice packager. So to help out on
+the easy stuff. People in #mageia-dev mentioned that this is fine.
+
+Someone willing to act as a mentor?
+
+If yes, could you arrange the permissions I'd need? My SSH public key is
+at http://www.gnome.org/~ovitters/id_rsa.pub and my identity / userid at
+Mageia is ovitters.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007606.html b/zarb-ml/mageia-dev/2011-August/007606.html new file mode 100644 index 000000000..0224d43e7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007606.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Looking for a Mageia packaging mentor + + + + + + + + + +

[Mageia-dev] Looking for a Mageia packaging mentor

+ D.Morgan + dmorganec at gmail.com +
+ Sat Aug 27 20:11:49 CEST 2011 +

+
+ +
On Sat, Aug 27, 2011 at 7:07 PM, Olav Vitters <olav at vitters.nl> wrote:
+> [ Initially I something similar to this to tombhadAC because he's
+>  involved with GNOME packaging, but think he's busy as I didn't get a
+>  response ]
+>
+> I'd like to join the Mageia packaging team.
+>
+> I'm interested to help ensure Cauldron
+> 1) has the latest GNOME packages available. Meaning: upgrade the micro
+> versions. I'm involved in GNOME (sysadmin, release team) and I use
+> Mageia myself, so that is the reason why I want to help Mageia.
+> 2) possibly add packages from Cooker that are not available in Cauldron
+> (I'm a *long* time Mandriva/Mandrake user). My main interest is with the
+> GNOME packages though.
+>
+> Experience in rpm packaging: Never created a spec file from scratch, but
+> have often changed existing spec files (minor changes such as version
+> changes, addition/removing of patches and so on) and sometimes had to
+> redo a patch (mostly Python; not a C developer). Done that when needed
+> over the last ~5 years or so across various distributions
+> (Mandrake/Fedora/RHEL and even a few times .deb on Ubuntu).
+>
+> Note: My interest is mainly to stay a novice packager. So to help out on
+> the easy stuff. People in #mageia-dev mentioned that this is fine.
+>
+> Someone willing to act as a mentor?
+>
+> If yes, could you arrange the permissions I'd need? My SSH public key is
+> at http://www.gnome.org/~ovitters/id_rsa.pub and my identity / userid at
+> Mageia is ovitters.
+> --
+> Regards,
+> Olav
+>
+
+i can be your mentor if you want i have a free slot :)
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007607.html b/zarb-ml/mageia-dev/2011-August/007607.html new file mode 100644 index 000000000..bb179d7a8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007607.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Looking for a Mageia packaging mentor + + + + + + + + + +

[Mageia-dev] Looking for a Mageia packaging mentor

+ Olav Vitters + olav at vitters.nl +
+ Sat Aug 27 21:19:28 CEST 2011 +

+
+ +
On Sat, Aug 27, 2011 at 08:11:49PM +0200, D.Morgan wrote:
+> > Someone willing to act as a mentor?
+> 
+> i can be your mentor if you want i have a free slot :)
+
+That would be nice! I'll try and add you on XMPP. My irc nickname is
+'bkor' btw.
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007608.html b/zarb-ml/mageia-dev/2011-August/007608.html new file mode 100644 index 000000000..05da7d60e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007608.html @@ -0,0 +1,141 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ Florian Hubold + doktor5000 at arcor.de +
+ Sat Aug 27 22:06:49 CEST 2011 +

+
+ +
Am 04.03.2011 22:30, schrieb Michael Scherer:
+>
+>
+> But we can filter and configure it to be a little more perfect.
+>
+> In a rather autocratic fashion, as the maintainer of rpmlint ( both packages
+> and uptream ), as a packager representative, and as a apprentice dictator
+> ( since there is lots of open position in this sector since a few weeks ),
+> I propose that this become the canonical source for rpmlint configuration.
+>
+> In practice, that mean that false positives will have to be added there,
+> that stuff that are noted as errors need to be set in that package, and
+> any policy changes must be made there.
+>
+> So the question is "how do we deal with evolution ( ie, how do we decide
+> something is now a error, or no longer one".
+>
+> Traditionally, packagers didn't care at all, and so the configuration bitrotted
+> since a long time, and people didn't used it, and I just added false positives
+> when packagers notified it ( ie, almost never, except when I noticed some of 
+> them ).
+> I suspect that my lack of communication around that didn't help ( and so
+> people didn't knew they could ask for adding a false positive to the list
+> of error to ignore ).
+>
+> Yet, I think we can do better, so feel free to suggest any mad idea for this.
+
+What about the following, AFAIK those are deprecated and rpmlint shouldn't 
+complain about:
+
+*files-attr-not-set*        as i was told by dmorgan, empty default attributes 
+(%defattr(-,root,root))
+are useless and not needed, but without it rpmlint complains with this warning 
+for every file.
+What's the status quoe here? rpmlint issue or maybe an rpm bug?
+Empty %defattr still needed or not and if not, could you make that warning an 
+exception?
+
+*no-%clean-section*
+*no-cleaning-of-buildroot %clean *related to the former, as %clean is not 
+needed anymore,
+because it's done automagically by rpm as a builtin
+
+
+All the following should be deprecated by filetriggers:
+
+*library-without-ldconfig-postin
+library-without-ldconfig-postun
+menu-without-postin
+menu-without-postun*
+
+
+I think the following are bogus, but i may be totally wrong:
+
+*strange-permission *       for SOURCES and SPEC it complains if not 0644, why 
+is that?
+*%ifarch-applied-patch*    if the build is broken only for i586 for example, 
+what's wrong about the %ifarch?
+Or maybe i don't get the description fully:
+
+    /Patches must be applied on all architectures and may contain
+    necessary configure and/or code patch to be effective only on a given arch./
+
+With the last part of the explanation and the warning itself, i'm confused. If 
+it is only
+effective on one arch and fixed build there, why apply it blindly to the other 
+where this may break build
+or have other unwanted sideeffects?
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007609.html b/zarb-ml/mageia-dev/2011-August/007609.html new file mode 100644 index 000000000..45f336def --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007609.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ Florian Hubold + doktor5000 at arcor.de +
+ Sat Aug 27 22:11:16 CEST 2011 +

+
+ +
Am 27.08.2011 18:08, schrieb Michael Scherer:
+> Le samedi 27 août 2011 à 17:58 +0200, Florian Hubold a écrit :
+>> Hello,
+>>
+>> as was already proposed some time ago, but not implemented yet,
+>> i'm proposing a mageia-packager package, maybe as a task-package.
+>> IMHO It should at least require the following:
+>>
+>> rpm-build
+>> rpmlint
+>> rpmlint-mageia-policy
+>> bm                              implicitly required by magpie
+>> mgarepo                     implicitly required by magpie
+>
+>> magpie
+> why ?
+Sorry, mixed that one up.
+>
+>> openssh-askpass        for basic ssh setup
+>> keychain                      for basic ssh setup
+> They should no longer be needed ( even if no one confirmed that on the
+> bug report about it ).
+>
+> And keychain is ( or was ) annoying, as it ask the key each time you
+> log :/ ( didn't tested since a long time however )
+Ok, so those two not. I've listed them because they're required for basic ssh 
+setup,
+as noted in the wiki, so i haven't tested if they're really needed.
+
+But overall you support the idea of such a metapackage? Yes, no, maybe?
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007610.html b/zarb-ml/mageia-dev/2011-August/007610.html new file mode 100644 index 000000000..b8fffee22 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007610.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Sat Aug 27 22:16:00 CEST 2011 +

+
+ +
On 27/08/2011 22:06, Florian Hubold wrote:
+> I think the following are bogus, but i may be totally wrong:
+>
+> *strange-permission * for SOURCES and SPEC it complains if not 0644, why
+> is that?
+rpmrebuild won't work if you can't read the files included in the source 
+package after extracting them.
+
+> *%ifarch-applied-patch* if the build is broken only for i586 for
+> example, what's wrong about the %ifarch?
+ >
+> Or maybe i don't get the description fully:
+>
+> /Patches must be applied on all architectures and may contain
+> necessary configure and/or code patch to be effective only on a given
+> arch./
+>
+> With the last part of the explanation and the warning itself, i'm
+> confused. If it is only
+> effective on one arch and fixed build there, why apply it blindly to the
+> other where this may break build
+> or have other unwanted sideeffects?
+Because you won't notice your patch doesn't apply anymore until you 
+build on the platform where it is actually applied. In most case, it 
+will be the buildbot which fails, whereas your own local build was OK. 
+The point here is 'the earlier it breaks, the quicker it gets noticed'.
+
+-- 
+BOFH excuse #47:
+
+Complete Transient Lockout
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007611.html b/zarb-ml/mageia-dev/2011-August/007611.html new file mode 100644 index 000000000..ae00b4adb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007611.html @@ -0,0 +1,173 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ Michael Scherer + misc at zarb.org +
+ Sat Aug 27 22:19:15 CEST 2011 +

+
+ +
Le samedi 27 août 2011 à 22:06 +0200, Florian Hubold a écrit :
+> Am 04.03.2011 22:30, schrieb Michael Scherer:
+> >
+> >
+> > But we can filter and configure it to be a little more perfect.
+> >
+> > In a rather autocratic fashion, as the maintainer of rpmlint ( both packages
+> > and uptream ), as a packager representative, and as a apprentice dictator
+> > ( since there is lots of open position in this sector since a few weeks ),
+> > I propose that this become the canonical source for rpmlint configuration.
+> >
+> > In practice, that mean that false positives will have to be added there,
+> > that stuff that are noted as errors need to be set in that package, and
+> > any policy changes must be made there.
+> >
+> > So the question is "how do we deal with evolution ( ie, how do we decide
+> > something is now a error, or no longer one".
+> >
+> > Traditionally, packagers didn't care at all, and so the configuration bitrotted
+> > since a long time, and people didn't used it, and I just added false positives
+> > when packagers notified it ( ie, almost never, except when I noticed some of 
+> > them ).
+> > I suspect that my lack of communication around that didn't help ( and so
+> > people didn't knew they could ask for adding a false positive to the list
+> > of error to ignore ).
+> >
+> > Yet, I think we can do better, so feel free to suggest any mad idea for this.
+> 
+> What about the following, AFAIK those are deprecated and rpmlint shouldn't 
+> complain about:
+> 
+> *files-attr-not-set*        as i was told by dmorgan, empty default attributes 
+> (%defattr(-,root,root))
+> are useless and not needed, but without it rpmlint complains with this warning 
+> for every file.
+> What's the status quoe here? rpmlint issue or maybe an rpm bug?
+> Empty %defattr still needed or not and if not, could you make that warning an 
+> exception?
+
+TO be really clean, this should be changed directly in rpmlint upstream
+to remove the check. But as I do not know the various supported version
+for this removal, I will add a filter.
+
+> *no-%clean-section*
+> *no-cleaning-of-buildroot %clean *related to the former, as %clean is not 
+> needed anymore,
+> because it's done automagically by rpm as a builtin
+
+Already filtered : 
+# %clean is now optional, and set by default to a proper value
+addFilter('no-%clean-section')
+
+> All the following should be deprecated by filetriggers:
+> 
+> *library-without-ldconfig-postin
+> library-without-ldconfig-postun
+
+Already filtered :
+addFilter('library-without-ldconfig-postin')
+addFilter('library-without-ldconfig-postun')
+
+> menu-without-postin
+> menu-without-postun*
+
+no, the menu file is the old menu system, which was replaced by xdg
+menus. This is not handled by filetriggers. So do we really have nothing
+more depending on it ? ( like some obscure wm ? ) 
+
+> 
+> I think the following are bogus, but i may be totally wrong:
+> 
+> *strange-permission *       for SOURCES and SPEC it complains if not 0644, why 
+> is that?
+
+The question is rather, "why should another permission be used ?". If
+not, we can end with 700 or anything weird. 
+
+
+> *%ifarch-applied-patch*    if the build is broken only for i586 for example, 
+> what's wrong about the %ifarch?
+> Or maybe i don't get the description fully:
+> 
+>     /Patches must be applied on all architectures and may contain
+>     necessary configure and/or code patch to be effective only on a given arch./
+> 
+> With the last part of the explanation and the warning itself, i'm confused. If 
+> it is only effective on one arch and fixed build there, why apply it blindly to the other 
+> where this may break build
+> or have other unwanted sideeffects?
+
+If the patch is applicable only to one arch because it break the build
+somewhere else, it is likely to be refused upstream. IF not suitable for
+upstream developpers, then it should not be suitable for us.
+
+So no, this one should not be silenced, and rather promoted to upload
+blocking errors.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007612.html b/zarb-ml/mageia-dev/2011-August/007612.html new file mode 100644 index 000000000..b5580369c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007612.html @@ -0,0 +1,104 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ Florian Hubold + doktor5000 at arcor.de +
+ Sat Aug 27 22:26:02 CEST 2011 +

+
+ +
Am 27.08.2011 22:16, schrieb Guillaume Rousse:
+> On 27/08/2011 22:06, Florian Hubold wrote:
+>> I think the following are bogus, but i may be totally wrong:
+>>
+>> *strange-permission * for SOURCES and SPEC it complains if not 0644, why
+>> is that?
+> rpmrebuild won't work if you can't read the files included in the source 
+> package after extracting them.
+Yes, understood perfectly.
+But why does it complain about 0664 which would be the default for those
+files with a freshly created /home? Maybe it should only warn if the permissions
+are actually less?
+>
+>> *%ifarch-applied-patch* if the build is broken only for i586 for
+>> example, what's wrong about the %ifarch?
+> >
+>> Or maybe i don't get the description fully:
+>>
+>> /Patches must be applied on all architectures and may contain
+>> necessary configure and/or code patch to be effective only on a given
+>> arch./
+>>
+>> With the last part of the explanation and the warning itself, i'm
+>> confused. If it is only
+>> effective on one arch and fixed build there, why apply it blindly to the
+>> other where this may break build
+>> or have other unwanted sideeffects?
+> Because you won't notice your patch doesn't apply anymore until you build on 
+> the platform where it is actually applied. In most case, it will be the 
+> buildbot which fails, whereas your own local build was OK. The point here is 
+> 'the earlier it breaks, the quicker it gets noticed'.
+>
+Ah, silly me. Now i got it.
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007613.html b/zarb-ml/mageia-dev/2011-August/007613.html new file mode 100644 index 000000000..79a026699 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007613.html @@ -0,0 +1,98 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ Florian Hubold + doktor5000 at arcor.de +
+ Sat Aug 27 22:41:39 CEST 2011 +

+
+ +
Am 27.08.2011 22:19, schrieb Michael Scherer:
+> Le samedi 27 août 2011 à 22:06 +0200, Florian Hubold a écrit :
+>>
+>> What about the following, AFAIK those are deprecated and rpmlint shouldn't
+>> complain about:
+>>
+>> *files-attr-not-set*        as i was told by dmorgan, empty default attributes
+>> (%defattr(-,root,root))
+>> are useless and not needed, but without it rpmlint complains with this warning
+>> for every file.
+>> What's the status quoe here? rpmlint issue or maybe an rpm bug?
+>> Empty %defattr still needed or not and if not, could you make that warning an
+>> exception?
+> TO be really clean, this should be changed directly in rpmlint upstream
+> to remove the check. But as I do not know the various supported version
+> for this removal, I will add a filter.
+So someone with more insights wrt RPM should comment on this. dmorgan?
+
+>
+>> I think the following are bogus, but i may be totally wrong:
+>>
+>> *strange-permission *       for SOURCES and SPEC it complains if not 0644, why
+>> is that?
+> The question is rather, "why should another permission be used ?". If
+> not, we can end with 700 or anything weird.
+See my following mail.
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007614.html b/zarb-ml/mageia-dev/2011-August/007614.html new file mode 100644 index 000000000..e472bff6a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007614.html @@ -0,0 +1,105 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ D.Morgan + dmorganec at gmail.com +
+ Sat Aug 27 23:02:19 CEST 2011 +

+
+ +
On Sat, Aug 27, 2011 at 10:41 PM, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Am 27.08.2011 22:19, schrieb Michael Scherer:
+>>
+>> Le samedi 27 août 2011 à 22:06 +0200, Florian Hubold a écrit :
+>>>
+>>> What about the following, AFAIK those are deprecated and rpmlint
+>>> shouldn't
+>>> complain about:
+>>>
+>>> *files-attr-not-set*        as i was told by dmorgan, empty default
+>>> attributes
+>>> (%defattr(-,root,root))
+>>> are useless and not needed, but without it rpmlint complains with this
+>>> warning
+>>> for every file.
+>>> What's the status quoe here? rpmlint issue or maybe an rpm bug?
+>>> Empty %defattr still needed or not and if not, could you make that
+>>> warning an
+>>> exception?
+>>
+>> TO be really clean, this should be changed directly in rpmlint upstream
+>> to remove the check. But as I do not know the various supported version
+>> for this removal, I will add a filter.
+>
+> So someone with more insights wrt RPM should comment on this. dmorgan?
+
+this is not needed since 2004.
+
+commit 47ea5da7dd42de36b235b688205fb35f53e3cad6
+Author: jbj <devnull at localhost>
+Date:   Wed Oct 13 21:03:29 2004 +0000
+- silently add default %defattr(-,root,root) for all packages.
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007615.html b/zarb-ml/mageia-dev/2011-August/007615.html new file mode 100644 index 000000000..a66104f68 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007615.html @@ -0,0 +1,117 @@ + + + + [Mageia-dev] Possible failure in our update process + + + + + + + + + +

[Mageia-dev] Possible failure in our update process

+ Samuel Verschelde + stormi at laposte.net +
+ Sat Aug 27 23:46:01 CEST 2011 +

+
+ +
Le jeudi 18 août 2011 17:46:06, John Balcaen a écrit :
+> Hello,
+> 
+> I noticed a problem with our update process thanks to bug #2450 [1]
+> Here we pushed a update to kipi-plugins package (due to a missing
+> requires) but the update ends up in a totally broken installation for
+> the end user which was not noticed by me (first in fault) & later by
+> QA.
+> 
+> Currently every package built for updates are done against
+> core/release, core/updates and core/updates_testing, here when i
+> pushed kipi-plugins update, KDE 4.6.5 was already available in
+> core/updates_testing so as expected kipi-plugins get linked against
+> KDE 4.6.5 & not against KDE 4.6.3 (available in core/release)
+> Since most of actors of the QA are simply installing all packages from
+> core/updates_testing  (like me) none of us noticed that it would break
+>  without KDE 4.6.5 installed and when probably for first updates
+> people are using a « fresh Mageia 1» , with several packages in
+> updates_testing in the same moment we can't really expect them to
+> removed or reinstall/restore a Mageia 1 for every package available in
+> testing.
+> 
+> A workaround (which could also ease work for QA people) would be to
+> have some temporary repositories as suggested by bolkm on irc, it
+> could be based on SRPM package name but for some project like KDE  it
+> would need more hacks since RPMS needed to be builded in a specific
+> order.
+> 
+> The QA user will be able to simply add a new media (like
+> urpmi.addmedia $mirror/core/updates_testing/packagetotest/ ) so it
+> will be more easy to test a package & *only* this one.
+> 
+> Another solution is to rebuild the package when moving in on
+> core/updates_release but in that case the package tested by QA is of
+> course not the same as the one available previously in testing.
+> 
+> What do you think ?
+> 
+> 
+
+If I understand correctly, the problem is when several packages interfere with 
+each other. One thing that could help would be that after submit each update 
+candidate be checked by a script that would :
+- detect BuildRequires that are present in updates_testing
+- (needed ?) detect Requires that are present in updates_testing
+
+When there are such dependencies that come from updates_testing, it means that 
+they have not been pushed to updates yet, and that the update candidate that 
+is being checked must be treated with care.
+
+In kipi-plugins case, maybe following such a check, we would have decided to 
+ship it as part of the big KDE update and not as a standalone update.
+
+The updates policy would have to be adapted so that this check becomes part of 
+every update candidate validation.
+
+I'm not sure this is a good idea, but I'm sending it to you all the same :)
+
+Samuel
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007616.html b/zarb-ml/mageia-dev/2011-August/007616.html new file mode 100644 index 000000000..30fe077f6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007616.html @@ -0,0 +1,126 @@ + + + + [Mageia-dev] Fw: The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] Fw: The Hydra Nature of the horde-* packages

+ Thomas Spuhler + thomas at btspuhler.com +
+ Sun Aug 28 00:13:04 CEST 2011 +

+
+ +
On Saturday, August 27, 2011 09:57:20 am Shlomi Fish wrote:
+> Begin forwarded message:
+> 
+> Date: Sat, 27 Aug 2011 19:47:37 +0300
+> From: Shlomi Fish <shlomif at shlomifish.org>
+> To: Mageia development mailing-list <mageia-dev at mageia.org>
+> Cc: thomas at btspuhler.com
+> Subject: Re: [Mageia-dev] The Hydra Nature of the horde-* packages
+> 
+> 
+> Hi Thomas,
+> 
+> On Sat, 27 Aug 2011 09:31:45 -0700
+> 
+> Thomas Spuhler <thomas at btspuhler.com> wrote:
+> > On Saturday, August 27, 2011 09:17:56 am Shlomi Fish wrote:
+> > > Hi all,
+> > > 
+> > > I just rebuilt a few horde-* packages for which there were missing
+> > > dependencies in http://pkgsubmit.mageia.org/data/missing-deps.i586.txt
+> > > , but now there are more that are not there:
+> > > 
+> > > horde-compress
+> > > horde-datatree
+> > > horde-history
+> > > horde-secret
+> > > horde-text-filter
+> > > horde-token
+> > > 
+> > > This reminds me of the http://en.wikipedia.org/wiki/Lernaean_Hydra
+> > > where if you cut one of its heads, then two grow instead.
+> > > 
+> > > How can we resolve all the horde dependencies for good? Why do they
+> > > reappear? What is the underlying problem?
+> > > 
+> > > I'm CCing it to mageia-sysadm because it may be a Sys admin problem.
+> > > 
+> > > Regards,
+> > > 
+> > > 	Shlomi Fish
+> > 
+> > These will be removed when the whole horde tree is done. The new names
+> > are:]
+> > 
+> > php-pear-Horde.....
+> > 
+> > I am working on them, but there are a lot of deps to be built.
+> 
+> I don't understand exactly how these things are related? Why have we been
+> having lots of broken horde-* dependencies for a long while? Why do horde-*
+> packages disappear? Can we discuss this on IRC? I am "rindolf" there.
+> 
+> Regards,
+> 
+> 	Shlomi Fish
+Why did you rebuild these? They have been obsoleted in i586 with php-pear-
+Horde packages with mostly the same name. 
+
+-- 
+Thomas
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007617.html b/zarb-ml/mageia-dev/2011-August/007617.html new file mode 100644 index 000000000..d5b43c46b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007617.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] clamav is in updates_testing but QA team got no update request + + + + + + + + + +

[Mageia-dev] clamav is in updates_testing but QA team got no update request

+ Samuel Verschelde + stormi at laposte.net +
+ Sun Aug 28 00:19:12 CEST 2011 +

+
+ +
There seems to be an update candidate for clamav, it's been in updates_testing 
+for one month or more, but I can't find any bug report in bugzilla assigned to 
+QA team (qa-bugs at ml.mageia.org) which means it will never reach updates.
+
+There are probably other packages in updates_testing for Mageia 1 without any 
+bug report passed to QA. Ultimately I would like to have a correspondance 
+table to be able to find them. This would probably mean to develop a tool for 
+that and slightly adapt the updates procedure, but we would also benefit from 
+the rigorous match between packages in updates_testing and update bug reports, 
+so less forgotten packages when pushing to updates.
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007618.html b/zarb-ml/mageia-dev/2011-August/007618.html new file mode 100644 index 000000000..dc6365398 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007618.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] clamav is in updates_testing but QA team got no update request + + + + + + + + + +

[Mageia-dev] clamav is in updates_testing but QA team got no update request

+ Luis Daniel Lucio Quiroz + dlucio at okay.com.mx +
+ Sun Aug 28 01:38:51 CEST 2011 +

+
+ +
Le Dimanche 28 Août 2011 00:19:12 Samuel Verschelde a écrit :
+> There seems to be an update candidate for clamav, it's been in
+> updates_testing for one month or more, but I can't find any bug report in
+> bugzilla assigned to QA team (qa-bugs at ml.mageia.org) which means it will
+> never reach updates.
+> 
+> There are probably other packages in updates_testing for Mageia 1 without
+> any bug report passed to QA. Ultimately I would like to have a
+> correspondance table to be able to find them. This would probably mean to
+> develop a tool for that and slightly adapt the updates procedure, but we
+> would also benefit from the rigorous match between packages in
+> updates_testing and update bug reports, so less forgotten packages when
+> pushing to updates.
+> 
+> Best regards
+> 
+> Samuel Verschelde
+
+I did push that clamav,
+but since i couldnt enter into buziglla i couldnt do ticket.  Yes i did try 
+asking sysadmins to reset my password, but it seems my account has problems.
+
+LD
+@ldlq
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007619.html b/zarb-ml/mageia-dev/2011-August/007619.html new file mode 100644 index 000000000..10c2c8efb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007619.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] [135775] - really disable automatic contrib libraries download + + + + + + + + + +

[Mageia-dev] [135775] - really disable automatic contrib libraries download

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Sun Aug 28 03:09:30 CEST 2011 +

+
+ +
On 27.08.2011 21:20, root at mageia.org wrote:
+> +#on update, when someone forgets to redo the tarball of the contribs libraries, handbrake buildsystem
+> +#will automatically download those, that is objectionable on mageia buildsystema and build should fail
+> +#small hack, proposed by Anssi, to disable accidental automatic downloading of contrib libraries
+> +for downloader in wget url; do
+> +mkdir -p disable_contrib.fetch-hack
+> +ln -s /bin/false disable_contrib.fetch-hack/${downloader}
+> +export PATH=$PWD/disable_contrib.fetch-hack:$PATH
+> +done
+> +
+
+Nit: export and mkdir could be outside the for loop, though there is no
+harm done here :)
+
+What do you want to do with faac. Just build with it?
+If so, you'll need to change the License tag, maybe to "GPLv2+ and
+Freeware".
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007620.html b/zarb-ml/mageia-dev/2011-August/007620.html new file mode 100644 index 000000000..4cba159fd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007620.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [135775] - really disable automatic contrib libraries download + + + + + + + + + +

[Mageia-dev] [135775] - really disable automatic contrib libraries download

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Sun Aug 28 04:12:39 CEST 2011 +

+
+ +
On 28.08.2011 04:09, Anssi Hannula wrote:
+> On 27.08.2011 21:20, root at mageia.org wrote:
+>> +#on update, when someone forgets to redo the tarball of the contribs libraries, handbrake buildsystem
+>> +#will automatically download those, that is objectionable on mageia buildsystema and build should fail
+>> +#small hack, proposed by Anssi, to disable accidental automatic downloading of contrib libraries
+>> +for downloader in wget url; do
+>> +mkdir -p disable_contrib.fetch-hack
+>> +ln -s /bin/false disable_contrib.fetch-hack/${downloader}
+>> +export PATH=$PWD/disable_contrib.fetch-hack:$PATH
+>> +done
+>> +
+> 
+> Nit: export and mkdir could be outside the for loop, though there is no
+> harm done here :)
+> 
+> What do you want to do with faac. Just build with it?
+> If so, you'll need to change the License tag, maybe to "GPLv2+ and
+> Freeware".
+> 
+
+Sorry, sent this to a wrong address.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007621.html b/zarb-ml/mageia-dev/2011-August/007621.html new file mode 100644 index 000000000..b4510c7ac --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007621.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-beta-l10n-7.0b2-0.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-beta-l10n-7.0b2-0.mga2

+ Sander Lepik + sander.lepik at eesti.ee +
+ Sun Aug 28 09:07:36 CEST 2011 +

+
+ +
28.08.2011 08:46, Mageia Team kirjutas:
+> Name        : firefox-beta-l10n            Relocations: (not relocatable)
+> Version     : 7.0b2                             Vendor: Mageia.Org
+> Release     : 0.mga2                        Build Date: Sun Aug 28 07:44:28 2011
+> Install Date: (not installed)               Build Host: jonund
+> Group       : Networking/WWW                Source RPM: (none)
+> Size        : 16047527                         License: GPL
+> Signature   : (none)
+> Packager    : Mageia Team <http://www.mageia.org>
+> URL         : http://www.firefox.com/
+> Summary     : Localizations for Firefox (virtual package)
+> Description :
+> Localizations for Firefox web browser.
+>
+> fwang <fwang> 7.0b2-0.mga2:
+> + Revision: 135845
+> - new version 7.0b2
+>
+>   + tv <tv>
+>     - clean spec file
+>     - imported package firefox-beta-l10n
+New version, but still a lot of errors: http://check.mageia.org/dependencies.html - what's
+the point?
+
+--
+Sander
+
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007622.html b/zarb-ml/mageia-dev/2011-August/007622.html new file mode 100644 index 000000000..1d79b2733 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007622.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-beta-l10n-7.0b2-0.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-beta-l10n-7.0b2-0.mga2

+ Funda Wang + fundawang at gmail.com +
+ Sun Aug 28 09:31:14 CEST 2011 +

+
+ +
The problem comes from wrong version set for firefox-l10n. We should
+set following in firefox-beta-l10n for pre-final versions:
+
+Version: 7.0
+Release: %mkrel -c b2 1
+
+But somebody pushed 7.0b2 as version, which will causes problems in
+the future. Anyway, i'm currently making extra provides for ff which
+is currently building. So it will be fine in an hour or so.
+
+2011/8/28 Sander Lepik <sander.lepik at eesti.ee>:
+> New version, but still a lot of errors: http://check.mageia.org/dependencies.html - what's
+> the point?
+>
+> --
+> Sander
+>
+>
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007623.html b/zarb-ml/mageia-dev/2011-August/007623.html new file mode 100644 index 000000000..7a69212fb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007623.html @@ -0,0 +1,149 @@ + + + + [Mageia-dev] Fw: The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] Fw: The Hydra Nature of the horde-* packages

+ Shlomi Fish + shlomif at shlomifish.org +
+ Sun Aug 28 09:23:27 CEST 2011 +

+
+ +
On Sat, 27 Aug 2011 15:13:04 -0700
+Thomas Spuhler <thomas at btspuhler.com> wrote:
+
+> On Saturday, August 27, 2011 09:57:20 am Shlomi Fish wrote:
+> > Begin forwarded message:
+> > 
+> > Date: Sat, 27 Aug 2011 19:47:37 +0300
+> > From: Shlomi Fish <shlomif at shlomifish.org>
+> > To: Mageia development mailing-list <mageia-dev at mageia.org>
+> > Cc: thomas at btspuhler.com
+> > Subject: Re: [Mageia-dev] The Hydra Nature of the horde-* packages
+> > 
+> > 
+> > Hi Thomas,
+> > 
+> > On Sat, 27 Aug 2011 09:31:45 -0700
+> > 
+> > Thomas Spuhler <thomas at btspuhler.com> wrote:
+> > > On Saturday, August 27, 2011 09:17:56 am Shlomi Fish wrote:
+> > > > Hi all,
+> > > > 
+> > > > I just rebuilt a few horde-* packages for which there were missing
+> > > > dependencies in http://pkgsubmit.mageia.org/data/missing-deps.i586.txt
+> > > > , but now there are more that are not there:
+> > > > 
+> > > > horde-compress
+> > > > horde-datatree
+> > > > horde-history
+> > > > horde-secret
+> > > > horde-text-filter
+> > > > horde-token
+> > > > 
+> > > > This reminds me of the http://en.wikipedia.org/wiki/Lernaean_Hydra
+> > > > where if you cut one of its heads, then two grow instead.
+> > > > 
+> > > > How can we resolve all the horde dependencies for good? Why do they
+> > > > reappear? What is the underlying problem?
+> > > > 
+> > > > I'm CCing it to mageia-sysadm because it may be a Sys admin problem.
+> > > > 
+> > > > Regards,
+> > > > 
+> > > > 	Shlomi Fish
+> > > 
+> > > These will be removed when the whole horde tree is done. The new names
+> > > are:]
+> > > 
+> > > php-pear-Horde.....
+> > > 
+> > > I am working on them, but there are a lot of deps to be built.
+> > 
+> > I don't understand exactly how these things are related? Why have we been
+> > having lots of broken horde-* dependencies for a long while? Why do horde-*
+> > packages disappear? Can we discuss this on IRC? I am "rindolf" there.
+> > 
+> > Regards,
+> > 
+> > 	Shlomi Fish
+> Why did you rebuild these? They have been obsoleted in i586 with php-pear-
+> Horde packages with mostly the same name. 
+> 
+
+Because they were marked as missing dependencies in:
+
+http://pkgsubmit.mageia.org/data/missing-deps.i586.txt
+
+And I wanted to reduce the missing-deps list. But so far I see that I am
+running into many dead ends with reducing the missing-deps list, and so I'm not
+sure I'd like to continue with doing this anymore.
+
+Regards,
+
+	Shlomi Fish
+
+-- 
+-----------------------------------------------------------------
+Shlomi Fish       http://www.shlomifish.org/
+What does "Zionism" mean? - http://shlom.in/def-zionism
+
+Chuck Norris doesn’t commit changes, the changes commit for him.
+    — Araujo
+
+Please reply to list if it's a mailing list post - http://shlom.in/reply .
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007624.html b/zarb-ml/mageia-dev/2011-August/007624.html new file mode 100644 index 000000000..55e02e41a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007624.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] [RPM] cauldron core/release perl-Gtk2-Unique-0.50.0-2.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release perl-Gtk2-Unique-0.50.0-2.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sun Aug 28 10:21:50 CEST 2011 +

+
+ +
On 28 August 2011 06:29, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> fwang <fwang> 0.50.0-2.mga2:
+> + Revision: 135835
+> - rebuild
+
+What for?
+As asked many times, please write why you rebuild packages.
+
+ + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007625.html b/zarb-ml/mageia-dev/2011-August/007625.html new file mode 100644 index 000000000..710384437 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007625.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ andre999 + andre999.mga at laposte.net +
+ Sun Aug 28 10:30:19 CEST 2011 +

+
+ +
Florian Hubold a écrit :
+> Hello,
+>
+> as was already proposed some time ago, but not implemented yet,
+> i'm proposing a mageia-packager package, maybe as a task-package.
+> IMHO It should at least require the following:
+>
+> rpm-build
+> rpmlint
+> rpmlint-mageia-policy
+> bm implicitly required by magpie
+> mgarepo implicitly required by magpie
+> magpie
+> openssh-askpass for basic ssh setup
+> keychain for basic ssh setup
+>
+>
+> What else should be in there? Please comment :)
+>
+Sounds ok (in my non-expert opinion),
+but maybe we should have a choice between
+openssh-askpass , openssh-askpass-gnome , and openssh-askpass-qt
+since they are equivalent ?  (with identical version numbering)
+(The latter 2 also being smaller)
+
+-- 
+André
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007626.html b/zarb-ml/mageia-dev/2011-August/007626.html new file mode 100644 index 000000000..3efff0e58 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007626.html @@ -0,0 +1,99 @@ + + + + [Mageia-dev] Rpmlint configuration, false positives + + + + + + + + + +

[Mageia-dev] Rpmlint configuration, false positives

+ andre999 + andre999.mga at laposte.net +
+ Sun Aug 28 10:31:00 CEST 2011 +

+
+ +
Michael Scherer a écrit :
+> Le samedi 27 août 2011 à 22:06 +0200, Florian Hubold a écrit :
+>> Am 04.03.2011 22:30, schrieb Michael Scherer:
+>>>
+>>> But we can filter and configure it to be a little more perfect.
+>>>
+>>> In a rather autocratic fashion, as the maintainer of rpmlint ( both packages
+>>> and uptream ), as a packager representative, and as a apprentice dictator
+>>> ( since there is lots of open position in this sector since a few weeks ),
+>>> I propose that this become the canonical source for rpmlint configuration.
+>>>
+>>> In practice, that mean that false positives will have to be added there,
+>>> that stuff that are noted as errors need to be set in that package, and
+>>> any policy changes must be made there.
+
+Good idea
+
+[...]
+
+>> I think the following are bogus, but i may be totally wrong:
+>>
+>> *strange-permission *       for SOURCES and SPEC it complains if not 0644, why
+>> is that?
+>
+> The question is rather, "why should another permission be used ?". If
+> not, we can end with 700 or anything weird.
+
+Like the 600 permissions that actually _did_ occur with Python-docs not too 
+long ago.  We need that warning.
+
+-- 
+André
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007627.html b/zarb-ml/mageia-dev/2011-August/007627.html new file mode 100644 index 000000000..94bb742ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007627.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] Possible failure in our update process + + + + + + + + + +

[Mageia-dev] Possible failure in our update process

+ andre999 + andre999.mga at laposte.net +
+ Sun Aug 28 10:31:10 CEST 2011 +

+
+ +
Samuel Verschelde a écrit :
+> Le jeudi 18 août 2011 17:46:06, John Balcaen a écrit :
+>> Hello,
+>>
+>> I noticed a problem with our update process thanks to bug #2450 [1]
+>> Here we pushed a update to kipi-plugins package (due to a missing
+>> requires) but the update ends up in a totally broken installation for
+>> the end user which was not noticed by me (first in fault)&  later by
+>> QA.
+>>
+>> Currently every package built for updates are done against
+>> core/release, core/updates and core/updates_testing, here when i
+>> pushed kipi-plugins update, KDE 4.6.5 was already available in
+>> core/updates_testing so as expected kipi-plugins get linked against
+>> KDE 4.6.5&  not against KDE 4.6.3 (available in core/release)
+>> Since most of actors of the QA are simply installing all packages from
+>> core/updates_testing  (like me) none of us noticed that it would break
+>>   without KDE 4.6.5 installed and when probably for first updates
+>> people are using a « fresh Mageia 1» , with several packages in
+>> updates_testing in the same moment we can't really expect them to
+>> removed or reinstall/restore a Mageia 1 for every package available in
+>> testing.
+>>
+>> A workaround (which could also ease work for QA people) would be to
+>> have some temporary repositories as suggested by bolkm on irc, it
+>> could be based on SRPM package name but for some project like KDE  it
+>> would need more hacks since RPMS needed to be builded in a specific
+>> order.
+>>
+>> The QA user will be able to simply add a new media (like
+>> urpmi.addmedia $mirror/core/updates_testing/packagetotest/ ) so it
+>> will be more easy to test a package&  *only* this one.
+>>
+>> Another solution is to rebuild the package when moving in on
+>> core/updates_release but in that case the package tested by QA is of
+>> course not the same as the one available previously in testing.
+>>
+>> What do you think ?
+>>
+>>
+>
+> If I understand correctly, the problem is when several packages interfere with
+> each other. One thing that could help would be that after submit each update
+> candidate be checked by a script that would :
+> - detect BuildRequires that are present in updates_testing
+> - (needed ?) detect Requires that are present in updates_testing
+>
+> When there are such dependencies that come from updates_testing, it means that
+> they have not been pushed to updates yet, and that the update candidate that
+> is being checked must be treated with care.
+>
+> In kipi-plugins case, maybe following such a check, we would have decided to
+> ship it as part of the big KDE update and not as a standalone update.
+>
+> The updates policy would have to be adapted so that this check becomes part of
+> every update candidate validation.
+>
+> I'm not sure this is a good idea, but I'm sending it to you all the same :)
+>
+> Samuel
+>
+That's a good idea.  It would avoid the situation where updates won't install 
+because of specified dependancies that are missing.  But such cases won't 
+result in breaks, since such packages won't be installed.
+
+Let's assume that a package functions correctly with the latest updates 
+installed, but it breaks on a system based on the latest release, but without 
+all updates (or packages on the test systems) installed.
+
+If an update installs on a users' system, but it breaks, it indicates that 
+something required is not available.  (Since it did work properly in a certain 
+context.)
+In other words, the requires for the package aren't correct.
+1) It could be that a package required is not specified (directly or indirectly).
+2) It could be that a more recent (or different) version of a specified package 
+is required.
+
+It would be useful to have a script that monitors the package during execution 
+and determines what is called, to give us a list of what packages and versions 
+were used.
+This will show us packages missing in requires.
+As for versions, that is trickier.  Requiring the versions used in the tests 
+would be excessive in many cases.  However if this analysis is done before 
+releasing the update, it would help to more quickly correct broken updates.
+
+Hopefully this analysis helps a bit ? :)
+
+-- 
+André
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007628.html b/zarb-ml/mageia-dev/2011-August/007628.html new file mode 100644 index 000000000..f79f4daa9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007628.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ Florian Hubold + doktor5000 at arcor.de +
+ Sun Aug 28 10:50:41 CEST 2011 +

+
+ +
Am 28.08.2011 10:30, schrieb andre999:
+> Florian Hubold a écrit :
+>> Hello,
+>>
+>> as was already proposed some time ago, but not implemented yet,
+>> i'm proposing a mageia-packager package, maybe as a task-package.
+>> IMHO It should at least require the following:
+>>
+>> rpm-build
+>> rpmlint
+>> rpmlint-mageia-policy
+>> bm implicitly required by magpie
+>> mgarepo implicitly required by magpie
+>> magpie
+>> openssh-askpass for basic ssh setup
+>> keychain for basic ssh setup
+>>
+>>
+>> What else should be in there? Please comment :)
+>>
+> Sounds ok (in my non-expert opinion),
+> but maybe we should have a choice between
+> openssh-askpass , openssh-askpass-gnome , and openssh-askpass-qt
+> since they are equivalent ?  (with identical version numbering)
+> (The latter 2 also being smaller)
+>
+When you install keychain , you should get asked by urpmi, no?
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007629.html b/zarb-ml/mageia-dev/2011-August/007629.html new file mode 100644 index 000000000..e813faeb8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007629.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ andre999 + andre999.mga at laposte.net +
+ Sun Aug 28 11:10:19 CEST 2011 +

+
+ +
Florian Hubold a écrit :
+> Am 28.08.2011 10:30, schrieb andre999:
+>> Florian Hubold a écrit :
+>>> Hello,
+>>>
+>>> as was already proposed some time ago, but not implemented yet,
+>>> i'm proposing a mageia-packager package, maybe as a task-package.
+>>> IMHO It should at least require the following:
+>>>
+>>> rpm-build
+>>> rpmlint
+>>> rpmlint-mageia-policy
+>>> bm implicitly required by magpie
+>>> mgarepo implicitly required by magpie
+>>> magpie
+>>> openssh-askpass for basic ssh setup
+>>> keychain for basic ssh setup
+>>>
+>>>
+>>> What else should be in there? Please comment :)
+>>>
+>> Sounds ok (in my non-expert opinion),
+>> but maybe we should have a choice between
+>> openssh-askpass , openssh-askpass-gnome , and openssh-askpass-qt
+>> since they are equivalent ? (with identical version numbering)
+>> (The latter 2 also being smaller)
+>>
+> When you install keychain , you should get asked by urpmi, no?
+>
+I don't know, but that sounds plausible, especially if they all have "provides 
+openssh-askpass".
+Obviously I'm not an expert ;)
+
+-- 
+André
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007630.html b/zarb-ml/mageia-dev/2011-August/007630.html new file mode 100644 index 000000000..39d1b5b41 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007630.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] Fw: The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] Fw: The Hydra Nature of the horde-* packages

+ Jani Välimaa + jani.valimaa at gmail.com +
+ Sun Aug 28 11:20:53 CEST 2011 +

+
+ +
2011/8/28 Thomas Spuhler <thomas at btspuhler.com>:
+> Why did you rebuild these? They have been obsoleted in i586 with php-pear-
+> Horde packages with mostly the same name.
+>
+
+Shouldn't we remove the old and obsoleted pkgs from SVN (or move them
+to old/) to prevent what just happened?
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007631.html b/zarb-ml/mageia-dev/2011-August/007631.html new file mode 100644 index 000000000..4edae20ff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007631.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development + + + + + + + + + +

[Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development

+ Marcello Anni + marcello.anni at alice.it +
+ Sun Aug 28 12:03:19 CEST 2011 +

+
+ +
Hi all,
+
+what about using mageia-app-db web platform to manage mageia 2 development? 
+i'm talking about this:
+
+http://mageia-app-db.tuxette.fr/projects/mageia-app-db/roadmap
+
+
+i'm sure this will help the coordination between people and will provide a 
+guide for the development process. 
+
+
+what do you think about this proposal?
+
+
+cheers,
+Marcello
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007632.html b/zarb-ml/mageia-dev/2011-August/007632.html new file mode 100644 index 000000000..0f4ae2e00 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007632.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development + + + + + + + + + +

[Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development

+ Anne Nicolas + ennael1 at gmail.com +
+ Sun Aug 28 12:39:41 CEST 2011 +

+
+ +
Le 28/08/2011 12:03, Marcello Anni a écrit :
+> Hi all,
+> 
+> what about using mageia-app-db web platform to manage mageia 2 development? 
+> i'm talking about this:
+> 
+> http://mageia-app-db.tuxette.fr/projects/mageia-app-db/roadmap
+> 
+> 
+> i'm sure this will help the coordination between people and will provide a 
+> guide for the development process. 
+> 
+> 
+> what do you think about this proposal?
+
+Well we already use Bugzilla for this including all specifications and
+keeping progress and history inside.
+
+Adding some statistics will do the trick and triage team can help on this.
+
+https://bugs.mageia.org/show_bug.cgi?id=1994
+
+Cheers
+
+> 
+> 
+> cheers,
+> Marcello
+
+
+-- 
+Anne
+http://mageia.org
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007633.html b/zarb-ml/mageia-dev/2011-August/007633.html new file mode 100644 index 000000000..3b373cbed --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007633.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development + + + + + + + + + +

[Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development

+ D.Morgan + dmorganec at gmail.com +
+ Sun Aug 28 13:18:07 CEST 2011 +

+
+ +
On Sun, Aug 28, 2011 at 12:03 PM, Marcello Anni <marcello.anni at alice.it> wrote:
+> Hi all,
+>
+> what about using mageia-app-db web platform to manage mageia 2 development?
+> i'm talking about this:
+>
+> http://mageia-app-db.tuxette.fr/projects/mageia-app-db/roadmap
+>
+>
+> i'm sure this will help the coordination between people and will provide a
+> guide for the development process.
+>
+>
+> what do you think about this proposal?
+
+this is for the use of mageia-app-db roadmap, no more, no less
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007634.html b/zarb-ml/mageia-dev/2011-August/007634.html new file mode 100644 index 000000000..2e058fac8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007634.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development + + + + + + + + + +

[Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development

+ Marcello Anni + marcello.anni at alice.it +
+ Sun Aug 28 15:20:01 CEST 2011 +

+
+ +
> Le 28/08/2011 12:03, Marcello Anni a écrit :
+> > Hi all,
+> > 
+> > what about using mageia-app-db web platform to manage mageia 2 
+development? 
+> > i'm talking about this:
+> > 
+> > http://mageia-app-db.tuxette.fr/projects/mageia-app-db/roadmap
+> > 
+> > 
+> > i'm sure this will help the coordination between people and will provide a 
+> > guide for the development process. 
+> > 
+> > 
+> > what do you think about this proposal?
+> 
+> Well we already use Bugzilla for this including all specifications and
+> keeping progress and history inside.
+> 
+> Adding some statistics will do the trick and triage team can help on this.
+> 
+> https://bugs.mageia.org/show_bug.cgi?id=1994
+> 
+
+isn't it a more advanced platform compared to the bugzilla? bugzilla isn't 
+developped for these tasks, it's only a bug tracker...  in plus, it's more 
+eye-candy and this is useful to comunicate our progress to our users (and 
+reviewers)
+
+
+Marcello
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007635.html b/zarb-ml/mageia-dev/2011-August/007635.html new file mode 100644 index 000000000..b10b1ce82 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007635.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development + + + + + + + + + +

[Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development

+ Marcello Anni + marcello.anni at alice.it +
+ Sun Aug 28 15:20:37 CEST 2011 +

+
+ +
> On Sun, Aug 28, 2011 at 12:03 PM, Marcello Anni <marcello.anni at alice.it> 
+wrote:
+> > Hi all,
+> >
+> > what about using mageia-app-db web platform to manage mageia 2 
+development?
+> > i'm talking about this:
+> >
+> > http://mageia-app-db.tuxette.fr/projects/mageia-app-db/roadmap
+> >
+> >
+> > i'm sure this will help the coordination between people and will provide a
+> > guide for the development process.
+> >
+> >
+> > what do you think about this proposal?
+> 
+> this is for the use of mageia-app-db roadmap, no more, no less
+
+i mean the platform... isn't it open-source? where is the problem?
+
+
+Marcello 
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007636.html b/zarb-ml/mageia-dev/2011-August/007636.html new file mode 100644 index 000000000..e6e92eff1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007636.html @@ -0,0 +1,92 @@ + + + + [Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development + + + + + + + + + +

[Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development

+ Michael Scherer + misc at zarb.org +
+ Sun Aug 28 16:12:45 CEST 2011 +

+
+ +
Le dimanche 28 août 2011 à 12:03 +0200, Marcello Anni a écrit :
+> Hi all,
+> 
+> what about using mageia-app-db web platform to manage mageia 2 development? 
+> i'm talking about this:
+> 
+> http://mageia-app-db.tuxette.fr/projects/mageia-app-db/roadmap
+> 
+> 
+> i'm sure this will help the coordination between people and will provide a 
+> guide for the development process. 
+> 
+> 
+> what do you think about this proposal?
+
+The webpage you give is redmine, not mageia app db.
+
+And so if the idea is to remove bugzilla to use redmine just to use the
+summary report, it would be much easier to simply write a web page to do
+that, or to submit patchs for the css of our bugzilla. 
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007637.html b/zarb-ml/mageia-dev/2011-August/007637.html new file mode 100644 index 000000000..db7344e77 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007637.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Potential problem with buildsystem + + + + + + + + + +

[Mageia-dev] Potential problem with buildsystem

+ Michael Scherer + misc at zarb.org +
+ Sun Aug 28 17:28:50 CEST 2011 +

+
+ +
Hi, 
+
+while trying to fix a future problem ( our build log were not cleaned,
+and we had 250 go of them on jonund ), I mixed months and minutes, and
+so the puppet job that I added to clean the log may have removed log
+files that should not have been removed. 
+
+So if one of your build is missing a log file, that's the reason. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007638.html b/zarb-ml/mageia-dev/2011-August/007638.html new file mode 100644 index 000000000..9837a61a3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007638.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development + + + + + + + + + +

[Mageia-dev] PROPOSAL: use the Mageia-app-db platform to manage mageia 2 development

+ D.Morgan + dmorganec at gmail.com +
+ Sun Aug 28 17:50:25 CEST 2011 +

+
+ +
On Sun, Aug 28, 2011 at 3:20 PM, Marcello Anni <marcello.anni at alice.it> wrote:
+>> On Sun, Aug 28, 2011 at 12:03 PM, Marcello Anni <marcello.anni at alice.it>
+> wrote:
+>> > Hi all,
+>> >
+>> > what about using mageia-app-db web platform to manage mageia 2
+> development?
+>> > i'm talking about this:
+>> >
+>> > http://mageia-app-db.tuxette.fr/projects/mageia-app-db/roadmap
+>> >
+>> >
+>> > i'm sure this will help the coordination between people and will provide a
+>> > guide for the development process.
+>> >
+>> >
+>> > what do you think about this proposal?
+>>
+>> this is for the use of mageia-app-db roadmap, no more, no less
+>
+> i mean the platform... isn't it open-source? where is the problem?
+>
+>
+> Marcello
+>
+
+this is not because that this is open source that your idea is correct.
+
+I think we should more use Bugzila + Wiki for this .
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007639.html b/zarb-ml/mageia-dev/2011-August/007639.html new file mode 100644 index 000000000..2879c2ab4 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007639.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Viviane, automated system to test installer + + + + + + + + + +

[Mageia-dev] Viviane, automated system to test installer

+ Margot + margot at otfordduckscomputers.co.uk +
+ Sun Aug 28 20:30:13 CEST 2011 +

+
+ +
On Thu, 25 Aug 2011 22:49:05 +0200
+Michael Scherer <misc at zarb.org> wrote:
+
+> Hi,
+> 
+> I finished a quick script that I wrote during my spare time on
+> Wednesday to do a automated test installation in a vm, using
+> libvirt, virtinst, and drakx auto-installation feature.  
+> 
+> As I like catchy names, the project is called Viviane, for 
+> Virtualized Integrated Verification of Installer with Automated
+> Networked Eyeballs. Why did I chose that name is buried deep in
+> the script, kudos to who find it ( and there goes the trick to
+> make people read my code ).
+> 
+
+I'm not a coder or packager, so didn't understand most of the code,
+but I enjoy a good puzzle. I think this is the clue in the code:
+
+'users' => [
+		    {
+		      'icon' => 'default',
+		      'realname' => 'Myrddin Wyllt',
+		      'uid' => undef,
+		      'groups' => ['dialout'],
+		      'name' => 'merlin',
+		      'shell' => '/bin/bash',
+		      'gid' => undef
+		    }
+		  ],
+
+Viviane is one of the many names for the Lady of the Lake. Maybe
+not many Mageia packagers have studied Arthurian legend? :-)
+
+-- 
+Margot
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
+**Otford Ducks Computers**
+We teach, you learn...
+...and, if you don't do your homework, we set the cat on you!
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007640.html b/zarb-ml/mageia-dev/2011-August/007640.html new file mode 100644 index 000000000..210217a45 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007640.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Viviane, automated system to test installer + + + + + + + + + +

[Mageia-dev] Viviane, automated system to test installer

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Sun Aug 28 22:20:27 CEST 2011 +

+
+ +
On 28 August 2011 20:30, Margot <margot at otfordduckscomputers.co.uk> wrote:
+> I'm not a coder or packager, so didn't understand most of the code,
+> but I enjoy a good puzzle. I think this is the clue in the code:
+>
+> 'users' => [
+>                    {
+>                      'icon' => 'default',
+>                      'realname' => 'Myrddin Wyllt',
+>                      'uid' => undef,
+>                      'groups' => ['dialout'],
+>                      'name' => 'merlin',
+>                      'shell' => '/bin/bash',
+>                      'gid' => undef
+>                    }
+>                  ],
+>
+> Viviane is one of the many names for the Lady of the Lake. Maybe
+> not many Mageia packagers have studied Arthurian legend? :-)
+
+That's for the romanised legend.
+There's no viviane/namue in the welsh/breton legends.
+That's middle age invention when christianizing the pagan legends
+(introduction of the holy grail, downfall by eve as viviane, ...)
+Thus -ENOENT
+
+Though Myrddin Wyllt (Merzhin in breton) does be part of  the original
+legends[1] used by the writers...
+
+[1]  as a old foul man living nude in the cold at top of the trees, being
+      driven mad by the number of deads at battle
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007641.html b/zarb-ml/mageia-dev/2011-August/007641.html new file mode 100644 index 000000000..58f047feb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007641.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ Funda Wang + fundawang at gmail.com +
+ Mon Aug 29 06:21:52 CEST 2011 +

+
+ +
Hello,
+
+It looks like our BS is becoming hungry to eat built packages:
+Submitted	User	Package	Target	Media	Status	Build time
+18 hours ago	wally	libcanberra-0.28-3.mga2	cauldron	core/release		uploaded	15215
+days
+23 hours ago	fwang	gnome-python-extras-2.25.3-27.mga2	cauldron	core/release		uploaded	15215
+days
+1 day ago	fwang	libnotify-0.7.4-1.mga2	cauldron	core/release		partial
+
+Could somebody give a look at the issue? And I think BS is much slower
+than the past. In the past, most packages were built succesfully
+within less than 5 minutes, but now > 10 minutes.
+
+Thanks.
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007642.html b/zarb-ml/mageia-dev/2011-August/007642.html new file mode 100644 index 000000000..061750fb3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007642.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ D.Morgan + dmorganec at gmail.com +
+ Mon Aug 29 08:02:29 CEST 2011 +

+
+ +
On Mon, Aug 29, 2011 at 6:21 AM, Funda Wang <fundawang at gmail.com> wrote:
+> Hello,
+>
+> It looks like our BS is becoming hungry to eat built packages:
+> Submitted       User    Package Target  Media   Status  Build time
+> 18 hours ago    wally   libcanberra-0.28-3.mga2 cauldron        core/release            uploaded        15215
+> days
+> 23 hours ago    fwang   gnome-python-extras-2.25.3-27.mga2      cauldron        core/release            uploaded        15215
+> days
+> 1 day ago       fwang   libnotify-0.7.4-1.mga2  cauldron        core/release            partial
+>
+> Could somebody give a look at the issue? And I think BS is much slower
+> than the past. In the past, most packages were built succesfully
+> within less than 5 minutes, but now > 10 minutes.
+>
+> Thanks.
+>
+
+I don't recall seeing such issues on the BS before maybe misc can have an idea
+and, we only have one node for the moment ( ecosse is disabled ) this
+explain why it is slower.
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007643.html b/zarb-ml/mageia-dev/2011-August/007643.html new file mode 100644 index 000000000..32b938799 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007643.html @@ -0,0 +1,63 @@ + + + + [Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside? + + + + + + + + + +

[Mageia-dev] [PROPOSAL] (task-)mageia-packager - what should be inside?

+ José Jorge + jjorge at free.fr +
+ Mon Aug 29 11:41:12 CEST 2011 +

+
+ +
Le samedi 27 août 2011 22:11:16, Florian Hubold a écrit :
+> But overall you support the idea of such a metapackage? Yes, no, maybe?
+Yes. Even if it is only 8 packages, I mostly use task-* packages when 
+preparing a system to something. And the list can evolve over time, making it 
+easier to maintain a packager system without following any mail.
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007644.html b/zarb-ml/mageia-dev/2011-August/007644.html new file mode 100644 index 000000000..a5506da0f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007644.html @@ -0,0 +1,152 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ John Balcaen + mikala at mageia.org +
+ Mon Aug 29 11:47:28 CEST 2011 +

+
+ +
2011/8/29  <root at mageia.org>:
+> Revision 135989 Author ze Date 2011-08-29 08:09:56 +0200 (Mon, 29 Aug 2011)
+>
+> Log Message
+>
+> - cmake its already builrequires by kde-macros
+> - this way we dont force building strictly  with OpenJDK
+> - remove clean section (done by default)
+> - simple way to list dirs
+> - set requires in devel package to release like hapens for restant packages
+>
+> Modified Paths
+>
+> cauldron/soprano/current/SPECS/soprano.spec
+>
+> Modified: cauldron/soprano/current/SPECS/soprano.spec
+> ===================================================================
+> --- cauldron/soprano/current/SPECS/soprano.spec	2011-08-29 05:21:36 UTC (rev
+> 135988)
+> +++ cauldron/soprano/current/SPECS/soprano.spec	2011-08-29 06:09:56 UTC (rev
+[...]
+>
+>  %if %with_java
+> -BuildRequires: java-rpmbuild
+> +BuildRequires: java-devel
+>  BuildRequires: chrpath
+>  %endif
+This is stupid.
+
+>  Conflicts: soprano-devel < 4:2.6.51-2
+>  Suggests: soprano-plugin-virtuoso = %{epoch}:%version
+>
+> @@ -55,8 +52,8 @@
+>  %defattr(-,root,root)
+>  %_bindir/sopranocmd
+>  %_bindir/sopranod
+> -%dir %_datadir/soprano
+> -%_datadir/soprano/rules
+> +%dir %_datadir/soprano/
+
+I guess i forgot the the purpose of %dir so could you explain me the difference
+between %dir %datadir/soprano & %dir %datadir/soprano/ ?
+
+[...]
+
+> -Provides: libsoprano-devel = %{epoch}:%version-%release
+> -Requires: %libsoprano = %{epoch}:%version-%release
+> -Requires: %libsopranoclient = %{epoch}:%version-%release
+> -Requires: %libsopranoserver = %{epoch}:%version-%release
+> -Requires: %libsopranoindex = %{epoch}:%version-%release
+> -Requires: %name = %{epoch}:%version-%release
+> -Requires: %{name}-plugin-virtuoso = %{epoch}:%version-%release
+> -Requires: %{name}-plugin-redland = %{epoch}:%version-%release
+> +Provides: libsoprano-devel = %{epoch}:%version
+> +Requires: %libsoprano = %{epoch}:%version
+> +Requires: %libsopranoclient = %{epoch}:%version
+> +Requires: %libsopranoserver = %{epoch}:%version
+> +Requires: %libsopranoindex = %{epoch}:%version
+> +Requires: %name = %{epoch}:%version
+> +Requires: %{name}-plugin-virtuoso = %{epoch}:%version
+> +Requires: %{name}-plugin-redland = %{epoch}:%version
+It's quite different of what you wrote in the description...
+Here you set the requires to %version & not to %release...
+Also it's quite different how we create requires on library packages
+on other kde's related packages (since we're using
+%epoch:%version-%release)
+but since you already talk with yourself for this change i guess you
+can surely share the reason for this change.
+
+Well i don't care anymore i guess..
+
+
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007645.html b/zarb-ml/mageia-dev/2011-August/007645.html new file mode 100644 index 000000000..a79586a3d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007645.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ Michael Scherer + misc at zarb.org +
+ Mon Aug 29 12:12:05 CEST 2011 +

+
+ +
Le lundi 29 août 2011 à 08:02 +0200, D.Morgan a écrit :
+> On Mon, Aug 29, 2011 at 6:21 AM, Funda Wang <fundawang at gmail.com> wrote:
+> > Hello,
+> >
+> > It looks like our BS is becoming hungry to eat built packages:
+> > Submitted       User    Package Target  Media   Status  Build time
+> > 18 hours ago    wally   libcanberra-0.28-3.mga2 cauldron        core/release            uploaded        15215
+> > days
+> > 23 hours ago    fwang   gnome-python-extras-2.25.3-27.mga2      cauldron        core/release            uploaded        15215
+> > days
+> > 1 day ago       fwang   libnotify-0.7.4-1.mga2  cauldron        core/release            partial
+> >
+> > Could somebody give a look at the issue? And I think BS is much slower
+> > than the past. In the past, most packages were built succesfully
+> > within less than 5 minutes, but now > 10 minutes.
+> >
+> > Thanks.
+> >
+> 
+> I don't recall seeing such issues on the BS before maybe misc can have an idea
+> and, we only have one node for the moment ( ecosse is disabled ) this
+> explain why it is slower.
+
+After looking at the problem, I suspect it could be linked to texmf.
+Each time iurt install it, the process stop.  
+
+Yet, I have no more idea, and couldn't investigate further for now.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007646.html b/zarb-ml/mageia-dev/2011-August/007646.html new file mode 100644 index 000000000..f274b2b8f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007646.html @@ -0,0 +1,91 @@ + + + + [Mageia-dev] clamav is in updates_testing but QA team got no update request + + + + + + + + + +

[Mageia-dev] clamav is in updates_testing but QA team got no update request

+ Buchan Milne + bgmilne at staff.telkomsa.net +
+ Mon Aug 29 12:28:48 CEST 2011 +

+
+ +
On Sunday, 28 August 2011 01:38:51 Luis Daniel Lucio Quiroz wrote:
+> Le Dimanche 28 Août 2011 00:19:12 Samuel Verschelde a écrit :
+> > There seems to be an update candidate for clamav, it's been in
+> > updates_testing for one month or more, but I can't find any bug report in
+> > bugzilla assigned to QA team (qa-bugs at ml.mageia.org) which means it will
+> > never reach updates.
+> > 
+> > There are probably other packages in updates_testing for Mageia 1 without
+> > any bug report passed to QA. Ultimately I would like to have a
+> > correspondance table to be able to find them. This would probably mean to
+> > develop a tool for that and slightly adapt the updates procedure, but we
+> > would also benefit from the rigorous match between packages in
+> > updates_testing and update bug reports, so less forgotten packages when
+> > pushing to updates.
+> > 
+> > Best regards
+> > 
+> > Samuel Verschelde
+> 
+> I did push that clamav,
+> but since i couldnt enter into buziglla i couldnt do ticket.  Yes i did try
+> asking sysadmins to reset my password, but it seems my account has
+> problems.
+
+Password resets done by admins for privileged users was broken if the admin 
+used https://identity.mageia.org to do the reset, but was fixed in trunk 
+(available at https://identity-trunk.mageia.org). I have merged this fix into 
+live, so it now works at https://identity.mageia.org .
+
+Regards,
+Buchan
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007647.html b/zarb-ml/mageia-dev/2011-August/007647.html new file mode 100644 index 000000000..2d3a1842e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007647.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] change in perl automatic provides extraction + + + + + + + + + +

[Mageia-dev] change in perl automatic provides extraction

+ Jerome Quelin + jquelin at gmail.com +
+ Mon Aug 29 13:08:12 CEST 2011 +

+
+ +
On 11/08/25 16:41 +0200, Jerome Quelin wrote:
+> i therefore propose to apply the following patch:
+> $ svn di
+> Index: find-provides.in
+> ===================================================================
+> --- find-provides.in    (révision 1889)
+> +++ find-provides.in    (copie de travail)
+> @@ -47,7 +47,7 @@
+>  #
+>  # --- Perl modules.
+>  [ -x @RPMVENDORDIR@/perl.prov ] &&
+> -    echo "$filelist" | tr '[:blank:]' \\n | @RPMVENDORDIR@/perl.prov | grep 'perl([[:upper:]]' | sort -u \
+> +    echo "$filelist" | tr '[:blank:]' \\n | @RPMVENDORDIR@/perl.prov | grep 'perl(' | sort -u \
+>         && test ${PIPESTATUS[2]} -ne 0 && echo 'error: @RPMVENDORDIR@/perl.prov failed' >&2 && exit 1
+>  
+>  #
+> 
+> 
+> ==> if someone has a compelling reason to disagree, speak now
+> 
+> otherwise, i'll proceed with the change, and will rebuild (at least)
+> perl to provide those. other modules will be rebuilt when updating them
+> to latest upstream.
+
+since nobody objected, i proceeded with the change which should land to
+bs soonish.
+
+jérôme 
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007648.html b/zarb-ml/mageia-dev/2011-August/007648.html new file mode 100644 index 000000000..778faf58c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007648.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ Michael Scherer + misc at zarb.org +
+ Mon Aug 29 13:47:51 CEST 2011 +

+
+ +
Le lundi 29 août 2011 à 08:02 +0200, D.Morgan a écrit :
+> On Mon, Aug 29, 2011 at 6:21 AM, Funda Wang <fundawang at gmail.com> wrote:
+> > Hello,
+> >
+> > It looks like our BS is becoming hungry to eat built packages:
+> > Submitted       User    Package Target  Media   Status  Build time
+> > 18 hours ago    wally   libcanberra-0.28-3.mga2 cauldron        core/release            uploaded        15215
+> > days
+> > 23 hours ago    fwang   gnome-python-extras-2.25.3-27.mga2      cauldron        core/release            uploaded        15215
+> > days
+> > 1 day ago       fwang   libnotify-0.7.4-1.mga2  cauldron        core/release            partial
+> >
+> > Could somebody give a look at the issue? And I think BS is much slower
+> > than the past. In the past, most packages were built succesfully
+> > within less than 5 minutes, but now > 10 minutes.
+> >
+> > Thanks.
+> >
+> 
+> I don't recall seeing such issues on the BS before maybe misc can have an idea
+> and, we only have one node for the moment ( ecosse is disabled ) this
+> explain why it is slower.
+
+After looking at the problem, I suspect it could be linked to texmf.
+Each time iurt install it, the process stop.  
+
+Yet, I have no more idea, and couldn't investigate further for now.
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007649.html b/zarb-ml/mageia-dev/2011-August/007649.html new file mode 100644 index 000000000..e99b3c3e8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007649.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ Michael Scherer + misc at zarb.org +
+ Mon Aug 29 15:43:50 CEST 2011 +

+
+ +
Le lundi 29 août 2011 à 13:47 +0200, Michael Scherer a écrit :
+> Le lundi 29 août 2011 à 08:02 +0200, D.Morgan a écrit :
+> > On Mon, Aug 29, 2011 at 6:21 AM, Funda Wang <fundawang at gmail.com> wrote:
+> > > Hello,
+> > >
+> > > It looks like our BS is becoming hungry to eat built packages:
+> > > Submitted       User    Package Target  Media   Status  Build time
+> > > 18 hours ago    wally   libcanberra-0.28-3.mga2 cauldron        core/release            uploaded        15215
+> > > days
+> > > 23 hours ago    fwang   gnome-python-extras-2.25.3-27.mga2      cauldron        core/release            uploaded        15215
+> > > days
+> > > 1 day ago       fwang   libnotify-0.7.4-1.mga2  cauldron        core/release            partial
+> > >
+> > > Could somebody give a look at the issue? And I think BS is much slower
+> > > than the past. In the past, most packages were built succesfully
+> > > within less than 5 minutes, but now > 10 minutes.
+> > >
+> > > Thanks.
+> > >
+> > 
+> > I don't recall seeing such issues on the BS before maybe misc can have an idea
+> > and, we only have one node for the moment ( ecosse is disabled ) this
+> > explain why it is slower.
+> 
+> After looking at the problem, I suspect it could be linked to texmf.
+> Each time iurt install it, the process stop.  
+> 
+> Yet, I have no more idea, and couldn't investigate further for now.
+
+Boklm found the problem, it was urpmi segfaulting.
+
+We remove the chroot, and thing seems to be ok now again.
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007650.html b/zarb-ml/mageia-dev/2011-August/007650.html new file mode 100644 index 000000000..0ec705f34 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007650.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ Funda Wang + fundawang at gmail.com +
+ Mon Aug 29 16:36:51 CEST 2011 +

+
+ +
2011/8/29 Michael Scherer <misc at zarb.org>:
+> After looking at the problem, I suspect it could be linked to texmf.
+> Each time iurt install it, the process stop.
+Will updating texlive help? It seems Mandriva's texlive packages are
+currently well-maintained.
+
+>
+> Yet, I have no more idea, and couldn't investigate further for now.
+> --
+> Michael Scherer
+>
+>
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007651.html b/zarb-ml/mageia-dev/2011-August/007651.html new file mode 100644 index 000000000..c419ea69b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007651.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ D.Morgan + dmorganec at gmail.com +
+ Mon Aug 29 16:38:17 CEST 2011 +

+
+ +
On Mon, Aug 29, 2011 at 4:36 PM, Funda Wang <fundawang at gmail.com> wrote:
+> 2011/8/29 Michael Scherer <misc at zarb.org>:
+>> After looking at the problem, I suspect it could be linked to texmf.
+>> Each time iurt install it, the process stop.
+> Will updating texlive help? It seems Mandriva's texlive packages are
+> currently well-maintained.
+
+this is on my todo for this week.  maybe tomorow.
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007652.html b/zarb-ml/mageia-dev/2011-August/007652.html new file mode 100644 index 000000000..57f63313d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007652.html @@ -0,0 +1,139 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Aug 29 17:06:19 CEST 2011 +

+
+ +
On Mon, 29 Aug 2011, Michael Scherer wrote:
+
+> Le lundi 29 août 2011 à 13:47 +0200, Michael Scherer a écrit :
+> > Le lundi 29 août 2011 à 08:02 +0200, D.Morgan a écrit :
+> > > On Mon, Aug 29, 2011 at 6:21 AM, Funda Wang <fundawang at gmail.com> wrote:
+> > > > Hello,
+> > > >
+> > > > It looks like our BS is becoming hungry to eat built packages:
+> > > > Submitted       User    Package Target  Media   Status  Build time
+> > > > 18 hours ago    wally   libcanberra-0.28-3.mga2 cauldron        core/release            uploaded        15215
+> > > > days
+> > > > 23 hours ago    fwang   gnome-python-extras-2.25.3-27.mga2      cauldron        core/release            uploaded        15215
+> > > > days
+> > > > 1 day ago       fwang   libnotify-0.7.4-1.mga2  cauldron        core/release            partial
+> > > >
+> > > > Could somebody give a look at the issue? And I think BS is much slower
+> > > > than the past. In the past, most packages were built succesfully
+> > > > within less than 5 minutes, but now > 10 minutes.
+> > > >
+> > > > Thanks.
+> > > >
+> > > 
+> > > I don't recall seeing such issues on the BS before maybe misc can have an idea
+> > > and, we only have one node for the moment ( ecosse is disabled ) this
+> > > explain why it is slower.
+> > 
+> > After looking at the problem, I suspect it could be linked to texmf.
+> > Each time iurt install it, the process stop.  
+> > 
+> > Yet, I have no more idea, and couldn't investigate further for now.
+> 
+> Boklm found the problem, it was urpmi segfaulting.
+> 
+> We remove the chroot, and thing seems to be ok now again.
+
+But we probably still have the problem, as segfaults seems to be
+happenning not all the time.
+
+After succesfully reproducing the error using the old chroot and running
+urpmi several times, the backtrace :
+
+#0  0xf7405b29 in _int_malloc () from /lib/i686/libc.so.6
+#1  0xf7408177 in malloc () from /lib/i686/libc.so.6
+#2  0xf6eadfa8 in __os_malloc (env=0xb442db8, size=4149199776, storep=0xffbbf5cc) at ../os/os_alloc.c:253
+#3  0xf6eac47c in __memp_sync_int (env=0xb442db8, dbmfp=0xb893130, trickle_max=0, flags=8, wrote_totalp=0x0, interruptedp=0x0)
+    at ../mp/mp_sync.c:294
+#4  0xf6eacfaf in __memp_fsync (dbmfp=0xb893130) at ../mp/mp_sync.c:202
+#5  0xf6e3cdf9 in __db_sync (dbp=0xb8963e8) at ../db/db_am.c:706
+#6  0xf6e3aa68 in __db_refresh (dbp=0xb8963e8, txn=0x0, flags=0, deferred_closep=0xffbbf6fc, reuse=0) at ../db/db.c:819
+#7  0xf6e3adc5 in __db_close (dbp=0xb8963e8, txn=0x0, flags=0) at ../db/db.c:695
+#8  0xf6e52a38 in __db_close_pp (dbp=0xb8963e8, flags=0) at ../db/db_iface.c:253
+#9  0xf72fec45 in db3close (dbi=0xb893030, flags=0) at backend/db3.c:494
+#10 0xf73071c6 in dbiClose (db=0xb2b6950) at ../lib/rpmdb_internal.h:453
+#11 rpmdbClose (db=0xb2b6950) at rpmdb.c:852
+#12 0xf73379d6 in rpmtsCloseDB (ts=0xb231b20) at rpmts.c:64
+#13 0xf7337a48 in rpmtsFree (ts=0xb231b20) at rpmts.c:567
+#14 0xf736c7a1 in XS_URPM__DB_DESTROY (my_perl=0x8d42008, cv=0x8e2d420) at URPM.xs:2794
+#15 0xf765867d in Perl_pp_entersub (my_perl=0x8d42008) at pp_hot.c:3046
+#16 0xf75e1a0e in Perl_call_sv (my_perl=0x8d42008, sv=0x8e2d420, flags=45) at perl.c:2647
+#17 0xf765f21c in S_curse (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6346
+#18 Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6077
+#19 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb009b48) at sv.c:6478
+#20 0xf760c46c in Perl_cv_undef (my_perl=0x8d42008, cv=0xb09a140) at pad.c:381
+#21 0xf765f604 in Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb13c088) at sv.c:6118
+#22 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb13c088) at sv.c:6478
+#23 0xf76477bc in Perl_hv_free_ent (my_perl=0x8d42008, hv=0x93f01f8, entry=0xb0313c8) at hv.c:1486
+#24 0xf7647aa4 in S_hfreeentries (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1803
+#25 0xf764c09b in Perl_hv_clear (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1559
+#26 0xf76893e5 in Perl_leave_scope (my_perl=0x8d42008, base=79) at scope.c:911
+#27 0xf7689463 in Perl_pop_scope (my_perl=0x8d42008) at scope.c:110
+#28 0xf7656c28 in Perl_pp_leavesub (my_perl=0x8d42008) at pp_hot.c:2626
+#29 0xf764f078 in Perl_runops_standard (my_perl=0x8d42008) at run.c:41
+#30 0xf75e7e59 in S_run_body (my_perl=0x8d42008) at perl.c:2345
+#31 perl_run (my_perl=0x8d42008) at perl.c:2268
+#32 0x08048c0e in main (argc=4, argv=0xffbbff94, env=0xffbbffa8) at perlmain.c:120
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007653.html b/zarb-ml/mageia-dev/2011-August/007653.html new file mode 100644 index 000000000..c43c16dff --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007653.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Aug 29 17:39:05 CEST 2011 +

+
+ +
On Mon, 29 Aug 2011, Funda Wang wrote:
+
+> 2011/8/29 Michael Scherer <misc at zarb.org>:
+> > After looking at the problem, I suspect it could be linked to texmf.
+> > Each time iurt install it, the process stop.
+> Will updating texlive help? It seems Mandriva's texlive packages are
+> currently well-maintained.
+
+According to the backtrace, it looks like a problem in perl, rpm or db.
+
+Perl has been updated recently, with this change :
+http://svnweb.mageia.org/packages/cauldron/perl/current/SPECS/perl.spec?r1=135776&r2=135775&pathrev=135776
+
+Could it be related to this ?
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007654.html b/zarb-ml/mageia-dev/2011-August/007654.html new file mode 100644 index 000000000..455784616 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007654.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Tiny cosmetic fixes + + + + + + + + + +

[Mageia-dev] Tiny cosmetic fixes

+ Remco Rijnders + remco at webconquest.com +
+ Mon Aug 29 18:38:30 CEST 2011 +

+
+ +
Hi all,
+
+The topic came up what to do with small cosmetic fixes in packages which 
+are part of the official release. See for instance the following bug 
+report: https://bugs.mageia.org/show_bug.cgi?id=1784
+
+Should we push these things as an update (and spending GB's of bandwidth 
+for all the upgrades) or leave them as is (and thereby perhaps annoying 
+the eyeballs of the users affected?)
+
+Any thoughts?
+
+Thanks,
+
+Remco
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 836 bytes
+Desc: Digital signature
+URL: </pipermail/mageia-dev/attachments/20110829/01dc2902/attachment.asc>
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007655.html b/zarb-ml/mageia-dev/2011-August/007655.html new file mode 100644 index 000000000..a7392dac1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007655.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ Funda Wang + fundawang at gmail.com +
+ Mon Aug 29 19:45:06 CEST 2011 +

+
+ +
Anyway, I've split out texlive deps out of gtk-doc, so normal gnome
+packages will be faster when building.
+
+2011/8/29 Funda Wang <fundawang at gmail.com>:
+> 2011/8/29 Michael Scherer <misc at zarb.org>:
+>> After looking at the problem, I suspect it could be linked to texmf.
+>> Each time iurt install it, the process stop.
+> Will updating texlive help? It seems Mandriva's texlive packages are
+> currently well-maintained.
+>
+>>
+>> Yet, I have no more idea, and couldn't investigate further for now.
+>> --
+>> Michael Scherer
+>>
+>>
+>
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007656.html b/zarb-ml/mageia-dev/2011-August/007656.html new file mode 100644 index 000000000..fabd22276 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007656.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] Tiny cosmetic fixes + + + + + + + + + +

[Mageia-dev] Tiny cosmetic fixes

+ Michael Scherer + misc at zarb.org +
+ Mon Aug 29 21:09:05 CEST 2011 +

+
+ +
Le lundi 29 août 2011 à 18:38 +0200, Remco Rijnders a écrit :
+> Hi all,
+> 
+> The topic came up what to do with small cosmetic fixes in packages which 
+> are part of the official release. See for instance the following bug 
+> report: https://bugs.mageia.org/show_bug.cgi?id=1784
+> 
+> Should we push these things as an update (and spending GB's of bandwidth 
+> for all the upgrades) or leave them as is (and thereby perhaps annoying 
+> the eyeballs of the users affected?)
+> 
+> Any thoughts?
+
+If someone is willing to do the work, yes, but I would rather see that
+as being a lower priority task ( even if we have no way to rate that or
+to note that somewhere ).
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007657.html b/zarb-ml/mageia-dev/2011-August/007657.html new file mode 100644 index 000000000..56d14fc5f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007657.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Tiny cosmetic fixes + + + + + + + + + +

[Mageia-dev] Tiny cosmetic fixes

+ andre999 + andre999.mga at laposte.net +
+ Mon Aug 29 21:18:47 CEST 2011 +

+
+ +
Remco Rijnders a écrit :
+> Hi all,
+>
+> The topic came up what to do with small cosmetic fixes in packages which
+> are part of the official release. See for instance the following bug
+> report: https://bugs.mageia.org/show_bug.cgi?id=1784
+>
+> Should we push these things as an update (and spending GB's of bandwidth
+> for all the upgrades) or leave them as is (and thereby perhaps annoying
+> the eyeballs of the users affected?)
+>
+> Any thoughts?
+>
+> Thanks,
+>
+> Remco
+
+Since such cases are
+(1) trivial in terms of risk (in this case an incorrect translation), with no 
+functional effect on other packages, and
+(2) correct esthetically negative problems for the users affected (in this case 
+german-language users of the package in question)
+
+it seems most appropriate to
+(1) have a minimal QA for the change, and
+(2) push the package with a low (lowest) priority
+
+That way, we don't (significantly) impact the build system, and we don't leave 
+users with up to 9 months of (minor) dysfunction.
+
+-- 
+André
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007658.html b/zarb-ml/mageia-dev/2011-August/007658.html new file mode 100644 index 000000000..d6c14610e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007658.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] Fw: The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] Fw: The Hydra Nature of the horde-* packages

+ nicolas vigier + boklm at mars-attacks.org +
+ Mon Aug 29 22:06:05 CEST 2011 +

+
+ +
On Sun, 28 Aug 2011, Jani Välimaa wrote:
+
+> 2011/8/28 Thomas Spuhler <thomas at btspuhler.com>:
+> > Why did you rebuild these? They have been obsoleted in i586 with php-pear-
+> > Horde packages with mostly the same name.
+> >
+> 
+> Shouldn't we remove the old and obsoleted pkgs from SVN (or move them
+> to old/) to prevent what just happened?
+
+Yes. They can be moved to svn+ssh://svn.mageia.org/svn/packages/obsolete.
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007659.html b/zarb-ml/mageia-dev/2011-August/007659.html new file mode 100644 index 000000000..91c081c09 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007659.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] Tiny cosmetic fixes + + + + + + + + + +

[Mageia-dev] Tiny cosmetic fixes

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Mon Aug 29 23:27:49 CEST 2011 +

+
+ +
On Mon, 29 Aug 2011 15:18:47 -0400, andre999 <andre999.mga at laposte.net> wrote:
+
+> it seems most appropriate to
+> (1) have a minimal QA for the change, and
+> (2) push the package with a low (lowest) priority
+
+Agreed.  As long as qa knows it's a cosmetic change, we'll primarily be
+checking that the update installs cleanly (not blocked by bug 2317),
+and minimal functionality tests.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007660.html b/zarb-ml/mageia-dev/2011-August/007660.html new file mode 100644 index 000000000..4a3dbce54 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007660.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] Fw: The Hydra Nature of the horde-* packages + + + + + + + + + +

[Mageia-dev] Fw: The Hydra Nature of the horde-* packages

+ D.Morgan + dmorganec at gmail.com +
+ Tue Aug 30 00:41:24 CEST 2011 +

+
+ +
On Mon, Aug 29, 2011 at 10:06 PM, nicolas vigier <boklm at mars-attacks.org> wrote:
+> On Sun, 28 Aug 2011, Jani Välimaa wrote:
+>
+>> 2011/8/28 Thomas Spuhler <thomas at btspuhler.com>:
+>> > Why did you rebuild these? They have been obsoleted in i586 with php-pear-
+>> > Horde packages with mostly the same name.
+>> >
+>>
+>> Shouldn't we remove the old and obsoleted pkgs from SVN (or move them
+>> to old/) to prevent what just happened?
+>
+> Yes. They can be moved to svn+ssh://svn.mageia.org/svn/packages/obsolete.
+>
+>
+
+do mgarepo look in svn+ssh://svn.mageia.org/svn/packages/obsolete
+before an import or not yet ?
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007661.html b/zarb-ml/mageia-dev/2011-August/007661.html new file mode 100644 index 000000000..77ff9fe27 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007661.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch? + + + + + + + + + +

[Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch?

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Aug 30 00:22:14 CEST 2011 +

+
+ +
As most of you may have noticed,
+
+we already needed to update Firefox for Mageia 1, as Mozilla EOL'ed older
+firefox releases with each new one. For thunderbird the situation is a bit
+different, in a short summary:
+
+Thunderbird 6 has been released, and EOL'ed Thunderbird 5, available for Cauldron.
+ From now there will be a new major release approx. every 6 weeks, similar to 
+Firefox.
+
+Thunderbird 3.1.2, next security release from the 3.1 branch, and available
+in updates_testing for Mageia 1. Upstream says it will support 3.1 branch
+in parallel to latest stable as longas the discussion about Mozilla Enterprise
+goes on, but no exact timeframe nor an estimate.
+
+
+Please see the following links:
+https://bugs.mageia.org/show_bug.cgi?id=2088
+https://mail.mozilla.org/pipermail/tb-enterprise/2011-August/000123.html
+https://wiki.mozilla.org/Releases
+http://people.mozilla.org/~mbanner2/tbdevspecifics/
+https://wiki.mozilla.org/Thunderbird/Enterprise
+
+After all we need a decision how to proceed. So what's your opinion?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007662.html b/zarb-ml/mageia-dev/2011-August/007662.html new file mode 100644 index 000000000..4de0cd030 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007662.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch? + + + + + + + + + +

[Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch?

+ nicolas vigier + boklm at mars-attacks.org +
+ Tue Aug 30 01:15:24 CEST 2011 +

+
+ +
On Tue, 30 Aug 2011, Florian Hubold wrote:
+
+>
+> After all we need a decision how to proceed. So what's your opinion?
+
+Decision on what ?
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007663.html b/zarb-ml/mageia-dev/2011-August/007663.html new file mode 100644 index 000000000..10d31c2ad --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007663.html @@ -0,0 +1,88 @@ + + + + [Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch? + + + + + + + + + +

[Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch?

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Aug 30 01:38:09 CEST 2011 +

+
+ +
Am 30.08.2011 01:15, schrieb nicolas vigier:
+> On Tue, 30 Aug 2011, Florian Hubold wrote:
+>
+>> After all we need a decision how to proceed. So what's your opinion?
+> Decision on what ?
+>
+>
+On the subject ^^ isn't that obvious?
+
+thunderbird update for mageia 1: update to 6.0 or  go with 3.1 branch?
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007664.html b/zarb-ml/mageia-dev/2011-August/007664.html new file mode 100644 index 000000000..9a548df3b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007664.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch? + + + + + + + + + +

[Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch?

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Tue Aug 30 03:28:40 CEST 2011 +

+
+ +
On Mon, 29 Aug 2011 18:22:14 -0400, Florian Hubold <doktor5000 at arcor.de> wrote:
+
+> After all we need a decision how to proceed. So what's your opinion?
+
+I'd like to see 3.* releases go to updates, and 6 and following, to
+backports, with only the latest version kept there.
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007665.html b/zarb-ml/mageia-dev/2011-August/007665.html new file mode 100644 index 000000000..26bb3f0d5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007665.html @@ -0,0 +1,218 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Zé + mmodem00 at gmail.com +
+ Tue Aug 30 04:21:12 CEST 2011 +

+
+ +
2011/8/29 John Balcaen <mikala at mageia.org>:
+> 2011/8/29  <root at mageia.org>:
+>> Revision 135989 Author ze Date 2011-08-29 08:09:56 +0200 (Mon, 29 Aug 2011)
+>>
+>> Log Message
+>>
+>> - cmake its already builrequires by kde-macros
+>> - this way we dont force building strictly  with OpenJDK
+>> - remove clean section (done by default)
+>> - simple way to list dirs
+>> - set requires in devel package to release like hapens for restant packages
+>>
+>> Modified Paths
+>>
+>> cauldron/soprano/current/SPECS/soprano.spec
+>>
+>> Modified: cauldron/soprano/current/SPECS/soprano.spec
+>> ===================================================================
+>> --- cauldron/soprano/current/SPECS/soprano.spec       2011-08-29 05:21:36 UTC (rev
+>> 135988)
+>> +++ cauldron/soprano/current/SPECS/soprano.spec       2011-08-29 06:09:56 UTC (rev
+> [...]
+>>
+>>  %if %with_java
+>> -BuildRequires: java-rpmbuild
+>> +BuildRequires: java-devel
+>>  BuildRequires: chrpath
+>>  %endif
+> This is stupid.
+>
+>>  Conflicts: soprano-devel < 4:2.6.51-2
+>>  Suggests: soprano-plugin-virtuoso = %{epoch}:%version
+>>
+>> @@ -55,8 +52,8 @@
+>>  %defattr(-,root,root)
+>>  %_bindir/sopranocmd
+>>  %_bindir/sopranod
+>> -%dir %_datadir/soprano
+>> -%_datadir/soprano/rules
+>> +%dir %_datadir/soprano/
+>
+> I guess i forgot the the purpose of %dir so could you explain me the difference
+> between %dir %datadir/soprano & %dir %datadir/soprano/ ?
+>
+> [...]
+>
+>> -Provides: libsoprano-devel = %{epoch}:%version-%release
+>> -Requires: %libsoprano = %{epoch}:%version-%release
+>> -Requires: %libsopranoclient = %{epoch}:%version-%release
+>> -Requires: %libsopranoserver = %{epoch}:%version-%release
+>> -Requires: %libsopranoindex = %{epoch}:%version-%release
+>> -Requires: %name = %{epoch}:%version-%release
+>> -Requires: %{name}-plugin-virtuoso = %{epoch}:%version-%release
+>> -Requires: %{name}-plugin-redland = %{epoch}:%version-%release
+>> +Provides: libsoprano-devel = %{epoch}:%version
+>> +Requires: %libsoprano = %{epoch}:%version
+>> +Requires: %libsopranoclient = %{epoch}:%version
+>> +Requires: %libsopranoserver = %{epoch}:%version
+>> +Requires: %libsopranoindex = %{epoch}:%version
+>> +Requires: %name = %{epoch}:%version
+>> +Requires: %{name}-plugin-virtuoso = %{epoch}:%version
+>> +Requires: %{name}-plugin-redland = %{epoch}:%version
+> It's quite different of what you wrote in the description...
+> Here you set the requires to %version & not to %release...
+> Also it's quite different how we create requires on library packages
+> on other kde's related packages (since we're using
+> %epoch:%version-%release)
+> but since you already talk with yourself for this change i guess you
+> can surely share the reason for this change.
+>
+> Well i don't care anymore i guess..
+
+Yes the commit coment was incorrect, what i wanted to say was this:
+- set requires in devel package to version like hapens for restant packages
+
+Since all soprano packages have requires to version (except the devel
+package), i just put the devel requires also to version, that way we
+had soprano requires only to version.
+See if we were really acting as a team then i would replade restant
+soprano packages to have requires to release instead changing then to
+version, but you with dmorgan have put me simply apart, so how could
+you expect me to do things other way if you with dmorgan have simply
+alienated me.
+
+You were also who started doing all by own way, you didnt discuss with
+me anychanges, for example the changes you made in wiki.
+For example you add severall items to Golds section without discussing
+any, they should be first added as proposals so that could be first
+discussed in a meeing.
+But for you theres no kde team, since you just do what it pleases you.
+But now you should be even more pleased since now dmorgan in the kde
+packaging policy wiki page have put that now in a PENDING status.
+
+I know very well from where comes all that dmorgan animosityagainst
+me, mem and dmorgan is the past have already had divergencies, so let
+you know that this simply dodnt appear out of the blue, there are a
+history regarding dmorgan and me.
+
+Before dmorgan appear we were going ok, of course we had some
+discussions but thats normal, but its not normal that without any
+proper reason dmorgan did talked to me with some "tone" and
+"aggressiveness".
+
+You even said that i would be happy if you left Mageia, and like i
+answered in other thread you were too far from the truth, you are a
+person that are always contributing, that put much effort to help
+Mageia, and no one in his perfect mind would think was good to put
+away some person with those capabilities.
+
+Some of my latest commits were correct and simple (for eexamplein
+kdelibs4), and they were reverted by dmorgan based in a rule that he
+created, and that rule was simply put by him, without any discusion,
+no one were asked about and i never agreed with it, he simply said
+"and now i take my sysadmin hat..." and did it.
+
+So from that point what would be the purpose to discuss any with you
+since no one can diverge from you, when that happens dmorgan appears
+and "takes his sysadmin hat..." and rises his tone saying i cant do
+this or that.
+Seamsn now you and dmorgan own kde.
+
+Your behaviour has changed mainly from the day that misc attacked me
+without knowing all facts, so from that point all that was being done
+as team SIMPLY didsappeared, and you didnt even said nothing about
+what dmorgan did, saying that my commits should be reviewed all by
+you, that is abusive, and if remember correctly untill that day we act
+as a team, and you be havior from that changed and severall times you
+rised your tone just like that for almost nothing.
+
+I always wanted that we could all could get along with each other, of
+course we would have some discussions (thats normal, and its from
+discussions that development grows), and from that we would reach
+agreements and consensus about what to do or follow.
+
+I think if we continued as a team without dmorgan interventions we
+would continue in the right path for Mageia grow and stability.
+
+And again i appeal that we can that we could have a meeting so that
+all could be discussed and defined, so that now we should act as a
+whole without any frictions.
+Like i satated im not here to fight or bash no one, but to act as a
+part of a whole.
+
+Yesterday i was about to remove me completly from Mageia, since i dont
+want to be in a place where someone can have abusice behaviours and no
+appears to regulate that sittuation.
+Mikala mayve this was your wish, since what have been happening its
+far from a community behaviour and you may see that im very different
+from Fwang, some that you have referred severall tmes that he changes
+things without discussing any, thing that i did used to do as a team,
+but my latest commit was something i did to see at what point things
+would go, and again i can see dmorgan can do everything he wants like
+now put me as a pending status regarding the kde team.
+
+-- 
+Zé
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007666.html b/zarb-ml/mageia-dev/2011-August/007666.html new file mode 100644 index 000000000..29474a571 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007666.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Zé + mmodem00 at gmail.com +
+ Tue Aug 30 04:33:44 CEST 2011 +

+
+ +
2011/8/30 Zé <mmodem00 at gmail.com>:
+>>>  %if %with_java
+>>> -BuildRequires: java-rpmbuild
+>>> +BuildRequires: java-devel
+>>>  BuildRequires: chrpath
+>>>  %endif
+>> This is stupid.
+
+The problem was that i didnt saw the part in the end about the
+problems of the GCJ/Jamvm alternatives.
+So this i imediatly reverted.
+
+>>>  Conflicts: soprano-devel < 4:2.6.51-2
+>>>  Suggests: soprano-plugin-virtuoso = %{epoch}:%version
+>>>
+>>> @@ -55,8 +52,8 @@
+>>>  %defattr(-,root,root)
+>>>  %_bindir/sopranocmd
+>>>  %_bindir/sopranod
+>>> -%dir %_datadir/soprano
+>>> -%_datadir/soprano/rules
+>>> +%dir %_datadir/soprano/
+>>
+>> I guess i forgot the the purpose of %dir so could you explain me the difference
+>> between %dir %datadir/soprano & %dir %datadir/soprano/ ?
+
+You didnt paste it complectly, but if is a dir could be better to have
+the / in the end to have it diferentiated:
+so the correct diff is:
+
+-%dir %_datadir/soprano
+-%_datadir/soprano/rules
++%dir %_datadir/soprano/
++%_datadir/soprano/rules/
+
+this way no one thinks that %_datadir/soprano/rules/ is a file,
+like you had %_datadir/soprano/rules  that can lead some to think its a file
+
+
+-- 
+Zé
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007667.html b/zarb-ml/mageia-dev/2011-August/007667.html new file mode 100644 index 000000000..c02a142b8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007667.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch? + + + + + + + + + +

[Mageia-dev] thunderbird update for mageia 1: update to 6.0 or go with 3.1 branch?

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 30 09:04:12 CEST 2011 +

+
+ +
'Twas brillig, and David W. Hodgins at 30/08/11 02:28 did gyre and gimble:
+> On Mon, 29 Aug 2011 18:22:14 -0400, Florian Hubold <doktor5000 at arcor.de>
+> wrote:
+> 
+>> After all we need a decision how to proceed. So what's your opinion?
+> 
+> I'd like to see 3.* releases go to updates, and 6 and following, to
+> backports, with only the latest version kept there.
+
+I think this is the best of both worlds.
+
+Col
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007668.html b/zarb-ml/mageia-dev/2011-August/007668.html new file mode 100644 index 000000000..77d90a897 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007668.html @@ -0,0 +1,120 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 30 10:50:36 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 03:33 +0100, Zé a écrit :
+> 2011/8/30 Zé <mmodem00 at gmail.com>:
+> >>>  %if %with_java
+> >>> -BuildRequires: java-rpmbuild
+> >>> +BuildRequires: java-devel
+> >>>  BuildRequires: chrpath
+> >>>  %endif
+> >> This is stupid.
+> 
+> The problem was that i didnt saw the part in the end about the
+> problems of the GCJ/Jamvm alternatives.
+> So this i imediatly reverted.
+> 
+> >>>  Conflicts: soprano-devel < 4:2.6.51-2
+> >>>  Suggests: soprano-plugin-virtuoso = %{epoch}:%version
+> >>>
+> >>> @@ -55,8 +52,8 @@
+> >>>  %defattr(-,root,root)
+> >>>  %_bindir/sopranocmd
+> >>>  %_bindir/sopranod
+> >>> -%dir %_datadir/soprano
+> >>> -%_datadir/soprano/rules
+> >>> +%dir %_datadir/soprano/
+> >>
+> >> I guess i forgot the the purpose of %dir so could you explain me the difference
+> >> between %dir %datadir/soprano & %dir %datadir/soprano/ ?
+> 
+> You didnt paste it complectly, but if is a dir could be better to have
+> the / in the end to have it diferentiated:
+> so the correct diff is:
+> 
+> -%dir %_datadir/soprano
+> -%_datadir/soprano/rules
+> +%dir %_datadir/soprano/
+> +%_datadir/soprano/rules/
+> 
+> this way no one thinks that %_datadir/soprano/rules/ is a file,
+> like you had %_datadir/soprano/rules  that can lead some to think its a file
+
+If you add %dir, then it seems pretty obvious that's a directory. 
+
+In fact, %dir is just a indication, since it applies without trouble on
+files ( according to my tests )
+
+
+I think you do not realize that's the kind of gratuitous changes that
+make people react badly to what you do, especially if you act like "here
+is my favorite style and let's apply it because that's the good one
+(tm)". 
+
+People are very attached to their own style, and changing it silently
+and gratuitously, ( like you did when you wrote a style guide on the
+wiki before discussing ) is something that will not make you win any
+friends. 
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007669.html b/zarb-ml/mageia-dev/2011-August/007669.html new file mode 100644 index 000000000..6ca38724c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007669.html @@ -0,0 +1,116 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ John Balcaen + mikala at mageia.org +
+ Tue Aug 30 12:04:36 CEST 2011 +

+
+ +
2011/8/29 Zé <mmodem00 at gmail.com>:
+> 2011/8/30 Zé <mmodem00 at gmail.com>:
+>>>>  %if %with_java
+>>>> -BuildRequires: java-rpmbuild
+>>>> +BuildRequires: java-devel
+>>>>  BuildRequires: chrpath
+>>>>  %endif
+>>> This is stupid.
+>
+> The problem was that i didnt saw the part in the end about the
+> problems of the GCJ/Jamvm alternatives.
+> So this i imediatly reverted.
+
+Sick...
+
+
+>
+>>>>  Conflicts: soprano-devel < 4:2.6.51-2
+>>>>  Suggests: soprano-plugin-virtuoso = %{epoch}:%version
+>>>>
+>>>> @@ -55,8 +52,8 @@
+>>>>  %defattr(-,root,root)
+>>>>  %_bindir/sopranocmd
+>>>>  %_bindir/sopranod
+>>>> -%dir %_datadir/soprano
+>>>> -%_datadir/soprano/rules
+>>>> +%dir %_datadir/soprano/
+>>>
+>>> I guess i forgot the the purpose of %dir so could you explain me the difference
+>>> between %dir %datadir/soprano & %dir %datadir/soprano/ ?
+>
+> You didnt paste it complectly, but if is a dir could be better to have
+> the / in the end to have it diferentiated:
+> so the correct diff is:
+>
+> -%dir %_datadir/soprano
+> -%_datadir/soprano/rules
+> +%dir %_datadir/soprano/
+> +%_datadir/soprano/rules/
+>
+> this way no one thinks that %_datadir/soprano/rules/ is a file,
+> like you had %_datadir/soprano/rules  that can lead some to think its a file
+So %dir before is useless ?
+Because from what i read here (
+http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html
+which is what you're always referring for)
+%dir is something quite explicit ...
+the example is even more explicit.
+So again you're changing something because *you* have the thruth and
+that we're wrong...
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007670.html b/zarb-ml/mageia-dev/2011-August/007670.html new file mode 100644 index 000000000..e68b46cb3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007670.html @@ -0,0 +1,248 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ John Balcaen + mikala at mageia.org +
+ Tue Aug 30 12:56:22 CEST 2011 +

+
+ +
2011/8/29 Zé <mmodem00 at gmail.com>:
+
+>> [...]
+>
+> Yes the commit coment was incorrect, what i wanted to say was this:
+> - set requires in devel package to version like hapens for restant packages
+>
+> Since all soprano packages have requires to version (except the devel
+> package), i just put the devel requires also to version, that way we
+> had soprano requires only to version.
+> See if we were really acting as a team then i would replade restant
+> soprano packages to have requires to release instead changing then to
+> version, but you with dmorgan have put me simply apart, so how could
+> you expect me to do things other way if you with dmorgan have simply
+> alienated me.
+
+Because it's to difficult to ask before doing changes ?
+
+> You were also who started doing all by own way, you didnt discuss with
+> me anychanges, for example the changes you made in wiki.
+> For example you add severall items to Golds section without discussing
+> any, they should be first added as proposals so that could be first
+> discussed in a meeing.
+
+Because thoses changes/proposal where *already* decided *before* you even
+come to KDE, i simply wrote them down.
+Of course that does not mean that we won't change the goal after, it is not like
+it was written in the stone... it's a *wiki*...
+
+> But for you theres no kde team, since you just do what it pleases you.
+> But now you should be even more pleased since now dmorgan in the kde
+> packaging policy wiki page have put that now in a PENDING status.
+> I know very well from where comes all that dmorgan animosityagainst
+> me, mem and dmorgan is the past have already had divergencies, so let
+> you know that this simply dodnt appear out of the blue, there are a
+> history regarding dmorgan and me.
+
+I don't care at all about animosity between you and dmorgan, stricly no...
+
+> Before dmorgan appear we were going ok, of course we had some
+> discussions but thats normal, but its not normal that without any
+> proper reason dmorgan did talked to me with some "tone" and
+> "aggressiveness".
+
+You should double check how you're talking on irc before saying that.
+
+> You even said that i would be happy if you left Mageia, and like i
+> answered in other thread you were too far from the truth, you are a
+> person that are always contributing, that put much effort to help
+> Mageia, and no one in his perfect mind would think was good to put
+> away some person with those capabilities.
+>
+> Some of my latest commits were correct and simple (for eexamplein
+> kdelibs4), and they were reverted by dmorgan based in a rule that he
+> created, and that rule was simply put by him, without any discusion,
+> no one were asked about and i never agreed with it, he simply said
+> "and now i take my sysadmin hat..." and did it.
+>
+> So from that point what would be the purpose to discuss any with you
+> since no one can diverge from you, when that happens dmorgan appears
+> and "takes his sysadmin hat..." and rises his tone saying i cant do
+> this or that.
+> Seamsn now you and dmorgan own kde.
+
+Ok so maybe you can stop a little bit your paranoïa...
+I asked dmorgan to reverse your previous commit because you did not ask
+anything neither show us a commit when you were supposed to do as i told
+you before but i guess you forgot this one (i did not do it personally because
+i'm was quite buzy but i guess i should have done it...)
+Here with your previous change i take the time to comment & ask for explanation
+because you again did not ask & decided what was better from *your*
+point of view.
+
+> Your behaviour has changed mainly from the day that misc attacked me
+> without knowing all facts, so from that point all that was being done
+> as team SIMPLY didsappeared, and you didnt even said nothing about
+> what dmorgan did, saying that my commits should be reviewed all by
+> you, that is abusive, and if remember correctly untill that day we act
+> as a team, and you be havior from that changed and severall times you
+> rised your tone just like that for almost nothing.
+
+I'm sorry but my behaviour did not change at all... It's just because
+i had enough with
+your style aka « i'm going to propose something and if you're not
+agree i'll apply it anyway
+because i'm the older packager, i know how to do things etc etc ...»
+or « i'm going to commit
+some changes which is not important from my point of view so it's not
+for other » or « i'm going
+to commit something and *ask* after about this »
+
+You probably think that i was agree with you simply because i was
+agree with *some* of
+your suggestions that's all...
+
+I really don't remember also how we act as a team since you did not
+take your part of the job:
+i asked you to do a simple thing on the wiki ( add the members of the
+kde team on a specific
+ wiki page)  & suddendly you start changing without asking the
+kde_policy_packaging wiki page
+
+I'm still waiting for your commit in soft regarding iaora_kde since June 12th...
+You're not doing correctly your job & then you complain that we're not
+acting as a team ?
+Also maybe you can start helping on bug fixing on mageia like for
+example Luc is doing ?
+
+I asked you to work on digikam2 initially but we spent too much time
+talking about libs package because
+you suddendly wanted to obsolete some kde libs because they were part
+of digikam SC and i was forced to
+ask neoclust & Gilles about this since you were not agree with me
+about the lib packaging because you had
+a better idea... and when we finally reached an agreement and you were
+supposed to provide a spec quite soon
+nothing happens..
+
+
+> I always wanted that we could all could get along with each other, of
+> course we would have some discussions (thats normal, and its from
+> discussions that development grows), and from that we would reach
+> agreements and consensus about what to do or follow.
+
+What with discussion if you're simply does not care about my opinion ?
+In fact you simply want to have a « leader » hat status ?
+
+> I think if we continued as a team without dmorgan interventions we
+> would continue in the right path for Mageia grow and stability.
+
+I would better say that it would be better *without* you until you're
+okay to discuss your changes
+before commiting them or *even* better as i said in a previous private
+email *TEST THEM* locally
+by building them in a iurt chroot (& yes i already sent you the
+documentation i used to create my
+iurt repository locally) instead of commiting & fixing build errors by
+submitting it in the BS.
+So in summary please don't target anyone else when you're the culprit
+with your attitude.
+Again that does not mean that all your commits are wrong but sometimes
+you changed the behavior
+simply because you think it's better, for example recently you add a
+patch on kdeutils (
+http://svnweb.mageia.org/packages/cauldron/kdeutils4/current/SPECS/kdeutils4.spec?r1=128724&r2=134478
+) to remove  a simple rm -rf in a spec.
+Is it wise to patch (& maintain a patch because i'm not sure you
+submitted it upstream) when we can simply remove thoses files in the
+spec ?
+Did we dicuss about this ? no because you probably think it's a better
+solution & it's a minor thing..
+
+
+
+> And again i appeal that we can that we could have a meeting so that
+> all could be discussed and defined, so that now we should act as a
+> whole without any frictions.
+> Like i satated im not here to fight or bash no one, but to act as a
+> part of a whole.
+
+I'm really doubt about that point since from what i see so far because
+you're not
+following your own words..
+
+> Yesterday i was about to remove me completly from Mageia, since i dont
+> want to be in a place where someone can have abusice behaviours and no
+> appears to regulate that sittuation.
+> Mikala mayve this was your wish, since what have been happening its
+> far from a community behaviour and you may see that im very different
+> from Fwang, some that you have referred severall tmes that he changes
+> things without discussing any, thing that i did used to do as a team,
+> but my latest commit was something i did to see at what point things
+> would go, and again i can see dmorgan can do everything he wants like
+> now put me as a pending status regarding the kde team.
+
+Well on that point i'm quite agree with dmorgan.
+Maybe you should really learn to work/integrate with the way we work...
+Maybe you should act more like luc who he's sending a review of his changes
+before commiting anything & waiting for an answer even if he's more than a good
+packager (& also a programmer by the way) but i guess he's probably biased since
+he used to work with kde reviewboard...
+
+
+-- 
+Balcaen John
+Jabber-id: mikala at jabber.littleboboy.net
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007671.html b/zarb-ml/mageia-dev/2011-August/007671.html new file mode 100644 index 000000000..85fb40d12 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007671.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 30 14:46:09 CEST 2011 +

+
+ +
Hi,
+
+Just for reference, I've update to x11-server locally. I've thus
+migrated the patches and such, so no need for it to be done again, just
+ping me!
+
+As for submitting it, I've only tested the intel, synaptics and evdev
+drivers (working fine as I type).
+
+I'm happy to submit things, but this will require rebuilds of quite a
+lot of packages and will likely cause some issues with proprietary
+drivers too.
+
+Let me know what peoples general feelings are.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007672.html b/zarb-ml/mageia-dev/2011-August/007672.html new file mode 100644 index 000000000..ff9f47c50 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007672.html @@ -0,0 +1,97 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 30 14:58:50 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 13:46 +0100, Colin Guthrie a écrit :
+> Hi,
+> 
+> Just for reference, I've update to x11-server locally. I've thus
+> migrated the patches and such, so no need for it to be done again, just
+> ping me!
+> 
+> As for submitting it, I've only tested the intel, synaptics and evdev
+> drivers (working fine as I type).
+> 
+> I'm happy to submit things, but this will require rebuilds of quite a
+> lot of packages and will likely cause some issues with proprietary
+> drivers too.
+
+Death to nvidia blob,
+
+( ie, submit now )
+
+-- 
+Michael Scherer
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007673.html b/zarb-ml/mageia-dev/2011-August/007673.html new file mode 100644 index 000000000..7c3b72ee5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007673.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Aug 30 15:47:42 CEST 2011 +

+
+ +
Am 30.08.2011 12:56, schrieb John Balcaen:
+> 2011/8/29 Zé<mmodem00 at gmail.com>:
+>
+>
+Guys, could you please chill down a bit?
+Seems this whole problem is about miscommunication
+and also about wrong attitude. Could you please discuss
+this first in private one-on-one, and if this is not sufficient
+then contact someone else to help you or in the worst
+case, contact the Council if you don't get this conflict solved?
+
+On topic: I think that John is the maintainer and does a pretty
+good job at it. So he should have the last word, and if he can't
+be convinced it's a good change than that's his decision.
+
+But a good portion of the problem would be non-existent if
+Zé would have discussed his proposals or issues with current
+packaging/packagers BEFOREHAND, from what i understand.
+
+
+Kind Regards
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007674.html b/zarb-ml/mageia-dev/2011-August/007674.html new file mode 100644 index 000000000..5570ad0ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007674.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 30 15:57:42 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 15:47 +0200, Florian Hubold a écrit :
+> Am 30.08.2011 12:56, schrieb John Balcaen:
+> > 2011/8/29 Zé<mmodem00 at gmail.com>:
+> >
+> >
+> Guys, could you please chill down a bit?
+> Seems this whole problem is about miscommunication
+> and also about wrong attitude. Could you please discuss
+> this first in private one-on-one, and if this is not sufficient
+> then contact someone else to help you or in the worst
+> case, contact the Council if you don't get this conflict solved?
+
+They did discuss in private chat, and also contacted someone to step and
+help. 
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007675.html b/zarb-ml/mageia-dev/2011-August/007675.html new file mode 100644 index 000000000..1344f72fb --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007675.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Florian Hubold + doktor5000 at arcor.de +
+ Tue Aug 30 16:05:02 CEST 2011 +

+
+ +
Am 30.08.2011 15:57, schrieb Michael Scherer:
+> Le mardi 30 août 2011 à 15:47 +0200, Florian Hubold a écrit :
+>> Am 30.08.2011 12:56, schrieb John Balcaen:
+>>> 2011/8/29 Zé<mmodem00 at gmail.com>:
+>>>
+>>>
+>> Guys, could you please chill down a bit?
+>> Seems this whole problem is about miscommunication
+>> and also about wrong attitude. Could you please discuss
+>> this first in private one-on-one, and if this is not sufficient
+>> then contact someone else to help you or in the worst
+>> case, contact the Council if you don't get this conflict solved?
+> They did discuss in private chat, and also contacted someone to step and
+> help.
+>
+>
+Well an open discussion on a public mailing list raises awareness
+on the conflict, but will it help in solving it? IMHO not. So what now?
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007676.html b/zarb-ml/mageia-dev/2011-August/007676.html new file mode 100644 index 000000000..2ad395abc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007676.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 30 16:14:09 CEST 2011 +

+
+ +
On 30 August 2011 14:58, Michael Scherer <misc at zarb.org> wrote:
+>> Just for reference, I've update to x11-server locally. I've thus
+>> migrated the patches and such, so no need for it to be done again, just
+>> ping me!
+>>
+>> As for submitting it, I've only tested the intel, synaptics and evdev
+>> drivers (working fine as I type).
+>>
+>> I'm happy to submit things, but this will require rebuilds of quite a
+>> lot of packages and will likely cause some issues with proprietary
+>> drivers too.
+>
+> Death to nvidia blob,
+>
+> ( ie, submit now )
+
+err I've refrained to update to 1.11.0 b/c of that, waitint to know
+if nvidia/amd will be supporting the new ABI.
+as ubuntu isn't swithcing to 1.11.0, I fear AMD won't support
+the new ABI...
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007677.html b/zarb-ml/mageia-dev/2011-August/007677.html new file mode 100644 index 000000000..41fbe774a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007677.html @@ -0,0 +1,71 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 30 16:18:48 CEST 2011 +

+
+ +
On 30 August 2011 16:05, Florian Hubold <doktor5000 at arcor.de> wrote:
+> Well an open discussion on a public mailing list raises awareness
+> on the conflict, but will it help in solving it? IMHO not. So what now?
+
+Well, there's one packager that was causing problems on mdv
+and now he has came to mga, problems happen again...
+
+I was under impression that Zé would be under mentoring?
+Has that be stoped?
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007678.html b/zarb-ml/mageia-dev/2011-August/007678.html new file mode 100644 index 000000000..f8bade93e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007678.html @@ -0,0 +1,113 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Tue Aug 30 16:34:29 CEST 2011 +

+
+ +
'Twas brillig, and Thierry Vignaud at 30/08/11 15:14 did gyre and gimble:
+> On 30 August 2011 14:58, Michael Scherer <misc at zarb.org> wrote:
+>>> Just for reference, I've update to x11-server locally. I've thus
+>>> migrated the patches and such, so no need for it to be done again, just
+>>> ping me!
+>>>
+>>> As for submitting it, I've only tested the intel, synaptics and evdev
+>>> drivers (working fine as I type).
+>>>
+>>> I'm happy to submit things, but this will require rebuilds of quite a
+>>> lot of packages and will likely cause some issues with proprietary
+>>> drivers too.
+>>
+>> Death to nvidia blob,
+>>
+>> ( ie, submit now )
+> 
+> err I've refrained to update to 1.11.0 b/c of that, waitint to know
+> if nvidia/amd will be supporting the new ABI.
+> as ubuntu isn't swithcing to 1.11.0, I fear AMD won't support
+> the new ABI...
+
+That was my primary concern :s
+
+That said, I've got hellish problems on intel for some months now and am
+upgrading my own xserver to see if it helps... it seems better so far
+but much too early to tell.
+
+I'll hold off pushing it until there is more solid consensus.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007679.html b/zarb-ml/mageia-dev/2011-August/007679.html new file mode 100644 index 000000000..84a75daa7 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007679.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 30 16:37:48 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 16:18 +0200, Thierry Vignaud a écrit :
+> On 30 August 2011 16:05, Florian Hubold <doktor5000 at arcor.de> wrote:
+> > Well an open discussion on a public mailing list raises awareness
+> > on the conflict, but will it help in solving it? IMHO not. So what now?
+> 
+> Well, there's one packager that was causing problems on mdv
+> and now he has came to mga, problems happen again...
+> 
+> I was under impression that Zé would be under mentoring?
+> Has that be stoped?
+
+When we opened the svn, we said that every people with a full packager
+account at mandriva could have one on our, since they already did the
+training part at Mandriva. 
+
+There was no reason to treat ze differently from you and me on this
+regard. 
+
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007680.html b/zarb-ml/mageia-dev/2011-August/007680.html new file mode 100644 index 000000000..d8fbd09c6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007680.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 30 16:48:15 CEST 2011 +

+
+ +
On 30 August 2011 16:37, Michael Scherer <misc at zarb.org> wrote:
+>> > Well an open discussion on a public mailing list raises awareness
+>> > on the conflict, but will it help in solving it? IMHO not. So what now?
+>>
+>> Well, there's one packager that was causing problems on mdv
+>> and now he has came to mga, problems happen again...
+>>
+>> I was under impression that Zé would be under mentoring?
+>> Has that be stoped?
+>
+> When we opened the svn, we said that every people with a full packager
+> account at mandriva could have one on our, since they already did the
+> training part at Mandriva.
+>
+> There was no reason to treat ze differently from you and me on this
+> regard.
+
+Weren't you mentoring him?
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007681.html b/zarb-ml/mageia-dev/2011-August/007681.html new file mode 100644 index 000000000..7dfd9bc37 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007681.html @@ -0,0 +1,102 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Michael Scherer + misc at zarb.org +
+ Tue Aug 30 16:51:27 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 16:14 +0200, Thierry Vignaud a écrit :
+> On 30 August 2011 14:58, Michael Scherer <misc at zarb.org> wrote:
+> >> Just for reference, I've update to x11-server locally. I've thus
+> >> migrated the patches and such, so no need for it to be done again, just
+> >> ping me!
+> >>
+> >> As for submitting it, I've only tested the intel, synaptics and evdev
+> >> drivers (working fine as I type).
+> >>
+> >> I'm happy to submit things, but this will require rebuilds of quite a
+> >> lot of packages and will likely cause some issues with proprietary
+> >> drivers too.
+> >
+> > Death to nvidia blob,
+> >
+> > ( ie, submit now )
+> 
+> err I've refrained to update to 1.11.0 b/c of that, waitint to know
+> if nvidia/amd will be supporting the new ABI.
+
+They will. The question is not "if", but "when". 
+
+And not pushing a new version is not gonna make this appear sooner.
+
+Also, not pushing the new version is likely decrease the quality of the
+xorg server, since there will be less tests done, ( or rather tests done
+later ). 
+
+This is also sending the wrong signal ( ie, "take cards supported by
+proprietary blob and by vendors that are not providing sources, because
+we care more about them rather than those who fully cooperate" ).
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007682.html b/zarb-ml/mageia-dev/2011-August/007682.html new file mode 100644 index 000000000..96a0067d8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007682.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 30 17:01:09 CEST 2011 +

+
+ +
On 30 August 2011 16:51, Michael Scherer <misc at zarb.org> wrote:
+>> err I've refrained to update to 1.11.0 b/c of that, waitint to know
+>> if nvidia/amd will be supporting the new ABI.
+>
+> They will. The question is not "if", but "when".
+>
+> And not pushing a new version is not gonna make this appear sooner.
+>
+> Also, not pushing the new version is likely decrease the quality of the
+> xorg server, since there will be less tests done, ( or rather tests done
+> later ).
+>
+> This is also sending the wrong signal ( ie, "take cards supported by
+> proprietary blob and by vendors that are not providing sources, because
+> we care more about them rather than those who fully cooperate" ).
+
+Well this is what we did back @mdv.
+This is also what I did before doing the 1.7->1.9 update and
+then the 1.9->1.10 update.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007683.html b/zarb-ml/mageia-dev/2011-August/007683.html new file mode 100644 index 000000000..e3162dab9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007683.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Kira + elegant.pegasus at gmail.com +
+ Tue Aug 30 17:05:05 CEST 2011 +

+
+ +
在 Tue, 30 Aug 2011 23:01:09 +0800, Thierry Vignaud  
+<thierry.vignaud at gmail.com>寫道:
+
+> On 30 August 2011 16:51, Michael Scherer <misc at zarb.org> wrote:
+>>> err I've refrained to update to 1.11.0 b/c of that, waitint to know
+>>> if nvidia/amd will be supporting the new ABI.
+>>
+>> They will. The question is not "if", but "when".
+>>
+>> And not pushing a new version is not gonna make this appear sooner.
+>>
+>> Also, not pushing the new version is likely decrease the quality of the
+>> xorg server, since there will be less tests done, ( or rather tests done
+>> later ).
+>>
+>> This is also sending the wrong signal ( ie, "take cards supported by
+>> proprietary blob and by vendors that are not providing sources, because
+>> we care more about them rather than those who fully cooperate" ).
+>
+> Well this is what we did back @mdv.
+> This is also what I did before doing the 1.7->1.9 update and
+> then the 1.9->1.10 update.
+Maybe a better way is to push it into backport testing of cauldron?
+
+Let the people have much faith to test it, don't let it directly gets
+
+into Main_Release/Update.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007684.html b/zarb-ml/mageia-dev/2011-August/007684.html new file mode 100644 index 000000000..33e45f8a6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007684.html @@ -0,0 +1,95 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Thomas Backlund + tmb at mageia.org +
+ Tue Aug 30 17:07:31 CEST 2011 +

+
+ +
Thierry Vignaud skrev 30.8.2011 18:01:
+> On 30 August 2011 16:51, Michael Scherer<misc at zarb.org>  wrote:
+>>> err I've refrained to update to 1.11.0 b/c of that, waitint to know
+>>> if nvidia/amd will be supporting the new ABI.
+>>
+>> They will. The question is not "if", but "when".
+>>
+>> And not pushing a new version is not gonna make this appear sooner.
+>>
+>> Also, not pushing the new version is likely decrease the quality of the
+>> xorg server, since there will be less tests done, ( or rather tests done
+>> later ).
+>>
+>> This is also sending the wrong signal ( ie, "take cards supported by
+>> proprietary blob and by vendors that are not providing sources, because
+>> we care more about them rather than those who fully cooperate" ).
+>
+> Well this is what we did back @mdv.
+> This is also what I did before doing the 1.7->1.9 update and
+> then the 1.9->1.10 update.
+
+Just push x11-server-1.11 to testing so people that want it can start 
+testing it.
+
+As for nVidia, the IgnoreABI works for some... Dont know about Amd...
+
+--
+Thomas
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007685.html b/zarb-ml/mageia-dev/2011-August/007685.html new file mode 100644 index 000000000..a1a7c8322 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007685.html @@ -0,0 +1,108 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Marja van Waes + mvw2011 at xs4all.nl +
+ Tue Aug 30 17:08:20 CEST 2011 +

+
+ +
Op 30-08-11 16:05, Florian Hubold schreef:
+> Am 30.08.2011 15:57, schrieb Michael Scherer:
+>> Le mardi 30 août 2011 à 15:47 +0200, Florian Hubold a écrit :
+>>> Am 30.08.2011 12:56, schrieb John Balcaen:
+>>>> 2011/8/29 Zé<mmodem00 at gmail.com>:
+>>>>
+>>>>
+>>> Guys, could you please chill down a bit?
+>>> Seems this whole problem is about miscommunication
+>>> and also about wrong attitude. Could you please discuss
+>>> this first in private one-on-one, and if this is not sufficient
+>>> then contact someone else to help you or in the worst
+>>> case, contact the Council if you don't get this conflict solved?
+>> They did discuss in private chat, and also contacted someone to step and
+>> help.
+>>
+>>
+> Well an open discussion on a public mailing list raises awareness
+> on the conflict, but will it help in solving it? IMHO not. So what now?
+
+This open discussion might even make things worse, because it arouses 
+people and makes some people want to do something about the situation 
+which, without enough knowledge, is a dangerous thing to do (Alas! I did 
+send mails to Zé and Mikala, trying to help but probably doing the 
+opposite).
+
+At the same time, I think a hidden conflict does more harm than one 
+everybody knows about.
+
+Besides, I think it is good to be aware that conflicts do arise, and 
+even arise in wonderful environments where a lot of nice people are 
+committing themselves to a great purpose without any financial profit in 
+return.
+
+What do you think about making a how-to about how to prevent conflicts? 
+Or a check list for steps to be taken when a conflict does arise? There 
+must be a lot of knowledge on these subjects within the Mageia 
+community. Most of us, if not all, have prevented and solved conflicts, 
+we only need to share our experience and knowledge.
+
+
+
+
+
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007686.html b/zarb-ml/mageia-dev/2011-August/007686.html new file mode 100644 index 000000000..e359c969f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007686.html @@ -0,0 +1,81 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Tue Aug 30 17:14:47 CEST 2011 +

+
+ +
On 30 August 2011 17:07, Thomas Backlund <tmb at mageia.org> wrote:
+>>> This is also sending the wrong signal ( ie, "take cards supported by
+>>> proprietary blob and by vendors that are not providing sources, because
+>>> we care more about them rather than those who fully cooperate" ).
+>>
+>> Well this is what we did back @mdv.
+>> This is also what I did before doing the 1.7->1.9 update and
+>> then the 1.9->1.10 update.
+>
+> Just push x11-server-1.11 to testing so people that want it can start
+> testing it.
+
+Yeah that works fine.
+I did this previously.
+
+ + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007687.html b/zarb-ml/mageia-dev/2011-August/007687.html new file mode 100644 index 000000000..91895e52c --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007687.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Tue Aug 30 17:16:00 CEST 2011 +

+
+ +
On 30.08.2011 17:14, Thierry Vignaud wrote:
+> On 30 August 2011 14:58, Michael Scherer <misc at zarb.org> wrote:
+>>> Just for reference, I've update to x11-server locally. I've thus
+>>> migrated the patches and such, so no need for it to be done again, just
+>>> ping me!
+>>>
+>>> As for submitting it, I've only tested the intel, synaptics and evdev
+>>> drivers (working fine as I type).
+>>>
+>>> I'm happy to submit things, but this will require rebuilds of quite a
+>>> lot of packages and will likely cause some issues with proprietary
+>>> drivers too.
+>>
+>> Death to nvidia blob,
+>>
+>> ( ie, submit now )
+> 
+> err I've refrained to update to 1.11.0 b/c of that, waitint to know
+> if nvidia/amd will be supporting the new ABI.
+> as ubuntu isn't swithcing to 1.11.0, I fear AMD won't support
+> the new ABI...
+
+AFAICS NVIDIA is held back by a forgotten ABI bump in xserver [1] but
+will likely get 1.11 support at least for their main beta driver soon,
+as usual (though they may have to skip supporting vanilla 1.11.0).
+
+AMD will indeed most likely not support 1.11 at least for several months
+as Ubuntu didn't switch to it.
+
+My vote is submission to /testing if it can be reasonably done at this
+point, and submission to /release when NVIDIA releases 1.11 support or
+some time (several weeks?) has passed without a NVIDIA release.
+
+I support not waiting until AMD gets support, however, as it would
+probably hold back upgrade for too long.
+
+(in any case, we'll want to update ldetect-lst at the same time when
+this is pushed to /release to ensure automatic switching to a working
+driver)
+
+[1] http://lists.x.org/archives/xorg-devel/2011-August/024752.html
+
+-- 
+Anssi Hannula
+
+ + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007688.html b/zarb-ml/mageia-dev/2011-August/007688.html new file mode 100644 index 000000000..882e49681 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007688.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Fwd: [RPM] cauldron core/release bind-9.8.0P4-1.mga2 + + + + + + + + + +

[Mageia-dev] Fwd: [RPM] cauldron core/release bind-9.8.0P4-1.mga2

+ Guillaume Rousse + guillomovitch at gmail.com +
+ Tue Aug 30 19:04:40 CEST 2011 +

+
+ +
guillomovitch <guillomovitch> 9.8.0P4-1.mga2:
+[..]
+- no need to build a non-threaded host binary, the threaded version 
+works correctly
+According to https://qa.mandriva.com/show_bug.cgi?id=16855, there was an 
+old issue with i586 build of the 'host' binary. As I only have x86_64 at 
+hand, can someone check and confirm the problem has been fixed upstream ?
+-- 
+BOFH excuse #426:
+
+internet is needed to catch the etherbunny
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007689.html b/zarb-ml/mageia-dev/2011-August/007689.html new file mode 100644 index 000000000..6cb4a83a6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007689.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] Heads up. Expect a lot of browser security updates. + + + + + + + + + +

[Mageia-dev] Heads up. Expect a lot of browser security updates.

+ David W. Hodgins + davidwhodgins at gmail.com +
+ Tue Aug 30 19:58:08 CEST 2011 +

+
+ +
+Due to another fraudulent security certificate, expect every package
+that includes a list of trusted ssl certificates to get updates.
+http://www.h-online.com/security/news/item/Fraudulent-certificate-triggers-blocking-from-software-companies-1333088.html
+
+Regards, Dave Hodgins
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007690.html b/zarb-ml/mageia-dev/2011-August/007690.html new file mode 100644 index 000000000..d80ea964f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007690.html @@ -0,0 +1,115 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ andre999 + andre999.mga at laposte.net +
+ Tue Aug 30 23:23:54 CEST 2011 +

+
+ +
Marja van Waes a écrit :
+> Op 30-08-11 16:05, Florian Hubold schreef:
+>> Am 30.08.2011 15:57, schrieb Michael Scherer:
+>>> Le mardi 30 août 2011 à 15:47 +0200, Florian Hubold a écrit :
+>>>> Am 30.08.2011 12:56, schrieb John Balcaen:
+>>>>> 2011/8/29 Zé<mmodem00 at gmail.com>:
+>>>>>
+>>>>>
+>>>> Guys, could you please chill down a bit?
+>>>> Seems this whole problem is about miscommunication
+>>>> and also about wrong attitude. Could you please discuss
+>>>> this first in private one-on-one, and if this is not sufficient
+>>>> then contact someone else to help you or in the worst
+>>>> case, contact the Council if you don't get this conflict solved?
+>>> They did discuss in private chat, and also contacted someone to step and
+>>> help.
+>>>
+>>>
+>> Well an open discussion on a public mailing list raises awareness
+>> on the conflict, but will it help in solving it? IMHO not. So what now?
+>
+> This open discussion might even make things worse, because it arouses
+> people and makes some people want to do something about the situation
+> which, without enough knowledge, is a dangerous thing to do (Alas! I did
+> send mails to Zé and Mikala, trying to help but probably doing the
+> opposite).
+>
+> At the same time, I think a hidden conflict does more harm than one
+> everybody knows about.
+>
+> Besides, I think it is good to be aware that conflicts do arise, and
+> even arise in wonderful environments where a lot of nice people are
+> committing themselves to a great purpose without any financial profit in
+> return.
+>
+> What do you think about making a how-to about how to prevent conflicts?
+> Or a check list for steps to be taken when a conflict does arise? There
+> must be a lot of knowledge on these subjects within the Mageia
+> community. Most of us, if not all, have prevented and solved conflicts,
+> we only need to share our experience and knowledge.
+
+A how-to (wiki page?) on dealing with conflicts sounds like a good idea.
+Although conflicts are inevitable as you say, I think it is important to avoid 
+them getting personal (in terms of blame), and also that we don't start working 
+at cross purposes.
+At the end of the road, for any group of intelligent people working together, 
+there has to be some compromise for things to advance.
+Which is hopefully what we all want for Mageia.
+
+My 2 cents :)
+-- 
+André
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007691.html b/zarb-ml/mageia-dev/2011-August/007691.html new file mode 100644 index 000000000..851292ef8 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007691.html @@ -0,0 +1,86 @@ + + + + [Mageia-dev] Tonight's meeting + + + + + + + + + +

[Mageia-dev] Tonight's meeting

+ Anne nicolas + ennael at mageia.org +
+ Wed Aug 31 11:29:23 CEST 2011 +

+
+ +
Hi there
+
+We will have our regular meeting on #mageia-dev at 19h UTC. Here are the topics
+:
+
+- Backports policy: final text for 6 coming months (yes we are late :) )
+- Updates managament: think about increasing people implied in process
+(packagers, trainees, triage)
+- triage review
+- QA review
+- mentoring review
+
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007692.html b/zarb-ml/mageia-dev/2011-August/007692.html new file mode 100644 index 000000000..6ebaf34bd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007692.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Drakx installer should install task-gnome, not -minimal + + + + + + + + + +

[Mageia-dev] Drakx installer should install task-gnome, not -minimal

+ Olav Vitters + olav at vitters.nl +
+ Wed Aug 31 11:40:09 CEST 2011 +

+
+ +
When I installed Mageia I noticed (due to missing packages), that it
+installed task-gnome-minimal. This was a bit surprising, because I
+assumed it would install full GNOME as I had selected GNOME during the
+install.
+
+Looking through the drakx sources, it seems for KDE4 it:
+ - during an upgrade, checks if it is installed using task-kde4-minimal
+ - BUT: to upgrade it installs task-kde4 (not the minimal one)
+
+So would appreciate if GNOME had the same working:
+ - for upgrade, check for task-gnome-minimal
+ - to perform upgrade, install task-gnome
+
+This seems a bit inconsistent? Not sure of 'CD' space issues though. I
+used the Mageia network boot image (the 40MB or so one) to install
+Cauldron via the internet. IMO if there are space issues, then only the
+CD version should be optimized for space, not the other options. For a
+network install I just want exactly what I select.
+
+Could this be changed?
+
+For easy references:
+  difference between KDE4 and GNOME:
+  http://svnweb.mageia.org/soft/drakx/trunk/perl-install/install/steps_interactive.pm?revision=832&view=markup#l406
+
+  desktop detection (same):
+  http://svnweb.mageia.org/soft/drakx/trunk/perl-install/pkgs.pm?revision=805&view=markup#l220
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007693.html b/zarb-ml/mageia-dev/2011-August/007693.html new file mode 100644 index 000000000..74f11ef0d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007693.html @@ -0,0 +1,103 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Aug 31 11:54:42 CEST 2011 +

+
+ +
On Mon, 29 Aug 2011, nicolas vigier wrote:
+
+> 
+> After succesfully reproducing the error using the old chroot and running
+> urpmi several times, the backtrace :
+> 
+> #0  0xf7405b29 in _int_malloc () from /lib/i686/libc.so.6
+> #1  0xf7408177 in malloc () from /lib/i686/libc.so.6
+> #2  0xf6eadfa8 in __os_malloc (env=0xb442db8, size=4149199776, storep=0xffbbf5cc) at ../os/os_alloc.c:253
+> #3  0xf6eac47c in __memp_sync_int (env=0xb442db8, dbmfp=0xb893130, trickle_max=0, flags=8, wrote_totalp=0x0, interruptedp=0x0)
+>     at ../mp/mp_sync.c:294
+> #4  0xf6eacfaf in __memp_fsync (dbmfp=0xb893130) at ../mp/mp_sync.c:202
+> #5  0xf6e3cdf9 in __db_sync (dbp=0xb8963e8) at ../db/db_am.c:706
+> #6  0xf6e3aa68 in __db_refresh (dbp=0xb8963e8, txn=0x0, flags=0, deferred_closep=0xffbbf6fc, reuse=0) at ../db/db.c:819
+> #7  0xf6e3adc5 in __db_close (dbp=0xb8963e8, txn=0x0, flags=0) at ../db/db.c:695
+> #8  0xf6e52a38 in __db_close_pp (dbp=0xb8963e8, flags=0) at ../db/db_iface.c:253
+> #9  0xf72fec45 in db3close (dbi=0xb893030, flags=0) at backend/db3.c:494
+> #10 0xf73071c6 in dbiClose (db=0xb2b6950) at ../lib/rpmdb_internal.h:453
+> #11 rpmdbClose (db=0xb2b6950) at rpmdb.c:852
+> #12 0xf73379d6 in rpmtsCloseDB (ts=0xb231b20) at rpmts.c:64
+> #13 0xf7337a48 in rpmtsFree (ts=0xb231b20) at rpmts.c:567
+> #14 0xf736c7a1 in XS_URPM__DB_DESTROY (my_perl=0x8d42008, cv=0x8e2d420) at URPM.xs:2794
+> #15 0xf765867d in Perl_pp_entersub (my_perl=0x8d42008) at pp_hot.c:3046
+> #16 0xf75e1a0e in Perl_call_sv (my_perl=0x8d42008, sv=0x8e2d420, flags=45) at perl.c:2647
+> #17 0xf765f21c in S_curse (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6346
+> #18 Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6077
+> #19 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb009b48) at sv.c:6478
+> #20 0xf760c46c in Perl_cv_undef (my_perl=0x8d42008, cv=0xb09a140) at pad.c:381
+> #21 0xf765f604 in Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb13c088) at sv.c:6118
+> #22 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb13c088) at sv.c:6478
+> #23 0xf76477bc in Perl_hv_free_ent (my_perl=0x8d42008, hv=0x93f01f8, entry=0xb0313c8) at hv.c:1486
+> #24 0xf7647aa4 in S_hfreeentries (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1803
+> #25 0xf764c09b in Perl_hv_clear (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1559
+> #26 0xf76893e5 in Perl_leave_scope (my_perl=0x8d42008, base=79) at scope.c:911
+> #27 0xf7689463 in Perl_pop_scope (my_perl=0x8d42008) at scope.c:110
+> #28 0xf7656c28 in Perl_pp_leavesub (my_perl=0x8d42008) at pp_hot.c:2626
+> #29 0xf764f078 in Perl_runops_standard (my_perl=0x8d42008) at run.c:41
+> #30 0xf75e7e59 in S_run_body (my_perl=0x8d42008) at perl.c:2345
+> #31 perl_run (my_perl=0x8d42008) at perl.c:2268
+> #32 0x08048c0e in main (argc=4, argv=0xffbbff94, env=0xffbbffa8) at perlmain.c:120
+
+And we still have a lot of urpmi segfaults everyday on the build system,
+so we have a problem somewhere.
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007694.html b/zarb-ml/mageia-dev/2011-August/007694.html new file mode 100644 index 000000000..91c41a2fa --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007694.html @@ -0,0 +1,109 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ nicolas vigier + boklm at mars-attacks.org +
+ Wed Aug 31 12:02:11 CEST 2011 +

+
+ +
On Wed, 31 Aug 2011, nicolas vigier wrote:
+
+> On Mon, 29 Aug 2011, nicolas vigier wrote:
+> 
+> > 
+> > After succesfully reproducing the error using the old chroot and running
+> > urpmi several times, the backtrace :
+> > 
+> > #0  0xf7405b29 in _int_malloc () from /lib/i686/libc.so.6
+> > #1  0xf7408177 in malloc () from /lib/i686/libc.so.6
+> > #2  0xf6eadfa8 in __os_malloc (env=0xb442db8, size=4149199776, storep=0xffbbf5cc) at ../os/os_alloc.c:253
+> > #3  0xf6eac47c in __memp_sync_int (env=0xb442db8, dbmfp=0xb893130, trickle_max=0, flags=8, wrote_totalp=0x0, interruptedp=0x0)
+> >     at ../mp/mp_sync.c:294
+> > #4  0xf6eacfaf in __memp_fsync (dbmfp=0xb893130) at ../mp/mp_sync.c:202
+> > #5  0xf6e3cdf9 in __db_sync (dbp=0xb8963e8) at ../db/db_am.c:706
+> > #6  0xf6e3aa68 in __db_refresh (dbp=0xb8963e8, txn=0x0, flags=0, deferred_closep=0xffbbf6fc, reuse=0) at ../db/db.c:819
+> > #7  0xf6e3adc5 in __db_close (dbp=0xb8963e8, txn=0x0, flags=0) at ../db/db.c:695
+> > #8  0xf6e52a38 in __db_close_pp (dbp=0xb8963e8, flags=0) at ../db/db_iface.c:253
+> > #9  0xf72fec45 in db3close (dbi=0xb893030, flags=0) at backend/db3.c:494
+> > #10 0xf73071c6 in dbiClose (db=0xb2b6950) at ../lib/rpmdb_internal.h:453
+> > #11 rpmdbClose (db=0xb2b6950) at rpmdb.c:852
+> > #12 0xf73379d6 in rpmtsCloseDB (ts=0xb231b20) at rpmts.c:64
+> > #13 0xf7337a48 in rpmtsFree (ts=0xb231b20) at rpmts.c:567
+> > #14 0xf736c7a1 in XS_URPM__DB_DESTROY (my_perl=0x8d42008, cv=0x8e2d420) at URPM.xs:2794
+> > #15 0xf765867d in Perl_pp_entersub (my_perl=0x8d42008) at pp_hot.c:3046
+> > #16 0xf75e1a0e in Perl_call_sv (my_perl=0x8d42008, sv=0x8e2d420, flags=45) at perl.c:2647
+> > #17 0xf765f21c in S_curse (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6346
+> > #18 Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6077
+> > #19 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb009b48) at sv.c:6478
+> > #20 0xf760c46c in Perl_cv_undef (my_perl=0x8d42008, cv=0xb09a140) at pad.c:381
+> > #21 0xf765f604 in Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb13c088) at sv.c:6118
+> > #22 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb13c088) at sv.c:6478
+> > #23 0xf76477bc in Perl_hv_free_ent (my_perl=0x8d42008, hv=0x93f01f8, entry=0xb0313c8) at hv.c:1486
+> > #24 0xf7647aa4 in S_hfreeentries (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1803
+> > #25 0xf764c09b in Perl_hv_clear (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1559
+> > #26 0xf76893e5 in Perl_leave_scope (my_perl=0x8d42008, base=79) at scope.c:911
+> > #27 0xf7689463 in Perl_pop_scope (my_perl=0x8d42008) at scope.c:110
+> > #28 0xf7656c28 in Perl_pp_leavesub (my_perl=0x8d42008) at pp_hot.c:2626
+> > #29 0xf764f078 in Perl_runops_standard (my_perl=0x8d42008) at run.c:41
+> > #30 0xf75e7e59 in S_run_body (my_perl=0x8d42008) at perl.c:2345
+> > #31 perl_run (my_perl=0x8d42008) at perl.c:2268
+> > #32 0x08048c0e in main (argc=4, argv=0xffbbff94, env=0xffbbffa8) at perlmain.c:120
+> 
+> And we still have a lot of urpmi segfaults everyday on the build system,
+> so we have a problem somewhere.
+
+First one was on August 26 on x86_64 and 27 on i586 :
+Aug 26 23:28:06 jonund kernel: urpmi[2555] general protection ip:7f4b3601e9d4 sp:7fffc8c41b40 error:0 in libc-2.12.1.so[7f4b35fab000+168000]
+Aug 27 11:02:37 jonund kernel: urpmi[5874]: segfault at 20 ip 00007f79b97618cd sp 00007fffe1b9db10 error 6 in libc-2.12.1.so[7f79b96ed000+168000]
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007695.html b/zarb-ml/mageia-dev/2011-August/007695.html new file mode 100644 index 000000000..41046dccd --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007695.html @@ -0,0 +1,112 @@ + + + + [Mageia-dev] Our BS is about to eat packages? + + + + + + + + + +

[Mageia-dev] Our BS is about to eat packages?

+ Funda Wang + fundawang at gmail.com +
+ Wed Aug 31 12:05:33 CEST 2011 +

+
+ +
Maybe the problem comes from glibc?
+
+2011/8/31 nicolas vigier <boklm at mars-attacks.org>:
+> On Wed, 31 Aug 2011, nicolas vigier wrote:
+>
+>> On Mon, 29 Aug 2011, nicolas vigier wrote:
+>>
+>> >
+>> > After succesfully reproducing the error using the old chroot and running
+>> > urpmi several times, the backtrace :
+>> >
+>> > #0  0xf7405b29 in _int_malloc () from /lib/i686/libc.so.6
+>> > #1  0xf7408177 in malloc () from /lib/i686/libc.so.6
+>> > #2  0xf6eadfa8 in __os_malloc (env=0xb442db8, size=4149199776, storep=0xffbbf5cc) at ../os/os_alloc.c:253
+>> > #3  0xf6eac47c in __memp_sync_int (env=0xb442db8, dbmfp=0xb893130, trickle_max=0, flags=8, wrote_totalp=0x0, interruptedp=0x0)
+>> >     at ../mp/mp_sync.c:294
+>> > #4  0xf6eacfaf in __memp_fsync (dbmfp=0xb893130) at ../mp/mp_sync.c:202
+>> > #5  0xf6e3cdf9 in __db_sync (dbp=0xb8963e8) at ../db/db_am.c:706
+>> > #6  0xf6e3aa68 in __db_refresh (dbp=0xb8963e8, txn=0x0, flags=0, deferred_closep=0xffbbf6fc, reuse=0) at ../db/db.c:819
+>> > #7  0xf6e3adc5 in __db_close (dbp=0xb8963e8, txn=0x0, flags=0) at ../db/db.c:695
+>> > #8  0xf6e52a38 in __db_close_pp (dbp=0xb8963e8, flags=0) at ../db/db_iface.c:253
+>> > #9  0xf72fec45 in db3close (dbi=0xb893030, flags=0) at backend/db3.c:494
+>> > #10 0xf73071c6 in dbiClose (db=0xb2b6950) at ../lib/rpmdb_internal.h:453
+>> > #11 rpmdbClose (db=0xb2b6950) at rpmdb.c:852
+>> > #12 0xf73379d6 in rpmtsCloseDB (ts=0xb231b20) at rpmts.c:64
+>> > #13 0xf7337a48 in rpmtsFree (ts=0xb231b20) at rpmts.c:567
+>> > #14 0xf736c7a1 in XS_URPM__DB_DESTROY (my_perl=0x8d42008, cv=0x8e2d420) at URPM.xs:2794
+>> > #15 0xf765867d in Perl_pp_entersub (my_perl=0x8d42008) at pp_hot.c:3046
+>> > #16 0xf75e1a0e in Perl_call_sv (my_perl=0x8d42008, sv=0x8e2d420, flags=45) at perl.c:2647
+>> > #17 0xf765f21c in S_curse (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6346
+>> > #18 Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb009b48) at sv.c:6077
+>> > #19 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb009b48) at sv.c:6478
+>> > #20 0xf760c46c in Perl_cv_undef (my_perl=0x8d42008, cv=0xb09a140) at pad.c:381
+>> > #21 0xf765f604 in Perl_sv_clear (my_perl=0x8d42008, orig_sv=0xb13c088) at sv.c:6118
+>> > #22 0xf765fa3a in Perl_sv_free2 (my_perl=0x8d42008, sv=0xb13c088) at sv.c:6478
+>> > #23 0xf76477bc in Perl_hv_free_ent (my_perl=0x8d42008, hv=0x93f01f8, entry=0xb0313c8) at hv.c:1486
+>> > #24 0xf7647aa4 in S_hfreeentries (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1803
+>> > #25 0xf764c09b in Perl_hv_clear (my_perl=0x8d42008, hv=0x93f01f8) at hv.c:1559
+>> > #26 0xf76893e5 in Perl_leave_scope (my_perl=0x8d42008, base=79) at scope.c:911
+>> > #27 0xf7689463 in Perl_pop_scope (my_perl=0x8d42008) at scope.c:110
+>> > #28 0xf7656c28 in Perl_pp_leavesub (my_perl=0x8d42008) at pp_hot.c:2626
+>> > #29 0xf764f078 in Perl_runops_standard (my_perl=0x8d42008) at run.c:41
+>> > #30 0xf75e7e59 in S_run_body (my_perl=0x8d42008) at perl.c:2345
+>> > #31 perl_run (my_perl=0x8d42008) at perl.c:2268
+>> > #32 0x08048c0e in main (argc=4, argv=0xffbbff94, env=0xffbbffa8) at perlmain.c:120
+>>
+>> And we still have a lot of urpmi segfaults everyday on the build system,
+>> so we have a problem somewhere.
+>
+> First one was on August 26 on x86_64 and 27 on i586 :
+> Aug 26 23:28:06 jonund kernel: urpmi[2555] general protection ip:7f4b3601e9d4 sp:7fffc8c41b40 error:0 in libc-2.12.1.so[7f4b35fab000+168000]
+> Aug 27 11:02:37 jonund kernel: urpmi[5874]: segfault at 20 ip 00007f79b97618cd sp 00007fffe1b9db10 error 6 in libc-2.12.1.so[7f79b96ed000+168000]
+>
+>
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007696.html b/zarb-ml/mageia-dev/2011-August/007696.html new file mode 100644 index 000000000..62b052311 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007696.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] unsatisfied typelib(GdmGreeter) + + + + + + + + + +

[Mageia-dev] unsatisfied typelib(GdmGreeter)

+ Marja van Waes + mvw2011 at xs4all.nl +
+ Wed Aug 31 13:10:31 CEST 2011 +

+
+ +
Hi,
+
+In cauldron, I get this when updating (as far as can I remember, this 
+wasn't reported in this mailinglist yet and I don't see it in Bugzilla):
+
+[root at LenovoBeneden marja]# LC_ALL=C urpmi --auto-update
+medium "Core Release" is up-to-date
+medium "Core Updates" is up-to-date
+medium "Nonfree Release" is up-to-date
+medium "Nonfree Updates" is up-to-date
+medium "Tainted Release" is up-to-date
+medium "Tainted Updates" is up-to-date
+A requested package cannot be installed:
+gnome-shell-3.1.90-2.mga2.i586 (due to unsatisfied typelib(GdmGreeter))
+Continue installation anyway? (Y/n) n
+[root at LenovoBeneden marja]#
+
+Greetz,
+Marja
+
+
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007697.html b/zarb-ml/mageia-dev/2011-August/007697.html new file mode 100644 index 000000000..652fa77b2 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007697.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] unsatisfied typelib(GdmGreeter) + + + + + + + + + +

[Mageia-dev] unsatisfied typelib(GdmGreeter)

+ Frank Griffin + ftg at roadrunner.com +
+ Wed Aug 31 13:21:37 CEST 2011 +

+
+ +
On 08/31/2011 07:10 AM, Marja van Waes wrote:
+>
+> In cauldron, I get this when updating (as far as can I remember, this 
+> wasn't reported in this mailinglist yet and I don't see it in Bugzilla):
+
+...
+>
+> A requested package cannot be installed:
+> gnome-shell-3.1.90-2.mga2.i586 (due to unsatisfied typelib(GdmGreeter))
+
+I  saw this yesterday too, but unless it persists for days, it's 
+probably just mirror lag, e.g. perhaps gnome-shell made it to the mirror 
+before GDM.  Considering the huge number of packages that showed up 
+yesterday, that wouldn't be surprising.
+
+ + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007698.html b/zarb-ml/mageia-dev/2011-August/007698.html new file mode 100644 index 000000000..4d3df4751 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007698.html @@ -0,0 +1,85 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 31 13:20:51 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 17:14 +0200, Thierry Vignaud a écrit :
+> On 30 August 2011 17:07, Thomas Backlund <tmb at mageia.org> wrote:
+> >>> This is also sending the wrong signal ( ie, "take cards supported by
+> >>> proprietary blob and by vendors that are not providing sources, because
+> >>> we care more about them rather than those who fully cooperate" ).
+> >>
+> >> Well this is what we did back @mdv.
+> >> This is also what I did before doing the 1.7->1.9 update and
+> >> then the 1.9->1.10 update.
+> >
+> > Just push x11-server-1.11 to testing so people that want it can start
+> > testing it.
+> 
+> Yeah that works fine.
+> I did this previously.
+
+And almost no one tested anything in main/testing. 
+See the case with rpm5, see the case with previous xorg at mandriva.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007699.html b/zarb-ml/mageia-dev/2011-August/007699.html new file mode 100644 index 000000000..6acbf3a99 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007699.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] Fwd: [RPM] cauldron core/release bind-9.8.0P4-1.mga2 + + + + + + + + + +

[Mageia-dev] Fwd: [RPM] cauldron core/release bind-9.8.0P4-1.mga2

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 31 13:26:12 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 19:04 +0200, Guillaume Rousse a écrit :
+> guillomovitch <guillomovitch> 9.8.0P4-1.mga2:
+> [..]
+> - no need to build a non-threaded host binary, the threaded version 
+> works correctly
+> According to https://qa.mandriva.com/show_bug.cgi?id=16855, there was an 
+> old issue with i586 build of the 'host' binary. As I only have x86_64 at 
+> hand, can someone check and confirm the problem has been fixed upstream ?
+
+Try to run host -w www.sgi.com on a 32 bits system, using a rebuilded 32
+bits package ?
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007700.html b/zarb-ml/mageia-dev/2011-August/007700.html new file mode 100644 index 000000000..ca9b4ad7e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007700.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 31 13:30:12 CEST 2011 +

+
+ +
Le mardi 30 août 2011 à 16:48 +0200, Thierry Vignaud a écrit :
+> On 30 August 2011 16:37, Michael Scherer <misc at zarb.org> wrote:
+> >> > Well an open discussion on a public mailing list raises awareness
+> >> > on the conflict, but will it help in solving it? IMHO not. So what now?
+> >>
+> >> Well, there's one packager that was causing problems on mdv
+> >> and now he has came to mga, problems happen again...
+> >>
+> >> I was under impression that Zé would be under mentoring?
+> >> Has that be stoped?
+> >
+> > When we opened the svn, we said that every people with a full packager
+> > account at mandriva could have one on our, since they already did the
+> > training part at Mandriva.
+> >
+> > There was no reason to treat ze differently from you and me on this
+> > regard.
+> 
+> Weren't you mentoring him?
+
+I did. I explained how the system worked on a technical level, and that
+was the only thing I add to do, as he knew how to do packages. I am not
+a utterfan of keeping people forever in the apprentice group, but that's
+just me. In any case, I was not here to educate people to behave
+properly in team, but to explain to them how to use the system.
+
+-- 
+Michael Scherer
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007701.html b/zarb-ml/mageia-dev/2011-August/007701.html new file mode 100644 index 000000000..137bbe1b6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007701.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] unsatisfied typelib(GdmGreeter) + + + + + + + + + +

[Mageia-dev] unsatisfied typelib(GdmGreeter)

+ Olav Vitters + olav at vitters.nl +
+ Wed Aug 31 13:35:33 CEST 2011 +

+
+ +
On Wed, Aug 31, 2011 at 07:21:37AM -0400, Frank Griffin wrote:
+> I  saw this yesterday too, but unless it persists for days, it's
+> probably just mirror lag, e.g. perhaps gnome-shell made it to the
+> mirror before GDM.  Considering the huge number of packages that
+> showed up yesterday, that wouldn't be surprising.
+
+Actually the new gnome-shell requires a newer GDM and the (upstream)
+release was delayed by a few days. So basically an upstream issue.
+
+GDM has since been released by upstream, so once the package is updated
+(maybe it has, didn't check yet) the dependency will be solved.
+-- 
+Regards,
+Olav
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007702.html b/zarb-ml/mageia-dev/2011-August/007702.html new file mode 100644 index 000000000..df6f0c3b9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007702.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Fwd: [RPM] cauldron core/release bind-9.8.0P4-1.mga2 + + + + + + + + + +

[Mageia-dev] Fwd: [RPM] cauldron core/release bind-9.8.0P4-1.mga2

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 31 13:59:24 CEST 2011 +

+
+ +
Le mercredi 31 août 2011 à 13:26 +0200, Michael Scherer a écrit :
+> Le mardi 30 août 2011 à 19:04 +0200, Guillaume Rousse a écrit :
+> > guillomovitch <guillomovitch> 9.8.0P4-1.mga2:
+> > [..]
+> > - no need to build a non-threaded host binary, the threaded version 
+> > works correctly
+> > According to https://qa.mandriva.com/show_bug.cgi?id=16855, there was an 
+> > old issue with i586 build of the 'host' binary. As I only have x86_64 at 
+> > hand, can someone check and confirm the problem has been fixed upstream ?
+> 
+> Try to run host -w www.sgi.com on a 32 bits system, using a rebuilded 32
+> bits package ?
+> 
+Work here on a up to date cauldron 32 bits vm.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007703.html b/zarb-ml/mageia-dev/2011-August/007703.html new file mode 100644 index 000000000..266d1d8ab --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007703.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] x11-server 1.11.0 + + + + + + + + + +

[Mageia-dev] x11-server 1.11.0

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 31 14:43:27 CEST 2011 +

+
+ +
On 31 August 2011 13:20, Michael Scherer <misc at zarb.org> wrote:
+> And almost no one tested anything in main/testing.
+> See the case with rpm5, see the case with previous xorg at mandriva.
+
+Well, for X.org I did get reports back which drivers were working or not.
+But I did have to send ping reminders though.
+
+At least, it would enables more people to:
+- test
+- be able to downgrade server & drivers if anything went wrong
+  (wouldn't be possible if x-1.11.0 is put directly in core/release)
+- contribute fixes (tmb helped fixed bogus drivers for 1.10.0)
+
+my 2 cents...
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007704.html b/zarb-ml/mageia-dev/2011-August/007704.html new file mode 100644 index 000000000..8c5094b3f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007704.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] perl-Sys-Mmap package review + + + + + + + + + +

[Mageia-dev] perl-Sys-Mmap package review

+ Barry Jackson + zen25000 at zen.co.uk +
+ Wed Aug 31 15:20:00 CEST 2011 +

+
+ +
Hello,
+Would someone please review the attached src.rpm for the above, with a 
+view to committing it.
+It is required by ZoneMinder which I am packaging - albeit slowly.
+Note my comment in %files section of spec.
+
+I still need a mentor if anyone has a slot (tiny crack would do) ;)
+
+Thanks, Barry (barjac)
+
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: perl-Sys-Mmap-0.16-0.mga1.src.rpm
+Type: application/octet-stream
+Size: 19148 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110831/8357faea/attachment-0001.obj>
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007705.html b/zarb-ml/mageia-dev/2011-August/007705.html new file mode 100644 index 000000000..1ef683511 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007705.html @@ -0,0 +1,101 @@ + + + + [Mageia-dev] unsatisfied typelib(GdmGreeter) + + + + + + + + + +

[Mageia-dev] unsatisfied typelib(GdmGreeter)

+ Colin Guthrie + mageia at colin.guthr.ie +
+ Wed Aug 31 16:17:00 CEST 2011 +

+
+ +
'Twas brillig, and Olav Vitters at 31/08/11 12:35 did gyre and gimble:
+> On Wed, Aug 31, 2011 at 07:21:37AM -0400, Frank Griffin wrote:
+>> I  saw this yesterday too, but unless it persists for days, it's
+>> probably just mirror lag, e.g. perhaps gnome-shell made it to the
+>> mirror before GDM.  Considering the huge number of packages that
+>> showed up yesterday, that wouldn't be surprising.
+> 
+> Actually the new gnome-shell requires a newer GDM and the (upstream)
+> release was delayed by a few days. So basically an upstream issue.
+> 
+> GDM has since been released by upstream, so once the package is updated
+> (maybe it has, didn't check yet) the dependency will be solved.
+
+Yeah it should be OK. It's working fine in my local builds.
+
+The upstream release fo gdm lagged a bit due to some errors in the
+release process which I was able to fix and contribute back upstream,
+but not until very late last night.
+
+Add this to the annoying issue of a missing gobject-introspection build
+require on our gdm package and you got a bit of a delay in the gdm release.
+
+I managed to push it out this morning so it'll take some time before it
+reaches you :)
+
+Have fun.
+
+Col
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007706.html b/zarb-ml/mageia-dev/2011-August/007706.html new file mode 100644 index 000000000..d8642c53d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007706.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] [137207] SILENT: new file ./SOURCES/jetty-01-depmap.xml + + + + + + + + + +

[Mageia-dev] [137207] SILENT: new file ./SOURCES/jetty-01-depmap.xml

+ Olav Vitters + olav at vitters.nl +
+ Wed Aug 31 16:51:28 CEST 2011 +

+
+ +
On Wed, Aug 31, 2011 at 03:45:43PM +0200, root at mageia.org wrote:
+> Author:   gil
+
+> SILENT: new file ./SOURCES/jetty-01-depmap.xml
+> 
+> Added Paths:
+> -----------
+>     cauldron/jetty/current/SOURCES/jetty-01-depmap.xml
+> 
+> Added: cauldron/jetty/current/SOURCES/jetty-01-depmap.xml
+> ===================================================================
+> --- cauldron/jetty/current/SOURCES/jetty-01-depmap.xml	                        (rev 0)
+> +++ cauldron/jetty/current/SOURCES/jetty-01-depmap.xml	2011-08-31 13:45:43 UTC (rev 137207)
+> @@ -0,0 +1,198 @@
+> +<dependencies>
+> +<dependency>
+
+This shouldn't have been put in SVN but in the special "bin" SVN right?
+
+-- 
+Regards,
+Olav
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007707.html b/zarb-ml/mageia-dev/2011-August/007707.html new file mode 100644 index 000000000..83c72b4b9 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007707.html @@ -0,0 +1,87 @@ + + + + [Mageia-dev] [137207] SILENT: new file ./SOURCES/jetty-01-depmap.xml + + + + + + + + + +

[Mageia-dev] [137207] SILENT: new file ./SOURCES/jetty-01-depmap.xml

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 31 17:50:08 CEST 2011 +

+
+ +
Le mercredi 31 août 2011 à 16:51 +0200, Olav Vitters a écrit :
+> On Wed, Aug 31, 2011 at 03:45:43PM +0200, root at mageia.org wrote:
+> > Author:   gil
+> 
+> > SILENT: new file ./SOURCES/jetty-01-depmap.xml
+> > 
+> > Added Paths:
+> > -----------
+> >     cauldron/jetty/current/SOURCES/jetty-01-depmap.xml
+> > 
+> > Added: cauldron/jetty/current/SOURCES/jetty-01-depmap.xml
+> > ===================================================================
+> > --- cauldron/jetty/current/SOURCES/jetty-01-depmap.xml	                        (rev 0)
+> > +++ cauldron/jetty/current/SOURCES/jetty-01-depmap.xml	2011-08-31 13:45:43 UTC (rev 137207)
+> > @@ -0,0 +1,198 @@
+> > +<dependencies>
+> > +<dependency>
+> 
+> This shouldn't have been put in SVN but in the special "bin" SVN right?
+
+Nope, that's a text file. 
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007708.html b/zarb-ml/mageia-dev/2011-August/007708.html new file mode 100644 index 000000000..a3e5b76fc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007708.html @@ -0,0 +1,66 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-mozvoikko-1.10.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-mozvoikko-1.10.0-1.mga2

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 31 18:39:30 CEST 2011 +

+
+ +
On 31 August 2011 18:11, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> Finnish spell-checking extension for Firefox 3 web browser. The
+> spell-checking is provided by the Voikko library.
+
+Really 3 :-) ?
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007709.html b/zarb-ml/mageia-dev/2011-August/007709.html new file mode 100644 index 000000000..a78754dc3 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007709.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] [RPM] cauldron core/release firefox-ext-mozvoikko-1.10.0-1.mga2 + + + + + + + + + +

[Mageia-dev] [RPM] cauldron core/release firefox-ext-mozvoikko-1.10.0-1.mga2

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Wed Aug 31 18:50:31 CEST 2011 +

+
+ +
On 31.08.2011 19:39, Thierry Vignaud wrote:
+> On 31 August 2011 18:11, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+>> Finnish spell-checking extension for Firefox 3 web browser. The
+>> spell-checking is provided by the Voikko library.
+> 
+> Really 3 :-) ?
+
+Oops, I only noticed the 3 in Summary :)
+
+Thanks, fixing.
+
+-- 
+Anssi Hannula
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007710.html b/zarb-ml/mageia-dev/2011-August/007710.html new file mode 100644 index 000000000..2e5566292 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007710.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] [RPM] cauldron nonfree/release kernel-firmware-extra-20110730-2.mga2.nonfree + + + + + + + + + +

[Mageia-dev] [RPM] cauldron nonfree/release kernel-firmware-extra-20110730-2.mga2.nonfree

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 31 20:20:24 CEST 2011 +

+
+ +
On 31 August 2011 20:02, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> ze <ze> 20110730-2.mga2:
+> + Revision: 137308
+> - rebuild
+
+why for?
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007711.html b/zarb-ml/mageia-dev/2011-August/007711.html new file mode 100644 index 000000000..188eff5ee --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007711.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] cauldron core/release rtl8192ce_se_de-0004.0816.2011-1.mga2 + + + + + + + + + +

[Mageia-dev] cauldron core/release rtl8192ce_se_de-0004.0816.2011-1.mga2

+ Thomas Backlund + tmb at mageia.org +
+ Wed Aug 31 21:04:01 CEST 2011 +

+
+ +
31.08.2011 20:40, Mageia Team skrev:
+> Name        : rtl8192ce_se_de              Relocations: (not relocatable)
+> Version     : 0004.0816.2011                    Vendor: Mageia.Org
+> Release     : 1.mga2                        Build Date: Wed Aug 31 19:39:13 2011
+>
+
+Why did you upload this crap ?
+
+You didn't even wait for response on the problems you reported last night :/
+
+This is duplicating code that is already in 3.x series kernels.
+
+When/If upstream kernel code does not work, report it to the 
+linux-wireless ml, so it can get fixed upstream!!
+
+The only time we provide vendor-released stuff it when it's not 
+supported in upstream kernels.
+
+I also told you I'll sync up kernel-firmware-extra to get the updated 
+firmwares provided.
+
+I also told you you cant ship the firmware in the same srpm as the 
+driver as the firmware belongs in nonfree!!
+
+
+This package will be nuked from the mirrors...
+
+--
+Thomas
+
+ + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007712.html b/zarb-ml/mageia-dev/2011-August/007712.html new file mode 100644 index 000000000..e85e0cc5d --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007712.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] [RPM] cauldron nonfree/release kernel-firmware-extra-20110730-2.mga2.nonfree + + + + + + + + + +

[Mageia-dev] [RPM] cauldron nonfree/release kernel-firmware-extra-20110730-2.mga2.nonfree

+ Michael Scherer + misc at zarb.org +
+ Wed Aug 31 21:12:41 CEST 2011 +

+
+ +
Le mercredi 31 août 2011 à 20:20 +0200, Thierry Vignaud a écrit :
+> On 31 August 2011 20:02, Mageia Team <buildsystem-daemon at mageia.org> wrote:
+> > ze <ze> 20110730-2.mga2:
+> > + Revision: 137308
+> > - rebuild
+> 
+> why for?
+
+Because he added a obsoletes on kernel-firmware-extra 
+( http://svnweb.mageia.org/packages/cauldron/rtl8192ce_se_de/current/SPECS/rtl8192ce_se_de.spec?r1=137298&r2=137304 ), and that packages got removed from the mirrors, as usual since we use youri to upload ( ie, around 2006 IIRC ).
+
+
+And yes, we should block upload with just "rebuild", I ponder on having
+a rpmlint rule just for that, not sure if it would be effective.
+-- 
+Michael Scherer
+
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007713.html b/zarb-ml/mageia-dev/2011-August/007713.html new file mode 100644 index 000000000..8c6183699 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007713.html @@ -0,0 +1,282 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Zé + mmodem00 at gmail.com +
+ Wed Aug 31 23:27:26 CEST 2011 +

+
+ +
2011/8/30 John Balcaen <mikala at mageia.org>:
+> 2011/8/29 Zé <mmodem00 at gmail.com>:
+>
+>>> [...]
+>>
+>> Yes the commit coment was incorrect, what i wanted to say was this:
+>> - set requires in devel package to version like hapens for restant packages
+>>
+>> Since all soprano packages have requires to version (except the devel
+>> package), i just put the devel requires also to version, that way we
+>> had soprano requires only to version.
+>> See if we were really acting as a team then i would replade restant
+>> soprano packages to have requires to release instead changing then to
+>> version, but you with dmorgan have put me simply apart, so how could
+>> you expect me to do things other way if you with dmorgan have simply
+>> alienated me.
+>
+> Because it's to difficult to ask before doing changes ?
+
+>From the last things you with dmorgan said and did this was also to
+see to what point you would go.
+
+The changes i made in kdelibs, that binaries in kde are only for
+development so i moved them to devel package and were reverted.
+Like dmorgan said all coomits i do even if were good commits would be
+reverted if not reviewed by you, that was some he just invented and
+that i never agreed.
+And as we agreed, only important changes should be discussed like it
+happened with the improvemenet i was planing to do to Qt.
+
+>> You were also who started doing all by own way, you didnt discuss with
+>> me anychanges, for example the changes you made in wiki.
+>> For example you add severall items to Golds section without discussing
+>> any, they should be first added as proposals so that could be first
+>> discussed in a meeing.
+>
+> Because thoses changes/proposal where *already* decided *before* you even
+> come to KDE, i simply wrote them down.
+> Of course that does not mean that we won't change the goal after, it is not like
+> it was written in the stone... it's a *wiki*...
+
+Thats not quite true, since for example i suggested that the lib
+packages could start being named only with a underscore instead
+dashes, and you acted like that was already decided, seams you were
+the only one who decided.
+
+>> But for you theres no kde team, since you just do what it pleases you.
+>> But now you should be even more pleased since now dmorgan in the kde
+>> packaging policy wiki page have put that now in a PENDING status.
+>> I know very well from where comes all that dmorgan animosityagainst
+>> me, mem and dmorgan is the past have already had divergencies, so let
+>> you know that this simply dodnt appear out of the blue, there are a
+>> history regarding dmorgan and me.
+>
+> I don't care at all about animosity between you and dmorgan, stricly no...
+>
+>> Before dmorgan appear we were going ok, of course we had some
+>> discussions but thats normal, but its not normal that without any
+>> proper reason dmorgan did talked to me with some "tone" and
+>> "aggressiveness".
+>
+> You should double check how you're talking on irc before saying that.
+>
+>> You even said that i would be happy if you left Mageia, and like i
+>> answered in other thread you were too far from the truth, you are a
+>> person that are always contributing, that put much effort to help
+>> Mageia, and no one in his perfect mind would think was good to put
+>> away some person with those capabilities.
+>>
+>> Some of my latest commits were correct and simple (for eexamplein
+>> kdelibs4), and they were reverted by dmorgan based in a rule that he
+>> created, and that rule was simply put by him, without any discusion,
+>> no one were asked about and i never agreed with it, he simply said
+>> "and now i take my sysadmin hat..." and did it.
+>>
+>> So from that point what would be the purpose to discuss any with you
+>> since no one can diverge from you, when that happens dmorgan appears
+>> and "takes his sysadmin hat..." and rises his tone saying i cant do
+>> this or that.
+>> Seamsn now you and dmorgan own kde.
+>
+> Ok so maybe you can stop a little bit your paranoïa...
+> I asked dmorgan to reverse your previous commit because you did not ask
+> anything neither show us a commit when you were supposed to do as i told
+> you before but i guess you forgot this one (i did not do it personally because
+> i'm was quite buzy but i guess i should have done it...)
+> Here with your previous change i take the time to comment & ask for explanation
+> because you again did not ask & decided what was better from *your*
+> point of view.
+
+This i have commented in the begining of this message.
+
+>> Your behaviour has changed mainly from the day that misc attacked me
+>> without knowing all facts, so from that point all that was being done
+>> as team SIMPLY didsappeared, and you didnt even said nothing about
+>> what dmorgan did, saying that my commits should be reviewed all by
+>> you, that is abusive, and if remember correctly untill that day we act
+>> as a team, and you be havior from that changed and severall times you
+>> rised your tone just like that for almost nothing.
+>
+> I'm sorry but my behaviour did not change at all... It's just because
+> i had enough with
+> your style aka « i'm going to propose something and if you're not
+> agree i'll apply it anyway
+> because i'm the older packager, i know how to do things etc etc ...»
+> or « i'm going to commit
+> some changes which is not important from my point of view so it's not
+> for other » or « i'm going
+> to commit something and *ask* after about this »
+>
+> You probably think that i was agree with you simply because i was
+> agree with *some* of
+> your suggestions that's all...
+>
+> I really don't remember also how we act as a team since you did not
+> take your part of the job:
+> i asked you to do a simple thing on the wiki ( add the members of the
+> kde team on a specific
+>  wiki page)  & suddendly you start changing without asking the
+> kde_policy_packaging wiki page
+
+I never acted like kde was mine, there were some commits i made in the
+begining but i remember we did had a conversation and i start
+discussing things, and as we agreeed discussing important things, as
+for the rest i think is preferable to just not comment...
+
+> I'm still waiting for your commit in soft regarding iaora_kde since June 12th...
+> You're not doing correctly your job & then you complain that we're not
+> acting as a team ?
+> Also maybe you can start helping on bug fixing on mageia like for
+> example Luc is doing ?
+>
+> I asked you to work on digikam2 initially but we spent too much time
+> talking about libs package because
+> you suddendly wanted to obsolete some kde libs because they were part
+> of digikam SC and i was forced to
+> ask neoclust & Gilles about this since you were not agree with me
+> about the lib packaging because you had
+> a better idea... and when we finally reached an agreement and you were
+> supposed to provide a spec quite soon
+> nothing happens..
+
+And now you say, as we discussed, so we did in fact discussed things
+and i didnt do any implementation without theres a consense.
+And as i already repleyed in other threads (but again you take things,
+you keep repeating yourself.), at that time i was too much busy with
+my son probems and didnt had time to do nothing, but i remember i did
+told you that.
+
+>
+>> I always wanted that we could all could get along with each other, of
+>> course we would have some discussions (thats normal, and its from
+>> discussions that development grows), and from that we would reach
+>> agreements and consensus about what to do or follow.
+>
+> What with discussion if you're simply does not care about my opinion ?
+> In fact you simply want to have a « leader » hat status ?
+
+And again seams your putting words in my mouth, like i liked you to leave...
+
+>> I think if we continued as a team without dmorgan interventions we
+>> would continue in the right path for Mageia grow and stability.
+>
+> I would better say that it would be better *without* you until you're
+> okay to discuss your changes
+> before commiting them or *even* better as i said in a previous private
+> email *TEST THEM* locally
+> by building them in a iurt chroot (& yes i already sent you the
+> documentation i used to create my
+> iurt repository locally) instead of commiting & fixing build errors by
+> submitting it in the BS.
+
+Yes, i tend to agree that at that time you didnt had others
+contributing or that could have a more active role and that always
+never disagree of your ideas, and all was like you wanted, wrongly or
+not. As i remember for example fixing severall things wrong in qt
+spec, many existing requires(pre) when there wasnt any %pre section.
+
+> So in summary please don't target anyone else when you're the culprit
+> with your attitude.
+> Again that does not mean that all your commits are wrong but sometimes
+> you changed the behavior
+> simply because you think it's better, for example recently you add a
+> patch on kdeutils (
+> http://svnweb.mageia.org/packages/cauldron/kdeutils4/current/SPECS/kdeutils4.spec?r1=128724&r2=134478
+> ) to remove  a simple rm -rf in a spec.
+> Is it wise to patch (& maintain a patch because i'm not sure you
+> submitted it upstream) when we can simply remove thoses files in the
+> spec ?
+
+Yes, thats the correct way to build kdeutils without printer_applet,
+not just removing files, but i think that patch will be submited
+upstream.
+
+> Did we dicuss about this ? no because you probably think it's a better
+> solution & it's a minor thing..
+
+That was already done after you started with that behaviour, but i
+also never see you discussing any change you made.
+Thats true, you never discuss any change, at least i never saw it.
+
+If theres a kde team, you and all kde members should discuss things,
+and maybe reach some agreement about whats really important to
+discuss, if dicuss all or just discuss more important changes, since
+discussing all can also delays development.
+
+>
+>> And again i appeal that we can that we could have a meeting so that
+>> all could be discussed and defined, so that now we should act as a
+>> whole without any frictions.
+>> Like i satated im not here to fight or bash no one, but to act as a
+>> part of a whole.
+>
+> I'm really doubt about that point since from what i see so far because
+> you're not
+> following your own words..
+>
+
+I think this doesnt deserve a real comment.
+
+
+-- 
+Zé
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007714.html b/zarb-ml/mageia-dev/2011-August/007714.html new file mode 100644 index 000000000..696c8a971 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007714.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] [RPM] cauldron nonfree/release kernel-firmware-extra-20110730-2.mga2.nonfree + + + + + + + + + +

[Mageia-dev] [RPM] cauldron nonfree/release kernel-firmware-extra-20110730-2.mga2.nonfree

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Aug 31 23:36:27 CEST 2011 +

+
+ +
On 31 August 2011 21:12, Michael Scherer <misc at zarb.org> wrote:
+>> > ze <ze> 20110730-2.mga2:
+>> > + Revision: 137308
+>> > - rebuild
+>>
+>> why for?
+>
+> Because he added a obsoletes on kernel-firmware-extra
+> ( http://svnweb.mageia.org/packages/cauldron/rtl8192ce_se_de/current/SPECS/rtl8192ce_se_de.spec?r1=137298&r2=137304 ), and that packages got removed from the mirrors, as usual since we use youri to upload ( ie, around 2006 IIRC ).
+>
+>
+> And yes, we should block upload with just "rebuild", I ponder on having
+> a rpmlint rule just for that, not sure if it would be effective.
+
+We're waiting for such a rule for a couple years now :-)
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/007715.html b/zarb-ml/mageia-dev/2011-August/007715.html new file mode 100644 index 000000000..05af9db13 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007715.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] [135989] + + + + + + + + + +

[Mageia-dev] [135989]

+ Zé + mmodem00 at gmail.com +
+ Wed Aug 31 23:45:44 CEST 2011 +

+
+ +
2011/8/30 John Balcaen <mikala at mageia.org>:
+> I'm still waiting for your commit in soft regarding iaora_kde since June 12th...
+> You're not doing correctly your job & then you complain that we're not
+> acting as a team ?
+> Also maybe you can start helping on bug fixing on mageia like for
+> example Luc is doing ?
+
+And this is another you keep repeating that i already did answered,
+but ill repeat:
+
+Iaora its a mandriva project that in wich the source was also imported
+to mageia svn.
+Whats there to update? the mageia iaora project?
+
+But if iaora project imported by dmorgan its not to develop, why just
+keep a copy of the original mandriva iaora project?
+
+There was a new version released in mandriva for some time, so i
+simply submit the new version of iaora in mageia.
+I dont get your point.
+-- 
+Zé
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/008112.html b/zarb-ml/mageia-dev/2011-August/008112.html new file mode 100644 index 000000000..c5f3aebc0 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/008112.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Minimal package number at first install + + + + + + + + + +

[Mageia-dev] Minimal package number at first install

+ Xuo + xuoy at free.fr +
+ Sun Aug 28 10:22:38 CEST 2011 +

+
+ +
Hi,
+
+I've just installed mageia-1 with the minimal number of packages
+(without urpmi) as it is possible to select during install.
+Then the required disk space used is about 660Mb !!
+I am not a specialist, but isn't it possible to have a "real" minimal
+number of packages installed ? For example, FreeNas is about 100Mb large.
+I can give the list of the installed packages but I don't know which
+ones I could remove (if it is possible to remove any of them).
+For me, the minimal list should be :
+
+  * kernel
+  * main commands (ls, mkdir, ...) + rpm (+urpmi for non-specialists !!)
+  * ssh + nfs network
+
+Then I could add all packages I want, one by one.
+
+Regards.
+
+Xuo.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: </pipermail/mageia-dev/attachments/20110828/648406ea/attachment-0001.html>
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/008113.html b/zarb-ml/mageia-dev/2011-August/008113.html new file mode 100644 index 000000000..e20cde9e1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/008113.html @@ -0,0 +1,76 @@ + + + + [Mageia-dev] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM summit at Plumbers 2011

+ Jon Masters + jcm at redhat.com +
+ Mon Aug 29 07:08:32 CEST 2011 +

+
+ +
On Tue, 2011-08-23 at 17:11 +0100, Steve McIntyre wrote:
+
+> UPDATE: we've not had many people confirm interest in this event yet,
+> which is a shame. If you would like to join us for this session,
+> please reply and let me know. If we don't get enough interest by the
+> end of Sunday (28th August), then we'll have to cancel the meeting.
+
+I'm obviously confirming, but I'll repeat that for the record. My
+interests here include helping to lead up Fedora's ARMv7 efforts, but
+also wider ARM platform standardization (boot, device enumeration,
+multi-arch, ABI, kernel consolidation, and many other things).
+
+If there's at least representation from a few of the distros (as it
+seems is the case at this point) then I think it's worthwhile having the
+formal slots. Nothing is lost in so doing. In any case, many discussions
+will take place if we have the opportunity to do so.
+
+Jon.
+
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/008114.html b/zarb-ml/mageia-dev/2011-August/008114.html new file mode 100644 index 000000000..6347cf665 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/008114.html @@ -0,0 +1,94 @@ + + + + [Mageia-dev] ARM summit at Plumbers 2011 + + + + + + + + + +

[Mageia-dev] ARM summit at Plumbers 2011

+ Jeff Law + law at redhat.com +
+ Mon Aug 29 18:22:04 CEST 2011 +

+
+ +
-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+On 08/28/11 22:02, Jon Masters wrote:
+> On Tue, 2011-08-23 at 17:11 +0100, Steve McIntyre wrote:
+> 
+>> UPDATE: we've not had many people confirm interest in this event
+>> yet, which is a shame. If you would like to join us for this
+>> session, please reply and let me know. If we don't get enough
+>> interest by the end of Sunday (28th August), then we'll have to
+>> cancel the meeting.
+> 
+> I'm obviously confirming, but I'll repeat that for the record. My 
+> interests here include helping to lead up Fedora's ARMv7 efforts,
+> but also wider ARM platform standardization (boot, device
+> enumeration, multi-arch, ABI, kernel consolidation, and many other
+> things).
+> 
+> If there's at least representation from a few of the distros (as it 
+> seems is the case at this point) then I think it's worthwhile having
+> the formal slots. Nothing is lost in so doing. In any case, many
+> discussions will take place if we have the opportunity to do so.
+I've certain got an interest in hashing out ARM relative issues from a
+tools standpoint.  So count me in.
+
+jeff
+
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
+
+iQEcBAEBAgAGBQJOW7VaAAoJEBRtltQi2kC74u8IAIJi+BTmyxbyg8fnYm+lMjq5
+K0CKMTpOcDCjZjEOcRx5YrTgOZsEwJKpngvqI82zzbz9vK6Gdw+0HydygaBSZSF7
+wBJGv6mmKrP2/ZUts3c68cQDSoNisfeEEZk2MVCrHqm1RZAWW2vynb8zSBr589kV
+f7WNEDNTZJwvam7DEZa4/ZAhPUfKxTwREl0H0ZK+miiW47vJtrQiZ6C9KJtFcgLN
+Kqo5Jlmtdn2Jmv5s0LXSABtfwRtULqRnTICzZIE8440T4RVDbDI7Sc4jOIy6d31C
+YQcKWOjXD9eYzYkOqeJfbLX5bLlOyjfbqfi8lA+jZbTVldjthOGAsmNR5E2h25Q=
+=mnMM
+-----END PGP SIGNATURE-----
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/2011-August/author.html b/zarb-ml/mageia-dev/2011-August/author.html new file mode 100644 index 000000000..406186883 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/author.html @@ -0,0 +1,2912 @@ + + + + The Mageia-dev August 2011 Archive by author + + + + + +

August 2011 Archives by author

+ +

Starting: Mon Aug 1 00:25:49 CEST 2011
+ Ending: Wed Aug 31 23:45:44 CEST 2011
+ Messages: 573

+

+

+ Last message date: + Wed Aug 31 23:45:44 CEST 2011
+ Archived on: Fri Sep 16 09:51:10 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2011-August/date.html b/zarb-ml/mageia-dev/2011-August/date.html new file mode 100644 index 000000000..020b70ef6 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/date.html @@ -0,0 +1,2912 @@ + + + + The Mageia-dev August 2011 Archive by date + + + + + +

August 2011 Archives by date

+ +

Starting: Mon Aug 1 00:25:49 CEST 2011
+ Ending: Wed Aug 31 23:45:44 CEST 2011
+ Messages: 573

+

+

+ Last message date: + Wed Aug 31 23:45:44 CEST 2011
+ Archived on: Fri Sep 16 09:51:10 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2011-August/index.html b/zarb-ml/mageia-dev/2011-August/index.html new file mode 120000 index 000000000..db4b46f72 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/zarb-ml/mageia-dev/2011-August/subject.html b/zarb-ml/mageia-dev/2011-August/subject.html new file mode 100644 index 000000000..e6dedbc50 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/subject.html @@ -0,0 +1,2912 @@ + + + + The Mageia-dev August 2011 Archive by subject + + + + + +

August 2011 Archives by subject

+ +

Starting: Mon Aug 1 00:25:49 CEST 2011
+ Ending: Wed Aug 31 23:45:44 CEST 2011
+ Messages: 573

+

+

+ Last message date: + Wed Aug 31 23:45:44 CEST 2011
+ Archived on: Fri Sep 16 09:51:10 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/2011-August/thread.html b/zarb-ml/mageia-dev/2011-August/thread.html new file mode 100644 index 000000000..ab7aa041b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/thread.html @@ -0,0 +1,3907 @@ + + + + The Mageia-dev August 2011 Archive by thread + + + + + +

August 2011 Archives by thread

+ +

Starting: Mon Aug 1 00:25:49 CEST 2011
+ Ending: Wed Aug 31 23:45:44 CEST 2011
+ Messages: 573

+

+

+ Last message date: + Wed Aug 31 23:45:44 CEST 2011
+ Archived on: Fri Sep 16 09:51:10 CEST 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + -- cgit v1.2.1